Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 8035 Ericsson
Updates: 5761 November 2016
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 8035 Ericsson
Updates: 5761 November 2016
Category: Standards Track
ISSN: 2070-1721
Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing
针对RTP/RTCP多路复用的会话描述协议（SDP）提供/应答澄清
Abstract
摘要
This document updates RFC 5761 by clarifying the SDP offer/answer negotiation of RTP and RTP Control Protocol (RTCP) multiplexing. It makes it clear that an answerer can only include an "a=rtcp-mux" attribute in a Session Description Protocol (SDP) answer if the associated SDP offer contained the attribute.
本文件通过澄清RTP和RTP控制协议（RTCP）多路复用的SDP提供/应答协商，更新了RFC 5761。它清楚地表明，如果相关的SDP提供包含“a=rtcp mux”属性，则应答者只能在会话描述协议（SDP）应答中包含该属性。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc8035.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8035.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Update to RFC 5761 . . . . . . . . . . . . . . . . . . . . . 3
3.1. Update to Section 5.1.1 . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Normative References . . . . . . . . . . . . . . . . . . . . 6
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Update to RFC 5761 . . . . . . . . . . . . . . . . . . . . . 3
3.1. Update to Section 5.1.1 . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Normative References . . . . . . . . . . . . . . . . . . . . 6
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
RFC 5761 [RFC5761] specifies how to multiplex RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP port, and how to negotiate usage of such multiplexing using the SDP offer/answer mechanism [RFC3264] with an "a=rtcp-mux" attribute. However, the text is unclear on whether an answerer is allowed to include the attribute in an answer even if the associated offer did not contain an attribute.
RFC 5761[RFC5761]指定如何在单个UDP端口上多路复用RTP数据包和RTP控制协议（RTCP）包，以及如何使用带有“a=RTCP mux”属性的SDP提供/应答机制[RFC3264]协商此类多路复用的使用。然而，文本不清楚是否允许回答者在回答中包含属性，即使相关报价不包含属性。
This document updates RFC 5761 [RFC5761] by clarifying that an answerer can only include an "a=rtcp-mux" attribute in an answer if the associated offer contained the attribute. It also clarifies that the negotiation of RTP and RTCP multiplexing is for usage in both directions.
本文档更新了RFC 5761[RFC5761]，澄清了如果相关报价包含“a=rtcp mux”属性，则应答者只能在应答中包含该属性。它还澄清了RTP和RTCP多路复用的协商是双向使用的。
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]中所述进行解释。
This section updates Section 5.1.1 of RFC 5761 by clarifying that an answerer can only include an "a=rtcp-mux" attribute in an answer if the associated offer contained the attribute, and by clarifying that the negotiation of RTP and RTCP multiplexing is for usage in both directions.
本节更新了RFC 5761第5.1.1节，澄清了如果相关报价包含“a=rtcp mux”属性，则应答者只能在应答中包含该属性，并澄清RTP和rtcp多路复用的协商是双向使用的。
In this section, any references to Sections 4 and 8 are to those sections in [RFC5761].
在本节中，对第4节和第8节的任何引用均指[RFC5761]中的章节。
OLD TEXT:
旧文本：
When the Session Description Protocol (SDP) [8] is used to negotiate RTP sessions following the offer/answer model [9], the "a=rtcp-mux" attribute (see Section 8) indicates the desire to multiplex RTP and RTCP onto a single port. The initial SDP offer MUST include this attribute at the media level to request multiplexing of RTP and RTCP on a single port. For example:
当会话描述协议（SDP）[8]用于按照提供/应答模型[9]协商RTP会话时，“a=rtcp mux”属性（见第8节）表示希望将RTP和rtcp多路复用到单个端口上。初始SDP提供必须在媒体级别包含此属性，以便在单个端口上请求RTP和RTCP的多路复用。例如：
v=0
o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e
s=-
c=IN IP6 2001:DB8::211:24ff:fea3:7a2e
t=1153134164 1153137764
m=audio 49170 RTP/AVP 97
a=rtpmap:97 iLBC/8000
a=rtcp-mux
v=0
o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e
s=-
c=IN IP6 2001:DB8::211:24ff:fea3:7a2e
t=1153134164 1153137764
m=audio 49170 RTP/AVP 97
a=rtpmap:97 iLBC/8000
a=rtcp-mux
This offer denotes a unicast voice-over-IP session using the RTP/AVP profile with iLBC coding. The answerer is requested to send both RTP and RTCP to port 49170 on IPv6 address 2001:DB8::211:24ff:fea3:7a2e.
此服务表示使用带有iLBC编码的RTP/AVP配置文件的单播IP语音会话。请求应答者将RTP和RTCP发送到IPv6地址2001:DB8:：211:24ff:fea3:7a2e上的端口49170。
If the answerer wishes to multiplex RTP and RTCP onto a single port, it MUST include a media-level "a=rtcp-mux" attribute in the answer. The RTP payload types used in the answer MUST conform to the rules in Section 4.
如果应答者希望将RTP和RTCP多路传输到单个端口上，则应答中必须包含媒体级“a=RTCP mux”属性。答案中使用的RTP有效负载类型必须符合第4节中的规则。
If the answer does not contain an "a=rtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=rtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=rtcp-mux" attribute.
如果答案不包含“a=rtcp mux”属性，则报价人不得在单个端口上多路传输RTP和rtcp数据包。相反，它应该在根据通常的端口选择规则分配的端口上发送和接收RTCP（端口对或信号端口，如果还包括“a=RTCP:”属性[10]）。当与不理解“a=rtcp mux”属性的对等方交谈时，会发生这种情况。
When SDP is used in a declarative manner, the presence of an "a=rtcp-mux" attribute signals that the sender will multiplex RTP and RTCP on the same port. The receiver MUST be prepared to receive RTCP packets on the RTP port, and any resource reservation needs to be made including the RTCP bandwidth.
以声明方式使用SDP时，“a=rtcp mux”属性表示发送方将在同一端口上多路传输RTP和rtcp。接收器必须准备好在RTP端口上接收RTCP数据包，并且需要进行任何资源预留，包括RTCP带宽。
NEW TEXT:
新案文：
When the Session Description Protocol (SDP) [8] is used to negotiate RTP sessions following the offer/answer model [9], the "a=rtcp-mux" attribute (see Section 8) indicates the desire to multiplex RTP and RTCP onto a single port, and the usage is always negotiated for both directions.
当会话描述协议（SDP）[8]用于协商遵循提供/应答模型[9]的RTP会话时，“a=rtcp mux”属性（见第8节）表示希望将RTP和rtcp多路复用到单个端口上，并且始终协商两个方向的使用。
If the offerer wishes to multiplex RTP and RTCP onto a single port, the initial SDP offer MUST include the attribute at the media level to request multiplexing of RTP and RTCP on a single port. For example:
如果报价人希望在单个端口上多路传输RTP和RTCP，则初始SDP报价必须包括媒体级别的属性，以请求在单个端口上多路传输RTP和RTCP。例如：
v=0
o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e
s=-
c=IN IP6 2001:DB8::211:24ff:fea3:7a2e
t=1153134164 1153137764
m=audio 49170 RTP/AVP 97
a=rtpmap:97 iLBC/8000
a=rtcp-mux
v=0
o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e
s=-
c=IN IP6 2001:DB8::211:24ff:fea3:7a2e
t=1153134164 1153137764
m=audio 49170 RTP/AVP 97
a=rtpmap:97 iLBC/8000
a=rtcp-mux
This offer denotes a unicast voice-over-IP session using the RTP/AVP profile with Internet Low Bit Rate Codec (iLBC) coding. The answerer is requested to send both RTP and RTCP to port 49170 on IPv6 address 2001:DB8::211:24ff:fea3:7a2e.
此服务表示使用RTP/AVP配置文件和Internet低比特率编解码器（iLBC）编码的单播IP语音会话。请求应答者将RTP和RTCP发送到IPv6地址2001:DB8:：211:24ff:fea3:7a2e上的端口49170。
If the offer contains the "a=rtcp-mux" attribute, and if the answerer wishes to multiplex RTP and RTCP onto a single port, it MUST include a media-level "a=rtcp-mux" attribute in the answer. The RTP payload types used in the answer MUST conform to the rules in Section 4. If the offer does not contain the "a=rtcp-mux" attribute, the answerer MUST NOT include an "a=rtcp-mux" attribute in the answer, and the answerer MUST NOT multiplex RTP and RTCP packets on a single port.
如果报价包含“a=rtcp mux”属性，并且如果应答者希望将RTP和rtcp多路传输到单个端口，则必须在应答中包含媒体级“a=rtcp mux”属性。答案中使用的RTP有效负载类型必须符合第4节中的规则。如果报价不包含“a=rtcp mux”属性，应答者不得在应答中包含“a=rtcp mux”属性，且应答者不得在单个端口上多路传输RTP和rtcp数据包。
If the answer contains an "a=rtcp-mux" attribute, the offerer and answerer MUST multiplex RTP and RTCP packets on a single port.
如果应答包含“a=rtcp mux”属性，则报价人和应答人必须在单个端口上多路传输RTP和rtcp数据包。
If the answer does not contain an "a=rtcp-mux" attribute, the offerer and answerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, they should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=rtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=rtcp-mux" attribute.
如果应答不包含“a=rtcp mux”属性，则报价人和应答人不得在单个端口上多路传输RTP和rtcp数据包。相反，他们应该在根据通常的端口选择规则分配的端口上发送和接收RTCP（端口对或信号端口，如果还包括“a=RTCP:”属性[10]）。当与不理解“a=rtcp mux”属性的对等方交谈时，会发生这种情况。
When SDP is used in a declarative manner, the presence of an "a=rtcp-mux" attribute signals that the sender will multiplex RTP and RTCP on the same port. The receiver MUST be prepared to receive RTCP packets on the RTP port, and any resource reservation needs to be made including the RTCP bandwidth.
以声明方式使用SDP时，“a=rtcp mux”属性表示发送方将在同一端口上多路传输RTP和rtcp。接收器必须准备好在RTP端口上接收RTCP数据包，并且需要进行任何资源预留，包括RTCP带宽。
The security considerations for RTP and RTCP multiplexing are described in RFC 5761. This specification does not impact those security considerations.
RFC 5761中描述了RTP和RTCP多路复用的安全注意事项。本规范不影响这些安全注意事项。
IANA has added a reference to this document for the att-field (media level only) registration "rtcp-mux" in the "Session Description Protocol (SDP) Parameters" registry.
IANA为“会话描述协议（SDP）参数”注册表中的att字段（仅媒体级）注册“rtcp mux”添加了对本文档的参考。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <http://www.rfc-editor.org/info/rfc3264>.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，DOI 10.17487/RFC3264，2002年6月<http://www.rfc-editor.org/info/rfc3264>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, <http://www.rfc-editor.org/info/rfc5761>.
[RFC5761]Perkins，C.和M.Westerlund，“在单个端口上多路复用RTP数据和控制数据包”，RFC 5761，DOI 10.17487/RFC5761，2010年4月<http://www.rfc-editor.org/info/rfc5761>.
Acknowledgements
致谢
Thanks to Colin Perkins, Magnus Westerlund, Paul Kyzivat, and Roni Even for providing comments on the document. Thomas Belling provided useful input in the discussions that took place in 3GPP and resulted in the submission of the document. Elwyn Davies performed the Gen-ART review. Rick Casarez performed the Ops-Dir review. Alissa Cooper and Spencer Dawkins provided IESG review comments.
感谢Colin Perkins、Magnus Westerlund、Paul Kyzivat和Roni对该文件的评论。Thomas Belling在3GPP中进行的讨论中提供了有用的信息，并最终提交了该文件。Elwyn Davies完成了Gen艺术评论。Rick Casarez执行了Ops Dir审查。Alissa Cooper和Spencer Dawkins提供了IESG审查意见。
Author's Address
作者地址
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420芬兰
Email: christer.holmberg@ericsson.com
Email: christer.holmberg@ericsson.com