Internet Engineering Task Force (IETF) V. Gurbani, Ed.
Request for Comments: 5923 Bell Laboratories, Alcatel-Lucent
Category: Standards Track R. Mahy
ISSN: 2070-1721 Unaffiliated
B. Tate
BroadSoft
June 2010
Internet Engineering Task Force (IETF) V. Gurbani, Ed.
Request for Comments: 5923 Bell Laboratories, Alcatel-Lucent
Category: Standards Track R. Mahy
ISSN: 2070-1721 Unaffiliated
B. Tate
BroadSoft
June 2010
Connection Reuse in the Session Initiation Protocol (SIP)
会话启动协议（SIP）中的连接重用
Abstract
摘要
This document enables a pair of communicating proxies to reuse a congestion-controlled connection between themselves for sending requests in the forwards and backwards direction. Because the connection is essentially aliased for requests going in the backwards direction, reuse is predicated upon both the communicating endpoints authenticating themselves using X.509 certificates through Transport Layer Security (TLS). For this reason, we only consider connection reuse for TLS over TCP and TLS over Stream Control Transmission Protocol (SCTP). This document also provides guidelines on connection reuse and virtual SIP servers and the interaction of connection reuse and DNS SRV lookups in SIP.
本文档使一对通信代理能够重用它们之间的拥塞控制连接，以便向前和向后发送请求。由于连接本质上是对反向请求的别名，因此重用是基于通信端点通过传输层安全性（TLS）使用X.509证书对自己进行身份验证。为此，我们只考虑TCP和TLS过流控制传输协议（SCTP）上的TLS的连接重用。本文档还提供了关于连接重用和虚拟SIP服务器以及SIP中连接重用和DNS SRV查找的交互的指南。
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/rfc5923.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5923.
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 ...................................................3
2. Terminology ....................................................4
3. Applicability Statement ........................................5
4. Benefits of TLS Connection Reuse ...............................5
5. Overview of Operation ..........................................6
6. Requirements ..................................................10
7. Formal Syntax .................................................11
8. Normative Behavior ............................................11
8.1. Client Behavior ...........................................11
8.2. Server Behavior ...........................................13
8.3. Closing a TLS Connection ..................................14
9. Security Considerations .......................................14
9.1. Authenticating TLS Connections: Client View ...............14
9.2. Authenticating TLS Connections: Server View ...............15
9.3. Connection Reuse and Virtual Servers ......................15
10. Connection Reuse and SRV Interaction ..........................17
11. IANA Considerations ...........................................17
12. Acknowledgments ...............................................17
13. References ....................................................18
13.1. Normative References ......................................18
13.2. Informative References ....................................18
1. Introduction ...................................................3
2. Terminology ....................................................4
3. Applicability Statement ........................................5
4. Benefits of TLS Connection Reuse ...............................5
5. Overview of Operation ..........................................6
6. Requirements ..................................................10
7. Formal Syntax .................................................11
8. Normative Behavior ............................................11
8.1. Client Behavior ...........................................11
8.2. Server Behavior ...........................................13
8.3. Closing a TLS Connection ..................................14
9. Security Considerations .......................................14
9.1. Authenticating TLS Connections: Client View ...............14
9.2. Authenticating TLS Connections: Server View ...............15
9.3. Connection Reuse and Virtual Servers ......................15
10. Connection Reuse and SRV Interaction ..........................17
11. IANA Considerations ...........................................17
12. Acknowledgments ...............................................17
13. References ....................................................18
13.1. Normative References ......................................18
13.2. Informative References ....................................18
SIP entities can communicate using either unreliable/connectionless (e.g., UDP) or reliable/connection-oriented (e.g., TCP, SCTP [RFC4960]) transport protocols. When SIP entities use a connection-oriented protocol (such as TCP or SCTP) to send a request, they typically originate their connections from an ephemeral port.
SIP实体可以使用不可靠/无连接（如UDP）或可靠/面向连接（如TCP、SCTP[RFC4960]）传输协议进行通信。当SIP实体使用面向连接的协议（如TCP或SCTP）发送请求时，它们通常从临时端口发起连接。
In the following example, A listens for SIP requests over TLS on TCP port 5061 (the default port for SIP over TLS over TCP), but uses an ephemeral port (port 49160) for a new connection to B. These entities could be SIP user agents or SIP proxy servers.
在以下示例中，A在TCP端口5061（TCP上的TLS上的SIP的默认端口）上通过TLS侦听SIP请求，但使用临时端口（端口49160）与B建立新连接。这些实体可以是SIP用户代理或SIP代理服务器。
+-----------+ 49160 (UAC) 5061 (UAS) +-----------+
| |--------------------------->| |
| Entity | | Entity |
| A | | B |
| | 5061 (UAS) | |
+-----------+ +-----------+
+-----------+ 49160 (UAC) 5061 (UAS) +-----------+
| |--------------------------->| |
| Entity | | Entity |
| A | | B |
| | 5061 (UAS) | |
+-----------+ +-----------+
Figure 1: Uni-directional connection for requests from A to B
图1：从A到B请求的单向连接
The SIP protocol includes the notion of a persistent connection (defined in Section 2), which is a mechanisms to insure that responses to a request reuse the existing connection that is typically still available, as well as reusing the existing connections for other requests sent by the originator of the connection. However, new requests sent in the backwards direction -- in the example above, requests from B destined to A -- are unlikely to reuse the existing connection. This frequently causes a pair of SIP entities to use one connection for requests sent in each direction, as shown below.
SIP协议包括持久连接的概念（在第2节中定义），这是一种机制，用于确保对请求的响应重用通常仍然可用的现有连接，以及将现有连接重用为连接发起人发送的其他请求。然而，向后发送的新请求——在上面的示例中，从B到A的请求——不太可能重用现有连接。这通常会导致一对SIP实体对每个方向发送的请求使用一个连接，如下所示。
+-----------+ 49160 5061 +-----------+
| |.......................>| |
| Entity | | Entity |
| A | 5061 49170 | B |
| |<-----------------------| |
+-----------+ +-----------+
+-----------+ 49160 5061 +-----------+
| |.......................>| |
| Entity | | Entity |
| A | 5061 49170 | B |
| |<-----------------------| |
+-----------+ +-----------+
Figure 2: Two connections for requests between A and B
图2:A和B之间请求的两个连接
Unlike TCP, TLS connections can be reused to send requests in the backwards direction since each end can be authenticated when the connection is initially set up. Once the authentication step has been performed, the situation can thought to resemble the picture in Figure 1 except that A and B both use a single shared connection, for
与TCP不同的是，TLS连接可以重新使用以向后发送请求，因为在最初建立连接时，可以对每一端进行身份验证。一旦执行了身份验证步骤，可以认为情况类似于图1中的图片，除了A和B都使用单个共享连接之外，例如
example, between port 49160 on A and port 5061 on B. When A wants to send a request to B, it will reuse this connection, and when B wants to send a request to A, it will reuse the same connection.
例如，A上的端口49160和B上的端口5061之间。当A想要向B发送请求时，它将重用此连接，当B想要向A发送请求时，它将重用相同的连接。
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]中所述进行解释。
Additional terminology used in this document:
本文件中使用的其他术语：
Advertised address: The address that occurs in the Via header field's sent-by production rule, including the port number and transport.
播发地址：在生产规则发送的Via标头字段中出现的地址，包括端口号和传输。
Alias: Reusing an existing connection to send requests in the backwards direction; i.e., A opens a connection to B to send a request, and B uses that connection to send requests in the backwards direction to A.
别名：重用现有连接以向后发送请求；i、 例如，A打开与B的连接以发送请求，B使用该连接向后向A发送请求。
Connection reuse: See "Alias".
连接重用：请参阅“别名”。
Persistent connection: The process of sending multiple, possibly unrelated requests on the same connection, and receiving responses on that connection as well. More succinctly, A opens a connection to B to send a request, and later reuses the same connection to send other requests, possibly unrelated to the dialog established by the first request. Responses will arrive over the same connection. Persistent connection behavior is specified in Section 18 of RFC 3261 [RFC3261]. Persistent connections do not imply connection reuse.
持久连接：在同一连接上发送多个可能不相关的请求，并在该连接上接收响应的过程。更简洁地说，A打开与B的连接以发送请求，然后重用同一连接以发送其他请求，可能与第一个请求建立的对话框无关。响应将通过相同的连接到达。RFC 3261[RFC3261]第18节规定了持久连接行为。持久连接并不意味着连接重用。
Resolved address: The network identifiers (IP address, port, transport) associated with a user agent as a result of executing RFC 3263 [RFC3263] on a Uniform Resource Identifier (URI).
解析地址：在统一资源标识符（URI）上执行RFC 3263[RFC3263]后，与用户代理关联的网络标识符（IP地址、端口、传输）。
Shared connection: See "Persistent connection".
共享连接：请参阅“持久连接”。
The applicability of the mechanism described in this document is for two adjacent SIP entities to reuse connections when they are agnostic about the direction of the connection, i.e., either end can initiate the connection. SIP entities that can only open a connection in a specific direction -- perhaps because of Network Address Translation (NAT) and firewalls -- reuse their connections using the mechanism described in the outbound document [RFC5626].
本文档中描述的机制适用于两个相邻的SIP实体，当它们不知道连接的方向时，可以重用连接，即任何一端都可以启动连接。可能由于网络地址转换（NAT）和防火墙的原因，只能在特定方向上打开连接的SIP实体使用出站文档[RFC5626]中描述的机制重用其连接。
This memo concerns connection reuse, not persistent connections (see definitions of these in Section 2). Behavior for persistent connections is specified in Section 18 of RFC 3261 [RFC3261] and is not altered by this memo.
本备忘录涉及连接重用，而不是持久连接（请参见第2节中的定义）。RFC 3261[RFC3261]第18节规定了持续连接的行为，本备忘录未对其进行更改。
This memo documents that it is good practice to only reuse those connections where the identity of the sender can be verified by the receiver. Thus, TLS (RFC 5246 [RFC5246]) connections (over any connection-oriented transport) formed by exchanging X.509 certificates can be reused because they authoritatively establish identities of the communicating parties (see Section 5).
此备忘录证明，只有在接收方可以验证发送方身份的情况下，才重用这些连接是一种良好的做法。因此，通过交换X.509证书形成的TLS（RFC 5246[RFC5246]）连接（通过任何面向连接的传输）可以重用，因为它们权威地建立通信方的身份（参见第5节）。
Opening an extra connection where an existing one is sufficient can result in potential scaling and performance problems. Each new connection using TLS requires a TCP three-way handshake, a handful of round trips to establish TLS, typically expensive asymmetric authentication and key generation algorithms, and certificate verification. This can lead to a build up of considerable queues as the server CPU saturates by the TLS handshakes it is already performing (Section 6.19 of Rescorla [Book-Rescorla-TLS]).
在现有连接足够的情况下打开额外连接可能会导致潜在的扩展和性能问题。使用TLS的每个新连接都需要TCP三方握手、少量往返以建立TLS、通常昂贵的不对称身份验证和密钥生成算法以及证书验证。这可能会导致大量队列的建立，因为服务器CPU已经被它正在执行的TLS握手饱和（Rescorla[Book Rescorla TLS]第6.19节）。
Consider the call flow shown below where Proxy A and Proxy B use the Record-Route mechanism to stay involved in a dialog. Proxy B will establish a new TLS connection just to send a BYE request.
考虑下面的调用流程，其中代理A和代理B使用记录路由机制来参与对话。代理B将建立一个新的TLS连接以发送BYE请求。
Proxy A Proxy B
| |
Create connection 1 +---INV--->|
| |
|<---200---+ Response over connection 1
| |
Reuse connection 1 +---ACK--->|
| |
= =
| |
|<---BYE---+ Create connection 2
| |
Response over +---200--->|
connection 2
Proxy A Proxy B
| |
Create connection 1 +---INV--->|
| |
|<---200---+ Response over connection 1
| |
Reuse connection 1 +---ACK--->|
| |
= =
| |
|<---BYE---+ Create connection 2
| |
Response over +---200--->|
connection 2
Figure 3: Multiple connections for requests
图3：请求的多个连接
Setting up a second connection (from B to A above) for subsequent requests, even requests in the context of an existing dialog (e.g., re-INVITE request or BYE request after an initial INVITE request, or a NOTIFY request after a SUBSCRIBE request or a REFER request), can also cause excessive delay (especially in networks with long round-trip times). Thus, it is advantageous to reuse connections whenever possible.
为后续请求设置第二个连接（从上面的B到a），甚至是现有对话框上下文中的请求（例如，初始INVITE请求后的REINVITE请求或BYE请求，或订阅请求或REFER请求后的NOTIFY请求），也可能导致过度延迟（特别是在往返时间较长的网络中）. 因此，尽可能重用连接是有利的。
From the user expectation point of view, it is advantageous if the re-INVITE requests or UPDATE requests are handled automatically and rapidly in order to avoid media and session state from being out of step. If a re-INVITE request requires a new TLS connection, the re-INVITE request could be delayed by several extra round-trip times. Depending on the round-trip time, this combined delay could be perceptible or even annoying to a human user. This is especially problematic for some common SIP call flows (for example, the recommended example flow in Figure 4 in RFC 3725 [RFC3725] uses many re-INVITE requests).
从用户期望的角度来看，如果重新邀请请求或更新请求被自动且快速地处理以避免媒体和会话状态失步，则这是有利的。如果重新邀请请求需要新的TLS连接，则重新邀请请求可能会延迟几次额外的往返时间。根据往返时间的不同，这种组合延迟可能会被人类用户察觉到，甚至令人讨厌。这对于一些常见的SIP调用流来说尤其有问题（例如，RFC 3725[RFC3725]中图4中推荐的示例流使用了许多重新邀请请求）。
The mechanism described in this document can mitigate the delays associated with subsequent requests.
本文档中描述的机制可以缓解与后续请求相关的延迟。
This section is tutorial in nature, and does not specify any normative behavior.
本节本质上是教程，不指定任何规范行为。
We now explain this working in more detail in the context of communication between two adjacent proxies. Without any loss of generality, the same technique can be used for connection reuse between a User Agent Client (UAC) and an edge proxy, or between an edge proxy and a UAS, or between an UAC and an UAS.
现在，我们将在两个相邻代理之间的通信上下文中更详细地解释此工作。在不丧失通用性的情况下，相同的技术可用于用户代理客户端（UAC）和边缘代理之间、边缘代理和UAS之间或UAC和UAS之间的连接重用。
P1 and P2 are proxies responsible for routing SIP requests to user agents that use them as edge proxies (see Figure 4).
P1和P2是代理，负责将SIP请求路由到将其用作边缘代理的用户代理（见图4）。
P1 <===================> P2
p1.example.com p2.example.net
(192.0.2.1) (192.0.2.128)
P1 <===================> P2
p1.example.com p2.example.net
(192.0.2.1) (192.0.2.128)
+---+ +---+
| | 0---0 0---0 | |
|___| /-\ /-\ |___|
/ / +---+ +---+ / /
+----+ +----+
User Agents User Agents
example.com domain example.net domain
+---+ +---+
| | 0---0 0---0 | |
|___| /-\ /-\ |___|
/ / +---+ +---+ / /
+----+ +----+
User Agents User Agents
example.com domain example.net domain
Figure 4: Proxy setup
图4：代理设置
For illustration purpose the discussion below uses TCP as a transport for TLS operations. Another streaming transport -- such as SCTP -- can be used as well.
出于说明目的，下面的讨论使用TCP作为TLS操作的传输。也可以使用另一种流传输，如SCTP。
The act of reusing a connection is initiated by P1 when it adds an "alias" header field parameter (defined later) to the Via header field. When P2 receives the request, it examines the topmost Via header field. If the Via header contained an "alias" header field parameter, P2 establishes a binding such that subsequent requests going to P1 will reuse the connection; i.e., requests are sent over the established connection.
当P1向Via标头字段添加“alias”标头字段参数（稍后定义）时，重新使用连接的行为由P1启动。当P2收到请求时，它会检查最顶端的Via头字段。如果Via报头包含“alias”报头字段参数，则P2建立一个绑定，以使到P1的后续请求将重用该连接；i、 例如，通过已建立的连接发送请求。
With reference to Figure 4, in order for P2 to reuse a connection for requests in the backwards direction, it is important that the validation model for requests sent in this direction (i.e., P2 to P1) is equivalent to the normal "connection in each direction" model, wherein P2 acting as client would open up a new connection in the backwards direction and validate the connection by examining the X.509 certificate presented. The act of reusing a connection needs the desired property that requests get delivered in the backwards direction only if they would have been delivered to the same destination had connection reuse not been employed. To guarantee this property, the X.509 certificate presented by P1 to P2 when a TLS connection is first authenticated are cached for later use.
参考图4，为了让P2重用向后方向请求的连接，在该方向（即P2到P1）发送的请求的验证模型必须与正常的“每个方向的连接”模型等效，其中，作为客户端的P2将在向后方向打开一个新连接，并通过检查提供的X.509证书来验证该连接。重用连接的行为需要所需的属性，即请求只有在没有使用连接重用的情况下才会被传递到相同的目的地时，才会被反向传递。为了保证此属性，在TLS连接首次经过身份验证时，P1向P2提供的X.509证书将被缓存以供以后使用。
To aid the discussion of connection reuse, this document defines a data structure called the connection alias table (or simply, alias table), which is used to store aliased addresses and is used by user agents to search for an existing connection before a new one is opened up to a destination. It is not the intent of this memo to standardize the implementation of an alias table; rather, we use it as a convenience to aid subsequent discussions.
为了帮助讨论连接重用，本文档定义了一个称为连接别名表（或简称别名表）的数据结构，用于存储别名地址，并由用户代理在打开新连接到目标之前搜索现有连接。本备忘录的目的不是标准化别名表的实现；相反，我们将其作为一种便利来帮助后续讨论。
P1 gets a request from one of its upstream user agents, and after performing RFC3263 [RFC3263] server selection, arrives at a resolved address of P2. P1 maintains an alias table, and it populates the alias table with the IP address, port number, and transport of P2 as determined through RFC3263 server selection. P1 adds an "alias" header field parameter to the topmost Via header field (inserted by it) before sending the request to P2. The value in the sent-by production rule of the Via header field (including the port number), and the transport over which the request was sent becomes the advertised address of P1:
P1从其上游用户代理之一获取请求，并在执行RFC3263[RFC3263]服务器选择后，到达P2的解析地址。P1维护一个别名表，并使用IP地址、端口号和P2的传输（通过RFC3263服务器选择确定）填充别名表。在将请求发送到P2之前，P1将“alias”标头字段参数添加到最顶端的Via标头字段（由其插入）。Via标头字段的Send by production规则中的值（包括端口号）和发送请求的传输成为P1的播发地址：
Via: SIP/2.0/TLS p1.example.com;branch=z9hG4bKa7c8dze;alias
Via: SIP/2.0/TLS p1.example.com;branch=z9hG4bKa7c8dze;alias
Assuming that P1 does not already have an existing aliased connection with P2, P1 now opens a connection with P2. P2 presents its X.509 certificate to P1 for validation (see Section 9.1). Upon connection authentication and acceptance, P1 adds P2 to its alias table. P1's alias table now looks like:
假设P1还没有与P2的现有别名连接，P1现在将打开与P2的连接。P2将其X.509证书提交给P1进行验证（见第9.1节）。连接验证和接受后，P1将P2添加到其别名表中。P1的别名表现在看起来像：
Destination Destination Destination Destination Alias IP Address Port Transport Identity Descriptor ... 192.0.2.128 5061 TLS sip:example.net 25 sip:p2.example.net
目标别名IP地址端口传输标识描述符。。。192.0.2.128 5061 TLS sip:example.net 25 sip:p2.example.net
Subsequent requests that traverse from P1 to P2 will reuse this connection; i.e., the requests will be sent over the descriptor 25.
从P1遍历到P2的后续请求将重用此连接；i、 例如，请求将通过描述符25发送。
The following columns in the alias table created at the client warrant an explanation:
在客户机上创建的别名表中的以下列值得解释：
1. The IP address, port, and transport are a result of executing the RFC3263 server resolution process on a next-hop URI.
1. IP地址、端口和传输是在下一跳URI上执行RFC3263服务器解析过程的结果。
2. The entries in the fourth column consists of the identities of the server as asserted in the X.509 certificate presented by the server. These identities are cached by the client after the server has been duly authenticated (see Section 9.1).
2. 第四列中的条目由服务器提供的X.509证书中声明的服务器标识组成。这些身份在服务器经过正式身份验证后由客户端缓存（见第9.1节）。
3. The entry in the last column is the socket descriptor over which P1, acting as a client, actively opened a TLS connection. At some later time, when P1 gets a request from one of the user agents in its domain, it will reuse the aliased connection accessible through socket descriptor 25 if and only if all of the following conditions hold:
3. 最后一列中的条目是套接字描述符，P1作为客户机在其上主动打开TLS连接。稍后，当P1从其域中的一个用户代理收到请求时，它将重用通过套接字描述符25访问的别名连接，如果且仅当以下所有条件都成立：
A. P1 determines through the RFC3263 server resolution process that the {transport, IP-address, port} tuple of P2 to be {TLS, 192.0.2.128, 5061}, and
A.P1通过RFC3263服务器解析过程确定P2的{transport，IP address，port}元组为{TLS，192.0.2.128，5061}，以及
B. The URI used for the RFC3263 server resolution matches one of the identities stored in the cached certificate (fourth column).
B.用于RFC3263服务器解析的URI与缓存证书中存储的标识之一匹配（第四列）。
When P2 receives the request, it examines the topmost Via header field to determine whether P1 is willing to use this connection as an aliased connection (i.e., accept requests from P2 towards P1). The Via header field at P2 now looks like the following (the "received" header field parameter is added by P2):
当P2接收到请求时，它检查最顶端的Via报头字段，以确定P1是否愿意将此连接用作别名连接（即，接受P2向P1发出的请求）。P2处的Via标头字段现在看起来如下所示（“接收”标头字段参数由P2添加）：
Via: SIP/2.0/TLS p1.example.com;branch=z9hG4bKa7c8dze;alias;
received=192.0.2.1
Via: SIP/2.0/TLS p1.example.com;branch=z9hG4bKa7c8dze;alias;
received=192.0.2.1
The presence of the "alias" Via header field parameter indicates that P1 supports aliasing on this connection. P2 now authenticates the connection (see Section 9.2) and if the authentication was successful, P2 creates an alias to P1 using the advertised address in the topmost Via header field. P2's alias table looks like the following:
“alias”Via header字段参数的存在表明P1支持此连接上的别名。P2现在对连接进行身份验证（参见第9.2节），如果身份验证成功，P2将使用最顶端的Via标头字段中的播发地址为P1创建别名。P2的别名表如下所示：
Destination Destination Destination Destination Alias IP Address Port Transport Identity Descriptor ... 192.0.2.1 5061 TLS sip:example.com 18 sip:p1.example.com
目标别名IP地址端口传输标识描述符。。。192.0.2.1 5061 TLS sip:example.com 18 sip:p1.example.com
There are a few items of interest here:
这里有几个有趣的项目：
1. The IP address field is populated with the source address of the client.
1. IP地址字段由客户端的源地址填充。
2. The port field is populated from the advertised address (topmost Via header field), if a port is present in it, or 5061 if it is not.
2. 端口字段是从播发地址（最顶端通过标头字段）填充的（如果其中存在端口），或者从5061填充（如果不存在）。
3. The transport field is populated from the advertised address (topmost Via header field).
3. 传输字段由播发地址填充（最上面的通过标头字段）。
4. The entries in the fourth column consist of the identities of the client as asserted in the X.509 certificate presented by the client. These identities are cached by the server after the client has been duly authenticated (see Section 9.2).
4. 第四列中的条目由客户端提供的X.509证书中声明的客户端身份组成。这些身份在客户端经过正式身份验证后由服务器缓存（见第9.2节）。
5. The entry in the last column is the socket descriptor over which the connection was passively accepted. At some later time, when P2 gets a request from one of the user agents in its domain, it will reuse the aliased connection accessible through socket descriptor 18 if and only if all of the following conditions hold:
5. 最后一列中的条目是被动接受连接的套接字描述符。稍后，当P2从其域中的一个用户代理收到请求时，它将重用通过套接字描述符18访问的别名连接，前提是且仅当以下所有条件均成立：
A. P2 determines through RFC3263 server resolution process that the {transport, IP-address, port} tuple of P1 to be {TLS, 192.0.2.1, 5061}, and
A.P2通过RFC3263服务器解析过程确定P1的{transport，IP address，port}元组为{TLS，192.0.2.1，5061}，以及
B. The URI used for RFC3263 server resolution matches one of the identities stored in the cached certificate (fourth column).
B.用于RFC3263服务器解析的URI与缓存证书中存储的标识之一匹配（第四列）。
6. The network address inserted in the "Destination IP Address" column is the source address as seen by P2 (i.e., the "received" header field parameter). It could be the case that the host name of P1 resolves to different IP addresses due to round-robin DNS. However, the aliased connection is to be established with the original sender of the request.
6. “目的地IP地址”列中插入的网络地址是P2看到的源地址（即“接收到的”头字段参数）。可能是由于循环DNS，P1的主机名解析为不同的IP地址。但是，将与请求的原始发件人建立别名连接。
The following are the requirements that motivated this specification:
以下是激发本规范的要求：
1. A connection sharing mechanism should allow SIP entities to reuse existing connections for requests and responses originated from either peer in the connection.
1. 连接共享机制应允许SIP实体重用来自连接中任一对等方的请求和响应的现有连接。
2. A connection sharing mechanism must not require clients to send all traffic from well-know SIP ports.
2. 连接共享机制不能要求客户端从众所周知的SIP端口发送所有流量。
3. A connection sharing mechanism must not require configuring ephemeral port numbers in DNS.
3. 连接共享机制不得要求在DNS中配置临时端口号。
4. A connection sharing mechanism must prevent unauthorized hijacking of other connections.
4. 连接共享机制必须防止未经授权劫持其他连接。
5. Connection sharing should persist across SIP transactions and dialogs.
5. 连接共享应该在SIP事务和对话框之间保持。
6. Connection sharing must work across name-based virtual SIP servers.
6. 连接共享必须跨基于名称的虚拟SIP服务器工作。
7. There is no requirement to share a complete path for ordinary connection reuse. Hop-by-hop connection sharing is more appropriate.
7. 普通连接重用不需要共享完整的路径。逐跳连接共享更合适。
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 5234 [RFC5234]. This document extends the via-params to include a new via-alias defined below.
以下语法规范使用RFC 5234[RFC5234]中所述的增广巴科斯诺尔形式（BNF）。本文档扩展了via参数，包括下面定义的新via别名。
via-params =/ via-alias via-alias = "alias"
via params=/via alias via alias=“alias”
Clients SHOULD keep connections up as long as they are needed. Connection reuse works best when the client and the server maintain their connections for long periods of time. Clients, therefore, SHOULD NOT automatically drop connections on completion of a transaction or termination of a dialog.
只要需要，客户端就应该保持连接。当客户端和服务器长时间保持连接时，连接重用效果最佳。因此，客户端不应在事务完成或对话框终止时自动断开连接。
The mechanism for connection reuse uses a new Via header field parameter. The "alias" header field parameter is included in a Via header field value to indicate that the client wants to create a transport layer alias. The client places its advertised address in the Via header field value (in the sent-by production).
连接重用机制使用一个新的Via header字段参数。“alias”标头字段参数包含在Via标头字段值中，以指示客户端希望创建传输层别名。客户机将其播发地址放在Via标头字段值中（在“由生产部门发送”字段中）。
If the client places an "alias" header field parameter in the topmost Via header of the request, the client SHOULD keep the connection open for as long as the resources on the host operating system allow it to, and that the client MUST accept requests over this connection -- in addition to the default listening port -- from its downstream peer. And furthermore, the client SHOULD reuse the connection when subsequent requests in the same or different transactions are destined to the same resolved address.
如果客户端将“alias”header字段参数放置在请求的最顶层Via头中，则客户端应在主机操作系统上的资源允许的时间内保持连接打开，并且客户端必须通过此连接（除了默认侦听端口）接受来自其下游对等方的请求。此外，当相同或不同事务中的后续请求被发送到相同的解析地址时，客户端应该重用连接。
Note that RFC 3261 states that a response arrives over the same connection that was opened for a request.
注意，RFC3261声明响应通过为请求打开的相同连接到达。
Whether or not to allow an aliased connection ultimately depends on the recipient of the request; i.e., the client does not get any confirmation that its downstream peer created the alias, or indeed that it even supports this specification. Thus, clients MUST NOT assume that the acceptance of a request by a server automatically enables connection aliasing. Clients MUST continue receiving requests on their default port.
是否允许别名连接最终取决于请求的接收者；i、 例如，客户端没有得到任何关于其下游对等方创建别名的确认，或者实际上它甚至不支持此规范。因此，客户端不能假设服务器接受请求会自动启用连接别名。客户端必须在其默认端口上继续接收请求。
Clients MUST authenticate the connection before forming an alias; Section 9.1 discusses the authentication steps in more detail. Once the server has been authenticated, the client MUST cache, in the alias table, the identity (or identities) of the server as determined in Section 7.1 of RFC 5922 [RFC5922]. The client MUST also populate the destination IP address, port, and transport of the server in the alias table; these fields are retrieved from executing RFC3263 server resolution process on the next-hop URI. And finally, the client MUST populate the alias descriptor field with the connection handle (or identifier) used to connect to the server.
在形成别名之前，客户端必须对连接进行身份验证；第9.1节更详细地讨论了认证步骤。服务器通过身份验证后，客户端必须在别名表中缓存RFC 5922[RFC5922]第7.1节中确定的服务器标识。客户端还必须在别名表中填充服务器的目标IP地址、端口和传输；这些字段是通过在下一个跃点URI上执行RFC3263服务器解析过程获取的。最后，客户端必须使用用于连接到服务器的连接句柄（或标识符）填充别名描述符字段。
Once the alias table has been updated with a resolved address, and the client wants to send a new request in the direction of the server, the client reuses the connection only if all of the following conditions hold:
使用解析的地址更新别名表后，客户端希望向服务器发送新请求，只有在满足以下所有条件时，客户端才会重新使用连接：
1. The client uses the RFC3263 resolution on a URI and arrives at a resolved address contained in the alias table, and
1. 客户端对URI使用RFC3263解析，并到达别名表中包含的解析地址，以及
2. The URI used for RFC3263 server resolution matches one of the identities stored in the alias table row corresponding to that resolved address.
2. 用于RFC3263服务器解析的URI与存储在别名表行中与该解析地址对应的标识之一匹配。
Clients MUST be prepared for the case that the connection no longer exists when they are ready to send a subsequent request over it. In such a case, a new connection MUST be opened to the resolved address and the alias table updated accordingly.
当客户机准备通过连接发送后续请求时，必须为连接不再存在的情况做好准备。在这种情况下，必须打开到解析地址的新连接，并相应地更新别名表。
This behavior has an adverse side effect when a CANCEL request or an ACK request for a non-2xx response is sent downstream. Normally, these would be sent over the same connection over which the INVITE request was sent. However, if between the sending of the INVITE request and subsequent sending of the CANCEL request or ACK request to a non-2xx response, the connection was closed, then the client SHOULD open a new connection to the resolved address and send the CANCEL request or ACK request there instead. The client MAY insert the newly opened connection into the alias table.
当向下游发送取消请求或非2xx响应的ACK请求时，此行为具有不利的副作用。通常，这些将通过发送INVITE请求的相同连接发送。但是，如果在发送INVITE请求和随后向非2xx响应发送CANCEL请求或ACK请求之间，连接已关闭，则客户端应打开到已解析地址的新连接，并改为向该地址发送CANCEL请求或ACK请求。客户端可以将新打开的连接插入别名表。
Servers SHOULD keep connections up unless they need to reclaim resources. Connection reuse works best when the client and the server maintain their connections for long periods of time. Servers, therefore, SHOULD NOT automatically drop connections on completion of a transaction or termination of a dialog.
服务器应该保持连接，除非它们需要回收资源。当客户端和服务器长时间保持连接时，连接重用效果最佳。因此，服务器不应在事务完成或对话框终止时自动断开连接。
When a server receives a request over TLS whose topmost Via header field contains an "alias" header field parameter, it signifies that the upstream client will leave the connection open beyond the transaction and dialog lifetime, and that subsequent transactions and dialogs that are destined to a resolved address that matches the identifiers in the advertised address in the topmost Via header field can reuse this connection.
当服务器通过TLS接收到请求时，其最顶端的Via标头字段包含“alias”标头字段参数，这表示上游客户端将在事务和对话框生存期之后保持连接打开，并且，如果后续事务和对话框的目的地为解析地址，且该解析地址与最顶端的Via标头字段中的播发地址中的标识符相匹配，则可以重用该连接。
Whether or not to use in the reverse direction a connection marked with the "alias" Via header field parameter ultimately depends on the policies of the server. It can choose to honor it, and thereby send subsequent requests over the aliased connection. If the server chooses not to honor an aliased connection, the server MUST allow the request to proceed as though the "alias" header field parameter was not present in the topmost Via header.
是否反向使用通过标头字段参数标记为“别名”的连接最终取决于服务器的策略。它可以选择接受它，从而通过别名连接发送后续请求。如果服务器选择不接受别名连接，则服务器必须允许请求继续，就像最顶端的Via标头中不存在“alias”标头字段参数一样。
This assures interoperability with RFC3261 server behavior. Clients can include the "alias" header field parameter without fear that the server will reject the SIP request because of its presence.
这确保了与RFC3261服务器行为的互操作性。客户端可以包含“alias”头字段参数，而不用担心服务器会因为SIP请求的存在而拒绝该请求。
Servers MUST be prepared to deal with the case that the aliased connection no longer exist when they are ready to send a subsequent request over it. This can happen if the peer ran out of operating system resources and had to close the connection. In such a case, the server MUST open a new connection to the resolved address and the alias table updated accordingly.
当服务器准备通过别名连接发送后续请求时，必须准备好处理别名连接不再存在的情况。如果对等方耗尽了操作系统资源，必须关闭连接，则可能发生这种情况。在这种情况下，服务器必须打开到解析地址的新连接，并相应地更新别名表。
If the sent-by production of the Via header field contains a port, the server MUST use it as a destination port. Otherwise, the default port is the destination port.
如果生产部门发送的Via标头字段包含端口，则服务器必须将其用作目标端口。否则，默认端口为目标端口。
Servers MUST follow the authentication steps outlined in Section 9.2 to authenticate the connection before forming an alias.
在形成别名之前，服务器必须遵循第9.2节中概述的身份验证步骤对连接进行身份验证。
The server, if it decides to reuse the connection, MUST cache in the alias table the identity (or identities) of the client as they appear in the X.509 certificate subjectAlternativeName extension field. The server also populates the destination IP address, port, and transport in the alias table from the topmost Via header field (using the
如果服务器决定重用连接，则必须在别名表中缓存出现在X.509 certificate subjectAlternativeName extension字段中的客户端标识。服务器还从最顶端的Via标头字段（使用
";received" parameter for the destination IP address). If the port number is omitted, a default port number of 5061 is to be used. And finally, the server populates the alias descriptor field with the connection handle (or identifier) used to accept the connection from the client (see Section 5 for the contents of the alias table).
目标IP地址的“received”参数）。如果省略端口号，将使用默认端口号5061。最后，服务器使用连接句柄（或标识符）填充alias descriptor字段，该连接句柄用于接受来自客户端的连接（有关alias表的内容，请参见第5节）。
Once the alias table has been updated, and the server wants to send a request in the direction of the client, it reuses the connection only if all of the following conditions hold:
更新别名表后，服务器希望向客户端发送请求，只有在满足以下所有条件时，才会重新使用连接：
1. The server, which acts as a client for this transaction, uses the RFC3263 resolution process on a URI and arrives at a resolved address contained in the alias table, and
1. 充当此事务客户端的服务器对URI使用RFC3263解析过程，并到达别名表中包含的解析地址，以及
2. The URI used for RFC3263 server resolution matches one of the identities stored in the alias table row corresponding to that resolved address.
2. 用于RFC3263服务器解析的URI与存储在别名表行中与该解析地址对应的标识之一匹配。
Either the client or the server may terminate a TLS session by sending a TLS closure alert. Before closing a TLS connection, the initiator of the closure MUST either wait for any outstanding SIP transactions to complete, or explicitly abandon them.
客户端或服务器都可以通过发送TLS关闭警报来终止TLS会话。在关闭TLS连接之前，关闭的发起人必须等待任何未完成的SIP事务完成，或者明确放弃它们。
After the initiator of the close has sent a closure alert, it MUST discard any TLS messages until it has received a similar alert from its peer. The receiver of the closure alert MUST NOT start any new SIP transactions after the receipt of the closure alert.
关闭的发起方发送关闭警报后，必须丢弃任何TLS消息，直到从其对等方收到类似警报为止。在收到关闭警报后，关闭警报的接收者不得启动任何新的SIP事务。
This document presents requirements and a mechanism for reusing existing connections easily. Unauthenticated connection reuse would present many opportunities for rampant abuse and hijacking. Authenticating connection aliases is essential to prevent connection hijacking. For example, a program run by a malicious user of a multiuser system could attempt to hijack SIP requests destined for the well-known SIP port from a large relay proxy.
本文档介绍了轻松重用现有连接的需求和机制。未经验证的连接重用将为猖獗的滥用和劫持提供许多机会。验证连接别名对于防止连接劫持至关重要。例如，多用户系统的恶意用户运行的程序可能会试图从大型中继代理劫持发送到知名SIP端口的SIP请求。
When a TLS client establishes a connection with a server, it is presented with the server's X.509 certificate. Authentication proceeds as described in Section 7.3 ("Client behavior") of RFC 5922 [RFC5922].
当TLS客户端与服务器建立连接时，它将显示服务器的X.509证书。按照RFC 5922[RFC5922]第7.3节（“客户行为”）的规定进行认证。
A TLS server conformant to this specification MUST ask for a client certificate; if the client possesses a certificate, it will be presented to the server for mutual authentication, and authentication proceeds as described in Section 7.4 ("Server behavior") of RFC 5922 [RFC5922].
符合本规范的TLS服务器必须要求客户端证书；如果客户机拥有一个证书，它将被提交给服务器进行相互身份验证，身份验证将按照RFC 5922[RFC5922]第7.4节（“服务器行为”）中的描述进行。
If the client does not present a certificate, the server MUST proceed as if the "alias" header field parameter was not present in the topmost Via header. In this case, the server MUST NOT update the alias table.
如果客户端不提供证书，则服务器必须继续运行，就像最顶端的Via标头中不存在“alias”标头字段参数一样。在这种情况下，服务器不得更新别名表。
Virtual servers present special considerations for connection reuse. Under the name-based virtual server scheme, one SIP proxy can host many virtual domains using one IP address and port number. If adequate defenses are not put in place, a connection opened to a downstream server on behalf of one domain can be reused to send requests in the backwards direction to a different domain. The "Destination Identity" column in the alias table has been added to aid in such defenses.
虚拟服务器为连接重用提供了特殊的考虑因素。在基于名称的虚拟服务器方案下，一个SIP代理可以使用一个IP地址和端口号承载多个虚拟域。如果没有足够的防御措施，代表一个域向下游服务器打开的连接可以重新使用，以便向后向另一个域发送请求。alias表中的“Destination Identity”列已添加，以帮助进行此类防御。
Virtual servers MUST only perform connection reuse for TLS connections; virtual servers MUST NOT perform connection reuse for other connection-oriented transports. To understand why this is the case, note that the alias table caches not only which connections go to which destination addresses, but also which connections have authenticated themselves as responsible for which domains. If a message is to be sent in the backwards direction to a new SIP domain that resolves to an address with a cached connection, the cached connection cannot be used because it is not authenticated for the new domain.
虚拟服务器只能对TLS连接执行连接重用；虚拟服务器不得对其他面向连接的传输执行连接重用。要理解为什么会出现这种情况，请注意别名表不仅缓存哪些连接指向哪个目标地址，而且缓存哪些连接已将自己验证为负责哪个域的连接。如果要将消息向后发送到解析为具有缓存连接的地址的新SIP域，则无法使用缓存连接，因为它未针对新域进行身份验证。
As an example, consider a proxy P1 that hosts two virtual domains -- example.com and example.net -- on the same IP address and port. RFC3263 server resolution is set up such that a DNS lookup of example.com and example.net both resolve to an {IP-address, port, transport} tuple of {192.0.2.1, 5061, TLS}. A user agent in the example.com domain sends a request to P1 causing it to make a downstream connection to its peering proxy, P2, and authenticating itself as a proxy in the example.com domain by sending it a X.509 certificate asserting such an identity. P2's alias table now looks like the following:
作为一个例子，考虑一个代理P1，它在同一IP地址和端口上承载两个虚拟域--ExpLy.com和Expul.NET。RFC3263服务器解析设置为example.com和example.net的DNS查找都解析为{192.0.2.15061，TLS}的{IP地址、端口、传输}元组。example.com域中的用户代理向P1发送一个请求，使其与对等代理P2建立下游连接，并通过向P1发送一个X.509证书来验证其自身作为example.com域中的代理的身份。P2的别名表现在如下所示：
Destination Destination Destination Destination Alias IP Address Port Transport Identity Descriptor ... 192.0.2.1 5061 TLS sip:example.com 18
目标别名IP地址端口传输标识描述符。。。192.0.2.1 5061 TLS sip:example.com 18
At some later point in time, a user agent in P2's domain wants to send a request to a user agent in the example.net domain. P2 performs an RFC3263 server resolution process on sips:example.net to derive a resolved address tuple {192.0.2.1, 5061, TLS}. It appears that a connection to this network address is already cached in the alias table; however, P2 cannot reuse this connection because the destination identity (sip:example.com) does not match the server identity used for RFC3261 resolution (sips:example.net). Hence, P2 will open up a new connection to the example.net virtual domain hosted on P1. P2's alias table will now look like:
在稍后的某个时间点，P2域中的用户代理希望向example.net域中的用户代理发送请求。P2在sips:example.net上执行RFC3263服务器解析过程，以派生解析的地址元组{192.0.2.15061，TLS}。与该网络地址的连接似乎已缓存在别名表中；但是，P2无法重用此连接，因为目标标识（sip:example.com）与用于RFC3261解析（sips:example.net）的服务器标识不匹配。因此，P2将打开到P1上托管的示例.net虚拟域的新连接。P2的别名表现在如下所示：
Destination Destination Destination Destination Alias IP Address Port Transport Identity Descriptor ... 192.0.2.1 5061 TLS sip:example.com 18 192.0.2.1 5061 TLS sip:example.net 54
目标别名IP地址端口传输标识描述符。。。192.0.2.1 5061 TLS sip:example.com 18 192.0.2.1 5061 TLS sip:example.net 54
The identities conveyed in an X.509 certificate are associated with a specific TLS connection. Absent such a guarantee of an identity tied to a specific connection, a normal TCP or SCTP connection cannot be used to send requests in the backwards direction without a significant risk of inadvertent (or otherwise) connection hijacking.
X.509证书中传递的身份与特定TLS连接相关联。如果不保证与特定连接相关的身份，则不能使用正常的TCP或SCTP连接向后发送请求，而不会产生意外（或其他）连接劫持的重大风险。
The above discussion details the impact on P2 when connection reuse is desired for virtual servers. There is a subtle, but important impact on P1 as well.
上面的讨论详细说明了虚拟服务器需要连接重用时对P2的影响。对P1也有微妙但重要的影响。
P1 should keep separate alias tables for the requests served from the UAs in the example.com domain from those served by the UAs in the example.net domain. This is so that the boundary between the two domains is preserved; P1 MUST NOT open a connection on behalf of one domain and reuse it to send a new request on behalf of another domain.
P1应为example.com域中UAs提供的请求与example.net域中UAs提供的请求保留单独的别名表。这是为了保持两个域之间的边界；P1不得代表一个域打开连接并重用它以代表另一个域发送新请求。
Connection reuse has an interaction with the DNS SRV load balancing mechanism. To understand the interaction, consider the following figure:
连接重用与DNS SRV负载平衡机制有交互作用。为了理解相互作用，请考虑下面的图形：
/+---- S1
+-------+/
| Proxy |------- S2
+-------+\
\+---- S3
/+---- S1
+-------+/
| Proxy |------- S2
+-------+\
\+---- S3
Figure 5: Load balancing
图5：负载平衡
Here, the proxy uses the DNS SRV to load balance across the three servers, S1, S2, and S3. Using the connect reuse mechanism specified in this document, over time the proxy will maintain a distinct aliased connection to each of the servers. However, once this is done, subsequent traffic is load balanced across the three downstream servers in the normal manner.
这里，代理使用DNS SRV在三台服务器S1、S2和S3之间进行负载平衡。使用本文档中指定的连接重用机制，随着时间的推移，代理将保持到每个服务器的不同别名连接。但是，一旦完成此操作，后续流量将以正常方式在三个下游服务器之间进行负载平衡。
This specification defines a new Via header field parameter called "alias" in the "Header Field Parameters and Parameter Values" sub-registry as per the registry created by RFC 3968 [RFC3968]. The required information is:
本规范根据RFC 3968[RFC3968]创建的注册表，在“header field Parameters and parameter Values”子注册表中定义了一个名为“alias”的新的Via header field参数。所需资料如下：
Header Field Parameter Name Predefined Values Reference
___________________________________________________________________
Via alias No RFC5923
Header Field Parameter Name Predefined Values Reference
___________________________________________________________________
Via alias No RFC5923
Thanks to Jon Peterson for helpful answers about certificate behavior with SIP, Jonathan Rosenberg for his initial support of this concept, and Cullen Jennings for providing a sounding board for this idea. Other members of the SIP WG that contributed to this document include Jeroen van Bemmel, Keith Drage, Matthew Gardiner, Rajnish Jain, Benny Prijono, and Rocky Wang.
感谢Jon Peterson对SIP证书行为的帮助回答，感谢Jonathan Rosenberg对这个概念的初步支持，感谢Cullen Jennings为这个想法提供了一个共鸣板。SIP工作组的其他成员包括Jeroen van Bemmel、Keith Drage、Matthew Gardiner、Rajnish Jain、Benny Prijono和Rocky Wang。
Dale Worley and Hadriel Kaplan graciously performed a WGLC review of the document. The resulting revision has benefited tremendously from their feedback.
戴尔·沃利（Dale Worley）和哈德里尔·卡普兰（Hadriel Kaplan）亲切地对该文件进行了工作组审查。由此产生的修订从他们的反馈中受益匪浅。
[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月。
[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月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC 3263，2002年6月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 5234，2008年1月。
[RFC5922] Gurbani, V., Lawrence, S., and B. Laboratories, "Domain Certificates in the Session Initiation Protocol (SIP)", RFC 5922, June 2010.
[RFC5922]Gurbani，V.，Lawrence，S.，and B.Laboratories，“会话启动协议（SIP）中的域证书”，RFC 59222010年6月。
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[RFC3968]Camarillo，G.“会话启动协议（SIP）的Internet分配号码管理机构（IANA）头字段参数注册表”，BCP 98，RFC 3968，2004年12月。
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626]Jennings，C.，Mahy，R.，和F.Audet，“在会话启动协议（SIP）中管理客户端启动的连接”，RFC 5626，2009年10月。
[Book-Rescorla-TLS] Rescorla, E., "SSL and TLS: Designing and Building Secure Systems", Addison-Wesley Publishing, 2001.
[Book Rescorla TLS]Rescorla，E.，“SSL和TLS：设计和构建安全系统”，Addison-Wesley出版社，2001年。
[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月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
Authors' Addresses
作者地址
Vijay K. Gurbani (editor) Bell Laboratories, Alcatel-Lucent
阿尔卡特朗讯贝尔实验室Vijay K.Gurbani（编辑）
EMail: vkg@alcatel-lucent.com
EMail: vkg@alcatel-lucent.com
Rohan Mahy Unaffiliated
Rohan Mahy非附属公司
EMail: rohan@ekabal.com
EMail: rohan@ekabal.com
Brett Tate BroadSoft
布雷特·泰特·布罗德索夫
EMail: brett@broadsoft.com
EMail: brett@broadsoft.com