Network Working Group G. Camarillo
Request for Comments: 4092 Ericsson
Category: Standards Track J. Rosenberg
Cisco Systems
June 2005
Network Working Group G. Camarillo
Request for Comments: 4092 Ericsson
Category: Standards Track J. Rosenberg
Cisco Systems
June 2005
Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)
会话描述协议（SDP）替代网络地址类型（ANAT）语义在会话启动协议（SIP）中的使用
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document describes how to use the Alternative Network Address Types (ANAT) semantics of the Session Description Protocol (SDP) grouping framework in SIP. In particular, we define the sdp-anat SIP option-tag. This SIP option-tag ensures that SDP session descriptions that use ANAT are only handled by SIP entities with ANAT support. To justify the need for such a SIP option-tag, we describe what could possibly happen if an ANAT-unaware SIP entity tried to handle media lines grouped with ANAT.
本文档描述了如何在SIP中使用会话描述协议（SDP）分组框架的可选网络地址类型（ANAT）语义。特别是，我们定义了sdp anat SIP选项标记。此SIP选项标记确保使用ANAT的SDP会话描述仅由支持ANAT的SIP实体处理。为了证明需要这样一个SIP选项标签，我们描述了如果一个不知道ANAT的SIP实体试图处理与ANAT分组的媒体线路，可能会发生什么情况。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. The sdp-anat Option-Tag . . . . . . . . . . . . . . . . . . . . 2
4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 3
4.1. Answerer Supports All the Network Types Offered . . . . 3
4.2. Answerer Does Not Support All the Network Types Offered. 3
4.3. OPTIONS Requests . . . . . . . . . . . . . . . . . . . . 4
5. Option-Tag Usage . . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
8. Normative References . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. The sdp-anat Option-Tag . . . . . . . . . . . . . . . . . . . . 2
4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 3
4.1. Answerer Supports All the Network Types Offered . . . . 3
4.2. Answerer Does Not Support All the Network Types Offered. 3
4.3. OPTIONS Requests . . . . . . . . . . . . . . . . . . . . 4
5. Option-Tag Usage . . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
8. Normative References . . . . . . . . . . . . . . . . . . . . . 5
SIP [3] UAs (User Agents) often support different network address types. For example, a UA may have an IPv6 address and an IPv4 address. Such a UA will typically be willing to use any of its addresses to establish a media session with a remote UA. If the remote UA only supports IPv6, for instance, both UAs will use IPv6 to send and receive media.
SIP[3]UAs（用户代理）通常支持不同的网络地址类型。例如，UA可能具有IPv6地址和IPv4地址。这样的UA通常愿意使用其任何地址与远程UA建立媒体会话。例如，如果远程UA仅支持IPv6，则两个UA都将使用IPv6发送和接收媒体。
The Alternative Network Address Types (ANAT) semantics [7] of the SDP [2] grouping framework [5] allow UAs to offer [4] alternative addresses of different types in an SDP session description. The IPv4/IPv6 dual-stack SIP UA of our previous example would generate an offer grouping an IPv6 media line and an IPv4 media line using ANAT. Upon receipt of this offer, the answerer [4] would accept one media line and reject the other.
SDP[2]分组框架[5]的替代网络地址类型（ANAT）语义[7]允许UAs在SDP会话描述中提供[4]不同类型的替代地址。我们前面示例中的IPv4/IPv6双栈SIP UA将生成一个使用ANAT对IPv6媒体线和IPv4媒体线进行分组的报价。收到此报价后，应答者[4]将接受一条媒体线路，拒绝另一条。
If the recipient of an offer that uses ANAT supports the ANAT semantics, everything works as described in the ANAT specification [7]. Nevertheless, the recipient of such an offer (i.e., the answerer) may not support ANAT. In this case, different implementations of the answerer would react in different ways. This document discusses the answerer's behaviors that are most likely to be found and describes their consequences. To avoid these consequences, we define the sdp-anat SIP option-tag.
如果使用ANAT的要约的接收者支持ANAT语义，则一切都按照ANAT规范[7]中的描述工作。然而，此类要约的接收人（即回答者）可能不支持ANAT。在这种情况下，应答器的不同实现将以不同的方式作出反应。本文件讨论了最有可能被发现的回答者的行为，并描述了其后果。为了避免这些后果，我们定义了sdp anat SIP选项标签。
The sdp-anat option-tag can be used to ensure that an offer using ANAT is not processed by answerers without support for ANAT. This option-tag can also be used to explicitly discover the capabilities of a UA (i.e., whether it supports ANAT).
sdp anat选项标签可用于确保在没有anat支持的情况下，应答者不会处理使用anat的报价。此选项标签还可用于显式发现UA的功能（即，它是否支持ANAT）。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释，并指出合规实施的要求级别。
We define the option-tag sdp-anat for use in the Require and Supported SIP [3] header fields. SIP user agents that place this option-tag in a Supported header field understand the ANAT semantics as defined in [7].
我们在Require和Supported SIP[3]头字段中定义了选项标记sdp anat。将此选项标记放置在受支持的标头字段中的SIP用户代理理解[7]中定义的ANAT语义。
Answerers without support for ANAT will react in different ways upon receipt of an offer using ANAT. We expect that, even under the same circumstances, different implementations will behave in different ways. In this section, we analyze these behaviors (i.e., the following subsections assume that the answerer does not support ANAT).
不支持ANAT的应答者在收到使用ANAT的报价时将以不同的方式作出反应。我们期望，即使在相同的情况下，不同的实现也会以不同的方式运行。在本节中，我们分析这些行为（即，以下小节假设回答者不支持ANAT）。
If the answerer supports all the network types in the offer, it may accept the offer and establish all the media streams in it. This behavior is not what the offerer expects because it results in too many media streams being established. If the answerer starts sending media over all of them, the result may be a high bandwidth usage.
如果应答者支持报价中的所有网络类型，则可以接受报价并在其中建立所有媒体流。这种行为不是报价人所期望的，因为它会导致建立太多的媒体流。如果应答者开始在所有这些设备上发送媒体，其结果可能是高带宽使用率。
The answerer may also reject the offer, because although it supports all the network types in it, the answerer may not support them simultaneously. The error response sent by the answerer will most likely not be explicit enough about the situation. So, the offerer will not understand what went wrong.
应答者也可能拒绝该提议，因为尽管它支持其中的所有网络类型，但应答者可能不会同时支持它们。应答者发送的错误响应很可能对情况不够明确。因此，发盘方将无法理解哪里出了问题。
In the previous scenarios, the sdp-anat option-tag would avoid the establishment of too many media streams and would allow the answerer to explicitly inform the offerer that the answerer did not support ANAT.
在前面的场景中，sdp anat选项标签将避免建立过多的媒体流，并允许应答者明确告知报价人应答者不支持anat。
If the answerer does not support all the network types in the offer, it may only establish the media streams whose address types it understands and reject the rest. This would be an acceptable behavior from the offerer's point of view.
如果应答者不支持报价中的所有网络类型，则只能建立其理解的地址类型的媒体流，并拒绝其余的媒体流。从报价人的角度来看，这是一种可接受的行为。
On the other hand, the answerer may also reject the offer because it contains unknown address types. The error response sent by the answerer will most likely not be explicit enough about the situation. So, the offerer will not understand what went wrong.
另一方面，应答者也可能拒绝报价，因为报价包含未知的地址类型。应答者发送的错误响应很可能对情况不够明确。因此，发盘方将无法理解哪里出了问题。
In the previous scenario, the sdp-anat option-tag would allow the answerer to explicitly inform the offerer that the answerer did not support ANAT.
在前面的场景中，sdp anat选项标签将允许应答者明确告知报价人应答者不支持anat。
Although RFC 3388 [5] provides servers with a means to indicate support for ANAT in an SDP description, many servers do not include an SDP description in their responses to OPTIONS requests. The sdp-anat option-tag makes it possible to discover if any server supports ANAT, since they would include this option-tag in a Supported header field in their responses.
尽管RFC 3388[5]为服务器提供了一种在SDP描述中表示支持ANAT的方法，但许多服务器在对选项请求的响应中不包含SDP描述。sdp anat选项标记可以发现是否有任何服务器支持anat，因为它们会在响应中的受支持标头字段中包含此选项标记。
As discussed in the previous section, the use of the sdp-anat option-tag makes SIP messages more explicit about ANAT support. So, SIP entities generating an offer that uses the ANAT semantics SHOULD place the sdp-anat option-tag in a Require header field. SIP entities that support the ANAT semantics MUST understand the sdp-anat option-tag.
如前一节所述，使用sdp anat选项标记可以使SIP消息更明确地说明anat支持。因此，生成使用ANAT语义的报价的SIP实体应该将sdp ANAT选项标记放在Require头字段中。支持ANAT语义的SIP实体必须理解sdp ANAT选项标记。
An attacker may attempt to add the sdp-anat option tag to the Require header field of a message to perform a DoS attack. If the UAS does not support ANAT, it will return an error response instead of processing the message.
攻击者可能试图将sdp anat选项标记添加到消息的Require header字段以执行DoS攻击。如果UAS不支持ANAT，它将返回错误响应，而不是处理消息。
An attacker may attempt to remove the sdp-anat option-tag from the Require header field of a message. This may result in the establishment of too many media streams.
攻击者可能试图从消息的Require header字段中删除sdp anat选项标记。这可能导致建立过多的媒体流。
To avoid the previous attacks, integrity protection of the Require header field is RECOMMENDED. The natural choice to integrity protect header fields in SIP is S/MIME [6].
为了避免以前的攻击，建议对Require header字段进行完整性保护。SIP中保护头字段完整性的自然选择是S/MIME[6]。
This document defines a SIP option-tag (sdp-anat) in Section 3. It has been registered by the IANA in the SIP parameter registry.
本文件在第3节中定义了SIP选项标签（sdp anat）。它已由IANA在SIP参数注册表中注册。
SIP user agents that place the sdp-anat option-tag in a Supported header field understand the ANAT semantics.
将sdp anat选项标记放置在受支持的头字段中的SIP用户代理理解anat语义。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[2] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[3] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[5] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
[5] Camarillo，G.，Eriksson，G.，Holler，J.，和H.Schulzrinne，“会话描述协议（SDP）中媒体线路的分组”，RFC 3388，2002年12月。
[6] Peterson, J., "S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)", RFC 3853, July 2004.
[6] Peterson，J.，“会话启动协议（SIP）的S/MIME高级加密标准（AES）要求”，RFC3853，2004年7月。
[7] Camarillo, G. and J. Rosenberg, "The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework", RFC 4091, June 2005.
[7] Camarillo，G.和J.Rosenberg，“会话描述协议（SDP）分组框架的替代网络地址类型（ANAT）语义”，RFC 4091，2005年6月。
Authors' Addresses
作者地址
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
Jonathan Rosenberg Cisco Systems 600美国新泽西州帕西帕尼拉尼德广场07054号
EMail: jdrosen@cisco.com
EMail: jdrosen@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。