idnits 2.17.1 draft-ietf-mmusic-sdp-g723-g729-06.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 28, 2014) is 3703 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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 Intended status: Standards Track Parthasarathi. Ravindran 4 Expires: September 1, 2014 Nokia Solutions and Networks 5 February 28, 2014 7 Offer/Answer Considerations for G723 Annex A and G729 Annex B 8 draft-ietf-mmusic-sdp-g723-g729-06 10 Abstract 12 This document provides the offer/answer considerations for the annexa 13 parameter of G723 and the annexb parameter of G729, G729D and G729E 14 when the value of the annexa or annexb parameter does not match in 15 the Session Description protocol (SDP) offer and answer. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 1, 2014. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Offer/Answer Considerations . . . . . . . . . . . . . . . . . . 3 54 3.1. Considerations for Use of Comfort Noise Frames . . . . . . 4 55 3.2. Offer/Answer Considerations for G723 Annex A . . . . . . . 4 56 3.3. Offer/Answer Considerations for G729 Annex B, G729D 57 Annex B and G729E Annex B . . . . . . . . . . . . . . . . . 4 58 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.1. Offer with G729 annexb=yes and answer with G729 60 annexb=no . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.2. Offer with G729 annexb=yes and answer with G729 and no 62 annexb parameter . . . . . . . . . . . . . . . . . . . . . 6 63 4.3. Offer with G729 and no annexb parameter and answer 64 with G729 annexb=no . . . . . . . . . . . . . . . . . . . . 6 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 67 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 7 68 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 [RFC4856] describes the annexa parameter for G723 as follows: 75 annexa: indicates that Annex A, voice activity detection, is used 76 or preferred. Permissible values are "yes" and "no" (without the 77 quotes); "yes" is implied if this parameter is omitted. 79 Also, [RFC4856] describes the annexb parameter for G729, G729D and 80 G729E as follows: 82 annexb: indicates that Annex B, voice activity detection, is used 83 or preferred. Permissible values are "yes" and "no" (without the 84 quotes); "yes" is implied if this parameter is omitted. 86 However, problem arises when the value of the annexa or annexb 87 parameter does not match in the SDP [RFC4566] offer and answer. 89 For example, if the offer has G729 with annexb=yes and the answer has 90 G729 with annexb=no, it can be interpreted in two different ways: 91 o The offerer and answerer proceed as if G729 is negotiated with 92 annexb=yes, or 93 o The offerer and answerer proceed as if G729 is negotiated with 94 annexb=no. 96 Since this is not clear in the existing specifications, various 97 implementations have interpreted the offer/answer in their own ways, 98 resulting in a different codec being chosen to call failure, when the 99 parameter value does not match in the offer and answer. 101 [RFC3264] requires SDP extensions that define new fmtp parameters to 102 specify their proper interpretation in offer/answer. This document 103 specifies the proper interpretation for the annexa and annexb 104 parameters in offer/answer. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 3. Offer/Answer Considerations 114 The general objective of the offer/answer considerations is to make 115 sure that if the offerer or answerer indicates it does not support 116 Annex A or Annex B, then Annex A or Annex B is not used. 118 3.1. Considerations for Use of Comfort Noise Frames 120 [RFC3551] states that 122 Receivers MUST accept comfort noise frames if restriction of their 123 use has not been signaled. The MIME registration for G729 in RFC 124 3555 specifies a parameter that MAY be used with MIME or SDP to 125 restrict the use of comfort noise frames. 127 Hence, if the SDP offer or answer indicates that comfort noise is not 128 supported, comfort noise frames MUST NOT be used. 130 3.2. Offer/Answer Considerations for G723 Annex A 132 When the offer or answer has G723 and the annexa parameter is absent, 133 the offerer or answerer knows that it has implied the default 134 "annexa=yes". This is because the annexa attribute is part of the 135 original registration of audio/G723 [RFC4856]. All implementations 136 that support G723 understand the annexa attribute. Hence, this case 137 MUST be considered as if the offer or answer has G723 with 138 annexa=yes. 140 When the offer has G723 with annexa=yes and the answer has G723 with 141 annexa=no, the offerer and answerer MUST proceed as if G723 is 142 negotiated with annexa=no. 144 When the offer has G723 with annexa=no, after the offer/answer 145 completion the offerer and answerer MUST proceed as if G723 is 146 negotiated with annexa=no. 148 When the offer has G723 with annexa=no, the reason for not 149 mandating that the answer MUST have annexa=no for G723 is that 150 there are implementations that omit the annexa parameter in 151 answer. In such case the offerer and answerer proceed as if G723 152 is negotiated with annexa=no. 154 When the offer has G723 with no annexa parameter and the answer has 155 G723 with annexa=yes, the offerer and answerer MUST proceed as if 156 G723 is negotiated with annexa=yes. 158 3.3. Offer/Answer Considerations for G729 Annex B, G729D Annex B and 159 G729E Annex B 161 In this section G729 represents any of G729 or G729D or G729E. 163 When the offer or answer has G729 and the annexb parameter is absent, 164 the offerer or answerer knows that it has implied the default 165 "annexb=yes". This is because the annexb attribute is part of the 166 original registration of audio/G729 [RFC4856]. All implementations 167 that support G729 understand the annexb attribute. Hence, this case 168 MUST be considered as if the offer or answer has G729 with 169 annexb=yes. 171 When the offer has G729 with annexb=yes and the answer has G729 with 172 annexb=no, the offerer and answerer MUST proceed as if G729 is 173 negotiated with annexb=no. 175 When the offer has G729 with annexb=no, after the offer/answer 176 completion the offerer and answerer MUST proceed as if G729 is 177 negotiated with annexb=no. 179 When the offer has G729 with annexb=no, the reason for not 180 mandating that the answer MUST have annexb=no for G729 is that 181 there are implementations that omit the annexb parameter in 182 answer. In such case the offerer and answerer proceed as if G729 183 is negotiated with annexb=no. 185 When the offer has G729 with no annexb parameter and the answer has 186 G729 with annexb=yes, the offerer and answerer MUST proceed as if 187 G729 is negotiated with annexb=yes. 189 4. Examples 191 4.1. Offer with G729 annexb=yes and answer with G729 annexb=no 193 [Offer with G729 annexb=yes] 195 v=0 196 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 197 s= 198 c=IN IP4 host.atlanta.example.com 199 t=0 0 200 m=audio 49170 RTP/AVP 18 201 a=rtpmap:18 G729/8000 202 a=fmtp:18 annexb=yes 204 [Answer with G729 annexb=no] 206 v=0 207 o=bob 1890844326 1890844326 IN IP4 host.bangalore.example.com 208 s= 209 c=IN IP4 host.bangalore.example.com 210 t=0 0 211 m=audio 19140 RTP/AVP 18 212 a=rtpmap:18 G729/8000 213 a=fmtp:18 annexb=no 215 In the above example the offerer and answerer proceed as if G729 is 216 negotiated with annexb=no. 218 4.2. Offer with G729 annexb=yes and answer with G729 and no annexb 219 parameter 221 [Offer with G729 annexb=yes] 223 v=0 224 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 225 s= 226 c=IN IP4 host.atlanta.example.com 227 t=0 0 228 m=audio 49170 RTP/AVP 18 229 a=rtpmap:18 G729/8000 230 a=fmtp:18 annexb=yes 232 [Answer with G729 and no annexb parameter] 234 v=0 235 o=bob 1890844326 1890844326 IN IP4 host.bangalore.example.com 236 s= 237 c=IN IP4 host.bangalore.example.com 238 t=0 0 239 m=audio 19140 RTP/AVP 18 240 a=rtpmap:18 G729/8000 242 In the above example the offerer and answerer proceed as if G729 is 243 negotiated with annexb=yes. 245 4.3. Offer with G729 and no annexb parameter and answer with G729 246 annexb=no 248 [Offer with G729 and no annexb parameter] 250 v=0 251 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 252 s= 253 c=IN IP4 host.atlanta.example.com 254 t=0 0 255 m=audio 49170 RTP/AVP 18 256 a=rtpmap:18 G729/8000 258 [Answer with G729 annexb=no] 260 v=0 261 o=bob 1890844326 1890844326 IN IP4 host.bangalore.example.com 262 s= 263 c=IN IP4 host.bangalore.example.com 264 t=0 0 265 m=audio 19140 RTP/AVP 18 266 a=rtpmap:18 G729/8000 267 a=fmtp:18 annexb=no 269 In the above example the offerer and answerer proceed as if G729 is 270 negotiated with annexb=no. 272 5. Security Considerations 274 The guidelines described in [RFC6562] are to be followed for Use of 275 Voice Activity Detection (i.e Annex A or Annex B) with SRTP. 277 6. IANA Considerations 279 There is no IANA consideration for this draft. 281 7. Acknowledgment 283 Thanks to Flemming Andreasen (Cisco), Miguel A. Garcia (Ericsson), 284 Ali C. Begen (Cisco), Paul Kyzivat (Huawei), Roni Even (Huawei), 285 Kevin Riley (Sonus), Ashish Sharma (Sonus), Kevin P. Fleming 286 (Digium), Dale Worley (Avaya), Cullen Jennings (Cisco), Ari Keranen 287 (Ericsson), Harprit S. Chhatwal (InnoMedia), Aurelien Sollaud 288 (Orange), SM, Stephen Casner, Keith Drage (Alcatel-Lucent), Stephen 289 Farrell, Barry Leiba and Ted Lemon for their valuable inputs and 290 comments. Martin Dolly (ATT) and Hadriel Kaplan (Acme Packet) 291 provided useful suggestions at the mic at IETF-83. 293 8. Normative References 295 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 296 Requirement Levels", BCP 14, RFC 2119, March 1997. 298 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 299 with Session Description Protocol (SDP)", RFC 3264, 300 June 2002. 302 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 303 Video Conferences with Minimal Control", STD 65, RFC 3551, 304 July 2003. 306 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 307 Description Protocol", RFC 4566, July 2006. 309 [RFC4856] Casner, S., "Media Type Registration of Payload Formats in 310 the RTP Profile for Audio and Video Conferences", 311 RFC 4856, February 2007. 313 [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of 314 Variable Bit Rate Audio with Secure RTP", RFC 6562, 315 March 2012. 317 Authors' Addresses 319 Muthu Arul Mozhi Perumal 320 Cisco Systems 321 Cessna Business Park 322 Sarjapur-Marathahalli Outer Ring Road 323 Bangalore, Karnataka 560103 324 India 326 Email: mperumal@cisco.com 328 Parthasarathi Ravindran 329 Nokia Solutions and Networks 330 Manyata Embassy Business park 331 Bangalore, Karnataka 560045 332 India 334 Email: partha@parthasarathi.co.in