idnits 2.17.1 draft-ietf-avt-rtp-g711wb-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 621. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 632. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 639. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 645. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 28, 2008) is 5840 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-G.711.1' ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Sollaud 3 Internet-Draft France Telecom 4 Intended status: Standards Track April 28, 2008 5 Expires: October 30, 2008 7 RTP Payload Format for ITU-T Recommendation G.711.1 8 draft-ietf-avt-rtp-g711wb-03 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on October 30, 2008. 35 Abstract 37 This document specifies a Real-time Transport Protocol (RTP) payload 38 format to be used for the International Telecommunication Union 39 (ITU-T) G.711.1 audio codec. Two media type registrations are also 40 included. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 3. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . . . 4 47 4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 5 48 4.1. Payload Header . . . . . . . . . . . . . . . . . . . . . . 5 49 4.2. Audio Data . . . . . . . . . . . . . . . . . . . . . . . . 6 50 5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 7 51 5.1. PCMA-WB Media Type Registration . . . . . . . . . . . . . 7 52 5.2. PCMU-WB Media Type Registration . . . . . . . . . . . . . 8 53 5.3. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 9 54 5.3.1. Offer-Answer Model Considerations . . . . . . . . . . 10 55 5.3.2. Declarative SDP Considerations . . . . . . . . . . . . 12 56 6. G.711 Interoperabilty . . . . . . . . . . . . . . . . . . . . 12 57 7. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 12 58 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 59 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 60 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 61 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 62 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 Intellectual Property and Copyright Statements . . . . . . . . . . 15 66 1. Introduction 68 The International Telecommunication Union (ITU-T) Recommendation 69 G.711.1 [ITU-G.711.1] is an embedded wideband extension of the 70 Recommendation G.711 [ITU-G.711] audio codec. This document 71 specifies a payload format for packetization of G.711.1 encoded audio 72 signals into the Real-time Transport Protocol (RTP). 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 2. Background 80 G.711.1 is a G.711 embedded wideband speech and audio coding 81 algorithm operating at 64, 80, and 96 kbps. At 64 kbps, G.711.1 is 82 fully interoperable with G.711. Hence, an efficient deployment in 83 existing G.711 based VoIP infrastructures is foreseen. 85 The codec operates on 5 ms frames, and the default sampling rate is 86 16 kHz. Input and output at 8 kHz are also supported for narrowband 87 modes. 89 The encoder produces an embedded bitstream structured in three layers 90 corresponding to three available bit rates: 64, 80, and 96 kbps. The 91 bitstream can be truncated at the decoder side or by any component of 92 the communication system to adjust "on the fly" the bit rate to the 93 desired value. 95 The following table gives more details on these layers. 97 +-------+------------------------+---------+ 98 | Layer | Description | Bitrate | 99 +-------+------------------------+---------+ 100 | L0 | G.711 compatible | 64 kbps | 101 | L1 | narrowband enhancement | 16 kbps | 102 | L2 | wideband enhancement | 16 kbps | 103 +-------+------------------------+---------+ 105 Table 1: Layers description 107 The combinations of these 3 layers results in the definition of 4 108 modes, as per the following table. 110 +------+----+----+----+------------+---------+ 111 | Mode | L0 | L1 | L2 | Audio band | Bitrate | 112 +------+----+----+----+------------+---------+ 113 | R1 | x | | | narrowband | 64 kbps | 114 | R2a | x | x | | narrowband | 80 kbps | 115 | R2b | x | | x | wideband | 80 kbps | 116 | R3 | x | x | x | wideband | 96 kbps | 117 +------+----+----+----+------------+---------+ 119 Table 2: Modes description 121 3. RTP Header Usage 123 The format of the RTP header is specified in [RFC3550]. The payload 124 format defined in this document uses the fields of the header in a 125 manner consistent with that specification. 127 marker (M): 128 G.711.1 does not define anything specific regarding Discontinuous 129 Transmission (DTX), a.k.a. silence suppression. Codec-independant 130 mechanisms may be used, like the generic comfort noise payload 131 format defined in [RFC3389]. 133 For applications which send either no packets or occasional 134 comfort-noise packets during silence, the first packet of a 135 talkspurt, that is, the first packet after a silence period during 136 which packets have not been transmitted contiguously, SHOULD be 137 distinguished by setting the marker bit in the RTP data header to 138 one. The marker bit in all other packets is zero. The beginning 139 of a talkspurt MAY be used to adjust the playout delay to reflect 140 changing network delays. Applications without silence suppression 141 MUST set the marker bit to zero. 143 payload type (PT): 144 The assignment of an RTP payload type for this packet format is 145 outside the scope of the document, and will not be specified here. 146 It is expected that the RTP profile under which this payload 147 format is being used will assign a payload type for this codec or 148 specify that the payload type is to be bound dynamically (see 149 Section 5.3). 151 timestamp: 152 The RTP timestamp clock frequency is the same as the default 153 sampling frequency: 16 kHz. 155 G.711.1 has also the capability to operate with 8 kHz sampled 156 input/output signals. It does not affect the bitstream, and the 157 decoder does not require a priori knowledge about the sampling 158 rate of the original signal at the input of the encoder. 159 Therefore, depending on the implementation and the audio acoustic 160 capabilities of the devices, the input of the encoder and/or the 161 output of the decoder can be configured at 8 kHz; however, a 16 162 kHz RTP clock rate MUST always be used. 164 The duration of one frame is 5 ms, corresponding to 80 samples at 165 16 kHz. Thus the timestamp is increased by 80 for each 166 consecutive frame. 168 4. Payload Format 170 The complete payload consists of a payload header of 1 octet, 171 followed by one or more consecutive G.711.1 audio frames of the same 172 mode. 174 The mode may change between packets, but not within a packet. 176 4.1. Payload Header 178 The payload header is illustrated below. 180 0 1 2 3 4 5 6 7 181 +-+-+-+-+-+-+-+-+ 182 |0 0 0 0 0| MI | 183 +-+-+-+-+-+-+-+-+ 185 The 5 most significant bits are reserved for further extension and 186 MUST be set to zero. 188 The MI field (3 bits) gives the mode of the following frame(s) as per 189 the table: 191 +------------+--------------+------------+ 192 | Mode Index | G.711.1 mode | Frame size | 193 +------------+--------------+------------+ 194 | 1 | R1 | 40 octets | 195 | 2 | R2a | 50 octets | 196 | 3 | R2b | 50 octets | 197 | 4 | R3 | 60 octets | 198 +------------+--------------+------------+ 200 Table 3: Modes in payload header 202 All other values of MI are reserved for future used and MUST NOT be 203 used. 205 Payloads received with an undefined MI value MUST be discarded. 207 If a restricted mode set has been set up by the signaling (see 208 Section 5), payloads received with a MI value not in this set MUST be 209 discarded. 211 4.2. Audio Data 213 After this payload header, the audio frames are packed in order of 214 time, that is, oldest first. All frames MUST be of the same mode, 215 indicated by the MI field of the payload header. 217 Within a frame, layers are always packed in the same order: L0 then 218 L1 for mode R2a, L0 then L2 for mode R2b, L0 then L1 then L2 for mode 219 R3. This is illustrated bellow. 221 +-------------------------------+ 222 R1 | L0 | 223 +-------------------------------+ 225 +-------------------------------+--------+ 226 R2a | L0 | L1 | 227 +-------------------------------+--------+ 229 +-------------------------------+--------+ 230 R2b | L0 | L2 | 231 +-------------------------------+--------+ 233 +-------------------------------+--------+--------+ 234 R3 | L0 | L1 | L2 | 235 +-------------------------------+--------+--------+ 237 The size of one frame is given by the mode, as per Table 3, and the 238 actual number of frames is easy to infer from the size of the audio 239 data part: 241 nb_frames = (size_of_audio_data) / (size_of_one_frame). 243 Only full frames must be considered. So if there is a remainder to 244 the division above, the corresponding remaining bytes in the received 245 payload MUST be ignored. 247 5. Payload Format Parameters 249 This section defines the parameters that may be used to configure 250 optional features in the G.711.1 RTP transmission. 252 Both A-law and mu-law G.711 are supported in the core layer L0, but 253 there is no interoperability between A-law and mu-law. So two media 254 types with the same parameters will be defined: audio/PCMA-WB for 255 A-law core, and audio/PCMU-WB for mu-law core. This is consistent 256 with the audio/PCMA and audio/PCMU media types separation for G.711 257 audio. 259 The parameters are defined here as part of the media subtype 260 registrations for the G.711.1 codec. A mapping of the parameters 261 into the Session Description Protocol (SDP) [RFC4566] is also 262 provided for those applications that use SDP. In control protocols 263 that do not use MIME or SDP, the media type parameters must be mapped 264 to the appropriate format used with that control protocol. 266 5.1. PCMA-WB Media Type Registration 268 [Note to RFC Editor: Please replace all occurrences of RFC XXXX by 269 the RFC number assigned to this document] 271 This registration is done using the template defined in [RFC4288] and 272 following [RFC4855]. 274 Type name: audio 276 Subtype name: PCMA-WB 278 Required parameters: none 280 Optional parameters: 282 mode-set: restricts the active codec mode set to a subset of all 283 modes. Possible values are a comma-separated list of modes from 284 the set: 1,2,3,4 (see Mode Index in Table 3 of RFC XXXX). The 285 modes are listed in order of preference, first is prefered. If 286 mode-set is specified, frames encoded with modes outside of the 287 subset MUST NOT be sent in any RTP payload. If not present, all 288 codec modes are allowed. 290 ptime: the recommended length of time (in milliseconds) represented 291 by the media in a packet. It should be an integer multiple of 5 292 ms (the frame size). See Section 6 of RFC 4566. 294 maxptime: the maximum length of time (in milliseconds) that can be 295 encapsulated in a packet. It should be an integer multiple of 5 296 ms (the frame size). See Section 6 of RFC 4566. 298 Encoding considerations: This media type is framed and contains 299 binary data; see Section 4.8 of RFC 4288. 301 Security considerations: See Section 8 of RFC XXXX 303 Interoperability considerations: none 305 Published specification: RFC XXXX 307 Applications which use this media type: Audio and video conferencing 308 tools. 310 Additional information: none 312 Person & email address to contact for further information: Aurelien 313 Sollaud, aurelien.sollaud@orange-ftgroup.com 315 Intended usage: COMMON 317 Restrictions on usage: This media type depends on RTP framing, and 318 hence is only defined for transfer via RTP. 320 Author: Aurelien Sollaud 322 Change controller: IETF Audio/Video Transport working group delegated 323 from the IESG 325 5.2. PCMU-WB Media Type Registration 327 This registration is done using the template defined in [RFC4288] and 328 following [RFC4855]. 330 Type name: audio 332 Subtype name: PCMU-WB 334 Required parameters: none 336 Optional parameters: 338 mode-set: restricts the active codec mode set to a subset of all 339 modes. Possible values are a comma-separated list of modes from 340 the set: 1,2,3,4 (see Mode Index in Table 3 of RFC XXXX). The 341 modes are listed in order of preference, first is prefered. If 342 mode-set is specified, frames encoded with modes outside of the 343 subset MUST NOT be sent in any RTP payload. If not present, all 344 codec modes are allowed. 346 ptime: the recommended length of time (in milliseconds) represented 347 by the media in a packet. It should be an integer multiple of 5 348 ms (the frame size). See Section 6 of RFC 4566. 350 maxptime: the maximum length of time (in milliseconds) that can be 351 encapsulated in a packet. It should be an integer multiple of 5 352 ms (the frame size). See Section 6 of RFC 4566. 354 Encoding considerations: This media type is framed and contains 355 binary data; see Section 4.8 of RFC 4288. 357 Security considerations: See Section 8 of RFC XXXX 359 Interoperability considerations: none 361 Published specification: RFC XXXX 363 Applications which use this media type: Audio and video conferencing 364 tools. 366 Additional information: none 368 Person & email address to contact for further information: Aurelien 369 Sollaud, aurelien.sollaud@orange-ftgroup.com 371 Intended usage: COMMON 373 Restrictions on usage: This media type depends on RTP framing, and 374 hence is only defined for transfer via RTP. 376 Author: Aurelien Sollaud 378 Change controller: IETF Audio/Video Transport working group delegated 379 from the IESG 381 5.3. Mapping to SDP Parameters 383 The information carried in the media type specification has a 384 specific mapping to fields in the Session Description Protocol (SDP) 385 [RFC4566], which is commonly used to describe RTP sessions. When SDP 386 is used to specify sessions employing the G.711.1 codec, the mapping 387 is as follows: 389 o The media type ("audio") goes in SDP "m=" as the media name. 391 o The media subtype ("PCMA-WB" or "PCMU-WB") goes in SDP "a=rtpmap" 392 as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 393 16000 for G.711.1. 395 o The parameter "mode-set" goes in the SDP "a=fmtp" attribute by 396 copying it as a "mode-set=" string. 398 o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and 399 "a=maxptime" attributes, respectively. 401 5.3.1. Offer-Answer Model Considerations 403 The following considerations apply when using SDP offer-answer 404 procedures [RFC3264] to negotiate the use of G.711.1 payload in RTP: 406 o Since G.711.1 is an extension of G.711, the offerer SHOULD 407 announce G.711 support in its "m=audio" line, with G.711.1 408 preferred. This will allow interoperability with both G.711.1 and 409 G.711-only capable parties. This is done by offering the PCMA 410 media subtype in addition to PCMA-WB, and/or PCMU in addition to 411 PCMU-WB. 413 Below is an example part of such an offer, for A-law: 415 m=audio 54874 RTP/AVP 96 8 416 a=rtpmap:96 PCMA-WB/16000 417 a=rtpmap:8 PCMA/8000 419 As a reminder, the payload format for G.711 is defined in Section 420 4.5.14 of [RFC3551]. 422 o The "mode-set" parameter is bi-directional, i.e., the restricted 423 mode set applies to media both to be received and sent by the 424 declaring entity. If a mode-set was supplied in the offer, the 425 answerer MUST return either the same mode-set or a subset of this 426 mode-set. The answerer MAY change the preference order. If no 427 mode-set was supplied in the offer, the anwerer MAY return a mode- 428 set to restrict the possible modes. In any cases, the mode-set in 429 the answer then applies for both offerer and answerer. The 430 offerer MUST NOT send frames of a mode that has been removed by 431 the answerer. 433 For multicast sessions, if "mode-set" is supplied in the offer, 434 the answerer SHALL only participate in the session if it supports 435 the offered mode set. 437 o The parameters "ptime" and "maxptime" will in most cases not 438 affect interoperability. The SDP offer-answer handling of the 439 "ptime" parameter is described in [RFC3264]. The "maxptime" 440 parameter MUST be handled in the same way. 442 o Any unknown parameter in an offer MUST be ignored by the receiver 443 and MUST NOT be included in the answer. 445 Below are some example parts of SDP offer-answer exchanges. 447 o Example 1 449 Offer: G.711.1 all modes, with G.711 fallback, prefers mu-law 450 m=audio 54874 RTP/AVP 96 97 0 8 451 a=rtpmap:96 PCMU-WB/16000 452 a=rtpmap:97 PCMA-WB/16000 453 a=rtpmap:0 PCMU/8000 454 a=rtpmap:8 PCMA/8000 456 Answer: all modes accepted, both mu- and A-law. 457 m=audio 59452 RTP/AVP 96 97 458 a=rtpmap:96 PCMU-WB/16000 459 a=rtpmap:97 PCMA-WB/16000 461 o Example 2 463 Offer: G.711.1 all modes, with G.711 fallback, prefers A-law 464 m=audio 54874 RTP/AVP 96 97 8 0 465 a=rtpmap:96 PCMA-WB/16000 466 a=rtpmap:97 PCMU-WB/16000 468 Answer: wants only A-law mode R3 469 m=audio 59452 RTP/AVP 96 470 a=rtpmap:96 PCMA-WB/16000 471 a=fmtp:96 mode-set=4 473 o Example 3 475 Offer: G.711.1 A-law with two modes, R2b and R3, with R3 preferred 476 m=audio 54874 RTP/AVP 96 477 a=rtpmap:96 PCMA-WB/16000 478 a=fmtp:96 mode-set=4,3 480 Answer: accepted 481 m=audio 59452 RTP/AVP 96 482 a=rtpmap:96 PCMA-WB/16000 483 a=fmtp:96 mode-set=4,3 485 If the answerer wanted to restrict to one mode, it would have 486 answered with only one value in the mode-set. For example mode- 487 set=3 for mode R2b. 489 5.3.2. Declarative SDP Considerations 491 For declarative use of SDP, nothing specific is defined for this 492 payload format. The configuration given by the SDP MUST be used when 493 sending and/or receiving media in the session. 495 6. G.711 Interoperabilty 497 The L0 layer of G.711.1 is fully interoperable with G.711, and is 498 embedded in all modes of G.711.1. This provides an easy G.711.1 - 499 G.711 transcoding process. 501 A gateway or any other network device receiving a G.711.1 packet can 502 easily extract a G.711-compatible payload, without the need to decode 503 and re-encode the audio signal. It simply has to take the audio data 504 of the payload, and strip the upper layers (L1 and/or L2), if any. 506 If a G.711.1 packet contains several frames, the concatenation of the 507 L0 layers of each frame will form a G.711-compatible payload. 509 7. Congestion Control 511 Congestion control for RTP SHALL be used in accordance with [RFC3550] 512 and any appropriate profile (for example, [RFC3551]). 514 The embedded nature of G.711.1 audio data can be helpful for 515 congestion control, since a coding mode with a lower bit rate can be 516 selected when needed. This property is usable only when multiple 517 modes have been negotiated (either no "mode-set" parameter in the 518 SDP, or a "mode-set" with at least 2 modes). 520 The number of frames encapsulated in each RTP payload influences the 521 overall bandwidth of the RTP stream, due to the header overhead. 522 Packing more frames in each RTP payload can reduce the number of 523 packets sent and hence the header overhead, at the expense of 524 increased delay and reduced error robustness. 526 8. Security Considerations 528 RTP packets using the payload format defined in this specification 529 are subject to the general security considerations discussed in the 530 RTP specification [RFC3550] and any appropriate profile (for example, 531 [RFC3551]). 533 As this format transports encoded speech/audio, the main security 534 issues include confidentiality, integrity protection, and 535 authentication of the speech/audio itself. The payload format itself 536 does not have any built-in security mechanisms. Any suitable 537 external mechanisms, such as SRTP [RFC3711], MAY be used. 539 This payload format and the G.711.1 encoding do not exhibit any 540 significant non-uniformity in the receiver-end computational load and 541 thus are unlikely to pose a denial-of-service threat due to the 542 receipt of pathological datagrams. 544 9. IANA Considerations 546 It is requested that two new media subtype (audio/PCMA-WB and audio/ 547 PCMU-WB) are registered by IANA, see Section 5.1 and Section 5.2. 549 10. References 551 10.1. Normative References 553 [ITU-G.711.1] 554 International Telecommunications Union, "Wideband embedded 555 extension for G.711 pulse code modulation", ITU- 556 T Recommendation G.711.1, March 2008. 558 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 559 Requirement Levels", BCP 14, RFC 2119, March 1997. 561 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 562 Jacobson, "RTP: A Transport Protocol for Real-Time 563 Applications", STD 64, RFC 3550, July 2003. 565 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 566 Video Conferences with Minimal Control", STD 65, RFC 3551, 567 July 2003. 569 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 570 Description Protocol", RFC 4566, July 2006. 572 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 573 Registration Procedures", BCP 13, RFC 4288, December 2005. 575 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 576 Formats", RFC 4855, February 2007. 578 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 579 with Session Description Protocol (SDP)", RFC 3264, 580 June 2002. 582 10.2. Informative References 584 [ITU-G.711] 585 International Telecommunications Union, "Pulse code 586 modulation (PCM) of voice frequencies", ITU- 587 T Recommendation G.711, November 1988. 589 [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for 590 Comfort Noise (CN)", RFC 3389, September 2002. 592 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 593 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 594 RFC 3711, March 2004. 596 Author's Address 598 Aurelien Sollaud 599 France Telecom 600 2 avenue Pierre Marzin 601 Lannion Cedex 22307 602 France 604 Phone: +33 2 96 05 15 06 605 Email: aurelien.sollaud@orange-ftgroup.com 607 Full Copyright Statement 609 Copyright (C) The IETF Trust (2008). 611 This document is subject to the rights, licenses and restrictions 612 contained in BCP 78, and except as set forth therein, the authors 613 retain all their rights. 615 This document and the information contained herein are provided on an 616 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 617 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 618 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 619 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 620 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 621 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 623 Intellectual Property 625 The IETF takes no position regarding the validity or scope of any 626 Intellectual Property Rights or other rights that might be claimed to 627 pertain to the implementation or use of the technology described in 628 this document or the extent to which any license under such rights 629 might or might not be available; nor does it represent that it has 630 made any independent effort to identify any such rights. Information 631 on the procedures with respect to rights in RFC documents can be 632 found in BCP 78 and BCP 79. 634 Copies of IPR disclosures made to the IETF Secretariat and any 635 assurances of licenses to be made available, or the result of an 636 attempt made to obtain a general license or permission for the use of 637 such proprietary rights by implementers or users of this 638 specification can be obtained from the IETF on-line IPR repository at 639 http://www.ietf.org/ipr. 641 The IETF invites any interested party to bring to its attention any 642 copyrights, patents or patent applications, or other proprietary 643 rights that may cover technology that may be required to implement 644 this standard. Please address the information to the IETF at 645 ietf-ipr@ietf.org.