MMUSIC Muthu A M. Perumal
Internet-Draft Cisco Systems
Updates: 4856 (if approved) Parthasarathi. Ravindran
Intended status: Standards Track Nokia Siemens Networks
Expires: January 16, 2014 July 15, 2013
Offer/Answer Considerations for G723 Annex A and G729 Annex B
draft-ietf-mmusic-sdp-g723-g729-04
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 Session Description
protocol(SDP) offer and answer. This document provides the offer/
answer considerations for these parameters and updates RFC4856.
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 January 16, 2014.
Copyright Notice
Copyright (c) 2013 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 January 16, 2014 [Page 1]
Internet-Draft Offer/Answer G723 AnnexA & G729 AnnexB July 2013
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 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. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Perumal & Ravindran Expires January 16, 2014 [Page 2]
Internet-Draft Offer/Answer G723 AnnexA & G729 AnnexB July 2013
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 [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 [RFC4856] does not state it clearly, 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. But, [RFC4856]
does not specify it for the Annex A flavor of G723 and the Annex B
flavors of G729, 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 January 16, 2014 [Page 3]
Internet-Draft Offer/Answer G723 AnnexA & G729 AnnexB July 2013
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.
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.
Perumal & Ravindran Expires January 16, 2014 [Page 4]
Internet-Draft Offer/Answer G723 AnnexA & G729 AnnexB July 2013
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.
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 January 16, 2014 [Page 5]
Internet-Draft Offer/Answer G723 AnnexA & G729 AnnexB July 2013
[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 January 16, 2014 [Page 6]
Internet-Draft Offer/Answer G723 AnnexA & G729 AnnexB July 2013
[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. Acknowledgement
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) and Aurelien Sollaud
(Orange) 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 January 16, 2014 [Page 7]
Internet-Draft Offer/Answer G723 AnnexA & G729 AnnexB July 2013
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 Siemens Networks
Manyata Embassy Business park
Bangalore, Karnataka
India
Email: partha@parthasarathi.co.in
Perumal & Ravindran Expires January 16, 2014 [Page 8]