GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7261

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7261.txt · Last modified: 2014/05/30 21:37 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki