idnits 2.17.1 draft-ietf-mmusic-sdp-g273-g729-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 abstract seems to contain references ([RFC4856]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4856, updated by this document, for RFC5378 checks: 2006-03-02) -- 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 (October 15, 2012) is 4204 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MMUSIC Muthu A M. Perumal 2 Internet-Draft Cisco Systems 3 Updates: 4856 (if approved) Parthasarathi. Ravindran 4 Intended status: Standards Track Nokia Siemens Networks 5 Expires: April 18, 2013 October 15, 2012 7 Offer/Answer Considerations for G.723 Annex A and G.729 Annex B 8 draft-ietf-mmusic-sdp-g273-g729-00 10 Abstract 12 [RFC4856] describes the annexa parameter for G723 and the annexb 13 parameter for G729, G729D and G729E. However, the specification does 14 not describe the offerer and answerer behavior when the value of the 15 annexa or annexb parameter does not match in the SDP offer and 16 answer. This document provides the offer/answer considerations for 17 these parameters and updates [RFC4856]. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 18, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Offer/Answer Considerations . . . . . . . . . . . . . . . . . . 4 56 3.1. Offer/Answer Considerations for G723 Annex A . . . . . . . 4 57 3.2. Offer/Answer Considerations for G.729 Annex B, G.729D 58 Annex B and G.729E Annex B . . . . . . . . . . . . . . . . 4 59 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.1. Offer with G279 annexb=yes and answer with G279 61 annexb=no . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.2. Offer with G279 annexb=yes and answer with G729 and no 63 annexb parameter . . . . . . . . . . . . . . . . . . . . . 5 64 4.3. Offer with G279 and no annexb parameter and answer 65 with G729 annexb=no . . . . . . . . . . . . . . . . . . . . 6 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 68 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 7 69 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 [RFC4856] describes the annexa parameter for G723 as follows: 76 annexa: indicates that Annex A, voice activity detection, is used 77 or preferred. Permissible values are "yes" and "no" (without the 78 quotes); "yes" is implied if this parameter is omitted. 80 Also, [RFC4856] describes the annexb parameter for G729, G729D and 81 G729E as follows: 83 annexb: indicates that Annex B, voice activity detection, is used 84 or preferred. Permissible values are "yes" and "no" (without the 85 quotes); "yes" is implied if this parameter is omitted. 87 However, it does not have any normative statement for the case where 88 the value of this parameter does not match in the SDP offer and 89 answer. For example, if the offer has G729 with annexb=yes and the 90 answer has G729 with annexb=no, it can be interpreted in two 91 different ways: 92 o The offerer and answerer proceed as if G729 is negotiated with 93 annexb=yes, or 94 o The offerer and answerer proceed as if G729 is negotiated with 95 annexb=no. 97 Since [RFC4856] does not state it clearly, various implementations 98 have interpreted the offer/answer in their own ways, resulting in a 99 different codec being chosen to call failure, when the parameter 100 value does not match in the offer and answer. 102 [RFC3264] requires SDP extensions that define new fmtp parameters to 103 specify their proper interpretation in offer/answer. But, [RFC4856] 104 does not specify it for the Annex A flavor of G.723 and the Annex B 105 flavors of G.729, G729D and G729E. 107 This document describes the offer/answer considerations for these 108 parameters and provides the necessary clarifications. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 3. Offer/Answer Considerations 118 [RFC3551] states that 120 Receivers MUST accept comfort noise frames if restriction of their 121 use has not been signaled. The MIME registration for G729 in RFC 122 3555 specifies a parameter that MAY be used with MIME or SDP to 123 restrict the use of comfort noise frames. 125 Based on the above, it is best to not use comfort noise frames if the 126 SDP offer or answer indicates no support for it. 128 3.1. Offer/Answer Considerations for G723 Annex A 130 When the offer or answer has G723 and the annexa parameter is absent, 131 it MUST be considered as if the offer or answer has G723 with 132 annexa=yes. 134 When the offer has G723 with annexa=yes and the answer has G723 with 135 annexa=no, the offerer and answerer MUST proceed as if G723 is 136 negotiated with annexa=no. 138 When the offer has G723 with annexa=no then the answer MUST NOT have 139 annexa=yes for G723. Thus the annexa parameter can be turned off by 140 the answerer, but cannot be turned on. 142 When the offer has G723 with annexa=no, the reason for not 143 mandating that the answer MUST have annexa=no for G723 is that 144 there are there implementations that omit the annexa parameter in 145 answer and expect the least common denominator to be used. 147 When the offer has G723 with no annexa parameter and the answer has 148 G723 with annexa=yes, the offerer and answerer MUST proceed as if 149 G723 is negotiated with annexa=yes. 151 3.2. Offer/Answer Considerations for G.729 Annex B, G.729D Annex B and 152 G.729E Annex B 154 In this section G729 represents any of G729 or G729D or G729E. 156 When the offer or answer has G729 and the annexb parameter is absent, 157 it MUST be considered as if the offer or answer has G729 with 158 annexb=yes. 160 When the offer has G729 with annexb=yes and the answer has G729 with 161 annexb=no, the offerer and answerer MUST proceed as if G729 is 162 negotiated with annexb=no. 164 When the offer has G729 with annexb=no then the answer MUST NOT have 165 annexb=yes for G729. Thus the annexb parameter can be turned off by 166 the answerer, but cannot be turned on. 168 When the offer has G729 with annexa=no, the reason for not 169 mandating that the answer MUST have annexa=no for G729 is that 170 there are there implementations that omit the annexa parameter in 171 answer and expect the least common denominator to be used. 173 When the offer has G729 with no annexb parameter and the answer has 174 G729 with annexb=yes, the offerer and answerer MUST proceed as if 175 G729 is negotiated with annexb=yes. 177 4. Examples 179 4.1. Offer with G279 annexb=yes and answer with G279 annexb=no 181 [Offer with G279 annexb=yes] 183 v=0 184 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 185 s= 186 c=IN IP4 host.atlanta.example.com 187 t=0 0 188 m=audio 49170 RTP/AVP 18 189 a=rtpmap:18 G729/8000 190 a=fmtp:18 annexb=yes 192 [Answer with G729 annexb=no] 194 v=0 195 o=bob 1890844326 1890844326 IN IP4 host.bangalore.example.com 196 s= 197 c=IN IP4 host.bangalore.example.com 198 t=0 0 199 m=audio 19140 RTP/AVP 18 200 a=rtpmap:18 G729/8000 201 a=fmtp:18 annexb=no 203 In the above example the offerer and answerer proceed as if G729 is 204 negotiated with annexb=no. 206 4.2. Offer with G279 annexb=yes and answer with G729 and no annexb 207 parameter 209 [Offer with G279 annexb=yes] 211 v=0 212 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 213 s= 214 c=IN IP4 host.atlanta.example.com 215 t=0 0 216 m=audio 49170 RTP/AVP 18 217 a=rtpmap:18 G729/8000 218 a=fmtp:18 annexb=yes 220 [Answer with G729 and no annexb parameter] 222 v=0 223 o=bob 1890844326 1890844326 IN IP4 host.bangalore.example.com 224 s= 225 c=IN IP4 host.bangalore.example.com 226 t=0 0 227 m=audio 19140 RTP/AVP 18 228 a=rtpmap:18 G729/8000 230 In the above example the offerer and answerer proceed as if G729 is 231 negotiated with annexb=yes. 233 4.3. Offer with G279 and no annexb parameter and answer with G729 234 annexb=no 236 [Offer with G279 and no annexb parameter] 238 v=0 239 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 240 s= 241 c=IN IP4 host.atlanta.example.com 242 t=0 0 243 m=audio 49170 RTP/AVP 18 244 a=rtpmap:18 G729/8000 246 [Answer with G729 annexb=no] 248 v=0 249 o=bob 1890844326 1890844326 IN IP4 host.bangalore.example.com 250 s= 251 c=IN IP4 host.bangalore.example.com 252 t=0 0 253 m=audio 19140 RTP/AVP 18 254 a=rtpmap:18 G729/8000 255 a=fmtp:18 annexb=no 257 In the above example the offerer and answerer proceed as if G729 is 258 negotiated with annexb=no. 260 5. Security Considerations 262 There is no extra security consideration apart from what is described 263 in [RFC4856]. 265 6. IANA Considerations 267 There is no IANA consideration for this draft. 269 7. Acknowledgement 271 Thanks to Flemming Andreasen (Cisco), Miguel A. Garcia (Ericsson), 272 Ali C. Begen (Cisco), Paul Kyzivat, Roni Even (Huawei), Kevin Riley 273 (Sonus), Ashish Sharma (Sonus), Kevin P. Fleming (Digium) and Harprit 274 S. Chhatwal (InnoMedia) for their valuable inputs and comments. 275 Martin Dolly (ATT) and Hadriel Kaplan (Acme Packet) provided useful 276 suggestions at the mic at IETF-83. 278 8. Normative References 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, March 1997. 283 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 284 with Session Description Protocol (SDP)", RFC 3264, 285 June 2002. 287 [RFC4856] Casner, S., "Media Type Registration of Payload Formats in 288 the RTP Profile for Audio and Video Conferences", 289 RFC 4856, February 2007. 291 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 292 Video Conferences with Minimal Control", STD 65, RFC 3551, 293 July 2003. 295 Authors' Addresses 297 Muthu Arul Mozhi Perumal 298 Cisco Systems 299 Cessna Business Park 300 Sarjapur-Marathahalli Outer Ring Road 301 Bangalore, Karnataka 560103 302 India 304 Email: mperumal@cisco.com 306 Parthasarathi Ravindran 307 Nokia Siemens Networks 308 Bangalore, Karnataka 309 India 311 Email: partha@parthasarathi.co.in