diff options
Diffstat (limited to 'doc/rfc/rfc7261.txt')
| -rw-r--r-- | doc/rfc/rfc7261.txt | 451 |
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc7261.txt b/doc/rfc/rfc7261.txt new file mode 100644 index 0000000..f393635 --- /dev/null +++ b/doc/rfc/rfc7261.txt @@ -0,0 +1,451 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Perumal +Request for Comments: 7261 Cisco Systems +Category: Standards Track P. Ravindran +ISSN: 2070-1721 NSN + May 2014 + + + Offer/Answer Considerations for G723 Annex A and G729 Annex B + +Abstract + + This document provides the offer/answer considerations for the annexa + parameter of G723 and the annexb parameter of G729, G729D, and G729E + when the value of the annexa or annexb parameter does not match in + the Session Description Protocol (SDP) offer and answer. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication 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 of this document, any errata, + and how to provide feedback on it may be obtained at + 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. + + + + + + + +Perumal & Ravindran Standards Track [Page 1] + +RFC 7261 Offer/Answer G723 AnnexA and G729 AnnexB May 2014 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Offer/Answer Considerations . . . . . . . . . . . . . . . . . 3 + 3.1. Considerations for Use of Comfort Noise Frames . . . . . 3 + 3.2. Offer/Answer Considerations for G723 Annex A . . . . . . 3 + 3.3. Offer/Answer Considerations for G729 Annex B, G729D Annex + B, and G729E Annex B . . . . . . . . . . . . . . . . . . 4 + 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 4.1. Offer with G729 annexb=yes and Answer with G729 annexb=no 5 + 4.2. Offer with G729 annexb=yes and Answer with G729 and No + annexb Parameter . . . . . . . . . . . . . . . . . . . . 5 + 4.3. Offer with G729 and No annexb Parameter and Answer with + G729 annexb=no . . . . . . . . . . . . . . . . . . . . . 6 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 + 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 + 7. Normative References . . . . . . . . . . . . . . . . . . . . 7 + +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, 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. + + + + + + +Perumal & Ravindran Standards Track [Page 2] + +RFC 7261 Offer/Answer G723 AnnexA and G729 AnnexB May 2014 + + + 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] 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. + + 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. + + + + +Perumal & Ravindran Standards Track [Page 3] + +RFC 7261 Offer/Answer G723 AnnexA and G729 AnnexB May 2014 + + + 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 such cases, 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 Annex B, and + G729E 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, + 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 such cases, 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. + + + + + + + +Perumal & Ravindran Standards Track [Page 4] + +RFC 7261 Offer/Answer G723 AnnexA and G729 AnnexB May 2014 + + +4. Examples + +4.1. Offer with G729 annexb=yes and Answer 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 above example, the offerer and answerer proceed as if G729 is + negotiated with annexb=no. + +4.2. Offer with G729 annexb=yes and Answer with G729 and No 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 + + + + + + + + + +Perumal & Ravindran Standards Track [Page 5] + +RFC 7261 Offer/Answer G723 AnnexA and G729 AnnexB May 2014 + + + [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 G729 and No annexb Parameter and Answer 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 above example, 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., Annex A or Annex B) with the Secure + Real-time Transport Protocol (SRTP). + + + + + + +Perumal & Ravindran Standards Track [Page 6] + +RFC 7261 Offer/Answer G723 AnnexA and G729 AnnexB May 2014 + + +6. Acknowledgments + + 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, Barry Leiba, and Ted Lemon for their valuable input and + comments. Martin Dolly (ATT) and Hadriel Kaplan (Acme Packet) + provided useful suggestions at the mic at 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. + + + + + + + + + + + + + + + + +Perumal & Ravindran Standards Track [Page 7] + +RFC 7261 Offer/Answer G723 AnnexA and G729 AnnexB May 2014 + + +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 + NSN + Manyata Embassy Business park + Bangalore, Karnataka 560045 + India + + EMail: partha@parthasarathi.co.in + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perumal & Ravindran Standards Track [Page 8] + |