doc: Add RFC documents

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]
+