Internet Engineering Task Force (IETF) F. Andreasen
Request for Comments: 5898 Cisco Systems
Category: Standards Track G. Camarillo
ISSN: 2070-1721 Ericsson
D. Oran
D. Wing
Cisco Systems
July 2010
Internet Engineering Task Force (IETF) F. Andreasen
Request for Comments: 5898 Cisco Systems
Category: Standards Track G. Camarillo
ISSN: 2070-1721 Ericsson
D. Oran
D. Wing
Cisco Systems
July 2010
Connectivity Preconditions for Session Description Protocol (SDP) Media Streams
会话描述协议（SDP）媒体流的连接先决条件
Abstract
摘要
This document defines a new connectivity precondition for the Session Description Protocol (SDP) precondition framework. A connectivity precondition can be used to delay session establishment or modification until media stream connectivity has been successfully verified. The method of verification may vary depending on the type of transport used for the media. For unreliable datagram transports such as UDP, verification involves probing the stream with data or control packets. For reliable connection-oriented transports such as TCP, verification can be achieved simply by successful connection establishment or by probing the connection with data or control packets, depending on the situation.
本文档为会话描述协议（SDP）前提条件框架定义了一个新的连接前提条件。连接先决条件可用于延迟会话建立或修改，直到成功验证媒体流连接。验证方法可能因介质使用的传输类型而异。对于不可靠的数据报传输（如UDP），验证涉及使用数据或控制数据包探测流。对于可靠的面向连接的传输（如TCP），验证可以通过成功建立连接或根据情况使用数据或控制包探测连接来实现。
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/rfc5898.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5898.
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许可证中所述的无担保。
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Connectivity Precondition Definition . . . . . . . . . . . . . 4
3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Operational Semantics . . . . . . . . . . . . . . . . . . 4
3.3. Status Type . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Direction Tag . . . . . . . . . . . . . . . . . . . . . . 5
3.5. Precondition Strength . . . . . . . . . . . . . . . . . . 5
4. Verifying Connectivity . . . . . . . . . . . . . . . . . . . . 6
4.1. Correlation of Dialog to Media Stream . . . . . . . . . . 7
4.2. Explicit Connectivity Verification Mechanisms . . . . . . 7
4.3. Verifying Connectivity for Connection-Oriented
Transports . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Connectivity and Other Precondition Types . . . . . . . . . . 9
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Connectivity Precondition Definition . . . . . . . . . . . . . 4
3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Operational Semantics . . . . . . . . . . . . . . . . . . 4
3.3. Status Type . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Direction Tag . . . . . . . . . . . . . . . . . . . . . . 5
3.5. Precondition Strength . . . . . . . . . . . . . . . . . . 5
4. Verifying Connectivity . . . . . . . . . . . . . . . . . . . . 6
4.1. Correlation of Dialog to Media Stream . . . . . . . . . . 7
4.2. Explicit Connectivity Verification Mechanisms . . . . . . 7
4.3. Verifying Connectivity for Connection-Oriented
Transports . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Connectivity and Other Precondition Types . . . . . . . . . . 9
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 16
The concept of a Session Description Protocol (SDP) [RFC4566] precondition in the Session Initiation Protocol (SIP) [RFC3261] is defined in RFC 3312 [RFC3312] (updated by RFC 4032 [RFC4032]). A precondition is a condition that has to be satisfied for a given media stream in order for session establishment or modification to proceed. When the precondition is not met, session progress is delayed until the precondition is satisfied or the session establishment fails. For example, RFC 3312 [RFC3312] defines the Quality of Service precondition, which is used to ensure availability of network resources prior to establishing a session (i.e., prior to starting to alert the callee).
会话启动协议（SIP）[RFC3261]中会话描述协议（SDP）[RFC4566]先决条件的概念在RFC 3312[RFC3312]（由RFC 4032[RFC4032]更新）中定义。先决条件是给定媒体流必须满足的条件，以便会话建立或修改继续进行。如果不满足先决条件，会话进程将延迟，直到满足先决条件或会话建立失败。例如，RFC 3312[RFC3312]定义了服务质量先决条件，该先决条件用于在建立会话之前（即，在开始向被叫方发出警报之前）确保网络资源的可用性。
SIP sessions are typically established in order to set up one or more media streams. Even though a media stream may be negotiated successfully through an SDP offer-answer exchange, the actual media stream itself may fail. For example, when there is one or more Network Address Translators (NATs) or firewalls in the media path, the media stream may not be received by the far end. In cases where the media is carried over a connection-oriented transport such as TCP [RFC0793], the connection-establishment procedures may fail. The connectivity precondition defined in this document ensures that session progress is delayed until media stream connectivity has been verified.
SIP会话通常是为了建立一个或多个媒体流而建立的。即使可以通过SDP提供-应答交换成功地协商媒体流，实际媒体流本身也可能失败。例如，当媒体路径中存在一个或多个网络地址转换器（nat）或防火墙时，远端可能无法接收媒体流。在媒体通过面向连接的传输（如TCP[RFC0793]）传输的情况下，连接建立过程可能会失败。本文档中定义的连接先决条件可确保在验证媒体流连接之前延迟会话进度。
The connectivity precondition type defined in this document follows the guidelines provided in RFC 4032 [RFC4032] to extend the SIP preconditions framework.
本文档中定义的连接前提条件类型遵循RFC 4032[RFC4032]中提供的准则，以扩展SIP前提条件框架。
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]中所述进行解释。
The connectivity precondition type is defined by the string "conn", and hence we modify the grammar found in RFC 3312 [RFC3312] and RFC 5027 [RFC5027] as follows:
连接前提条件类型由字符串“conn”定义，因此我们修改RFC 3312[RFC3312]和RFC 5027[RFC5027]中的语法，如下所示：
precondition-type = "conn" / "sec" / "qos" / token
precondition-type = "conn" / "sec" / "qos" / token
This precondition tag is registered with the IANA in Section 8.
该前提条件标签在第8节中向IANA注册。
According to RFC 4032 [RFC4032], documents defining new precondition types need to describe the behavior of UAs (User Agents) from the moment session establishment is suspended due to a set of preconditions, until it is resumed when these preconditions are met. An entity that wishes to delay session establishment or modification until media stream connectivity has been established uses this precondition-type in an offer. When a mandatory connectivity precondition is received in an offer, session establishment or modification is delayed until the connectivity precondition has been met (i.e., until media stream connectivity has been established in the desired direction or directions). The delay of session establishment defined here implies that alerting of the called party does not occur until the precondition has been satisfied.
根据RFC 4032[RFC4032]，定义新前提条件类型的文档需要描述UAs（用户代理）的行为，从会话建立由于一组前提条件而暂停的那一刻起，直到满足这些前提条件后恢复会话。希望在建立媒体流连接之前延迟会话建立或修改的实体在报价中使用此先决条件类型。当在报价中接收到强制连接前提条件时，会话建立或修改将延迟，直到满足连接前提条件（即，直到在所需的一个或多个方向上建立了媒体流连接）。此处定义的会话建立延迟意味着在满足先决条件之前不会发出被叫方警报。
Packets may be both sent and received on the media streams in question. However, such packets SHOULD be limited to packets that are necessary to verify connectivity between the two endpoints involved on the media stream. That is, the underlying media stream SHOULD NOT be cut through. For example, Interactive Connectivity Establishment (ICE) connectivity checks [RFC5245] and TCP SYN, SYN-ACK, and ACK packets can be exchanged on media streams that support them as a way of verifying connectivity.
分组可以在所讨论的媒体流上发送和接收。然而，此类分组应限于验证媒体流上涉及的两个端点之间的连接所必需的分组。也就是说，底层媒体流不应被切断。例如，交互式连接建立（ICE）连接检查[RFC5245]和TCP SYN、SYN-ACK和ACK数据包可以在支持它们的媒体流上交换，作为验证连接的一种方式。
Some media streams are described by a single 'm' line but, nevertheless, involve multiple addresses. For example, RFC 5109 [RFC5109] specifies how to send FEC (Forward Error Correction) information as a separate stream (the address for the FEC stream is provided in an 'a=fmtp' line). When a media stream consists of multiple destination addresses, connectivity to all of them MUST be verified in order for the precondition to be met. In the case of RTP media streams [RFC3550] that use RTCP, connectivity MUST be verified for both RTP and RTCP; the RTCP transmission interval rules MUST still be adhered to.
一些媒体流由一个“m”行描述，但涉及多个地址。例如，RFC 5109[RFC5109]指定如何将FEC（前向纠错）信息作为单独的流发送（FEC流的地址在“a=fmtp”行中提供）。当媒体流由多个目标地址组成时，必须验证与所有目标地址的连接，以满足前提条件。对于使用RTCP的RTP媒体流[RFC3550]，必须验证RTP和RTCP的连接性；仍然必须遵守RTCP传输间隔规则。
RFC 3312 [RFC3312] defines support for two kinds of status types -- namely, segmented and end-to-end. The connectivity precondition-type defined here MUST be used with the end-to-end status type; use of the segmented status type is undefined.
RFC33312[RFC3312]定义了对两种状态类型的支持——即分段和端到端。此处定义的连接前提条件类型必须与端到端状态类型一起使用；分段状态类型的使用未定义。
The direction attributes defined in RFC 3312 [RFC3312] are interpreted as follows:
RFC 3312[RFC3312]中定义的方向属性解释如下：
o send: the party that generated the session description is sending packets on the media stream to the other party, and the other party has received at least one of those packets. That is, there is connectivity in the forward (sending) direction.
o 发送：生成会话描述的一方正在向另一方发送媒体流上的数据包，而另一方至少已收到其中一个数据包。也就是说，在前向（发送）方向上存在连通性。
o recv: the other party is sending packets on the media stream to the party that generated the session description, and this party has received at least one of those packets. That is, there is connectivity in the backwards (receiving) direction.
o recv：另一方正在通过媒体流向生成会话描述的一方发送数据包，并且该方至少收到了其中一个数据包。也就是说，存在向后（接收）方向的连接。
o sendrecv: both the send and recv conditions hold.
o sendrecv：send和recv条件都有效。
Note that a "send" connectivity precondition from the offerer's point of view corresponds to a "recv" connectivity precondition from the answerer's point of view, and vice versa. If media stream connectivity in both directions is required before session establishment or modification continues, the desired status needs to be set to "sendrecv".
请注意，从报价人的角度来看，“发送”连接先决条件对应于从应答人的角度来看“接收”连接先决条件，反之亦然。如果在会话建立或修改继续之前需要双向媒体流连接，则需要将所需状态设置为“sendrecv”。
Connectivity preconditions may have a strength-tag of either "mandatory" or "optional".
连接前提条件的强度标签可能为“强制性”或“可选”。
When a mandatory connectivity precondition is offered and the answerer cannot satisfy the connectivity precondition (e.g., because the offer does not include parameters that enable connectivity to be verified without media cut through) the offer MUST be rejected as described in RFC 3312 [RFC3312].
如果提供了强制性连接先决条件，且应答者无法满足连接先决条件（例如，因为报价不包括能够在无介质直通的情况下验证连接的参数），则必须按照RFC 3312[RFC3312]中的说明拒绝报价。
When an optional connectivity precondition is offered, the answerer MUST generate its answer SDP as soon as possible. Since session progress is not delayed in this case, it is not known whether the associated media streams will have connectivity. If the answerer wants to delay session progress until connectivity has been verified, the answerer MUST increase the strength of the connectivity precondition by using a strength-tag of "mandatory" in the answer.
当提供可选连接前提条件时，应答者必须尽快生成其应答SDP。由于在这种情况下不会延迟会话进度，因此不知道相关联的媒体流是否具有连接性。如果应答者希望在验证连接之前延迟会话进度，则应答者必须在应答中使用“强制”强度标签来增加连接前提条件的强度。
Note that use of a mandatory precondition requires the presence of a SIP "Require" header with the option tag "precondition". Any SIP UA that does not support a mandatory precondition will reject such requests. To get around this issue, an optional connectivity precondition and the SIP "Supported" header with the option tag "precondition" can be used instead.
请注意，使用强制先决条件需要SIP“Require”标头和选项标记“premission”。任何不支持强制先决条件的SIP UA将拒绝此类请求。为了解决这个问题，可以使用可选的连接前提条件和带有选项标记“premission”的SIP“Supported”头。
Offers with connectivity preconditions in re-INVITEs or UPDATEs follow the rules given in Section 6 of RFC 3312 [RFC3312]. That is:
在重新邀请或更新中具有连接先决条件的优惠遵循RFC 3312[RFC3312]第6节中给出的规则。即:
Both user agents SHOULD continue using the old session parameters until all the mandatory preconditions are met. At that moment, the user agents can begin using the new session parameters.
两个用户代理都应继续使用旧的会话参数，直到满足所有必需的先决条件。此时，用户代理可以开始使用新的会话参数。
Media stream connectivity is ascertained by use of a connectivity verification mechanism between the media endpoints. A connectivity verification mechanism may be an explicit mechanism, such as ICE [RFC5245] or ICE TCP [ICE-TCP], or it may be an implicit mechanism, such as TCP. Explicit mechanisms provide specifications for when connectivity between two endpoints using an offer/answer exchange is ascertained, whereas implicit mechanisms do not. The verification mechanism is negotiated as part of the normal offer/answer exchange; however, it is not identified explicitly. More than one mechanism may be negotiated, but the offerer and answerer need not use the same. The following rules guide which connectivity verification mechanism to use:
通过使用媒体端点之间的连接验证机制来确定媒体流连接。连接验证机制可以是显式机制，如ICE[RFC5245]或ICE TCP[ICE-TCP]，也可以是隐式机制，如TCP。显式机制为使用提供/应答交换的两个端点之间的连接何时确定提供了规范，而隐式机制则没有。验证机制作为正常报价/应答交换的一部分进行协商；但是，它没有明确标识。可以协商多种机制，但报价人和应答人不必使用相同的机制。以下规则指导要使用的连接验证机制：
o If an explicit connectivity verification mechanism (e.g., ICE) is negotiated, the precondition is met when the mechanism verifies connectivity successfully.
o 如果协商了显式连接验证机制（如ICE），则该机制成功验证连接时满足前提条件。
o Otherwise, if a connection-oriented transport (e.g., TCP) is negotiated, the precondition is met when the connection is established.
o 否则，如果协商面向连接的传输（例如TCP），则在建立连接时满足先决条件。
o Otherwise, if an implicit verification mechanism is provided by the transport itself or the media stream data using the transport, the precondition is met when the mechanism verifies connectivity successfully.
o 否则，如果传输本身或使用传输的媒体流数据提供了隐式验证机制，则在该机制成功验证连接时满足前提条件。
o Otherwise, connectivity cannot be verified reliably, and the connectivity precondition will never be satisfied if requested.
o 否则，无法可靠地验证连接性，并且如果请求，将永远无法满足连接性前提条件。
This document does not mandate any particular connectivity verification mechanism; however, in the following, we provide additional considerations for verification mechanisms.
本文件不要求任何特定的连接验证机制；然而，在下文中，我们为核查机制提供了额外的考虑因素。
SIP and SDP do not provide any inherent capabilities for associating an incoming media stream packet with a particular dialog. Thus, when an offerer is trying to ascertain connectivity, and an incoming media stream packet is received, the offerer may not know which dialog had its "recv" connectivity verified. Explicit connectivity verification mechanisms therefore typically provide a means to correlate the media stream, whose connectivity is being verified, with a particular SIP dialog. However, some connectivity verification mechanisms may not provide such a correlation. In the absence of a mechanism for the correlation of dialog to media stream (e.g., ICE), a UAS (User Agent Server) MUST NOT require the offerer to confirm a connectivity precondition.
SIP和SDP不提供将传入媒体流数据包与特定对话框关联的任何固有功能。因此，当报价人试图确定连接性，并且接收到传入的媒体流分组时，报价人可能不知道哪个对话验证了其“recv”连接性。因此，显式连接验证机制通常提供将其连接正在验证的媒体流与特定SIP对话框相关联的方法。然而，某些连接验证机制可能无法提供这种相关性。在缺少将对话与媒体流（例如，ICE）关联的机制的情况下，UAS（用户代理服务器）不得要求报价人确认连接先决条件。
Explicit connectivity verification mechanisms typically use probe traffic with some sort of feedback to inform the sender whether reception was successful. Below we provide two examples of such mechanisms, and how they are used with connectivity preconditions:
显式连接验证机制通常使用带有某种反馈的探测流量来通知发送方接收是否成功。下面我们提供了两个此类机制的示例，以及如何在连接前提下使用它们：
Interactive Connectivity Establishment (ICE) [RFC5245] provides one or more candidate addresses in signaling between the offerer and the answerer and then uses STUN (Simple Traversal of the UDP Protocol through NAT) Binding Requests to determine which pairs of candidate addresses have connectivity. Each STUN Binding Request contains a password that is communicated in the SDP as well; this enables correlation between STUN Binding Requests and candidate addresses for a particular media stream. It also provides correlation with a particular SIP dialog.
交互式连接建立（ICE）[RFC5245]在报价人和应答人之间的信令中提供一个或多个候选地址，然后使用STUN（通过NAT简单遍历UDP协议）绑定请求来确定哪些候选地址对具有连接。每个STUN绑定请求也包含一个在SDP中通信的密码；这使得STUN绑定请求和特定媒体流的候选地址之间存在关联。它还提供与特定SIP对话框的关联。
ICE implementations may be either full or lite (see [RFC5245]). Full implementations generate and respond to STUN Binding Requests, whereas lite implementations only respond to them. With ICE, one side is a controlling agent, and the other side is a controlled agent. A full implementation can take on either role, whereas a lite implementation can only be a controlled agent. The controlling agent decides which valid candidate to use and informs the controlled agent of it by identifying the pair as the nominated pair. This leads to the following connectivity precondition rules:
ICE实现可以是完整的，也可以是精简的（参见[RFC5245]）。完整实现生成并响应STUN绑定请求，而lite实现只响应它们。对于ICE，一边是控制剂，另一边是控制剂。完整实现可以承担任何角色，而lite实现只能是受控代理。控制代理决定使用哪个有效候选，并通过将候选对标识为指定候选对来通知控制代理。这将导致以下连接先决条件规则：
o A full implementation ascertains both "send" and "recv" connectivity when it operates as a STUN client and has sent a STUN Binding Request that resulted in a successful check for all the components of the media stream (as defined further in ICE).
o 当它作为一个STUN客户端运行并发送了一个STUN绑定请求，从而成功检查了媒体流的所有组件（如ICE中的进一步定义）时，完整的实现将确定“发送”和“接收”连接。
o A full or a lite implementation ascertains "recv" connectivity when it operates as a STUN server and has received a STUN Binding Request that resulted in a successful response for all the components of the media stream (as defined further in ICE).
o 完整或lite实现在其作为STUN服务器运行并接收到STUN绑定请求时确定“recv”连接，该请求导致媒体流所有组件的成功响应（如ICE中的进一步定义）。
o A lite implementation ascertains "send" and "recv" connectivity when the controlling agent has informed it of the nominated pair for all the components of the media stream.
o lite实现在控制代理通知其媒体流的所有组件的指定对时确定“发送”和“接收”连接。
A simpler and slightly more delay-prone alternative to the above rules is for all ICE implementations to ascertain "send" and "recv" connectivity for a media stream when the ICE state for that media stream has moved to Completed.
上述规则的一个更简单、更容易延迟的替代方案是，当媒体流的ICE状态移动到完成时，所有ICE实现都要确定媒体流的“发送”和“接收”连接。
Note that there is never a need for the answerer to request confirmation of the connectivity precondition when using ICE: the answerer can determine the status locally. Also note, that when ICE is used to verify connectivity preconditions, the precondition is not satisfied until connectivity has been verified for all the component transport addresses used by the media stream. For example, with an RTP-based media stream where RTCP is not suppressed, connectivity MUST be ascertained for both RTP and RTCP. Finally, it should be noted, that although connectivity has been ascertained, a new offer/ answer exchange may be required before media can flow (per ICE).
请注意，在使用ICE时，应答者无需请求确认连接先决条件：应答者可以在本地确定状态。还请注意，当使用ICE验证连接前提条件时，在验证媒体流使用的所有组件传输地址的连接之前，前提条件不会得到满足。例如，对于未抑制RTCP的基于RTP的媒体流，必须确定RTP和RTCP的连接。最后，应注意的是，尽管已确定连通性，但在媒体能够流动之前，可能需要进行新的报价/应答交换（每个ICE）。
The above are merely examples of explicit connectivity verification mechanisms. Other techniques can be used as well. It is however RECOMMENDED that ICE be supported by entities that support connectivity preconditions. Use of ICE has the benefit of working for all media streams (not just RTP) as well as facilitating NAT and firewall traversal, which may otherwise interfere with connectivity. Furthermore, the ICE recommendation provides a baseline to ensure
以上只是显式连接验证机制的示例。也可以使用其他技术。但是，建议ICE由支持连接前提条件的实体支持。使用ICE有利于处理所有媒体流（不仅仅是RTP）以及促进NAT和防火墙穿越，否则可能会干扰连接。此外，ICE建议提供了一个基线，以确保
that all entities that require probe traffic to support the connectivity preconditions have a common way of ascertaining connectivity.
所有需要探测流量以支持连接前提条件的实体都有一种确定连接的通用方法。
Connection-oriented transport protocols generally provide an implicit connectivity verification mechanism. Connection establishment involves sending traffic in both directions thereby verifying connectivity at the transport-protocol level. When a three-way (or more) handshake for connection establishment succeeds, bi-directional communication is confirmed and both the "send" and "recv" preconditions are satisfied whether requested or not. In the case of TCP for example, once the TCP three-way handshake has completed (SYN, SYN-ACK, ACK), the TCP connection is established and data can be sent and received by either party (i.e., both a send and a receive connectivity precondition has been satisfied). SCTP (Stream Control Transmission Protocol) [RFC4960] connections have similar semantics as TCP and SHOULD be treated the same.
面向连接的传输协议通常提供隐式连接验证机制。连接建立涉及向两个方向发送通信量，从而在传输协议级别验证连接。当用于建立连接的三向（或更多）握手成功时，双向通信得到确认，并且无论是否请求，“发送”和“接收”前提条件都得到满足。例如，在TCP的情况下，一旦TCP三方握手完成（SYN，SYN-ACK，ACK），TCP连接就建立起来，任何一方都可以发送和接收数据（即，发送和接收连接先决条件都已满足）。SCTP（流控制传输协议）[RFC4960]连接具有与TCP相似的语义，应被视为相同的连接。
When a connection-oriented transport is part of an offer, it may be passive, active, or active/passive [RFC4145]. When it is passive, the offerer expects the answerer to initiate the connection establishment, and when it is active, the offerer wants to initiate the connection establishment. When it is active/passive, the answerer decides. As noted earlier, lack of a media-stream-to-dialog correlation mechanism can make it difficult to guarantee with whom connectivity has been ascertained. When the offerer takes on the passive role, the offerer will not necessarily know which SIP dialog originated an incoming connection request. If the offerer instead is active, this problem is avoided.
当面向连接的传输是报价的一部分时，它可以是被动的、主动的或主动/被动的[RFC4145]。当它是被动的时，发盘方希望应答方启动连接建立，当它是主动的时，发盘方希望启动连接建立。当它是主动/被动时，由回答者决定。如前所述，缺少媒体流到对话的关联机制可能导致难以保证与谁的连接已被确定。当发盘方扮演被动角色时，发盘方不一定知道哪个SIP对话发起了传入的连接请求。如果报价人处于活动状态，则可以避免此问题。
The role of a connectivity precondition is to ascertain media stream connectivity before establishing or modifying a session. The underlying intent is for the two parties to be able to exchange media packets successfully. However, connectivity by itself may not fully satisfy this. Quality of Service, for example, may be required for the media stream; this can be addressed by use of the "qos" precondition defined in RFC 3312 [RFC3312]. Similarly, successful security parameter negotiation may be another prerequisite; this can be addressed by use of the "sec" precondition defined in RFC 5027 [RFC5027].
连接先决条件的作用是在建立或修改会话之前确定媒体流连接。基本意图是双方能够成功交换媒体数据包。然而，连接性本身可能无法完全满足这一要求。例如，媒体流可能需要服务质量；这可以通过使用RFC 3312[RFC3312]中定义的“qos”前提条件来解决。同样，成功的安全参数协商可能是另一个先决条件；这可以通过使用RFC 5027[RFC5027]中定义的“sec”前提条件来解决。
The first example uses the connectivity precondition with TCP in the context of a session involving a wireless access medium. Both UAs use a radio access network that does not allow them to send any data (not even a TCP SYN) until a radio bearer has been set up for the connection. Figure 1 shows the message flow of this example (the required PRACK transaction has been omitted for clarity -- see [RFC3312] for details):
第一个示例在涉及无线访问介质的会话上下文中使用TCP的连接前提条件。两个UAs都使用一个无线接入网络，在为连接设置无线承载之前，该网络不允许它们发送任何数据（甚至不允许发送TCP SYN）。图1显示了该示例的消息流（为了清晰起见，省略了所需的PRACK事务——有关详细信息，请参见[RFC3312]：
A B
| INVITE |
| a=curr:conn e2e none |
| a=des:conn mandatory e2e sendrecv |
| a=setup:holdconn |
|----------------------------------->|
| |
| 183 Session Progress |
| a=curr:conn e2e none |
| a=des:conn mandatory e2e sendrecv |
| a=setup:holdconn |
|<-----------------------------------|
| |
| UPDATE |
| a=curr:conn e2e none |
| a=des:conn mandatory e2e sendrecv |
A's radio | a=setup:actpass |
bearer is +----------------------------------->|
up | |
| 200 OK |
| a=curr:conn e2e none |
| a=des:conn mandatory e2e sendrecv |
| a=setup:active |
|<-----------------------------------|
| |
| |
| |
| | B's radio
|<---TCP Connection Establishment--->+ bearer is up
| | B sends TCP SYN
| |
| |
| 180 Ringing | TCP connection
|<-----------------------------------+ is up
| | B alerts the user
| |
A B
| INVITE |
| a=curr:conn e2e none |
| a=des:conn mandatory e2e sendrecv |
| a=setup:holdconn |
|----------------------------------->|
| |
| 183 Session Progress |
| a=curr:conn e2e none |
| a=des:conn mandatory e2e sendrecv |
| a=setup:holdconn |
|<-----------------------------------|
| |
| UPDATE |
| a=curr:conn e2e none |
| a=des:conn mandatory e2e sendrecv |
A's radio | a=setup:actpass |
bearer is +----------------------------------->|
up | |
| 200 OK |
| a=curr:conn e2e none |
| a=des:conn mandatory e2e sendrecv |
| a=setup:active |
|<-----------------------------------|
| |
| |
| |
| | B's radio
|<---TCP Connection Establishment--->+ bearer is up
| | B sends TCP SYN
| |
| |
| 180 Ringing | TCP connection
|<-----------------------------------+ is up
| | B alerts the user
| |
Figure 1: Message Flow with Two Types of Preconditions
图1：具有两种先决条件的消息流
A sends an INVITE requesting connection-establishment preconditions. The setup attribute in the offer is set to holdconn [RFC4145] because A cannot send or receive any data before setting up a radio bearer for the connection.
A发送一个INVITE请求建立连接的先决条件。要约中的设置属性设置为holdconn[RFC4145]，因为在为连接设置无线电承载之前，A无法发送或接收任何数据。
B agrees to use the connectivity precondition by sending a 183 (Session Progress) response. The setup attribute in the answer is also set to holdconn because B, like A, cannot send or receive any data before setting up a radio bearer for the connection.
B同意通过发送183（会话进度）响应来使用连接前提条件。应答中的setup属性也设置为holdconn，因为B与A一样，在为连接设置无线电承载之前无法发送或接收任何数据。
When A's radio bearer is ready, A sends an UPDATE to B with a setup attribute with a value of actpass. This attribute indicates that A can perform an active or a passive TCP open. A is letting B choose which endpoint will initiate the connection.
当A的无线电承载就绪时，A向B发送一个更新，该更新带有一个设置属性，值为actpass。此属性表示可以执行主动或被动TCP打开。A让B选择哪个端点将启动连接。
Since B's radio bearer is not ready yet, B chooses to be the one initiating the connection and indicates this with a setup attribute with a value of active. At a later point, when B's radio bearer is ready, B initiates the TCP connection towards A.
由于B的无线电承载尚未准备就绪，B选择启动连接，并使用值为active的setup属性来指示这一点。稍后，当B的无线承载就绪时，B向a发起TCP连接。
Once the TCP connection is established successfully, B knows the "sendrecv" precondition is satisfied, and B proceeds with the session (i.e., alerts the Callee), and sends a 180 (Ringing) response.
一旦TCP连接成功建立，B知道“sendrecv”先决条件已满足，B继续会话（即提醒被叫方），并发送180（振铃）响应。
The second example shows a basic SIP session establishment using SDP connectivity preconditions and ICE (the required PRACK transaction and some SDP details have been omitted for clarity). The offerer (A) is a full ICE implementation whereas the answerer (B) is a lite ICE implementation. The message flow for this scenario is shown in Figure 2 below.
第二个示例显示了使用SDP连接先决条件和ICE的基本SIP会话建立（为了清楚起见，省略了所需的PRACK事务和一些SDP细节）。报价人（A）是完整的ICE实现，而应答人（B）是精简的ICE实现。此场景的消息流如下图2所示。
A B
A B
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| |
|~~~~~ Connectivity check to B ~~~~~~~~~~~~~>|
|<~~~~ Connectivity to B OK ~~~~~~~~~~~~~~~~~|
| |
|-------------(3) UPDATE SDP3--------------->|
| |
|<--------(4) 200 OK (UPDATE) SDP4-----------|
| |
|<-------------(5) 180 Ringing---------------|
| |
| |
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| |
|~~~~~ Connectivity check to B ~~~~~~~~~~~~~>|
|<~~~~ Connectivity to B OK ~~~~~~~~~~~~~~~~~|
| |
|-------------(3) UPDATE SDP3--------------->|
| |
|<--------(4) 200 OK (UPDATE) SDP4-----------|
| |
|<-------------(5) 180 Ringing---------------|
| |
| |
Figure 2: Connectivity Precondition with ICE Connectivity Checks
图2：具有ICE连接检查的连接前提条件
SDP1: A includes a mandatory end-to-end connectivity precondition with a desired status of "sendrecv"; this will ensure media stream connectivity in both directions before continuing with the session setup. Since media stream connectivity in either direction is unknown at this point, the current status is set to "none". A's local status table (see [RFC3312]) for the connectivity precondition is as follows:
SDP1:A包括一个必需的端到端连接前提条件，其所需状态为“sendrecv”；在继续会话设置之前，这将确保媒体流在两个方向上的连接。由于此时任何方向的媒体流连接都未知，因此当前状态设置为“无”。A的本地状态表（参见[RFC3312]）中的连接前提条件如下：
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | no | mandatory | no
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | no | mandatory | no
and the resulting offer SDP is:
由此产生的报价SDP为：
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=rtcp:20001
a=curr:conn e2e none
a=des:conn mandatory e2e sendrecv
a=candidate:1 1 UDP 2130706431 192.0.2.1 20000 typ host
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=rtcp:20001
a=curr:conn e2e none
a=des:conn mandatory e2e sendrecv
a=candidate:1 1 UDP 2130706431 192.0.2.1 20000 typ host
SDP2: When B receives the offer, B sees the mandatory sendrecv connectivity precondition. B is a lite ICE implementation and hence B can only ascertain "recv" connectivity (from B's point of view)
SDP2：当B收到报价时，B会看到强制的sendrecv连接先决条件。B是lite ICE实现，因此B只能确定“recv”连接（从B的角度）
from A; thus, B wants A to inform it about connectivity in the other direction ("send" from B's point of view). B's local status table therefore looks as follows:
从一个；因此，B希望A向其告知另一个方向的连通性（“从B的角度发送”）。因此，B的本地状态表如下所示：
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | no | mandatory | no
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | no | mandatory | no
Since B is a lite ICE implementation and B wants to ask A for confirmation about the "send" (from B's point of view) connectivity precondition, the resulting answer SDP becomes:
由于B是lite ICE实现，并且B希望要求a确认“发送”（从B的角度来看）连接前提条件，因此SDP的结果是：
a=ice-lite
a=ice-pwd:qrCA8800133321zF9AIj98
a=ice-ufrag:H92p
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=rtcp:30001
a=curr:conn e2e none
a=des:conn mandatory e2e sendrecv
a=conf:conn e2e send
a=candidate:1 1 UDP 2130706431 192.0.2.4 30000 typ host
a=ice-lite
a=ice-pwd:qrCA8800133321zF9AIj98
a=ice-ufrag:H92p
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=rtcp:30001
a=curr:conn e2e none
a=des:conn mandatory e2e sendrecv
a=conf:conn e2e send
a=candidate:1 1 UDP 2130706431 192.0.2.4 30000 typ host
Since the "send" and the "recv" connectivity precondition (from B's point of view) are still not satisfied, session establishment remains suspended.
由于“发送”和“接收”连接前提条件（从B的角度来看）仍然不满足，会话建立仍然暂停。
SDP3: When A receives the answer SDP, A notes that B is a lite ICE implementation and that confirmation was requested for B's "send" connectivity precondition, which is the "recv" precondition from A's point of view. A performs a successful send and recv connectivity check to B by sending an ICE connectivity check to B and receiving the corresponding response. A's local status table becomes:
SDP3：当A收到回答SDP时，A注意到B是lite ICE实现，并且要求确认B的“发送”连接前提条件，从A的角度来看，这是“recv”前提条件。通过向B发送ICE连接检查并接收相应的响应，A向B执行成功的发送和接收连接检查。A的本地状态表变为：
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | yes | mandatory | no
recv | yes | mandatory | yes
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | yes | mandatory | no
recv | yes | mandatory | yes
whereas B's local status table becomes:
鉴于B的本地状态表变为：
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | yes | mandatory | no
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | yes | mandatory | no
Since B asked for confirmation about the "recv" connectivity (from A's point of view), A now sends an UPDATE (5) to B to confirm the connectivity from A to B:
由于B要求确认“recv”连接（从A的角度来看），A现在向B发送更新（5）以确认从A到B的连接：
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=rtcp:20001
a=curr:conn e2e sendrecv
a=des:conn mandatory e2e sendrecv
a=candidate:1 1 UDP 2130706431 192.0.2.1 20000 typ host
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=rtcp:20001
a=curr:conn e2e sendrecv
a=des:conn mandatory e2e sendrecv
a=candidate:1 1 UDP 2130706431 192.0.2.1 20000 typ host
B knows it has recv connectivity (verified by ICE as well as A's UPDATE) and send connectivity (confirmed by A's UPDATE) at this point. B's local status table becomes:
B知道其具有recv连接（由ICE和A的更新验证）和发送连接（由A的更新确认）。B的本地状态表变为：
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | yes | mandatory | no
recv | yes | mandatory | no
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | yes | mandatory | no
recv | yes | mandatory | no
and the session can continue.
会议可以继续。
General security considerations for preconditions are discussed in RFC 3312 [RFC3312] and RFC 4032 [RFC4032]. As discussed in RFC 4032 [RFC4032], it is strongly RECOMMENDED that S/MIME [RFC3853] integrity protection be applied to the SDP session descriptions. When the user agent provides identity services (rather than the proxy server), the SIP identity mechanism specified in RFC 4474 [RFC4474] provides an alternative end-to-end integrity protection. Additionally, the following security issues relate specifically to connectivity preconditions.
RFC 3312[RFC3312]和RFC 4032[RFC4032]中讨论了前置条件的一般安全注意事项。如RFC 4032[RFC4032]中所述，强烈建议对SDP会话描述应用S/MIME[RFC3853]完整性保护。当用户代理提供身份服务（而不是代理服务器）时，RFC 4474[RFC4474]中指定的SIP身份机制提供替代的端到端完整性保护。此外，以下安全问题专门与连接前提条件有关。
Connectivity preconditions rely on mechanisms beyond SDP, such as TCP [RFC0793] connection establishment or ICE connectivity checks [RFC5245], to establish and verify connectivity between an offerer and an answerer. An attacker that prevents those mechanisms from succeeding (e.g., by keeping ICE connectivity checks from arriving at their destination) can prevent media sessions from being established. While this attack relates to connectivity preconditions, it is actually an attack against the connection-establishment mechanisms used by the endpoints. This attack can be performed in the presence or in the absence of connectivity preconditions. In their presence, the whole session setup will be disrupted. In their absence, only the establishment of the particular stream under attack will be
连通性先决条件依赖于SDP之外的机制，如TCP[RFC0793]连接建立或ICE连通性检查[RFC5245]，以建立和验证报价人和应答人之间的连通性。阻止这些机制成功（例如，阻止ICE连接检查到达目的地）的攻击者可以阻止建立媒体会话。虽然此攻击与连接先决条件有关，但实际上是针对端点使用的连接建立机制的攻击。此攻击可以在存在或不存在连接先决条件的情况下执行。当他们在场时，整个会话设置将被中断。如果没有它们，则只会创建受攻击的特定流
disrupted. This specification does not provide any mechanism against attackers able to block traffic between the endpoints involved in the session because such an attacker will always be able to launch DoS (Denial-of-Service) attacks.
中断。此规范未提供任何机制来抵御能够阻止会话中涉及的端点之间通信的攻击者，因为此类攻击者始终能够发起DoS（拒绝服务）攻击。
Instead of blocking the connectivity checks, the attacker can generate forged connectivity checks that would cause the endpoints to assume that there was connectivity when there was actually no connectivity. This attack would result in the user experience being poor because the session would be established without all the media streams being ready. The same attack can be used, regardless of whether or not connectivity preconditions are used, to attempt to hijack a connection. The forged connectivity checks would trick the endpoints into sending media to the wrong direction. To prevent these attacks, it is RECOMMENDED that the mechanisms used to check connectivity are adequately secured by message authentication and integrity protection. For example, Section 2.5 of [RFC5245] discusses how message integrity and data origin authentication are implemented in ICE connectivity checks.
攻击者可以生成伪造的连接检查，而不是阻止连接检查，这将导致端点在实际上没有连接的情况下假设存在连接。此攻击将导致用户体验不佳，因为在没有准备好所有媒体流的情况下建立会话。无论是否使用连接先决条件，都可以使用相同的攻击试图劫持连接。伪造的连接检查会欺骗端点将媒体发送到错误的方向。为了防止这些攻击，建议通过消息身份验证和完整性保护充分保护用于检查连接的机制。例如，[RFC5245]的第2.5节讨论了如何在ICE连接检查中实现消息完整性和数据源身份验证。
IANA has registered a new precondition type under the Precondition Types used with SIP subregistry, which is located under the Session Initiation Protocol (SIP) Parameters registry.
IANA已在SIP Subistry使用的前提条件类型下注册了一个新的前提条件类型，该类型位于会话启动协议（SIP）参数注册表下。
Precondition-Type Description Reference
----------------- ----------------------------------- ---------
conn Connectivity precondition [RFC5898]
Precondition-Type Description Reference
----------------- ----------------------------------- ---------
conn Connectivity precondition [RFC5898]
[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月。
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[RFC3312]Camarillo，G.，Marshall，W.，和J.Rosenberg，“资源管理和会话启动协议（SIP）的集成”，RFC 3312，2002年10月。
[RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)", RFC 3853, July 2004.
[RFC3853]Peterson，J.，“会话启动协议（SIP）的S/MIME高级加密标准（AES）要求”，RFC3853，2004年7月。
[RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation Protocol (SIP) Preconditions Framework", RFC 4032, March 2005.
[RFC4032]Camarillo，G.和P.Kyzivat，“会话启动协议（SIP）先决条件框架的更新”，RFC 4032，2005年3月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，2006年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月。
[RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for Session Description Protocol (SDP) Media Streams", RFC 5027, October 2007.
[RFC5027]Andreasen，F.和D.Wing，“会话描述协议（SDP）媒体流的安全先决条件”，RFC 5027，2007年10月。
[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月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4145]Yon，D.和G.Camarillo，“会话描述协议（SDP）中基于TCP的媒体传输”，RFC 41452005年9月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, December 2007.
[RFC5109]Li，A.“通用前向纠错的RTP有效载荷格式”，RFC 5109，2007年12月。
[ICE-TCP] Perreault, S., Ed. and J. Rosenberg, "TCP Candidates with Interactive Connectivity Establishment (ICE)", Work in Progress, October 2009.
[ICE-TCP]Perreault，S.，Ed.和J.Rosenberg，“具有交互式连接建立（ICE）的TCP候选者”，正在进行的工作，2009年10月。
Authors' Addresses
作者地址
Flemming Andreasen Cisco Systems, Inc. 499 Thornall Street, 8th Floor Edison, NJ 08837 USA
Flemming Andreasen Cisco Systems，Inc.美国新泽西州爱迪生市索纳尔街499号8楼，邮编：08837
EMail: fandreas@cisco.com
EMail: fandreas@cisco.com
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
David Oran Cisco Systems, Inc. 7 Ladyslipper Lane Acton, MA 01720 USA
David Oran Cisco Systems，Inc.地址：美国马萨诸塞州阿克顿市Ladyslipper Lane 7号01720
EMail: oran@cisco.com
EMail: oran@cisco.com
Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
Dan Wing Cisco Systems，Inc.美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
EMail: dwing@cisco.com
EMail: dwing@cisco.com