draft-ietf-mmusic-sdp-g723-g729-05.txt   draft-ietf-mmusic-sdp-g723-g729-06.txt 
MMUSIC Muthu A M. Perumal MMUSIC Muthu A M. Perumal
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track Parthasarathi. Ravindran Intended status: Standards Track Parthasarathi. Ravindran
Expires: August 2, 2014 Nokia Solutions and Networks Expires: September 1, 2014 Nokia Solutions and Networks
January 29, 2014 February 28, 2014
Offer/Answer Considerations for G723 Annex A and G729 Annex B Offer/Answer Considerations for G723 Annex A and G729 Annex B
draft-ietf-mmusic-sdp-g723-g729-05 draft-ietf-mmusic-sdp-g723-g729-06
Abstract Abstract
This document provides the offer/answer considerations for the annexa This document provides the offer/answer considerations for the annexa
parameter of G723 and the annexb parameter of G729, G729D and G729E 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 when the value of the annexa or annexb parameter does not match in
the Session Description protocol (SDP) offer and answer. the Session Description protocol (SDP) offer and answer.
Status of this Memo Status of this Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 2, 2014. This Internet-Draft will expire on September 1, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 10 skipping to change at page 2, line 10
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Offer/Answer Considerations . . . . . . . . . . . . . . . . . . 3 3. Offer/Answer Considerations . . . . . . . . . . . . . . . . . . 3
3.1. Offer/Answer Considerations for G723 Annex A . . . . . . . 4 3.1. Considerations for Use of Comfort Noise Frames . . . . . . 4
3.2. Offer/Answer Considerations for G729 Annex B, G729D 3.2. Offer/Answer Considerations for G723 Annex A . . . . . . . 4
3.3. Offer/Answer Considerations for G729 Annex B, G729D
Annex B and G729E Annex B . . . . . . . . . . . . . . . . . 4 Annex B and G729E Annex B . . . . . . . . . . . . . . . . . 4
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Offer with G729 annexb=yes and answer with G729 4.1. Offer with G729 annexb=yes and answer with G729
annexb=no . . . . . . . . . . . . . . . . . . . . . . . . . 5 annexb=no . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Offer with G729 annexb=yes and answer with G729 and no 4.2. Offer with G729 annexb=yes and answer with G729 and no
annexb parameter . . . . . . . . . . . . . . . . . . . . . 6 annexb parameter . . . . . . . . . . . . . . . . . . . . . 6
4.3. Offer with G729 and no annexb parameter and answer 4.3. Offer with G729 and no annexb parameter and answer
with G729 annexb=no . . . . . . . . . . . . . . . . . . . . 6 with G729 annexb=no . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
[RFC4856] describes the annexa parameter for G723 as follows: [RFC4856] describes the annexa parameter for G723 as follows:
annexa: indicates that Annex A, voice activity detection, is used annexa: indicates that Annex A, voice activity detection, is used
or preferred. Permissible values are "yes" and "no" (without the or preferred. Permissible values are "yes" and "no" (without the
quotes); "yes" is implied if this parameter is omitted. quotes); "yes" is implied if this parameter is omitted.
skipping to change at page 3, line 48 skipping to change at page 3, line 48
parameters in offer/answer. parameters in offer/answer.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Offer/Answer Considerations 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 [RFC3551] states that
Receivers MUST accept comfort noise frames if restriction of their Receivers MUST accept comfort noise frames if restriction of their
use has not been signaled. The MIME registration for G729 in RFC 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 3555 specifies a parameter that MAY be used with MIME or SDP to
restrict the use of comfort noise frames. restrict the use of comfort noise frames.
Hence, if the SDP offer or answer indicates that comfort noise is not Hence, if the SDP offer or answer indicates that comfort noise is not
supported, comfort noise frames MUST NOT be used. supported, comfort noise frames MUST NOT be used.
3.1. Offer/Answer Considerations for G723 Annex A 3.2. 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, When the offer or answer has G723 and the annexa parameter is absent,
the offerer or answerer knows that it has implied the default the offerer or answerer knows that it has implied the default
"annexa=yes". This is because the annexa attribute is part of the "annexa=yes". This is because the annexa attribute is part of the
original registration of audio/G723 [RFC4856]. All implementations original registration of audio/G723 [RFC4856]. All implementations
that support G723 understand the annexa attribute. Hence, this case that support G723 understand the annexa attribute. Hence, this case
MUST be considered as if the offer or answer has G723 with MUST be considered as if the offer or answer has G723 with
annexa=yes. annexa=yes.
When the offer has G723 with annexa=yes and the answer has G723 with When the offer has G723 with annexa=yes and the answer has G723 with
skipping to change at page 4, line 44 skipping to change at page 4, line 45
When the offer has G723 with annexa=no, the reason for not When the offer has G723 with annexa=no, the reason for not
mandating that the answer MUST have annexa=no for G723 is that mandating that the answer MUST have annexa=no for G723 is that
there are implementations that omit the annexa parameter in there are implementations that omit the annexa parameter in
answer. In such case the offerer and answerer proceed as if G723 answer. In such case the offerer and answerer proceed as if G723
is negotiated with annexa=no. is negotiated with annexa=no.
When the offer has G723 with no annexa parameter and the answer has 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 with annexa=yes, the offerer and answerer MUST proceed as if
G723 is negotiated with annexa=yes. G723 is negotiated with annexa=yes.
3.2. Offer/Answer Considerations for G729 Annex B, G729D Annex B and 3.3. Offer/Answer Considerations for G729 Annex B, G729D Annex B and
G729E Annex B G729E Annex B
In this section G729 represents any of G729 or G729D or G729E. 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.
When the offer or answer has G729 and the annexb parameter is absent, When the offer or answer has G729 and the annexb parameter is absent,
the offerer or answerer knows that it has implied the default the offerer or answerer knows that it has implied the default
"annexb=yes". This is because the annexb attribute is part of the "annexb=yes". This is because the annexb attribute is part of the
original registration of audio/G729 [RFC4856]. All implementations original registration of audio/G729 [RFC4856]. All implementations
that support G729 understand the annexb attribute. Hence, this case that support G729 understand the annexb attribute. Hence, this case
MUST be considered as if the offer or answer has G729 with MUST be considered as if the offer or answer has G729 with
annexb=yes. annexb=yes.
When the offer has G729 with annexb=yes and the answer has G729 with 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 annexb=no, the offerer and answerer MUST proceed as if G729 is
skipping to change at page 7, line 31 skipping to change at page 7, line 21
t=0 0 t=0 0
m=audio 19140 RTP/AVP 18 m=audio 19140 RTP/AVP 18
a=rtpmap:18 G729/8000 a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no a=fmtp:18 annexb=no
In the above example the offerer and answerer proceed as if G729 is In the above example the offerer and answerer proceed as if G729 is
negotiated with annexb=no. negotiated with annexb=no.
5. Security Considerations 5. Security Considerations
There is no extra security consideration apart from what is described The guidelines described in [RFC6562] are to be followed for Use of
in [RFC4856]. Voice Activity Detection (i.e Annex A or Annex B) with SRTP.
6. IANA Considerations 6. IANA Considerations
There is no IANA consideration for this draft. There is no IANA consideration for this draft.
7. Acknowledgment 7. Acknowledgment
Thanks to Flemming Andreasen (Cisco), Miguel A. Garcia (Ericsson), Thanks to Flemming Andreasen (Cisco), Miguel A. Garcia (Ericsson),
Ali C. Begen (Cisco), Paul Kyzivat (Huawei), Roni Even (Huawei), Ali C. Begen (Cisco), Paul Kyzivat (Huawei), Roni Even (Huawei),
Kevin Riley (Sonus), Ashish Sharma (Sonus), Kevin P. Fleming Kevin Riley (Sonus), Ashish Sharma (Sonus), Kevin P. Fleming
(Digium), Dale Worley (Avaya), Cullen Jennings (Cisco), Ari Keranen (Digium), Dale Worley (Avaya), Cullen Jennings (Cisco), Ari Keranen
(Ericsson), Harprit S. Chhatwal (InnoMedia), Aurelien Sollaud (Ericsson), Harprit S. Chhatwal (InnoMedia), Aurelien Sollaud
(Orange), SM, Stephen Casner and Keith Drage (Alcatel-Lucent) for (Orange), SM, Stephen Casner, Keith Drage (Alcatel-Lucent), Stephen
their valuable inputs and comments. Martin Dolly (ATT) and Hadriel Farrell, Barry Leiba and Ted Lemon for their valuable inputs and
Kaplan (Acme Packet) provided useful suggestions at the mic at comments. Martin Dolly (ATT) and Hadriel Kaplan (Acme Packet)
IETF-83. provided useful suggestions at the mic at IETF-83.
8. Normative References 8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
skipping to change at page 8, line 25 skipping to change at page 8, line 16
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. July 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4856] Casner, S., "Media Type Registration of Payload Formats in [RFC4856] Casner, S., "Media Type Registration of Payload Formats in
the RTP Profile for Audio and Video Conferences", the RTP Profile for Audio and Video Conferences",
RFC 4856, February 2007. 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.
Authors' Addresses Authors' Addresses
Muthu Arul Mozhi Perumal Muthu Arul Mozhi Perumal
Cisco Systems Cisco Systems
Cessna Business Park Cessna Business Park
Sarjapur-Marathahalli Outer Ring Road Sarjapur-Marathahalli Outer Ring Road
Bangalore, Karnataka 560103 Bangalore, Karnataka 560103
India India
Email: mperumal@cisco.com Email: mperumal@cisco.com
 End of changes. 13 change blocks. 
23 lines changed or deleted 27 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/