Skip to main content

Offer/Answer Considerations for G723 Annex A and G729 Annex B
draft-ietf-mmusic-sdp-g723-g729-05

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7261.
Authors Muthu Arul Perumal , Parthasarathi Ravindran
Last updated 2014-02-20 (Latest revision 2014-01-29)
Replaces draft-ietf-mmusic-sdp-g273-g729
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Ari Keränen
Shepherd write-up Show Last changed 2013-10-25
IESG IESG state Became RFC 7261 (Proposed Standard)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Gonzalo Camarillo
Send notices to mmusic-chairs@tools.ietf.org, draft-ietf-mmusic-sdp-g723-g729@tools.ietf.org
IANA IANA review state IANA OK - No Actions Needed
draft-ietf-mmusic-sdp-g723-g729-05
MMUSIC                                                Muthu A M. Perumal
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                Parthasarathi. Ravindran
Expires: August 2, 2014                     Nokia Solutions and Networks
                                                        January 29, 2014

     Offer/Answer Considerations for G723 Annex A and G729 Annex B
                   draft-ietf-mmusic-sdp-g723-g729-05

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 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 2, 2014.

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      Expires August 2, 2014                 [Page 1]
Internet-Draft   Offer/Answer G723 AnnexA & G729 AnnexB     January 2014

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Offer/Answer Considerations . . . . . . . . . . . . . . . . . . 3
     3.1.  Offer/Answer Considerations for G723 Annex A  . . . . . . . 4
     3.2.  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  . . . . . . . . . . . . . . . . . . . . . 6
     4.3.  Offer with G729 and no annexb parameter and answer
           with G729 annexb=no . . . . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Acknowledgment  . . . . . . . . . . . . . . . . . . . . . . . . 7
   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8

Perumal & Ravindran      Expires August 2, 2014                 [Page 2]
Internet-Draft   Offer/Answer G723 AnnexA & G729 AnnexB     January 2014

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, 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

   [RFC3551] states that

Perumal & Ravindran      Expires August 2, 2014                 [Page 3]
Internet-Draft   Offer/Answer G723 AnnexA & G729 AnnexB     January 2014

      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.1.  Offer/Answer Considerations for G723 Annex A

   The general objective of the below offer/answer considerations is to
   make sure that if the offerer or answerer indicates it does not
   support Annex A, Annex A is not used.

   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 such case 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.2.  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.

   The general objective of the below offer/answer considerations is to
   make sure that if the offerer or answerer indicates it does not
   support Annex B, Annex B is not used.

Perumal & Ravindran      Expires August 2, 2014                 [Page 4]
Internet-Draft   Offer/Answer G723 AnnexA & G729 AnnexB     January 2014

   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
      answer.  In such case 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 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

Perumal & Ravindran      Expires August 2, 2014                 [Page 5]
Internet-Draft   Offer/Answer G723 AnnexA & G729 AnnexB     January 2014

           [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

           [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

Perumal & Ravindran      Expires August 2, 2014                 [Page 6]
Internet-Draft   Offer/Answer G723 AnnexA & G729 AnnexB     January 2014

           [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

   There is no extra security consideration apart from what is described
   in [RFC4856].

6.  IANA Considerations

   There is no IANA consideration for this draft.

7.  Acknowledgment

   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 and Keith Drage (Alcatel-Lucent) for
   their valuable inputs and comments.  Martin Dolly (ATT) and Hadriel
   Kaplan (Acme Packet) provided useful suggestions at the mic at
   IETF-83.

Perumal & Ravindran      Expires August 2, 2014                 [Page 7]
Internet-Draft   Offer/Answer G723 AnnexA & G729 AnnexB     January 2014

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.

   [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.

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
   Nokia Solutions and Networks
   Manyata Embassy Business park
   Bangalore, Karnataka  560045
   India

   Email: partha@parthasarathi.co.in

Perumal & Ravindran      Expires August 2, 2014                 [Page 8]