Network Working Group J. Rosenberg
Request for Comments: 4168 Cisco Systems
Category: Standards Track H. Schulzrinne
Columbia University
G. Camarillo
Ericsson
October 2005
Network Working Group J. Rosenberg
Request for Comments: 4168 Cisco Systems
Category: Standards Track H. Schulzrinne
Columbia University
G. Camarillo
Ericsson
October 2005
The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)
作为会话启动协议（SIP）传输的流控制传输协议（SCTP）
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 specifies a mechanism for usage of SCTP (the Stream Control Transmission Protocol) as the transport mechanism between SIP (Session Initiation Protocol) entities. SCTP is a new protocol that provides several features that may prove beneficial for transport between SIP entities that exchange a large amount of messages, including gateways and proxies. As SIP is transport-independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP.
本文档指定了使用SCTP（流控制传输协议）作为SIP（会话启动协议）实体之间传输机制的机制。SCTP是一种新的协议，它提供了一些特性，这些特性可能有利于交换大量消息的SIP实体之间的传输，包括网关和代理。由于SIP是独立于传输的，所以支持SCTP是一个相对简单的过程，与支持TCP几乎相同。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Potential Benefits ..............................................2
3.1. Advantages over UDP ........................................3
3.2. Advantages over TCP ........................................3
4. Transport Parameter .............................................5
5. SCTP Usage ......................................................5
5.1. Mapping of SIP Transactions into SCTP Streams ..............5
6. Locating a SIP Server ...........................................6
7. Security Considerations .........................................7
8. IANA Considerations .............................................7
9. References ......................................................7
9.1. Normative References .......................................7
9.2. Informative References .....................................8
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Potential Benefits ..............................................2
3.1. Advantages over UDP ........................................3
3.2. Advantages over TCP ........................................3
4. Transport Parameter .............................................5
5. SCTP Usage ......................................................5
5.1. Mapping of SIP Transactions into SCTP Streams ..............5
6. Locating a SIP Server ...........................................6
7. Security Considerations .........................................7
8. IANA Considerations .............................................7
9. References ......................................................7
9.1. Normative References .......................................7
9.2. Informative References .....................................8
The Stream Control Transmission Protocol (SCTP) [4] has been designed as a new transport protocol for the Internet (or intranets) at the same layer as TCP and UDP. SCTP has been designed with the transport of legacy SS7 signaling messages in mind. We have observed that many of the features designed to support transport of such signaling are also useful for the transport of SIP (the Session Initiation Protocol) [5], which is used to initiate and manage interactive sessions on the Internet.
流控制传输协议（SCTP）[4]被设计为与TCP和UDP在同一层的互联网（或内部网）的新传输协议。SCTP的设计考虑了传统SS7信令消息的传输。我们已经观察到，许多设计用于支持此类信令传输的功能对于SIP（会话启动协议）[5]的传输也很有用，SIP用于启动和管理Internet上的交互式会话。
SIP itself is transport-independent, and can run over any reliable or unreliable message or stream transport. However, procedures are only defined for transport over UDP and TCP. This document defines transport of SIP over SCTP.
SIP本身是独立于传输的，可以在任何可靠或不可靠的消息或流传输上运行。但是，仅为UDP和TCP上的传输定义了过程。本文档定义了通过SCTP的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 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
RFC 3257 presents some of the key benefits of SCTP [10]. We summarize some of these benefits here and analyze how they relate to SIP (a more detailed analysis can be found in [12]).
RFC 3257介绍了SCTP的一些主要优点[10]。我们在此总结了其中一些好处，并分析了它们与SIP的关系（更详细的分析见[12]）。
All the advantages that SCTP has over UDP regarding SIP transport are also shared by TCP. Below, there is a list of the general advantages that a connection-oriented transport protocol such as TCP or SCTP has over a connection-less transport protocol such as UDP.
与UDP相比，SCTP在SIP传输方面的所有优势也由TCP共享。下面列出了面向连接的传输协议（如TCP或SCTP）与无连接传输协议（如UDP）相比的一般优势。
Fast Retransmit: SCTP can quickly determine the loss of a packet, because of its usage of SACK and a mechanism that sends SACK messages faster than normal when losses are detected. The result is that losses of SIP messages can be detected much faster than when SIP is run over UDP (detection will take at least 500 ms, if not more). Note that TCP SACK exists as well, and TCP also has a fast retransmit option. Over an existing connection, this results in faster call setup times under conditions of packet loss, which is very desirable. This is probably the most significant advantage of SCTP for SIP transport.
快速重传：SCTP可以快速确定数据包的丢失，因为它使用了SACK，并且在检测到丢失时发送SACK消息的速度比正常情况下快。结果是，SIP消息丢失的检测速度比通过UDP运行SIP时快得多（检测至少需要500毫秒，如果不是更多的话）。请注意，TCP SACK也存在，并且TCP还具有快速重传选项。在现有连接上，这会导致在丢包情况下更快的呼叫建立时间，这是非常理想的。这可能是SCTP用于SIP传输的最大优势。
Congestion Control: SCTP maintains congestion control over the entire association. For SIP, this means that the aggregate rate of messages between two entities can be controlled. When SIP is run over TCP, the same advantages are afforded. However, when run over UDP, SIP provides less effective congestion control. This is because congestion state (measured in terms of the UDP retransmit interval) is computed on a transaction-by-transaction basis, rather than across all transactions. Thus, congestion control performance is similar to opening N parallel TCP connections, as opposed to sending N messages over one TCP connection.
拥塞控制：SCTP对整个关联保持拥塞控制。对于SIP，这意味着可以控制两个实体之间消息的聚合速率。当SIP在TCP上运行时，提供了相同的优势。但是，在UDP上运行时，SIP提供的拥塞控制效果较差。这是因为拥塞状态（根据UDP重新传输间隔测量）是基于事务逐个事务计算的，而不是跨所有事务计算的。因此，拥塞控制性能类似于打开N个并行TCP连接，而不是通过一个TCP连接发送N条消息。
Transport-Layer Fragmentation: SCTP and TCP provide transport-layer fragmentation. If a SIP message is larger than the MTU size, it is fragmented at the transport layer. When UDP is used, fragmentation occurs at the IP layer. IP fragmentation increases the likelihood of having packet losses and makes NAT and firewall traversal difficult, if not impossible. This feature will become important if the size of SIP messages grows dramatically.
传输层碎片：SCTP和TCP提供传输层碎片。如果SIP消息大于MTU大小，则它在传输层被分段。使用UDP时，在IP层发生碎片。IP碎片增加了数据包丢失的可能性，使NAT和防火墙穿越变得困难（如果不是不可能的话）。如果SIP消息的大小急剧增长，此功能将变得非常重要。
We have shown the advantages of SCTP and TCP over UDP. We now analyze the advantages of SCTP over TCP.
我们已经展示了SCTP和TCP相对于UDP的优势。现在我们分析SCTP相对于TCP的优势。
Head of the Line: SCTP is message-based, as opposed to TCP, which is stream-based. This allows SCTP to separate different signalling messages at the transport layer. TCP only understands bytes. Assembling received bytes to form signalling messages is performed at the application layer. Therefore, TCP always delivers an
首行：SCTP是基于消息的，而TCP是基于流的。这允许SCTP在传输层分离不同的信令消息。TCP只理解字节。将接收到的字节组合成信令消息是在应用层执行的。因此，TCP总是提供
ordered stream of bytes to the application. On the other hand, SCTP can deliver signalling messages to the application as soon as they arrive (when using the unordered service). The loss of a signalling message does not affect the delivery of the rest of the messages. This avoids the head of line blocking problem in TCP, which occurs when multiple higher layer connections are multiplexed within a single TCP connection. A SIP transaction can be considered an application layer connection. There are multiple transactions running between proxies. The loss of a message in one transaction should not adversely effect the ability of a different transaction to send a message. Thus, if SIP is run between entities with many transactions occurring in parallel, SCTP can provide improved performance over SIP over TCP (but not SIP over UDP; SIP over UDP is not ideal from a congestion control standpoint; see above).
到应用程序的有序字节流。另一方面，SCTP可以在信令消息到达时（使用无序服务时）立即向应用程序发送信令消息。信令消息的丢失不会影响其余消息的传递。这避免了TCP中的线头阻塞问题，即在单个TCP连接中多路复用多个更高层连接时发生的问题。SIP事务可以被视为应用层连接。代理之间运行多个事务。在一个事务中丢失消息不应对另一个事务发送消息的能力产生不利影响。因此，如果SIP在多个并行事务发生的实体之间运行，则SCTP可以通过TCP上的SIP提供更好的性能（但不是UDP上的SIP；从拥塞控制的角度来看，UDP上的SIP并不理想；请参见上文）。
Easier Parsing: Another advantage of message-based protocols, such as SCTP and UDP, over stream-based protocols, such as TCP, is that they allow easier parsing of messages at the application layer. There is no need to establish boundaries (typically using Content-Length headers) between different messages. However, this advantage is almost negligible.
更容易解析：与基于流的协议（如TCP）相比，基于消息的协议（如SCTP和UDP）的另一个优点是，它们允许在应用层更容易解析消息。不需要在不同的消息之间建立边界（通常使用内容长度头）。然而，这一优势几乎可以忽略不计。
Multihoming: An SCTP connection can be associated with multiple IP addresses on the same host. Data is always sent over one of the addresses, but if it becomes unreachable, data sent to one can migrate to a different address. This improves fault tolerance; network failures making one interface of the server unavailable do not prevent the service from continuing to operate. SIP servers are likely to have substantial fault tolerance requirements. It is worth noting that, because SIP is message oriented and not stream oriented, the existing SRV (Service Selection) procedures defined in [5] can accomplish the same goal, even when SIP is run over TCP. In fact, SRV records allow the 'connection' to fail over to a separate host. Since SIP proxies can run statelessly, failover can be accomplished without data synchronization between the primary and its backups. Thus, the multihoming capabilities of SCTP provide marginal benefits.
多主：SCTP连接可以与同一主机上的多个IP地址相关联。数据总是通过其中一个地址发送，但如果无法访问，发送到其中一个地址的数据可以迁移到另一个地址。这提高了容错能力；网络故障导致服务器的一个接口不可用不会阻止服务继续运行。SIP服务器可能有大量的容错要求。值得注意的是，由于SIP是面向消息的，而不是面向流的，因此[5]中定义的现有SRV（服务选择）过程可以实现相同的目标，即使SIP是通过TCP运行的。事实上，SRV记录允许“连接”故障转移到单独的主机。由于SIP代理可以无状态运行，因此可以在主代理与其备份之间不进行数据同步的情况下完成故障切换。因此，SCTP的多宿能力带来的好处微乎其微。
It is important to note that most of the benefits of SCTP for SIP occur under loss conditions. Therefore, under a zero loss condition, SCTP transport of SIP should perform on par with TCP transport. Research is needed to evaluate under what loss conditions the improvements in setup times and throughput will be observed.
需要注意的是，SCTP对SIP的大部分好处都发生在丢失情况下。因此，在零丢失条件下，SIP的SCTP传输应该与TCP传输保持一致。需要进行研究，以评估在什么样的损失条件下，可以观察到安装时间和吞吐量的改善。
Via header fields carry a transport protocol identifier. RFC 3261 defines the value "SCTP" for SCTP, but does not define the value for the transport parameter for TLS over SCTP. Note that the value "TLS", defined by RFC 3261, is intended for TLS over TCP.
Via标头字段带有传输协议标识符。RFC 3261为SCTP定义了值“SCTP”，但没有为通过SCTP的TLS定义传输参数的值。请注意，RFC 3261定义的值“TLS”用于TCP上的TLS。
Here we define the value "TLS-SCTP" for the transport part of the Via header field to be used for requests sent over TLS over SCTP [8]. The updated augmented BNF (Backus-Naur Form) [2] for this parameter is the following (the original BNF for this parameter can be found in RFC 3261):
这里，我们为Via标头字段的传输部分定义值“TLS-SCTP”，用于通过TLS通过SCTP发送的请求[8]。此参数的更新增广BNF（Backus Naur Form）[2]如下所示（此参数的原始BNF可在RFC 3261中找到）：
transport = "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP"
/ other-transport
transport = "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP"
/ other-transport
The following are examples of Via header fields using "SCTP" and "TLS-SCTP":
以下是使用“SCTP”和“TLS-SCTP”的Via标头字段示例：
Via: SIP/2.0/SCTP ws1234.example.com:5060
Via: SIP/2.0/TLS-SCTP ws1234.example.com:5060
Via: SIP/2.0/SCTP ws1234.example.com:5060
Via: SIP/2.0/TLS-SCTP ws1234.example.com:5060
Rules for sending a request over SCTP are identical to TCP. The only difference is that an SCTP sender has to choose a particular stream within an association in order to send the request (see Section 5.1).
通过SCTP发送请求的规则与TCP相同。唯一的区别是SCTP发送方必须选择关联中的特定流才能发送请求（参见第5.1节）。
Note that no SCTP identifier needs to be defined for SIP messages. Therefore, the Payload Protocol Identifier in SCTP DATA chunks transporting SIP messages MUST be set to zero.
注意，不需要为SIP消息定义SCTP标识符。因此，传输SIP消息的SCTP数据块中的有效负载协议标识符必须设置为零。
The SIP transport layers of both peers are responsible for managing the persistent SCTP connection between them. On the sender side, the core or a client (or server) transaction generates a request (or response) and passes it to the transport layer. The transport sends the request to the peer's transaction layer. The peer's transaction layer is responsible for delivering the incoming request (or response) to the proper existing server (or client) transaction. If no server (or client) transaction exists for the incoming message, the transport layer passes the request (or response) to the core, which may decide to construct a new server (or client) transaction.
两个对等方的SIP传输层负责管理它们之间的持久SCTP连接。在发送方，核心或客户端（或服务器）事务生成请求（或响应）并将其传递给传输层。传输将请求发送到对等方的事务层。对等方的事务层负责将传入的请求（或响应）传递到适当的现有服务器（或客户端）事务。如果传入消息不存在服务器（或客户端）事务，则传输层将请求（或响应）传递给核心，核心可能决定构造新的服务器（或客户端）事务。
SIP transactions need to be mapped into SCTP streams in a way that avoids Head Of the Line (HOL) blocking. Among the different ways of performing this mapping that fulfill this requirement, we have chosen
SIP事务需要以避免行首（HOL）阻塞的方式映射到SCTP流中。在满足这一需求的不同映射方式中，我们选择了
the simplest one; a SIP entity SHOULD send every SIP message (request or response) over stream zero with the unordered flag set. On the receiving side, a SIP entity MUST be ready to receive SIP messages over any stream.
最简单的一个；SIP实体应该通过流0发送每个SIP消息（请求或响应），并设置无序标志。在接收端，SIP实体必须准备好通过任何流接收SIP消息。
In the past, it was proposed that SCTP stream IDs be used as lightweight SIP transaction identifiers. That proposal was withdrawn because SIP now provides (as defined in RFC 3261 [5]) a transaction identifier in the branch parameter of the Via entries. This transaction identifier, missing in the previous SIP spec [9], makes it unnecessary to use the SCTP stream IDs to demultiplex SIP traffic.
在过去，有人建议将SCTP流ID用作轻量级SIP事务标识符。该提议被撤回，因为SIP现在在Via条目的分支参数中提供（如RFC 3261[5]中定义的）事务标识符。在以前的SIP规范[9]中缺少此事务标识符，因此无需使用SCTP流ID来解复用SIP流量。
In many circumstances, SIP requires the use of TLS [3], for instance, when routing a SIPS URI [5]. As defined in RFC 3436 [8], TLS running over SCTP MUST NOT use the SCTP unordered delivery service. Moreover, any SIP use of an extra layer between the transport layer and SIP that requires ordered delivery of messages MUST NOT use the SCTP unordered delivery service.
在许多情况下，SIP需要使用TLS[3]，例如，在路由SIPS URI[5]时。如RFC 3436[8]所定义，通过SCTP运行的TLS不得使用SCTP无序交付服务。此外，任何在传输层和SIP之间使用需要有序传递消息的额外层的SIP都不得使用SCTP无序传递服务。
SIP applications that require ordered delivery of messages from the transport layer (e.g., TLS) SHOULD send SIP messages belonging to the same SIP transaction over the same SCTP stream. Additionally, they SHOULD send messages belonging to different SIP transactions over different SCTP streams, as long as there are enough available streams.
需要从传输层（例如TLS）有序传递消息的SIP应用程序应通过相同的SCTP流发送属于相同SIP事务的SIP消息。此外，只要有足够的可用流，它们就应该通过不同的SCTP流发送属于不同SIP事务的消息。
A common scenario where the above mechanism should be used consists of two proxies exchanging SIP traffic over a TLS connection using SCTP as the transport protocol. This works because all of the SIP transactions between the two proxies can be established within one SCTP association.
应使用上述机制的常见场景包括两个代理，使用SCTP作为传输协议，通过TLS连接交换SIP流量。这是因为两个代理之间的所有SIP事务都可以在一个SCTP关联中建立。
Note that if both sides of the association follow this recommendation, when a request arrives over a particular stream, the server is free to return responses over a different stream. This way, both sides manage the available streams in the sending direction, independently of the streams chosen by the other side to send a particular SIP message. This avoids undesirable collisions when seizing a particular stream.
请注意，如果关联的双方都遵循此建议，则当请求通过特定流到达时，服务器可以自由地通过不同的流返回响应。这样，双方在发送方向上管理可用流，独立于另一方选择发送特定SIP消息的流。这可以避免在捕获特定流时发生不必要的冲突。
The primary issue when sending a request is determining whether the next hop server supports SCTP so that an association can be opened. SIP entities follow normal SIP procedures to discover [6] a server that supports SCTP.
发送请求时的主要问题是确定下一跳服务器是否支持SCTP，以便打开关联。SIP实体遵循正常的SIP过程来发现[6]支持SCTP的服务器。
However, in order to use TLS on top of SCTP, an extra definition is needed. RFC 3263 defines the NAPTR (Naming Authority Pointer) [7] service value "SIP+D2S" for SCTP, but fails to define a value for TLS over SCTP. Here we define the NAPTR service value "SIPS+D2S" for servers that support TLS over SCTP [8].
然而，为了在SCTP之上使用TLS，需要一个额外的定义。RFC 3263为SCTP定义NAPTR（命名机构指针）[7]服务值“SIP+D2S”，但未能为通过SCTP的TLS定义值。这里，我们为支持基于SCTP的TLS的服务器定义NAPTR服务值“SIPS+D2S”[8]。
The security issues raised in RFC 3261 [5] are not worsened by SCTP, provided the advice in Section 5.1 is followed and TLS over SCTP [8] is used where TLS would be required in RFC 3261 [5] or in RFC 3263 [6]. So, the mechanisms described in RFC 3436 [8] MUST be used when SIP runs on top of TLS [3] and SCTP.
如果遵循第5.1节中的建议，并且在RFC 3261[5]或RFC 3263[6]中需要TLS的地方使用SCTP[8]上的TLS，则SCTP不会加剧RFC 3261[5]中提出的安全问题。因此，当SIP在TLS[3]和SCTP之上运行时，必须使用RFC 3436[8]中描述的机制。
This document defines a new NAPTR service field value (SIPS+ D2S). The IANA has registered this value under the "Registry for the SIP SRV Resource Record Services Field". The resulting entry is as follows:
本文档定义了一个新的NAPTR服务字段值（SIPS+D2S）。IANA已在“SIP SRV资源记录服务注册表”字段下注册了该值。结果分录如下：
Services Field Protocol Reference
-------------------- -------- ---------
SIPS+D2S SCTP [RFC4168]
Services Field Protocol Reference
-------------------- -------- ---------
SIPS+D2S SCTP [RFC4168]
[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] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[2] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[3] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[4] Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.，和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[5] 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.
[5] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[6] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC3263，2002年6月。
[7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[7] Mealling，M.“动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库”，RFC3403，2002年10月。
[8] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.
[8] Jungmaier，A.，Rescorla，E.，和M.Tuexen，“流控制传输协议上的传输层安全”，RFC 3436，2002年12月。
[9] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[9] Handley，M.，Schulzrinne，H.，Schooler，E.，和J.Rosenberg，“SIP：会话启动协议”，RFC 25431999年3月。
[10] Coene, L., "Stream Control Transmission Protocol Applicability Statement", RFC 3257, April 2002.
[10] Coene，L.，“流控制传输协议适用性声明”，RFC 3257，2002年4月。
[11] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004.
[11] Camarillo，G.，“会话启动协议（SIP）的Internet分配号码管理局（IANA）统一资源标识符（URI）参数注册表”，BCP 99，RFC 3969，2004年12月。
[12] Camarillo, G., Schulrinne, H., and R. Kantola, "Evaluation of Transport Protocols for the Session Initiation Protocol", IEEE, Network vol. 17, no. 5, 2003.
[12] Camarillo，G.，Schulrinne，H.，和R.Kantola，“会话启动协议的传输协议评估”，IEEE，网络第17卷，第5期，2003年。
Authors' Addresses
作者地址
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
Jonathan Rosenberg Cisco Systems 600美国新泽西州帕西帕尼拉尼德广场07054号
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 US
Henning Schulzrinne哥伦比亚大学M/S 0401 1214美国纽约州阿姆斯特丹大道10027-7003号
EMail: schulzrinne@cs.columbia.edu
EMail: schulzrinne@cs.columbia.edu
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
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编辑功能的资金目前由互联网协会提供。