Payload Muthu A M. Perumal Internet-Draft Cisco Systems Intended status: Standards Track Parthasarathi. Ravindran Expires: August 27, 2012 Sonus Networks February 24, 2012 Offer/Answer Considerations for G.723 Annex A and G.729 Annex B draft-muthu-payload-offer-answer-g723-g729-00 Abstract [RFC4856] describes the annexa parameter for G723 and the annexb parameter for G729, G729D and G729E. However, the specification does not describe the offerer and answerer behavior when the value of the annexa or annexb parameter does not match in the SDP offer and answer. This document provides the offer/answer considerations for these parameters. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any 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 August 27, 2012. Copyright Notice Copyright (c) 2012 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 Perumal & Ravindran Expires August 27, 2012 [Page 1] Internet-Draft Offer/Answer G723 AnnexA & G729 AnnexB February 2012 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Offer/Answer Considerations . . . . . . . . . . . . . . . . . . 4 3.1. Offer/Answer Considerations for G723 Annex A . . . . . . . 4 3.2. Offer/Answer Considerations for G.729 Annex B, G.729D Annex B and G.729E Annex B . . . . . . . . . . . . . . . . 4 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Offer with G279 annexb=yes and answer with G279 annexb=no . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Offer with G279 annexb=yes and answer with G729 and no annexb parameter . . . . . . . . . . . . . . . . . . . . . 6 4.3. Offer with G279 and no annexb parameter and answer with G729 annexb=no . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Perumal & Ravindran Expires August 27, 2012 [Page 2] Internet-Draft Offer/Answer G723 AnnexA & G729 AnnexB February 2012 1. 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, G729D 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, it does not have any normative statement for the case where the value of this parameter does not match in the SDP 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. o The offerer and answerer proceed as if G729 is negotiated with annexb=no. Since [RFC4856] does not state it clearly, various implementations have interpreted the offer/answer in their own ways, resulting in a different codec parameter being chosen to call failure, when the parameter value does not match in the offer and answer. [RFC3264] section 6.1 states that SDP extensions that define new fmtp parameters SHOULD specify the proper interpretation in offer/answer. But, [RFC4856] does not specify it for the Annex A flavor of G.723 and the Annex B flavors of G.729, G729D and G729E. This document describes the offer/answer considerations for these parameters and provides the necessary clarifications. 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]. Perumal & Ravindran Expires August 27, 2012 [Page 3] Internet-Draft Offer/Answer G723 AnnexA & G729 AnnexB February 2012 3. Offer/Answer Considerations [RFC3551] states that 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. Based on the above it is best to not use comfort noise frames if the SDP offer or answer indicates no support for it. 3.1. Offer/Answer Considerations for G723 Annex A When the offer or answer has G723 and the annexa parameter is absent, it 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 then the answer MUST NOT have annexa=yes for G723. Thus the annexa parameter can be turned off by the answerer, but cannot be turned on. Open item: Should the above be restated as follows? When the offer has G723 with annexa=no then the answer MUST have annexa=no for G723. This is technically correct, but are there implementations that omit the annexa parameter in answer and expect the least common denominator to be used? 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.2. Offer/Answer Considerations for G.729 Annex B, G.729D Annex B and G.729E Annex B In this section G729 represents any of G729 or G729D or G729E. When the offer or answer has G729 and the annexb parameter is absent, it 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 Perumal & Ravindran Expires August 27, 2012 [Page 4] Internet-Draft Offer/Answer G723 AnnexA & G729 AnnexB February 2012 negotiated with annexb=no. When the offer has G729 with annexb=no then the answer MUST NOT have annexb=yes for G729. Thus the annexb parameter can be turned off by the answerer, but cannot be turned on. Open item: Should the above be restated as follows? When the offer has G729 with annexb=no then the answer MUST have annexb=no for G729. This is technically correct, but are there implementations that omit the annexb parameter in answer and expect the least common denominator to be used? When the offer has G.729 with no annexb parameter and the answer has G.729 with annexb=yes, the offerer and answerer MUST proceed as if G.729 is negotiated with annexb=yes. 4. Examples 4.1. Offer with G279 annexb=yes and answer with G279 annexb=no [Offer with G279 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 above example the offerer and answerer proceed as if G729 is negotiated with annexb=no. Perumal & Ravindran Expires August 27, 2012 [Page 5] Internet-Draft Offer/Answer G723 AnnexA & G729 AnnexB February 2012 4.2. Offer with G279 annexb=yes and answer with G729 and no annexb parameter [Offer with G279 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 above example the offerer and answerer proceed as if G729 is negotiated with annexb=yes. 4.3. Offer with G279 and no annexb parameter and answer with G729 annexb=no [Offer with G279 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 Perumal & Ravindran Expires August 27, 2012 [Page 6] Internet-Draft Offer/Answer G723 AnnexA & G729 AnnexB February 2012 [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 above example the offerer and answerer proceed as if G729 is negotiated with annexb=no. 5. Security Considerations There is no extra security required apart from what is described in [RFC4856]. 6. IANA Considerations There is no IANA consideration for this draft. 7. Acknowledgement Thanks to Flemming Andreasen (Cisco), Paul Kyzivat, Kevin Riley (Sonus), Ashish Sharma (Sonus) for their valuable comments and inputs. 8. 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. [RFC4856] Casner, S., "Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences", RFC 4856, February 2007. [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, Perumal & Ravindran Expires August 27, 2012 [Page 7] Internet-Draft Offer/Answer G723 AnnexA & G729 AnnexB February 2012 July 2003. Authors' Addresses Muthu Arul Mozhi Perumal Cisco Systems Cessna Business Park Sarjapur-Marathahalli Outer Ring Road Bangalore, Karnataka 560103 India Email: mperumal@cisco.com Parthasarathi Ravindran Sonus Networks Prestige Shantiniketan - Business Precinct Whitefield Road Bangalore, Karnataka 560066 India Email: pravindran@sonusnet.com Perumal & Ravindran Expires August 27, 2012 [Page 8]