Internet Engineering Task Force (IETF) M. Perumal
Request for Comments: 7261 Cisco Systems
Category: Standards Track P. Ravindran
ISSN: 2070-1721 NSN
May 2014
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
G723附录A和G729附录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.
本文件提供了当附录A或附录B参数的值与会话描述协议（SDP）提供和应答中的值不匹配时，G723的附录A参数和G729、G729D和G729E的附录B参数的提供/应答注意事项。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 . . . . . . . . . . . . . . . . . . . . . . . . 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
[RFC4856] describes the annexa parameter for G723 as follows:
[RFC4856]对G723的附录A参数描述如下：
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.
附录A：表示使用或首选附录A“语音活动检测”。允许值为“是”和“否”（不带引号）；如果省略此参数，则表示“是”。
Also, [RFC4856] describes the annexb parameter for G729, G729D, and G729E as follows:
此外，[RFC4856]对G729、G729D和G729E的附录B参数描述如下：
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.
附录B：表示使用或首选附录B“语音活动检测”。允许值为“是”和“否”（不带引号）；如果省略此参数，则表示“是”。
However, a problem arises when the value of the annexa or annexb parameter does not match in the SDP [RFC4566] offer and answer.
但是，当附录a或附录B参数的值与SDP[RFC4566]报价和应答中的值不匹配时，会出现问题。
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:
例如，如果报价的G729带有附录B=是，而答案的G729带有附录B=否，则可以用两种不同的方式进行解释：
o The offerer and answerer proceed as if G729 is negotiated with annexb=yes, or
o 报价人和应答人继续进行，就好像G729与附录B协商一样=是，或
o The offerer and answerer proceed as if G729 is negotiated with annexb=no.
o 报价人和应答人继续进行，就好像G729与附录B=否进行谈判一样。
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.
[RFC3264]要求SDP扩展定义新的fmtp参数，以在报价/应答中指定其正确解释。本文件规定了报价/应答中附录A和附录B参数的正确解释。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
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.
报价/应答考虑的总体目标是确保如果报价人或应答人表示不支持附件A或附件B，则不使用附件A或附件B。
[RFC3551] states that:
[RFC3551]声明：
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.
如果未发出使用限制信号，则接收器必须接受舒适噪音框架。RFC 3555中G729的MIME注册指定了一个参数，该参数可与MIME或SDP一起使用，以限制舒适噪声帧的使用。
Hence, if the SDP offer or answer indicates that comfort noise is not supported, comfort noise frames MUST NOT be used.
因此，如果SDP报价或应答表明不支持舒适性噪音，则不得使用舒适性噪音框。
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.
当报价或答复包含G723且附录A参数不存在时，报价人或答复人知道其暗示默认“附录A=是”。这是因为annexa属性是audio/G723[RFC4856]原始注册的一部分。所有支持G723的实现都理解annexa属性。因此，必须将这种情况视为报价或答复包含附录A=是的G723。
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.
当报价中有附录A=yes的G723，而答案中有附录A=no的G723时，报价人和应答人必须按照附录A=no谈判G723的方式进行。
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.
当报价包含附录A=no的G723时，在报价/应答完成后，报价人和应答人必须继续进行，就像G723与附录A=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.
当报价中包含附录A=no的G723时，不要求G723的答案必须包含附录A=no的原因是，有些实现在答案中省略了附录A参数。在这种情况下，报价人和应答人继续进行，就好像G723与附录A=否进行谈判一样。
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.
当报价中有G723且无附录A参数，且答案中有G723且附录A=yes时，报价人和应答人必须继续，就好像G723与附录A=yes协商一样。
3.3. Offer/Answer Considerations for G729 Annex B, G729D Annex B, and G729E Annex B
3.3. G729附录B、G729D附录B和G729E附录B的报价/应答注意事项
In this section, G729 represents any of G729 or G729D or G729E.
在本节中，G729表示G729、G729D或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.
当报价或应答包含G729且附录B参数不存在时，报价人或应答人知道其隐含默认“附录B=是”。这是因为annexb属性是audio/G729[RFC4856]原始注册的一部分。所有支持G729的实现都理解annexb属性。因此，必须将这种情况视为报价或答复中包含附录B=是的G729。
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.
当报价中有附录B=是的G729，而答案中有附录B=否的G729时，报价人和应答人必须继续进行，就好像G729是与附录B=否进行谈判一样。
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.
当报价包含附录B=否的G729时，在报价/应答完成后，报价人和应答人必须继续进行，就像G729与附录B=否进行谈判一样。
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.
当报价中包含附录B=no的G729时，不要求G729的答案必须包含附录B=no的原因是有一些实现在答案中省略了附录B参数。在这种情况下，报价人和应答人继续进行，就好像G729与附录B=否协商一样。
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.
当报价中有G729且无附录B参数，且答案中有G729且附录B=yes时，报价人和应答人必须继续进行，就好像G729与附录B=yes协商一样。
[Offer with G729 annexb=yes]
[提供G729附录B=是]
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
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]
[回答G729附录B=否]
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
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.
在上述示例中，报价人和应答人继续进行，就好像G729与附录B=否进行谈判一样。
4.2. Offer with G729 annexb=yes and Answer with G729 and No annexb Parameter
4.2. 提供G729附录B=是，回答G729和否附录B参数
[Offer with G729 annexb=yes]
[提供G729附录B=是]
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
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]
[用G729回答，无附录B参数]
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
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.
在上述示例中，报价人和应答人继续进行，就好像G729与附录B=是进行谈判一样。
4.3. Offer with G729 and No annexb Parameter and Answer with G729 annexb=no
4.3. 提供G729且无附录B参数，回答G729附录B=否
[Offer with G729 and no annexb parameter]
[带有G729且无附录B参数的报价]
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
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]
[回答G729附录B=否]
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
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.
在上述示例中，报价人和应答人继续进行，就好像G729与附录B=否进行谈判一样。
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).
语音活动检测（即附录A或附录B）与安全实时传输协议（SRTP）的使用应遵循[RFC6562]中所述的指南。
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.
感谢Flemming Andreasen（思科）、Miguel A.Garcia（爱立信）、Ali C.Begen（思科）、Paul Kyzivat（华为）、Roni Even（华为）、Kevin Riley（索努斯）、Ashish Sharma（索努斯）、Kevin P.Fleming（Digium）、Dale Worley（Avaya）、Cullen Jennings（思科）、Ari Keranen（爱立信）、Harprit S.Chhatwal（InnoMedia）、Aurelian Sollaud（橙色）、SM、，斯蒂芬·卡斯纳、基思·德拉格（阿尔卡特-朗讯）、斯蒂芬·法雷尔、巴里·莱巴和特德·莱蒙，感谢他们的宝贵意见和评论。Martin Dolly（ATT）和Hadriel Kaplan（Acme Packet）在IETF 83的mic上提供了有用的建议。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551]Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC4856] Casner, S., "Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences", RFC 4856, February 2007.
[RFC4856]Casner，S.，“音频和视频会议RTP配置文件中有效负载格式的媒体类型注册”，RFC 4856，2007年2月。
[RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, March 2012.
[RFC6562]Perkins，C.和JM。Valin，“带安全RTP的可变比特率音频使用指南”，RFC 6562，2012年3月。
Authors' Addresses
作者地址
Muthu Arul Mozhi Perumal Cisco Systems Cessna Business Park Sarjapur-Marathahalli Outer Ring Road Bangalore, Karnataka 560103 India
印度卡纳塔克邦班加罗尔Sarjapur Marathahalli外环路思科系统塞斯纳商业园
EMail: mperumal@cisco.com
EMail: mperumal@cisco.com
Parthasarathi Ravindran NSN Manyata Embassy Business park Bangalore, Karnataka 560045 India
印度卡纳塔克邦班加罗尔市曼雅塔大使馆商务园Parthasarathi Ravindran NSN 560045
EMail: partha@parthasarathi.co.in
EMail: partha@parthasarathi.co.in