idnits 2.17.1 draft-muthu-payload-offer-answer-g723-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 -- The document date (February 24, 2012) is 4438 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 (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Payload Muthu A M. Perumal 2 Internet-Draft Cisco Systems 3 Intended status: Standards Track Parthasarathi. Ravindran 4 Expires: August 27, 2012 Sonus Networks 5 February 24, 2012 7 Offer/Answer Considerations for G.723 Annex A and G.729 Annex B 8 draft-muthu-payload-offer-answer-g723-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. 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 August 27, 2012. 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 . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . . 8 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. 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 parameter being chosen to call failure, when the 100 parameter value does not match in the offer and answer. 102 [RFC3264] section 6.1 states that SDP extensions that define new fmtp 103 parameters SHOULD specify the proper interpretation in offer/answer. 104 But, [RFC4856] does not specify it for the Annex A flavor of G.723 105 and the Annex B 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 Open item: Should the above be restated as follows? 143 When the offer has G723 with annexa=no then the answer MUST have 144 annexa=no for G723. 145 This is technically correct, but are there implementations that 146 omit the annexa parameter in answer and expect the least common 147 denominator to be used? 149 When the offer has G723 with no annexa parameter and the answer has 150 G723 with annexa=yes, the offerer and answerer MUST proceed as if 151 G723 is negotiated with annexa=yes. 153 3.2. Offer/Answer Considerations for G.729 Annex B, G.729D Annex B and 154 G.729E Annex B 156 In this section G729 represents any of G729 or G729D or G729E. 158 When the offer or answer has G729 and the annexb parameter is absent, 159 it MUST be considered as if the offer or answer has G729 with 160 annexb=yes. 162 When the offer has G729 with annexb=yes and the answer has G729 with 163 annexb=no, the offerer and answerer MUST proceed as if G729 is 164 negotiated with annexb=no. 166 When the offer has G729 with annexb=no then the answer MUST NOT have 167 annexb=yes for G729. Thus the annexb parameter can be turned off by 168 the answerer, but cannot be turned on. 170 Open item: Should the above be restated as follows? 171 When the offer has G729 with annexb=no then the answer MUST have 172 annexb=no for G729. 173 This is technically correct, but are there implementations that 174 omit the annexb parameter in answer and expect the least common 175 denominator to be used? 177 When the offer has G.729 with no annexb parameter and the answer has 178 G.729 with annexb=yes, the offerer and answerer MUST proceed as if 179 G.729 is negotiated with annexb=yes. 181 4. Examples 183 4.1. Offer with G279 annexb=yes and answer with G279 annexb=no 185 [Offer with G279 annexb=yes] 187 v=0 188 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 189 s= 190 c=IN IP4 host.atlanta.example.com 191 t=0 0 192 m=audio 49170 RTP/AVP 18 193 a=rtpmap:18 G729/8000 194 a=fmtp:18 annexb=yes 196 [Answer with G729 annexb=no] 198 v=0 199 o=bob 1890844326 1890844326 IN IP4 host.bangalore.example.com 200 s= 201 c=IN IP4 host.bangalore.example.com 202 t=0 0 203 m=audio 19140 RTP/AVP 18 204 a=rtpmap:18 G729/8000 205 a=fmtp:18 annexb=no 207 In the above example the offerer and answerer proceed as if G729 is 208 negotiated with annexb=no. 210 4.2. Offer with G279 annexb=yes and answer with G729 and no annexb 211 parameter 213 [Offer with G279 annexb=yes] 215 v=0 216 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 217 s= 218 c=IN IP4 host.atlanta.example.com 219 t=0 0 220 m=audio 49170 RTP/AVP 18 221 a=rtpmap:18 G729/8000 222 a=fmtp:18 annexb=yes 224 [Answer with G729 and no annexb parameter] 226 v=0 227 o=bob 1890844326 1890844326 IN IP4 host.bangalore.example.com 228 s= 229 c=IN IP4 host.bangalore.example.com 230 t=0 0 231 m=audio 19140 RTP/AVP 18 232 a=rtpmap:18 G729/8000 234 In the above example the offerer and answerer proceed as if G729 is 235 negotiated with annexb=yes. 237 4.3. Offer with G279 and no annexb parameter and answer with G729 238 annexb=no 240 [Offer with G279 and no annexb parameter] 242 v=0 243 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 244 s= 245 c=IN IP4 host.atlanta.example.com 246 t=0 0 247 m=audio 49170 RTP/AVP 18 248 a=rtpmap:18 G729/8000 250 [Answer with G729 annexb=no] 252 v=0 253 o=bob 1890844326 1890844326 IN IP4 host.bangalore.example.com 254 s= 255 c=IN IP4 host.bangalore.example.com 256 t=0 0 257 m=audio 19140 RTP/AVP 18 258 a=rtpmap:18 G729/8000 259 a=fmtp:18 annexb=no 261 In the above example the offerer and answerer proceed as if G729 is 262 negotiated with annexb=no. 264 5. Security Considerations 266 There is no extra security required apart from what is described in 267 [RFC4856]. 269 6. IANA Considerations 271 There is no IANA consideration for this draft. 273 7. Acknowledgement 275 Thanks to Flemming Andreasen (Cisco), Paul Kyzivat, Kevin Riley 276 (Sonus), Ashish Sharma (Sonus) for their valuable comments and 277 inputs. 279 8. Normative References 281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, March 1997. 284 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 285 with Session Description Protocol (SDP)", RFC 3264, 286 June 2002. 288 [RFC4856] Casner, S., "Media Type Registration of Payload Formats in 289 the RTP Profile for Audio and Video Conferences", 290 RFC 4856, February 2007. 292 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 293 Video Conferences with Minimal Control", STD 65, RFC 3551, 294 July 2003. 296 Authors' Addresses 298 Muthu Arul Mozhi Perumal 299 Cisco Systems 300 Cessna Business Park 301 Sarjapur-Marathahalli Outer Ring Road 302 Bangalore, Karnataka 560103 303 India 305 Email: mperumal@cisco.com 307 Parthasarathi Ravindran 308 Sonus Networks 309 Prestige Shantiniketan - Business Precinct 310 Whitefield Road 311 Bangalore, Karnataka 560066 312 India 314 Email: pravindran@sonusnet.com