MMUSIC Muthu AInternet Engineering Task Force (IETF) M. PerumalInternet-DraftRequest for Comments: 7261 Cisco SystemsIntended status:Category: Standards TrackParthasarathi.P. RavindranExpires: September 1, 2014 Nokia Solutions and Networks February 28,ISSN: 2070-1721 NSN May 2014 Offer/Answer Considerations for G723 Annex A and G729 Annex Bdraft-ietf-mmusic-sdp-g723-g729-06Abstract This document provides the offer/answer considerations for the annexa parameter of G723 and the annexb parameter of G729,G729DG729D, and G729E when the value of the annexa or annexb parameter does not match in the Session DescriptionprotocolProtocol (SDP) offer and answer. Status ofthisThis Memo ThisInternet-Draftissubmitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved fora maximumpublication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status ofsix monthsthis document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 1, 2014.http://www.rfc-editor.org/info/rfc7261. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .. 32 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . ..3 3. Offer/Answer Considerations . . . . . . . . . . . . . . . . ..3 3.1. Considerations for Use of Comfort Noise Frames . . . . .. 43 3.2. Offer/Answer Considerations for G723 Annex A . . . . . .. 43 3.3. Offer/Answer Considerations for G729 Annex B, G729D AnnexBB, and G729E Annex B . . . . . . . . . . . . . . . . . . 4 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . ..5 4.1. Offer with G729 annexb=yes andanswerAnswer with G729 annexb=no. . . . . . . . . . . . . . . . . . . . . . . . .5 4.2. Offer with G729 annexb=yes andanswerAnswer with G729 andnoNo annexb parameter . . . . . . . . . . . . . . . . . . . .. 65 4.3. Offer with G729 andnoNo annexbparameterParameter andanswerAnswer with G729 annexb=no . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . .. 76 6.IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgment .Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 78.7. Normative References . . . . . . . . . . . . . . . . . . . ..7Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 81. Introduction [RFC4856] describes the annexa parameter for G723 as follows: annexa: indicates that Annex A, voice activity detection, is used or preferred. Permissible values are "yes" and "no" (without the quotes); "yes" is implied if this parameter is omitted. Also, [RFC4856] describes the annexb parameter for G729,G729DG729D, and G729E as follows: annexb: indicates that Annex B, voice activity detection, is used or preferred. Permissible values are "yes" and "no" (without the quotes); "yes" is implied if this parameter is omitted. However, a problem arises when the value of the annexa or annexb parameter does not match in the SDP [RFC4566] offer and answer. For example, if the offer has G729 with annexb=yes and the answer has G729 with annexb=no, it can be interpreted in two different ways: o The offerer and answerer proceed as if G729 is negotiated with annexb=yes, or o The offerer and answerer proceed as if G729 is negotiated with annexb=no. Since this is not clear in the existing specifications, various implementations have interpreted the offer/answer in their own ways, resulting in a different codec being chosen to call failure, when the parameter value does not match in the offer and answer. [RFC3264] requires SDP extensions that define new fmtp parameters to specify their proper interpretation in offer/answer. This document specifies the proper interpretation for the annexa and annexb parameters in offer/answer. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Offer/Answer Considerations The general objective of the offer/answer considerations is to make sure that if the offerer or answerer indicates it does not support Annex A or Annex B, then Annex A or Annex B is not used. 3.1. Considerations for Use of Comfort Noise Frames [RFC3551] statesthatthat: Receivers MUST accept comfort noise frames if restriction of their use has not been signaled. The MIME registration for G729 in RFC 3555 specifies a parameter that MAY be used with MIME or SDP to restrict the use of comfort noise frames. Hence, if the SDP offer or answer indicates that comfort noise is not supported, comfort noise frames MUST NOT be used. 3.2. Offer/Answer Considerations for G723 Annex A When the offer or answer has G723 and the annexa parameter is absent, the offerer or answerer knows that it has implied the default "annexa=yes". This is because the annexa attribute is part of the original registration of audio/G723 [RFC4856]. All implementations that support G723 understand the annexa attribute. Hence, this case MUST be considered as if the offer or answer has G723 with annexa=yes. When the offer has G723 with annexa=yes and the answer has G723 with annexa=no, the offerer and answerer MUST proceed as if G723 is negotiated with annexa=no. When the offer has G723 with annexa=no, after the offer/answer completion the offerer and answerer MUST proceed as if G723 is negotiated with annexa=no. When the offer has G723 with annexa=no, the reason for not mandating that the answer MUST have annexa=no for G723 is that there are implementations that omit the annexa parameter in answer. In suchcasecases, the offerer and answerer proceed as if G723 is negotiated with annexa=no. When the offer has G723 with no annexa parameter and the answer has G723 with annexa=yes, the offerer and answerer MUST proceed as if G723 is negotiated with annexa=yes. 3.3. Offer/Answer Considerations for G729 Annex B, G729D AnnexBB, and G729E Annex B In thissectionsection, G729 represents any of G729 or G729D or G729E. When the offer or answer has G729 and the annexb parameter is absent, the offerer or answerer knows that it has implied the default "annexb=yes". This is because the annexb attribute is part of the original registration of audio/G729 [RFC4856]. All implementations that support G729 understand the annexb attribute. Hence, this case MUST be considered as if the offer or answer has G729 with annexb=yes. When the offer has G729 with annexb=yes and the answer has G729 with annexb=no, the offerer and answerer MUST proceed as if G729 is negotiated with annexb=no. When the offer has G729 with annexb=no, after the offer/answer completion the offerer and answerer MUST proceed as if G729 is negotiated with annexb=no. When the offer has G729 with annexb=no, the reason for not mandating that the answer MUST have annexb=no for G729 is that there are implementations that omit the annexb parameter in the answer. In suchcasecases, the offerer and answerer proceed as if G729 is negotiated with annexb=no. When the offer has G729 with no annexb parameter and the answer has G729 with annexb=yes, the offerer and answerer MUST proceed as if G729 is negotiated with annexb=yes. 4. Examples 4.1. Offer with G729 annexb=yes andanswerAnswer with G729 annexb=no [Offer with G729 annexb=yes] v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 18 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=yes [Answer with G729 annexb=no] v=0 o=bob 1890844326 1890844326 IN IP4 host.bangalore.example.com s= c=IN IP4 host.bangalore.example.com t=0 0 m=audio 19140 RTP/AVP 18 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no In the aboveexampleexample, the offerer and answerer proceed as if G729 is negotiated with annexb=no. 4.2. Offer with G729 annexb=yes andanswerAnswer with G729 andnoNo annexb parameter [Offer with G729 annexb=yes] v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 18 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=yes [Answer with G729 and no annexb parameter] v=0 o=bob 1890844326 1890844326 IN IP4 host.bangalore.example.com s= c=IN IP4 host.bangalore.example.com t=0 0 m=audio 19140 RTP/AVP 18 a=rtpmap:18 G729/8000 In the aboveexampleexample, the offerer and answerer proceed as if G729 is negotiated with annexb=yes. 4.3. Offer with G729 andnoNo annexbparameterParameter andanswerAnswer with G729 annexb=no [Offer with G729 and no annexb parameter] v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 18 a=rtpmap:18 G729/8000 [Answer with G729 annexb=no] v=0 o=bob 1890844326 1890844326 IN IP4 host.bangalore.example.com s= c=IN IP4 host.bangalore.example.com t=0 0 m=audio 19140 RTP/AVP 18 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no In the aboveexampleexample, the offerer and answerer proceed as if G729 is negotiated with annexb=no. 5. Security Considerations The guidelines described in [RFC6562] are to be followed for Use of Voice Activity Detection(i.e(i.e., Annex A or Annex B) withSRTP.the Secure Real-time Transport Protocol (SRTP). 6.IANA Considerations There is no IANA consideration for this draft. 7. AcknowledgmentAcknowledgments Thanks to Flemming Andreasen (Cisco), Miguel A. Garcia (Ericsson), Ali C. Begen (Cisco), Paul Kyzivat (Huawei), Roni Even (Huawei), Kevin Riley (Sonus), Ashish Sharma (Sonus), Kevin P. Fleming (Digium), Dale Worley (Avaya), Cullen Jennings (Cisco), Ari Keranen (Ericsson), Harprit S. Chhatwal (InnoMedia), Aurelien Sollaud (Orange), SM, Stephen Casner, Keith Drage (Alcatel-Lucent), Stephen Farrell, BarryLeibaLeiba, and Ted Lemon for their valuableinputsinput and comments. Martin Dolly (ATT) and Hadriel Kaplan (Acme Packet) provided useful suggestions at the mic atIETF-83. 8.IETF 83. 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4856] Casner, S., "Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences", RFC 4856, February 2007. [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, March 2012. Authors' Addresses Muthu Arul Mozhi Perumal Cisco Systems Cessna Business Park Sarjapur-Marathahalli Outer Ring Road Bangalore, Karnataka 560103 IndiaEmail:EMail: mperumal@cisco.com Parthasarathi RavindranNokia Solutions and NetworksNSN Manyata Embassy Business park Bangalore, Karnataka 560045 IndiaEmail:EMail: partha@parthasarathi.co.in