idnits 2.17.1 draft-ietf-avt-rfc4749-dtx-update-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 336. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 347. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 354. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 360. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4749, but the abstract doesn't seem to directly say this. It does mention RFC4749 though, so this could be OK. 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). (Using the creation date from RFC4749, updated by this document, for RFC5378 checks: 2005-12-07) -- 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 (December 8, 2008) is 5610 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.729.1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-G.729.1-C' ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 10 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 Updates: 4749 (if approved) December 8, 2008 5 Intended status: Standards Track 6 Expires: June 11, 2009 8 G.729.1 RTP Payload Format update: DTX support 9 draft-ietf-avt-rfc4749-dtx-update-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 11, 2009. 36 Abstract 38 This document updates the Real-time Transport Protocol (RTP) payload 39 format to be used for the International Telecommunication Union 40 (ITU-T) Recommendation G.729.1 audio codec. It adds Discontinuous 41 Transmission (DTX) support to the RFC 4749 specification, in a 42 backward-compatible way. An updated media type registration is 43 included for this payload format. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . . . 3 50 4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 4 51 5. Payload Format Parameters . . . . . . . . . . . . . . . . . . . 5 52 5.1. Media Type Registration Update . . . . . . . . . . . . . . 5 53 5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . . 5 54 5.2.1. DTX Offer-Answer Model Considerations . . . . . . . . . 6 55 5.2.2. DTX Declarative SDP Considerations . . . . . . . . . . 7 56 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 7 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 58 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 59 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 61 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 Intellectual Property and Copyright Statements . . . . . . . . . . 9 65 1. Introduction 67 The International Telecommunication Union (ITU-T) Recommendation 68 G.729.1 [ITU-G.729.1] is a scalable and wideband extension of the 69 Recommendation G.729 [ITU-G.729] audio codec. [RFC4749] specifies 70 the payload format for packetization of G.729.1 encoded audio signals 71 into the Real-time Transport Protocol (RTP) [RFC3550]. 73 The Annex C of G.729.1 [ITU-G.729.1-C] adds Discontinuous 74 Transmission (DTX) support to G.729.1. This document updates the RTP 75 payload format to allow usage of this Annex. 77 Only changes or additions to [RFC4749] will be described in the 78 following sections. 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 2. Background 86 G.729.1 supports Discontinuous Transmission (DTX), a.k.a. "silence 87 suppression". It means that the coder includes a Voice Activity 88 Detection (VAD) algorithm, to determine if an audio frame contains 89 silence or actual audio. During silence periods, the coder may 90 significantly decrease the transmitted bit rate by sending a small 91 frame called Silence Insertion Descriptor (SID), and then stop 92 transmission. The receiver's decoder will generate comfort noise 93 (CNG) according to the parameters contained in the SID. This DTX/CNG 94 scheme is specified in [ITU-G.729.1-C]. 96 G.729.1 SID has an embedded structure. The core SID is the same as 97 the legacy G.729 SID [ITU-G.729-B]. A first enhancement layer adds 98 some parameters for narrowband comfort noise, while a second 99 enhancement layer adds wideband information. G.729.1 SID can be 2, 100 3, or 6 octets long. 102 3. RTP Header Usage 104 The fields of the RTP header must be used as described in [RFC4749], 105 except for the Marker (M) bit. 107 If DTX is used, the first packet of a talkspurt, that is, the first 108 packet after a silence period during which packets have not been 109 transmitted contiguously, MUST be distinguished by setting the M bit 110 in the RTP data header to one. The M bit in all other packets MUST 111 be set to zero. The beginning of a talkspurt MAY be used to adjust 112 the playout delay to reflect changing network delays. 114 If DTX is not used, the M bit MUST be set to zero in all packets. 116 4. Payload Format 118 The payload format is the same as in [RFC4749], with the option to 119 add a SID at the end. 121 So the complete payload consists of a payload header of 1 octet (MBS 122 and FT fields), followed by zero or more consecutive audio frames at 123 the same bit rate, followed by zero or one SID. 125 Note that it is consistent with the payload format of G.729 126 described in section 4.5.6 of [RFC3551]. 128 To be able to transport a SID alone, that is, without actual audio 129 frames, we assign the FT value 14 to SID. When using FT=14, only a 130 single SID frame SHALL be included in the payload. The actual SID 131 size (2, 3, or 6 octets) is inferred from the payload size: it is the 132 size of what is left after the payload header. 134 When a SID is appended to actual audio frames, the FT value remains 135 the one describing the encoding rate of the audio frames. Since the 136 SID is much smaller than any other frame, it can be easily detected 137 at the receiver side, and it will not hinder the calculation of the 138 number of frames. The actual SID size is inferred from the payload 139 size: it is the size of what is left after the audio frames. 141 Section 5.4 of [RFC4749] mandates to ignore the remainging bytes 142 after complete frames. This document overrides this statement: the 143 receiver of the payload must consider these remainging bytes as a SID 144 frame. If the size of this remainder is not a valid SID frame size 145 (2, 3, or 6 octets), the receiver MUST ignore these bytes. 147 The full FT table is given for convenience: 149 +-------+---------------+-------------------+ 150 | FT | encoding rate | frame size | 151 +-------+---------------+-------------------+ 152 | 0 | 8 kbps | 20 octets | 153 | 1 | 12 kbps | 30 octets | 154 | 2 | 14 kbps | 35 octets | 155 | 3 | 16 kbps | 40 octets | 156 | 4 | 18 kbps | 45 octets | 157 | 5 | 20 kbps | 50 octets | 158 | 6 | 22 kbps | 55 octets | 159 | 7 | 24 kbps | 60 octets | 160 | 8 | 26 kbps | 65 octets | 161 | 9 | 28 kbps | 70 octets | 162 | 10 | 30 kbps | 75 octets | 163 | 11 | 32 kbps | 80 octets | 164 | 12-13 | (reserved) | - | 165 | 14 | SID | 2, 3, or 6 octets | 166 | 15 | NO_DATA | 0 | 167 +-------+---------------+-------------------+ 169 DTX has no impact on the MBS definition and use. 171 5. Payload Format Parameters 173 Parameters defined in [RFC4749] are not modified. We add a new 174 optional parameter to configure DTX. 176 5.1. Media Type Registration Update 178 We add a new optional parameter to the audio/G7291 media subtype: 180 dtx: indicates that discontinuous transmission (DTX) is used or 181 preferred. Permissible values are 0 and 1. 0 means no DTX. 1 182 means DTX support, as described in Annex C of ITU-T Recommendation 183 G.729.1. 0 is implied if this parameter is omitted. 185 When DTX is turned off, the RTP payload MUST NOT contain SID, and the 186 FT value 14 MUST NOT be used. 188 5.2. Mapping to SDP Parameters 190 The information carried in the media type specification has a 191 specific mapping to fields in the Session Description Protocol (SDP) 192 [RFC4566], which is commonly used to describe RTP sessions. 194 The mapping described in [RFC4749] remains unchanged. 196 The "dtx" parameter goes in the SDP "a=fmtp" attribute. 198 Some example partial SDP session descriptions utilizing G.729.1 199 encodings follow. 201 Example 1: default parameters (DTX off) 203 m=audio 57586 RTP/AVP 96 204 a=rtpmap:96 G7291/16000 206 Example 2: recommended packet duration of 40 ms (=2 frames), maximum 207 bit rate is 20 kbps, DTX supported and preferred. 209 m=audio 49987 RTP/AVP 97 210 a=rtpmap:97 G7291/16000 211 a=fmtp:97 maxbitrate=20000; dtx=1 212 a=ptime:40 214 5.2.1. DTX Offer-Answer Model Considerations 216 The offer-answer model considerations of [RFC4749] fully apply. In 217 this section we only define the management of the "dtx" parameter. 219 The "dtx" parameter concerns both sending and receiving, so both 220 sides of a bi-directional session MUST have the same DTX setting. If 221 one party indicates it does not support DTX, DTX must be deactivated 222 both ways. In other words, DTX is actually activated if, and only 223 if, "dtx=1" in the offer and in the answer. 225 A special rule applies for multicast: the "dtx" parameter becomes 226 declarative and MUST NOT be negotiated. This parameter is fixed, and 227 a participant MUST use the configuration that is provided for the 228 session. 230 A RTP receiver compliant with only RFC 4749 and not this 231 specification will ignore the "dtx" parameter and will not include it 232 in its answer, so DTX will not be activated in this case. As a 233 remark, if that happened, this kind of receiver would not be confused 234 by a RTP stream with DTX because RFC 4749 requires to ignore the 235 bytes that are now used for SID frames. But during silence period, 236 the receiver would then react using packet loss concealment instead 237 of comfort noise generation, leading to bad audio quality. This 238 justifies the use of the "dtx" parameter, even if the payload format 239 is backward compatible at the binary level. 241 5.2.2. DTX Declarative SDP Considerations 243 The "dtx" parameter is declarative and provides the parameter that 244 SHALL be used when receiving and/or sending the configured stream. 246 6. Congestion Control 248 The congestion control considerations of [RFC4749] apply. 250 The use of DTX can help congestion control by reducing the number of 251 transmitted RTP packets and the average bandwidth of audio streams. 253 7. Security Considerations 255 The security considerations of [RFC4749] apply. 257 By observing the RTP flow with DTX, an attacker could see when and 258 how long people are speaking. This is a general fact for DTX, and 259 G.729.1 DTX introduces no new specific issue. 261 8. IANA Considerations 263 It is requested that one new optional parameter for media subtype 264 (audio/G7291) is registered by IANA, see Section 5.1. 266 9. References 268 9.1. Normative References 270 [ITU-G.729.1] 271 International Telecommunications Union, "G.729 based 272 Embedded Variable bit-rate coder: An 8-32 kbit/s scalable 273 wideband coder bitstream interoperable with G.729", ITU- 274 T Recommendation G.729.1, May 2006. 276 [ITU-G.729.1-C] 277 International Telecommunications Union, "G.729.1 DTX/CNG 278 scheme", ITU-T Recommendation G.729.1 Annex C, May 2008. 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, March 1997. 283 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 284 Jacobson, "RTP: A Transport Protocol for Real-Time 285 Applications", STD 64, RFC 3550, July 2003. 287 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 288 Description Protocol", RFC 4566, July 2006. 290 [RFC4749] Sollaud, A., "RTP Payload Format for the G.729.1 Audio 291 Codec", RFC 4749, October 2006. 293 9.2. Informative References 295 [ITU-G.729] 296 International Telecommunications Union, "Coding of speech 297 at 8 kbit/s using conjugate-structure algebraic-code- 298 excited linear-prediction (CS-ACELP)", ITU- 299 T Recommendation G.729, March 1996. 301 [ITU-G.729-B] 302 International Telecommunications Union, "A silence 303 compression scheme for G.729 optimized for terminals 304 conforming to Recommendation V.70", ITU-T Recommendation 305 G.729 Annex B, October 1996. 307 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 308 Video Conferences with Minimal Control", STD 65, RFC 3551, 309 July 2003. 311 Author's Address 313 Aurelien Sollaud 314 France Telecom 315 2 avenue Pierre Marzin 316 Lannion Cedex 22307 317 France 319 Phone: +33 2 96 05 15 06 320 Email: aurelien.sollaud@orange-ftgroup.com 322 Full Copyright Statement 324 Copyright (C) The IETF Trust (2008). 326 This document is subject to the rights, licenses and restrictions 327 contained in BCP 78, and except as set forth therein, the authors 328 retain all their rights. 330 This document and the information contained herein are provided on an 331 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 332 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 333 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 334 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 335 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 336 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 338 Intellectual Property 340 The IETF takes no position regarding the validity or scope of any 341 Intellectual Property Rights or other rights that might be claimed to 342 pertain to the implementation or use of the technology described in 343 this document or the extent to which any license under such rights 344 might or might not be available; nor does it represent that it has 345 made any independent effort to identify any such rights. Information 346 on the procedures with respect to rights in RFC documents can be 347 found in BCP 78 and BCP 79. 349 Copies of IPR disclosures made to the IETF Secretariat and any 350 assurances of licenses to be made available, or the result of an 351 attempt made to obtain a general license or permission for the use of 352 such proprietary rights by implementers or users of this 353 specification can be obtained from the IETF on-line IPR repository at 354 http://www.ietf.org/ipr. 356 The IETF invites any interested party to bring to its attention any 357 copyrights, patents or patent applications, or other proprietary 358 rights that may cover technology that may be required to implement 359 this standard. Please address the information to the IETF at 360 ietf-ipr@ietf.org.