idnits 2.17.1 draft-sollaud-avt-rfc4749-dtx-update-00.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 309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 320. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 327. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 333. 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 (January 14, 2008) is 5940 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. '1' ** Obsolete normative reference: RFC 4566 (ref. '6') (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 9 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) January 14, 2008 5 Intended status: Standards Track 6 Expires: July 17, 2008 8 G.729.1 RTP Payload Format update: DTX support 9 draft-sollaud-avt-rfc4749-dtx-update-00 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 July 17, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document updates the Real-time Transport Protocol (RTP) payload 43 format to be used for the International Telecommunication Union 44 (ITU-T) G.729.1 audio codec. It adds Discontinuous Transmission 45 (DTX) support to the RFC 4749 specification, in a backward-compatible 46 way. An updated media type registration is included for this payload 47 format. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 4 55 5. Payload Format Parameters . . . . . . . . . . . . . . . . . . . 5 56 5.1. Media Type Registration Update . . . . . . . . . . . . . . 5 57 5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . . 5 58 5.2.1. DTX Offer-Answer Model Considerations . . . . . . . . . 5 59 5.2.2. DTX Declarative SDP Considerations . . . . . . . . . . 6 60 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 6 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 65 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 Intellectual Property and Copyright Statements . . . . . . . . . . 8 69 1. Introduction 71 The International Telecommunication Union (ITU-T) recommendation 72 G.729.1 [1] is a scalable and wideband extension of the 73 recommendation G.729 [7] audio codec. RFC 4749 [3] specifies the 74 payload format for packetization of G.729.1 encoded audio signals 75 into the Real-time Transport Protocol (RTP) [4]. 77 The ITU-T is about to release an Appendix, to add Discontinuous 78 Transmission (DTX) support to G.729.1. This document updates the RTP 79 payload format to allow usage of this Appendix. 81 Only changes or additions to RFC 4749 [3] will be described in the 82 following sections. 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119 [2]. 88 2. Background 90 G.729.1 supports Discontinuous Transmission (DTX), a.k.a. silence 91 suppression. It means that the coder includes a Voice Activity 92 Detection (VAD) algorithm, to determine if an audio frame contains 93 silence or actual audio. During silence periods, the coder may 94 significantly decrease the transmitted bit rate by sending a small 95 frame called Silence Insertion Descriptors (SID), and then stop 96 transmission. The receiver's decoder will generate comfort noise 97 according to the the parameters contained in the SID. 99 G.729.1 SID has an embedded structure. The core SID is the same as 100 the legacy G.729 SID [8]. A first enhancement layer adds some 101 parameters for narrowband comfort noise, while a second enhancement 102 layer adds wideband information. In the current state of the 103 specification, SID can be 2, 3, or 6 octets long. 105 3. RTP Header Usage 107 The fields of the RTP header must be used as described in RFC 4749, 108 except for the Marker (M) bit. 110 If DTX is used, the first packet of a talkspurt, that is, the first 111 packet after a silence period during which packets have not been 112 transmitted contiguously, SHOULD be distinguished by setting the M 113 bit in the RTP data header to one. The M bit in all other packets 114 MUST be set to zero. The beginning of a talkspurt MAY be used to 115 adjust the playout delay to reflect changing network delays. 117 If DTX is not used, the M bit MUST be set to zero in all packets. 119 4. Payload Format 121 The payload format is the same as in RFC 4749, with the option to add 122 a SID at the end. 124 So the complete payload consists of a payload header of 1 octet (MBS 125 and FT fields), followed by zero or more consecutive audio frames at 126 the same bit rate, followed by zero or one SID. 128 Note that it is consistent with the payload format of G.729 129 described in section 4.5.6 of RFC 3551 [5]. 131 To be able to transport a SID alone, that is, without actual audio 132 frames, we assign the FT value 14 to SID. The actual SID size (2, 3, 133 or 6 octets) is inferred from the payload size. 135 When a SID is appended to actual audio frames, the FT value remains 136 the one describing the encoding rate of the audio frames. Since the 137 SID is much smaller than any other frame, it can be easily detected 138 at the receiver side, and it will not hinder the calculation of the 139 number of frames. 141 The full FT table is given for convenience: 143 +-------+---------------+-------------------+ 144 | FT | encoding rate | frame size | 145 +-------+---------------+-------------------+ 146 | 0 | 8 kbps | 20 octets | 147 | 1 | 12 kbps | 30 octets | 148 | 2 | 14 kbps | 35 octets | 149 | 3 | 16 kbps | 40 octets | 150 | 4 | 18 kbps | 45 octets | 151 | 5 | 20 kbps | 50 octets | 152 | 6 | 22 kbps | 55 octets | 153 | 7 | 24 kbps | 60 octets | 154 | 8 | 26 kbps | 65 octets | 155 | 9 | 28 kbps | 70 octets | 156 | 10 | 30 kbps | 75 octets | 157 | 11 | 32 kbps | 80 octets | 158 | 12-13 | (reserved) | - | 159 | 14 | SID | 2, 3, or 6 octets | 160 | 15 | NO_DATA | 0 | 161 +-------+---------------+-------------------+ 163 DTX has no impact on the MBS definition and use. 165 5. Payload Format Parameters 167 Parameters defined in RFC 4749 are not modified. We add a new 168 optional parameter to configure DTX. 170 5.1. Media Type Registration Update 172 We add a new optional parameter to the audio/G7291 media subtype: 174 dtx: indicates that discontinuous transmission (DTX) is used or 175 preferred. Permissible values are 0 and 1. 0 means no DTX. 1 176 means DTX support, as described in Appendix ZZZ of Recommendation 177 G.729.1. 0 is implied if this parameter is omitted. 179 When DTX is turned off, the RTP payload MUST NOT contain SID. 181 5.2. Mapping to SDP Parameters 183 The information carried in the media type specification has a 184 specific mapping to fields in the Session Description Protocol (SDP) 185 [6], which is commonly used to describe RTP sessions. 187 The mapping described in RFC 4749 remains unchanged. The "dtx" 188 parameter goes in the SDP "a=fmtp" attribute. 190 Some example SDP session descriptions utilizing G.729.1 encodings 191 follow. 193 Example 1: default parameters (DTX off) 195 m=audio 57586 RTP/AVP 96 196 a=rtpmap:96 G7291/16000 198 Example 2: recommended packet duration of 40 ms (=2 frames), maximum 199 bit rate is 20 kbps, DTX supported and preferred. 201 m=audio 49987 RTP/AVP 97 202 a=rtpmap:97 G7291/16000 203 a=fmtp:97 maxbitrate=20000; dtx=1 204 a=ptime:40 206 5.2.1. DTX Offer-Answer Model Considerations 208 The offer-answer model considerations of RFC 4749 fully apply. In 209 this section we only define the management of the "dtx" parameter. 211 The "dtx" parameter concerns both sending and receiving, so both 212 sides of a bi-directional session MUST have the same DTX setting. If 213 one party indicates it does not support DTX, DTX must be deactivated 214 both ways. In other words, DTX is actually activated if, and only 215 if, "dtx=1" in the offer and in the answer. 217 A special rule apply for multicast: the "dtx" parameter becomes 218 declarative and MUST NOT be negotiated. This parameter is fixed, and 219 a participant MUST use the configuration that is provided for the 220 session. 222 5.2.2. DTX Declarative SDP Considerations 224 The "dtx" parameter is declarative and provides the parameter that 225 SHALL be used when receiving and/or sending the configured stream. 227 6. Congestion Control 229 The congestion control considerations of RFC 4749 apply. 231 The use of DTX can help congestion control by reducing the number of 232 transmitted RTP packets and the average bandwidth of audio streams. 234 As opposed to the scalable bitrates of G.729.1 audio frames, the 235 scalable property of G.729.1 SID is not intended to adapt bandwidth. 236 Its main goal is to preserve G.729 interoperability while providing 237 comfort noise quality enhancements. 239 7. Security Considerations 241 DTX introduces no new security issue. 243 8. IANA Considerations 245 It is requested that one new parameter for media subtype (audio/ 246 G7291) is registered by IANA, see Section 5.1. 248 9. References 250 9.1. Normative References 252 [1] International Telecommunications Union, "G.729 based Embedded 253 Variable bit-rate coder: An 8-32 kbit/s scalable wideband coder 254 bitstream interoperable with G.729", ITU-T Recommendation 255 G.729.1, May 2006. 257 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 258 Levels", BCP 14, RFC 2119, March 1997. 260 [3] Sollaud, A., "RTP Payload Format for the G.729.1 Audio Codec", 261 RFC 4749, October 2006. 263 [4] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 264 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 265 RFC 3550, July 2003. 267 [5] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 268 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 270 [6] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 271 Description Protocol", RFC 4566, July 2006. 273 9.2. Informative References 275 [7] International Telecommunications Union, "Coding of speech at 8 276 kbit/s using conjugate-structure algebraic-code-excited linear- 277 prediction (CS-ACELP)", ITU-T Recommendation G.729, March 1996. 279 [8] International Telecommunications Union, "A silence compression 280 scheme for G.729 optimized for terminals conforming to 281 Recommendation V.70", ITU-T Recommendation G.729 Annex B, 282 October 1996. 284 Author's Address 286 Aurelien Sollaud 287 France Telecom 288 2 avenue Pierre Marzin 289 Lannion Cedex 22307 290 France 292 Phone: +33 2 96 05 15 06 293 Email: aurelien.sollaud@orange-ftgroup.com 295 Full Copyright Statement 297 Copyright (C) The IETF Trust (2008). 299 This document is subject to the rights, licenses and restrictions 300 contained in BCP 78, and except as set forth therein, the authors 301 retain all their rights. 303 This document and the information contained herein are provided on an 304 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 305 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 306 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 307 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 308 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 309 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 311 Intellectual Property 313 The IETF takes no position regarding the validity or scope of any 314 Intellectual Property Rights or other rights that might be claimed to 315 pertain to the implementation or use of the technology described in 316 this document or the extent to which any license under such rights 317 might or might not be available; nor does it represent that it has 318 made any independent effort to identify any such rights. Information 319 on the procedures with respect to rights in RFC documents can be 320 found in BCP 78 and BCP 79. 322 Copies of IPR disclosures made to the IETF Secretariat and any 323 assurances of licenses to be made available, or the result of an 324 attempt made to obtain a general license or permission for the use of 325 such proprietary rights by implementers or users of this 326 specification can be obtained from the IETF on-line IPR repository at 327 http://www.ietf.org/ipr. 329 The IETF invites any interested party to bring to its attention any 330 copyrights, patents or patent applications, or other proprietary 331 rights that may cover technology that may be required to implement 332 this standard. Please address the information to the IETF at 333 ietf-ipr@ietf.org. 335 Acknowledgment 337 Funding for the RFC Editor function is provided by the IETF 338 Administrative Support Activity (IASA).