Internet Engineering Task Force (IETF) J. Rosenberg
Request for Comments: 5768 jdrosen.net
Category: Standards Track April 2010
ISSN: 2070-1721
Internet Engineering Task Force (IETF) J. Rosenberg
Request for Comments: 5768 jdrosen.net
Category: Standards Track April 2010
ISSN: 2070-1721
Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP)
表示支持会话启动协议（SIP）中的交互式连接建立（ICE）
Abstract
摘要
This specification defines a media feature tag and an option tag for use with the Session Initiation Protocol (SIP). The media feature tag allows a User Agent (UA) to communicate to its registrar that it supports ICE. The option tag allows a UA to require support for ICE in order for a call to proceed.
本规范定义了用于会话启动协议（SIP）的媒体功能标签和选项标签。媒体功能标签允许用户代理（UA）与其注册器通信它支持ICE。选项标签允许UA需要ICE支持才能继续呼叫。
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/rfc5768.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5768.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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 .....................................................2
3. Motivation ......................................................3
3.1. Gateways ...................................................3
3.2. Mandating Support for ICE ..................................3
4. Media Feature Tag Definition ....................................3
5. Option Tag Definition ...........................................4
6. Security Considerations .........................................4
7. IANA Considerations .............................................4
7.1. Option Tag .................................................4
7.2. Media Feature Tag ..........................................5
8. References ......................................................5
8.1. Normative References .......................................5
8.2. Informative References .....................................6
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Motivation ......................................................3
3.1. Gateways ...................................................3
3.2. Mandating Support for ICE ..................................3
4. Media Feature Tag Definition ....................................3
5. Option Tag Definition ...........................................4
6. Security Considerations .........................................4
7. IANA Considerations .............................................4
7.1. Option Tag .................................................4
7.2. Media Feature Tag ..........................................5
8. References ......................................................5
8.1. Normative References .......................................5
8.2. Informative References .....................................6
RFC 3264 [RFC3264] defines a two-phase exchange of Session Description Protocol (SDP) [RFC4566] messages for the purposes of establishment of multimedia sessions. This offer/answer mechanism is used by protocols such as the Session Initiation Protocol (SIP) [RFC3261].
RFC 3264[RFC3264]定义了会话描述协议（SDP）[RFC4566]消息的两阶段交换，用于建立多媒体会话。此提供/应答机制由诸如会话发起协议（SIP）[RFC3261]之类的协议使用。
Protocols using offer/answer are difficult to operate through Network Address Translators (NAT). Because their purpose is to establish a flow of media packets, they tend to carry IP addresses within their messages, which is known to be problematic through NAT [RFC3235]. To remedy this, an extension to SDP, called Interactive Connectivity Establishment (ICE) has been defined [RFC5245]. ICE defines procedures by which agents gather a multiplicity of addresses, include all of them in an SDP offer or answer, and then use peer-to-peer Session Traversal Utilities for NAT (STUN) [RFC5389] connectivity checks to determine a valid address.
使用提供/应答的协议很难通过网络地址转换器（NAT）进行操作。因为它们的目的是建立媒体包流，所以它们往往在消息中携带IP地址，这在NAT[RFC3235]中是有问题的。为了解决这个问题，定义了SDP的一个扩展，称为交互式连接建立（ICE）[RFC5245]。ICE定义了代理收集多个地址的过程，将所有地址包含在SDP提供或应答中，然后使用NAT（STUN）[RFC5389]连接检查的对等会话遍历实用程序来确定有效地址。
This specification defines a media feature tag, "sip.ice", and a SIP option tag, "ice", that can be used by SIP User Agents that make use of ICE. Section 3 motivates the need for the media feature tag and option tag, and Section 4 and Section 5 formally define them.
本规范定义了一个媒体功能标签“sip.ice”和一个sip选项标签“ice”，可供使用ice的sip用户代理使用。第3节激发了对媒体功能标签和选项标签的需求，第4节和第5节正式定义了它们。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
There are two primary motivations for defining an option tag and a media feature tag. They are support for gateways, and requiring ICE for a call.
定义选项标记和媒体功能标记有两个主要动机。它们支持网关，并且需要ICE进行呼叫。
Unfortunately, ICE requires both endpoints to support it in order for it to be used. Within a domain, there will typically be User Agents that do and do not support ICE. In order to facilitate deployment of ICE, it is anticipated that domains will make use of gateways that act as ICE agents on one side, and non-ICE agents on the other side. This would allow a call from domain A into domain B to make use of ICE, even if the device in domain B does not itself yet support ICE. However, when domain B receives a call, it will need to know whether the call needs to pass through such a gateway, or whether it can go to the terminating UA directly.
不幸的是，ICE需要两个端点来支持它才能使用。在域中，通常会有支持和不支持ICE的用户代理。为了促进ICE的部署，预计域将使用网关，在一侧充当ICE代理，在另一侧充当非ICE代理。这将允许从域a到域B的调用使用ICE，即使域B中的设备本身还不支持ICE。然而，当域B接收到呼叫时，它需要知道呼叫是否需要通过这样一个网关，或者它是否可以直接到达终端UA。
In order to make such a determination, this specification defines a media feature tag, "sip.ice", which can be included in the Contact header field of a REGISTER request [RFC3840]. This allows the registrar to track whether or not a UA supports ICE. This information can be accessed by a proxy in order to determine whether or not a call needs to route through a gateway.
为了进行这样的确定，本规范定义了媒体特征标签“sip.ice”，它可以包括在寄存器请求[RFC3840]的联系人头部字段中。这允许注册官跟踪UA是否支持ICE。代理可以访问此信息，以确定呼叫是否需要通过网关路由。
Although ICE provides a built in fall back to non-ICE operation when the answerer doesn't support it, there are cases where the offerer would rather abort the call rather than proceed without ICE. Typically, this is because they would like to choose a different m/c-line address for a non-ICE peer than they would for an ICE capable peer.
尽管当应答者不支持ICE时，ICE提供了内置的非ICE回退操作，但在某些情况下，发盘者宁愿中止呼叫也不愿在没有ICE的情况下继续。通常，这是因为他们希望为非ICE对等机选择不同于ICE对等机的m/c-line地址。
To do this, the "ice" SIP option tag can be included in the Require header field of an INVITE request.
为此，可以在INVITE请求的Require头字段中包含“ice”SIP选项标记。
The "sip.ice" media feature tag indicates support for ICE. An agent supports ICE if it is either a lite or full implementation, and consequently, is capable of including candidate attributes in an SDP offer or answer for at least one transport protocol. An agent that supports ICE SHOULD include this media feature tag in the Contact header field of its REGISTER requests and OPTION responses.
“sip.ice”媒体功能标签表示支持ice。如果ICE是lite或完整实现，则代理支持ICE，因此能够在SDP提供或应答中包含至少一个传输协议的候选属性。支持ICE的代理应在其注册请求和选项响应的联系人标头字段中包含此媒体功能标签。
An agent MAY include the media feature tag in the Contact header field of an INVITE or INVITE response; however, doing so is redundant with ICE attributes in the SDP that indicate the same thing. In cases where an INVITE omits an offer, the lack or presence of the media feature tag in the Contact header field cannot be used by the callee (which will be the offerer) to determine whether the caller supports ICE. In cases of third-party call control [RFC3725], the caller may be a controller that does (or doesn't) support ICE, while the answerer may be an agent that does (or doesn't) support ICE.
代理可以在邀请或邀请响应的联系人头部字段中包括媒体特征标签；但是，这样做与SDP中指示相同内容的ICE属性是多余的。如果INVITE忽略了报价，则被叫方（将是报价方）不能使用Contact header字段中缺少或存在media feature标记来确定主叫方是否支持ICE。在第三方呼叫控制[RFC3725]的情况下，呼叫者可能是支持（或不支持）ICE的控制器，而应答者可能是支持（或不支持）ICE的代理。
This "ice" OPTION tag SHOULD NOT be used in conjunction with the Supported header field (this SHOULD NOT include responses to OPTION requests). The media feature tag is used as the one and only mechanism for indicating support for ICE. The option tag is meant to be used only with the Require header field. When placed in the Require header field of an INVITE request, it indicates that the User Agent Server (UAS) must support ICE in order to process the call. An agent supports ICE if it is either a full or lite implementation, and consequently, is capable of including candidate attributes in an SDP offer or answer for at least one transport protocol.
此“ice”选项标记不应与支持的标题字段一起使用（不应包括对选项请求的响应）。媒体功能标签用作指示支持ICE的唯一机制。选项标记仅用于Require header字段。当放置在INVITE请求的Require header字段中时，它表示用户代理服务器（UAS）必须支持ICE才能处理该调用。如果ICE是完整或lite实现，则代理支持ICE，因此能够在SDP提供或应答中包含至少一个传输协议的候选属性。
A malicious intermediary might attempt to modify a SIP message by inserting a Require header field containing the "ice" option tag. If ICE were not supported on the UAS, this would cause the call to fail when it would otherwise succeed. Of course, this attack is not specific to ICE, and can be done using any option tag. This attack is prevented by usage of the SIPS mechanism as defined in RFC 3261.
恶意中介可能试图通过插入包含“ice”选项标记的Require头字段来修改SIP消息。如果UAS上不支持ICE，这将导致调用失败，否则调用将成功。当然，这种攻击不是针对ICE的，可以使用任何选项标记进行。使用RFC 3261中定义的SIPS机制可防止此攻击。
Similarly, an intermediary might attempt to remove the media feature tag from a REGISTER request or OPTIONS request, which might cause a call to skip ICE processing when it otherwise might make use of it. This attack is also prevented using the SIPS mechanism.
类似地，中介可能会尝试从注册请求或选项请求中删除媒体功能标签，这可能会导致调用跳过ICE处理，否则可能会使用ICE处理。还可以使用SIPS机制防止此攻击。
This specification defines a new media feature tag and SIP option tag.
本规范定义了一个新的媒体功能标签和SIP选项标签。
This section defines a new SIP option tag per the guidelines in Section 27.1 of RFC 3261.
本节根据RFC 3261第27.1节中的指南定义了新的SIP选项标签。
Name: ice
名称：冰
Description: This option tag is used to identify the Interactive Connectivity Establishment (ICE) extension. When present in a Require header field, it indicates that ICE is required by an agent.
描述：此选项标签用于标识交互式连接建立（ICE）扩展。当出现在Require头字段中时，表示代理需要ICE。
This section registers a new media feature tag in the SIP tree, defined in Section 12.1 of RFC 3840 [RFC3840].
本节在SIP树中注册了一个新的媒体功能标签，定义见RFC 3840[RFC3840]第12.1节。
Media feature tag name: sip.ice
媒体功能标签名称：sip.ice
ASN.1 Identifier: 1.3.6.1.8.4.22
ASN.1标识符：1.3.6.1.8.4.22
Summary of the media feature indicated by this tag: This feature tag indicates that the device supports Interactive Connectivity Establishment (ICE).
此标签指示的媒体功能摘要：此功能标签指示设备支持交互式连接建立（ICE）。
Values appropriate for use with this feature tag: Boolean.
适用于此功能标记的值：布尔值。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application, for describing the capabilities of a device, such as a phone or PDA.
该特征标签主要用于以下应用、协议、服务或协商机制：该特征标签在通信应用中最有用，用于描述诸如电话或PDA之类的设备的能力。
Examples of typical use: Routing a call to a phone that can support ICE.
典型用途示例：将呼叫路由到支持ICE的电话。
Related standards or documents: RFC 5768
相关标准或文件：RFC 5768
Security Considerations: Security considerations for this media feature tag are discussed in Section 6 of this document.
安全注意事项：本文档第6节讨论了此媒体功能标签的安全注意事项。
[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月。
[RFC3261] 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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[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月。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3840]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，2004年8月。
[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月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月。
[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, January 2002.
[RFC3235]Senie，D.，“网络地址转换器（NAT）-友好的应用程序设计指南”，RFC 32352002年1月。
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[RFC3725]Rosenberg，J.，Peterson，J.，Schulzrinne，H.，和G.Camarillo，“会话启动协议（SIP）中第三方呼叫控制（3pcc）的当前最佳实践”，BCP 85，RFC 37252004年4月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT的会话遍历实用程序（STUN）”，RFC 5389，2008年10月。
Author's Address
作者地址
Jonathan Rosenberg jdrosen.net Monmouth, NJ US
Jonathan Rosenberg jdrosen.net美国新泽西州蒙茅斯
EMail: jdrosen@jdrosen.net
URI: http://www.jdrosen.net
EMail: jdrosen@jdrosen.net
URI: http://www.jdrosen.net