Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 6223 Ericsson
Category: Standards Track April 2011
ISSN: 2070-1721
Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 6223 Ericsson
Category: Standards Track April 2011
ISSN: 2070-1721
Indication of Support for Keep-Alive
支持“保持活力”的指示
Abstract
摘要
This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, "keep", which allows adjacent SIP entities to explicitly negotiate usage of the Network Address Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in cases where SIP Outbound is not supported, cannot be applied, or where usage of keep-alives is not implicitly negotiated as part of the SIP Outbound negotiation.
本规范通过标头字段参数“keep”定义了一个新的会话发起协议（SIP），该参数允许相邻SIP实体在不支持SIP出站的情况下，明确协商SIP出站中定义的网络地址转换（NAT）保持活动机制的使用，或者在SIP出站协商中未隐式协商keep alives的使用。
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/rfc6223.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6223.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Use-Case: Dialog from Non-Registered UAs ...................3
1.2. Use-Case: SIP Outbound Not Supported .......................3
1.3. Use-Case: SIP Dialog Initiated Outbound Flows ..............3
2. Conventions .....................................................3
3. Definitions .....................................................4
4. User Agent and Proxy Behavior ...................................4
4.1. General ....................................................4
4.2. Lifetime of Keep-Alives ....................................5
4.2.1. General .............................................5
4.2.2. Keep-Alives Associated with Registration ............5
4.2.3. Keep-Alives Associated with Dialog ..................6
4.3. Behavior of a SIP Entity Willing to Send Keep-Alives .......6
4.4. Behavior of a SIP Entity Willing to Receive Keep-Alives ....7
5. Keep-Alive Frequency ............................................8
6. Connection Reuse ................................................9
7. Examples ........................................................9
7.1. General ....................................................9
7.2. Keep-Alive Negotiation Associated with
Registration: UA-Proxy .....................................9
7.3. Keep-Alive Negotiation Associated with Dialog: UA-Proxy ...11
7.4. Keep-Alive Negotiation Associated with Dialog: UA-UA ......13
8. Grammar ........................................................15
8.1. General ...................................................15
8.2. ABNF ......................................................15
9. IANA Considerations ............................................15
9.1. "keep" Via Header Field Parameter .........................15
10. Security Considerations .......................................15
11. Acknowledgements ..............................................16
12. References ....................................................17
12.1. Normative References .....................................17
12.2. Informative References ...................................17
1. Introduction ....................................................2
1.1. Use-Case: Dialog from Non-Registered UAs ...................3
1.2. Use-Case: SIP Outbound Not Supported .......................3
1.3. Use-Case: SIP Dialog Initiated Outbound Flows ..............3
2. Conventions .....................................................3
3. Definitions .....................................................4
4. User Agent and Proxy Behavior ...................................4
4.1. General ....................................................4
4.2. Lifetime of Keep-Alives ....................................5
4.2.1. General .............................................5
4.2.2. Keep-Alives Associated with Registration ............5
4.2.3. Keep-Alives Associated with Dialog ..................6
4.3. Behavior of a SIP Entity Willing to Send Keep-Alives .......6
4.4. Behavior of a SIP Entity Willing to Receive Keep-Alives ....7
5. Keep-Alive Frequency ............................................8
6. Connection Reuse ................................................9
7. Examples ........................................................9
7.1. General ....................................................9
7.2. Keep-Alive Negotiation Associated with
Registration: UA-Proxy .....................................9
7.3. Keep-Alive Negotiation Associated with Dialog: UA-Proxy ...11
7.4. Keep-Alive Negotiation Associated with Dialog: UA-UA ......13
8. Grammar ........................................................15
8.1. General ...................................................15
8.2. ABNF ......................................................15
9. IANA Considerations ............................................15
9.1. "keep" Via Header Field Parameter .........................15
10. Security Considerations .......................................15
11. Acknowledgements ..............................................16
12. References ....................................................17
12.1. Normative References .....................................17
12.2. Informative References ...................................17
Section 3.5 of SIP Outbound [RFC5626] defines two keep-alive mechanisms. Even though the keep-alive mechanisms are separated from the rest of the SIP Outbound mechanism, SIP Outbound does not define a mechanism to explicitly negotiate usage of the keep-alive mechanisms. In some cases, usage of keep-alives can be implicitly negotiated as part of the SIP Outbound negotiation.
SIP出站[RFC5626]第3.5节定义了两种保持活动的机制。即使keep-alive机制与SIP出站机制的其余部分分离，SIP出站也没有定义一种机制来明确协商keep-alive机制的使用。在某些情况下，保持有效性的使用可以作为SIP出站协商的一部分进行隐式协商。
However, there are SIP Outbound use-cases where usage of keep-alives is not implicitly negotiated as part of the SIP Outbound negotiation. In addition, there are cases where SIP Outbound is not supported, or where it cannot be applied, but where there is still a need to be
然而，也有一些SIP出站用例，其中keep alives的使用不是作为SIP出站协商的一部分隐式协商的。此外，还存在不支持SIP出站，或无法应用SIP出站，但仍需要应用的情况
able to negotiate usage of keep-alives. Last, SIP Outbound only allows keep-alives to be negotiated between a User Agent (UA) and an edge proxy, and not between other SIP entities.
能够协商保持生命的使用。最后，SIP Outbound只允许在用户代理（UA）和边缘代理之间协商keep alives，而不允许在其他SIP实体之间协商keep alives。
This specification defines a new Session Initiation Protocol (SIP) [RFC3261] Via header field parameter, "keep", which allows adjacent SIP entities to explicitly negotiate usage of the NAT keep-alive mechanisms defined in SIP Outbound. The "keep" parameter allows SIP entities to indicate willingness to send keep-alives, to indicate willingness to receive keep-alives, and -- for SIP entities willing to receive keep-alives -- to provide a recommended keep-alive frequency.
该规范通过标头字段参数“keep”定义了一个新的会话发起协议（SIP）[RFC3261]，该参数允许相邻SIP实体明确协商SIP出站中定义的NAT保持活动机制的使用。“keep”参数允许SIP实体表示愿意发送keep-alive，表示愿意接收keep-alive，并且——对于愿意接收keep-alive的SIP实体——提供建议的keep-alive频率。
The following sections describe use-cases where a mechanism to explicitly negotiate usage of keep-alives is needed.
以下各节描述了需要明确协商使用keep-alives的机制的用例。
In some cases, a User Agent Client (UAC) does not register itself before it establishes a dialog, but in order to maintain NAT bindings open during the lifetime of the dialog, it still needs to be able to negotiate the sending of keep-alives towards its adjacent downstream SIP entity. A typical example is an emergency call, where a registration is not always required in order to make the call.
在某些情况下，用户代理客户端（UAC）在建立对话框之前不会注册自身，但为了在对话框的生命周期内保持NAT绑定打开，它仍然需要能够协商向其相邻的下游SIP实体发送keep alives。一个典型的例子是紧急呼叫，拨打该呼叫并不总是需要注册。
In some cases, some SIP entities that need to be able to negotiate the use of keep-alives might not support SIP Outbound. However, they might still support the keep-alive mechanisms defined in SIP Outbound and need to be able to negotiate usage of them.
在某些情况下，一些需要能够协商使用keep alives的SIP实体可能不支持SIP Outbound。但是，它们可能仍然支持SIP Outbound中定义的keep-alive机制，并且需要能够协商使用它们。
SIP Outbound allows the establishment of flows using the initial request for a dialog. As specified in RFC 5626 [RFC5626], usage of keep-alives is not implicitly negotiated for such flows.
SIP Outbound允许使用对话框的初始请求建立流。如RFC 5626[RFC5626]中所述，对于此类流，保持有效性的使用不是隐式协商的。
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 BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
Edge proxy: As defined in RFC 5626, a SIP proxy that is located topologically between the registering User Agent (UA) and the Authoritative Proxy.
边缘代理：如RFC 5626中所定义，一种SIP代理，在拓扑上位于注册用户代理（UA）和权威代理之间。
NOTE: In some deployments, the edge proxy might be physically located in the same SIP entity as the Authoritative Proxy.
注意：在某些部署中，边缘代理可能在物理上与权威代理位于同一个SIP实体中。
Keep-alives: The keep-alive messages defined in RFC 5626.
Keep alives：RFC 5626中定义的Keep alive消息。
"keep" parameter: A SIP Via header field parameter that a SIP entity can insert in the topmost Via header field that it adds to the request, to explicitly indicate willingness to send keep-alives towards its adjacent downstream SIP entity. A SIP entity can add a parameter value to the "keep" parameter in a response to explicitly indicate willingness to receive keep-alives from its adjacent upstream SIP entity.
“keep”参数：SIP实体可以在其添加到请求的最顶端的Via头字段中插入的SIP Via头字段参数，以明确表示是否愿意向其相邻的下游SIP实体发送keep alives。SIP实体可以在响应中向“keep”参数添加参数值，以明确表示愿意从其相邻的上游SIP实体接收keep alive。
SIP entity: SIP User Agent (UA), or proxy, as defined in RFC 3261.
SIP实体：SIP用户代理（UA）或代理，如RFC 3261中所定义。
Adjacent downstream SIP entity: The adjacent SIP entity in the direction towards which a SIP request is sent.
相邻下游SIP实体：SIP请求发送方向上的相邻SIP实体。
Adjacent upstream SIP entity: The adjacent SIP entity in the direction from which a SIP request is received.
相邻上游SIP实体：接收SIP请求的方向上的相邻SIP实体。
This section describes how SIP UAs and proxies negotiate usage of keep-alives associated with a registration or a dialog, which types of SIP requests can be used in order to negotiate the usage, and the lifetime of the negotiated keep-alives.
本节描述SIP UAs和代理如何协商与注册或对话相关联的保留有效期的使用，可以使用哪些类型的SIP请求来协商使用，以及协商的保留有效期。
SIP entities indicate willingness to send keep-alives towards the adjacent downstream SIP entity using SIP requests. The associated responses are used by SIP entities to indicate willingness to receive keep-alives. SIP entities that indicate willingness to receive keep-alives can provide a recommended keep-alive frequency.
SIP实体表示愿意使用SIP请求向相邻的下游SIP实体发送keep alive。SIP实体使用相关的响应来表示是否愿意接收保留生命。表示愿意接收保持有效的SIP实体可以提供建议的保持有效的频率。
The procedures to negotiate usage of keep-alives are identical for SIP UAs and proxies.
SIP UAs和代理的协商保持有效性的程序是相同的。
In general, it can be useful for SIP entities to indicate willingness to send keep-alives, even if they are not aware of any necessity for them to send keep-alives, since the adjacent downstream SIP entity
通常，SIP实体表示愿意发送保持有效信息是有用的，即使他们不知道发送保持有效信息的任何必要性，因为相邻的下游SIP实体
might have knowledge about the necessity. Similarly, if the adjacent upstream SIP entity has indicated willingness to send keep-alives, it can be useful for SIP entities to indicate willingness to receive keep-alives, even if they are not aware of any necessity for the adjacent upstream SIP entity to send them.
可能知道这一必要性。类似地，如果相邻上游SIP实体已经表示愿意发送保持有效期，则SIP实体可以表示愿意接收保持有效期，即使它们不知道相邻上游SIP实体发送保持有效期的任何必要性。
NOTE: Usage of keep-alives is negotiated per direction. If a SIP entity has indicated willingness to receive keep-alives from an adjacent SIP entity, the sending of keep-alives towards that adjacent SIP entity needs to be separately negotiated.
注：保持生命的使用按方向协商。如果SIP实体已表示愿意从相邻SIP实体接收keep alives，则需要单独协商向该相邻SIP实体发送keep alives。
NOTE: Since there are SIP entities that already use a combination of Carriage Return and Line Feed (CRLF) as keep-alive messages, and SIP entities are expected to be able to receive those, this specification does not forbid the sending of double-CRLF keep-alive messages towards an adjacent SIP entity even if usage of keep-alives with that SIP entity has not been negotiated. However, the "keep" parameter is still important in order for a SIP entity to indicate that it supports the sending of double-CRLF keep-alive messages, so that the adjacent downstream SIP entity does not use other mechanisms (e.g., short registration refresh intervals) in order to keep NAT bindings open.
注意：由于有SIP实体已经将回车和换行（CRLF）组合用作保持活动消息，并且SIP实体预计能够接收这些消息，本规范不禁止向相邻SIP实体发送双CRLF保持活动消息，即使未与该SIP实体协商使用保持活动。然而，“keep”参数仍然很重要，以便SIP实体指示其支持发送双CRLF保持活动消息，以便相邻下游SIP实体不使用其他机制（例如，较短的注册刷新间隔）来保持NAT绑定打开。
The lifetime of negotiated keep-alives depends on whether the keep-alives are associated with a registration or a dialog. This section describes the lifetime of negotiated keep-alives.
协商保留有效期取决于保留有效期是与注册关联还是与对话关联。本节描述协商保存的生命周期。
SIP entities use a registration request in order to negotiate usage of keep-alives associated with a registration. Usage of keep-alives can be negotiated when the registration is established, or later during the registration. Once negotiated, keep-alives are sent until the registration is terminated, or until a subsequent registration refresh request is sent or forwarded. When a subsequent registration refresh request is sent or forwarded, if a SIP entity is willing to continue sending keep-alives associated with the registration, usage of keep-alives MUST be re-negotiated. If usage is not successfully re-negotiated, the SIP entity MUST cease the sending of keep-alives associated with the registration.
SIP实体使用注册请求来协商与注册相关联的保持有效性的使用。保留有效期的使用可以在注册成立时协商，也可以在注册后期协商。协商后，将发送保留有效信息，直到注册终止，或直到发送或转发后续注册刷新请求。当发送或转发后续注册刷新请求时，如果SIP实体愿意继续发送与注册相关联的keep alives，则必须重新协商keep alives的使用。如果使用未成功重新协商，SIP实体必须停止发送与注册相关的保留有效信息。
NOTE: The sending of keep-alives associated with a registration can only be negotiated in the direction from the registering SIP entity towards the registrar.
注意：与注册相关的保留有效性的发送只能按照注册SIP实体向注册商的方向进行协商。
SIP entities use an initial request for a dialog, or a mid-dialog target refresh request [RFC3261], in order to negotiate the sending and receiving of keep-alives associated with a dialog. Usage of keep-alives can be negotiated when the dialog is established, or later during the lifetime of the dialog. Once negotiated, keep-alives MUST be sent for the lifetime of the dialog, until the dialog is terminated. Once the usage of keep-alives associated with a dialog has been negotiated, it is not possible to re-negotiate the usage associated with the dialog.
SIP实体使用对话的初始请求或中间对话目标刷新请求[RFC3261]，以便协商与对话相关联的保持有效性的发送和接收。可以在建立对话框时协商使用keep alives，也可以在对话框生命周期内的稍后时间协商使用keep alives。协商完成后，必须在对话框的生命周期内发送keep alives，直到对话框终止。一旦协商了与对话框关联的keep alives的用法，就不可能重新协商与对话框关联的用法。
As defined in RFC 5626, a SIP entity that supports the sending of keep-alives must act as a Session Traversal Utilities for NAT (STUN) client [RFC5389]. The SIP entity must support those aspects of STUN that are required in order to apply the STUN keep-alive mechanism defined in RFC 5626, and it must support the CRLF keep-alive mechanism defined in RFC 5626. RFC 5626 defines when to use STUN and when to use double-CRLF for keep-alives.
如RFC 5626中所定义，支持发送保留有效信息的SIP实体必须充当NAT（STUN）客户端的会话遍历实用程序[RFC5389]。SIP实体必须支持应用RFC 5626中定义的STUN保持活动机制所需的STUN方面，并且必须支持RFC 5626中定义的CRLF保持活动机制。RFC 5626定义了何时使用眩晕以及何时使用双CRLF来保持生命。
When a SIP entity sends or forwards a request, if it wants to negotiate the sending of keep-alives associated with a registration or a dialog, it MUST insert a "keep" parameter in the topmost Via header field that it adds to the request, to indicate willingness to send keep-alives.
当SIP实体发送或转发请求时，如果它想要协商发送与注册或对话框相关的保留有效期，它必须在添加到请求的最顶端的Via头字段中插入“keep”参数，以表明发送保留有效期的意愿。
When the SIP entity receives the associated response, if the "keep" parameter in the topmost Via header field of the response contains a "keep" parameter value, it MUST start sending keep-alives towards the same destination where it would send a subsequent request (e.g., REGISTER requests and initial requests for dialog) associated with the registration (if the keep-alive negotiation is for a registration), or where it would send subsequent mid-dialog requests (if the keep-alive negotiation is for a dialog). Subsequent mid-dialog requests are addressed based on the dialog route set.
当SIP实体接收到相关响应时，如果响应最顶端的Via标头字段中的“keep”参数包含“keep”参数值，则它必须开始向相同的目的地发送keep alives，并在该目的地发送后续请求（例如，注册请求和对话框的初始请求）与注册关联（如果保持活动协商用于注册），或者它将发送后续mid对话请求的位置（如果保持活动协商用于对话）。后续的mid对话请求将根据对话路由集进行处理。
Once a SIP entity has negotiated the sending of keep-alives associated with a dialog towards an adjacent SIP entity, it MUST NOT insert a "keep" parameter in any subsequent SIP requests associated with that dialog towards that adjacent SIP entity. Such "keep" parameters MUST be ignored, if received.
一旦SIP实体协商向相邻SIP实体发送与对话相关联的keep alives，则不得在与该对话相关联的任何后续SIP请求中向该相邻SIP实体插入“keep”参数。如果收到此类“保留”参数，则必须忽略。
Since an ACK request does not have an associated response, it cannot be used to negotiate usage of keep-alives. Therefore, a SIP entity MUST NOT insert a "keep" parameter in the topmost Via header field of an ACK request. Such "keep" parameters MUST be ignored, if received.
由于ACK请求没有关联的响应，因此不能使用它来协商keep alives的使用。因此，SIP实体不得在ACK请求的最顶端Via头字段中插入“keep”参数。如果收到此类“保留”参数，则必须忽略。
A SIP entity MUST NOT indicate willingness to send keep-alives associated with a dialog, unless it has also inserted itself in the dialog route set [RFC3261].
SIP实体不得表示愿意发送与对话相关联的保留有效信息，除非它也已将自身插入对话路由集[RFC3261]。
NOTE: When a SIP entity sends an initial request for a dialog, if the adjacent downstream SIP entity does not insert itself in the dialog route set using a Record-Route header field [RFC3261], the adjacent downstream SIP entity will change once the dialog route set has been established. If a SIP entity inserts a "keep" parameter in the topmost Via header field of an initial request for a dialog, and the "keep" parameter in the associated response does not contain a parameter value, the SIP entity might choose to insert a "keep" parameter in the topmost Via header field of a subsequent SIP request associated with the dialog, in case the new adjacent downstream SIP entity (based on the dialog route set) is willing to receive keep-alives (in which case it will add a parameter value to the "keep" parameter).
注：当SIP实体发送对话初始请求时，如果相邻下游SIP实体未使用记录路由头字段[RFC3261]将自身插入对话路由集中，则一旦建立对话路由集，相邻下游SIP实体将发生更改。如果SIP实体在对话初始请求的最顶端通过头字段中插入“keep”参数，并且相关响应中的“keep”参数不包含参数值，则SIP实体可以选择在与对话相关联的后续SIP请求的最顶端通过头字段中插入“keep”参数，如果新的相邻下游SIP实体（基于对话路由集）愿意接收keep alives（在这种情况下，它将向“keep”参数添加一个参数值）。
If an INVITE request is used to indicate willingness to send keep-alives, as long as at least one response (provisional or final) to the INVITE request contains a "keep" parameter with a parameter value, it is seen as an indication that the adjacent downstream SIP entity is willing to receive keep-alives associated with the dialog on which the response is received.
如果INVITE请求用于表示发送保留有效信息的意愿，只要INVITE请求的至少一个响应（临时或最终）包含带有参数值的“保留”参数，它被视为相邻下游SIP实体愿意接收与接收响应的对话相关联的保持有效性的指示。
As defined in RFC 5626, a SIP entity that supports the receiving of keep-alives must act as a STUN server [RFC5389]. The SIP entity must support those aspects of STUN that are required in order to apply the STUN keep-alive mechanism defined in RFC 5626, and it must support the CRLF keep-alive mechanism defined in RFC 5626.
如RFC 5626中所定义，支持接收保留有效信息的SIP实体必须充当STUN服务器[RFC5389]。SIP实体必须支持应用RFC 5626中定义的STUN保持活动机制所需的STUN方面，并且必须支持RFC 5626中定义的CRLF保持活动机制。
When a SIP entity sends or forwards a response, and the adjacent upstream SIP entity has indicated willingness to send keep-alives, if the SIP entity is willing to receive keep-alives associated with the registration or with the dialog from that adjacent upstream SIP entity, then it MUST add a parameter value to the "keep" parameter before sending or forwarding the response. The parameter value, if present and with a value other than zero, represents a recommended keep-alive frequency, given in seconds.
当SIP实体发送或转发响应，且相邻上游SIP实体已表示愿意发送保留有效信息时，如果SIP实体愿意从该相邻上游SIP实体接收与注册或对话相关的保留有效信息，则必须向“保留”添加参数值参数，然后发送或转发响应。参数值（如果存在且值不是零）表示建议的保持活动频率，以秒为单位。
There might be multiple responses to an INVITE request. When a SIP entity indicates willingness to receive keep-alives in a response to an INVITE request, it MUST add a parameter value to the "keep" parameter in at least one reliable response to the request. The SIP entity MAY add identical parameter values to the "keep" parameters in other responses to the same request. The SIP entity MUST NOT add
一个INVITE请求可能有多个响应。当SIP实体表示愿意在对INVITE请求的响应中接收keep ALIVE时，它必须在对请求的至少一个可靠响应中向“keep”参数添加一个参数值。SIP实体可以在对相同请求的其他响应中向“keep”参数添加相同的参数值。SIP实体不能添加
different parameter values to the "keep" parameters in responses to the same request. The SIP entity SHOULD indicate the willingness to receive keep-alives as soon as possible.
响应同一请求时，“保留”参数的不同参数值。SIP实体应表明愿意尽快接收保留生命。
A SIP entity MUST NOT indicate willingness to receive keep-alives associated with a dialog, unless it has also inserted itself in the dialog route set [RFC3261].
SIP实体不得表示愿意接收与对话相关联的保留有效信息，除非它已将自身插入对话路由集[RFC3261]。
If a SIP entity receives a SIP response, where the topmost Via header field contains a "keep" parameter with a non-zero value that indicates a recommended keep-alive frequency, given in seconds, it MUST use the procedures defined for the Flow-Timer header field [RFC5626]. According to the procedures, the SIP entity must send keep-alives at least as often as the indicated recommended keep-alive frequency, and if the SIP entity uses the recommended keep-alive frequency, then it should send its keep-alives so that the interval between each keep-alive is randomly distributed between 80% and 100% of the recommended keep-alive frequency.
如果SIP实体接收到SIP响应，其中最顶端的Via标头字段包含一个非零值的“keep”（保持）参数，该参数表示建议的保持活动频率（以秒为单位），则必须使用为Flow Timer标头字段定义的程序[RFC5626]。根据程序，SIP实体必须至少按照所示的建议保持活动频率发送保持活动，如果SIP实体使用建议的保持活动频率，然后，它应该发送其保持活动，以便每次保持活动之间的间隔随机分布在推荐保持活动频率的80%到100%之间。
If the received "keep" parameter value is zero, the SIP entity can send keep-alives at its discretion. RFC 5626 provides additional guidance on selecting the keep-alive frequency in case a recommended keep-alive frequency is not provided.
如果收到的“keep”参数值为零，SIP实体可以自行决定发送keep alives。RFC 5626提供了在未提供建议的保持活动频率的情况下选择保持活动频率的额外指导。
This specification does not specify actions to take if negotiated keep-alives are not received. As defined in RFC 5626, the receiving SIP entity may consider a connection to be dead in such situations.
本规范未规定在未收到协商保存有效性时应采取的措施。如RFC 5626中定义的，接收SIP实体可以考虑在这样的情况下连接死亡。
If a SIP entity that adds a parameter value to the "keep" parameter in order to indicate willingness to receive keep-alives also inserts a Flow-Timer header field (that can happen if the SIP entity is using both the Outbound mechanism and the keep-alive mechanism) in the same SIP message, the header field value and the "keep" parameter value MUST be identical.
如果向“keep”参数添加参数值以表示愿意接收keep alives的SIP实体也在同一SIP消息中插入流量计时器头字段（如果SIP实体同时使用出站机制和保持活动机制，则可能发生这种情况），则头字段值和“keep”参数值必须相同。
SIP Outbound uses the Flow-Timer header field to indicate the server-recommended keep-alive frequency; however, it will only be sent between a UA and an edge proxy. On the other hand, by using the "keep" parameter, the sending and receiving of keep-alives can be negotiated between multiple entities on the signalling path. In addition, since the server-recommended keep-alive frequency might vary between different SIP entities, a single Flow-Timer header field cannot be used to indicate all the different frequency values.
SIP Outbound使用Flow Timer标头字段指示服务器建议的保持活动频率；但是，它将仅在UA和边缘代理之间发送。另一方面，通过使用“keep”参数，可以在信令路径上的多个实体之间协商keep alive的发送和接收。此外，由于服务器建议的保持活动频率可能在不同的SIP实体之间有所不同，因此不能使用单个Flow Timer标头字段来指示所有不同的频率值。
Keep-alives are often sent in order to keep NAT bindings open, so that SIP requests sent in the reverse direction will pass by the NAT and reuse the same connection. In the case of non-connection-oriented transport protocols, keep-alives would permit the same path to be reused. This specification does not define such a connection reuse mechanism. The keep-alive mechanism defined in this specification is only used to negotiate the sending and receiving of keep-alives. Entities that want to reuse connections need to use another mechanism to ensure that security aspects associated with connection reuse are taken into consideration.
发送Keep alive通常是为了保持NAT绑定打开，这样以相反方向发送的SIP请求将经过NAT并重用相同的连接。对于非面向连接的传输协议，keep-alives将允许重用相同的路径。本规范未定义此类连接重用机制。本规范中定义的keep alive机制仅用于协商keep alives的发送和接收。想要重用连接的实体需要使用另一种机制来确保考虑与连接重用相关的安全方面。
RFC 5923 [RFC5923] specifies a mechanism for using connection-oriented transports to send requests in the reverse direction, and an entity that wants to use connection reuse as well as indicate support of keep-alives on that connection will insert both the "alias" parameter defined in RFC 5923 and the "keep" parameter defined in this specification.
RFC 5923[RFC5923]指定了一种使用面向连接的传输以反向发送请求的机制，并且希望使用连接重用并指示支持该连接上的保持有效性的实体将插入RFC 5923中定义的“别名”参数和“保持”参数本规范中定义的参数。
SIP Outbound specifies how registration flows are used to send requests in the reverse direction.
SIP Outbound指定如何使用注册流反向发送请求。
This section shows example flows where usage of keep-alives, associated with a registration and a dialog, is negotiated between different SIP entities.
本节展示了在不同SIP实体之间协商使用与注册和对话框相关联的keep alives的示例流程。
NOTE: The examples do not show the actual syntactical encoding of the request lines, response lines, and the Via header fields, but rather a pseudocode in order to identify the message type and also identify to which SIP entity a Via header field is associated.
注意：这些示例没有显示请求行、响应行和Via报头字段的实际语法编码，而是一个伪代码，用于标识消息类型并标识Via报头字段与哪个SIP实体相关联。
Figure 1 shows an example where Alice sends a REGISTER request. She indicates willingness to send keep-alives by inserting a "keep" parameter in the Via header field of her request. The edge proxy (P1) forwards the request towards the registrar.
图1显示了Alice发送注册请求的示例。她通过在请求的Via头字段中插入一个“keep”参数表示愿意发送keep alives。边缘代理（P1）将请求转发给注册器。
P1 is willing to receive keep-alives from Alice for the duration of the registration, so when P1 receives the associated response it adds a "keep" parameter value, which indicates a recommended keep-alive frequency of 30 seconds, to Alice's Via header field, before it forwards the response towards Alice.
P1愿意在注册期间从Alice接收keep alives，因此当P1接收到相关响应时，它会在Alice的Via header字段中添加一个“keep”参数值，该参数值指示30秒的建议保持活动频率，然后再将响应转发给Alice。
When Alice receives the response, she determines from her Via header field that P1 is willing to receive keep-alives associated with the registration. Until either the registration expires or Alice sends a registration refresh request, Alice then sends periodic keep-alives (in this example using the STUN keep-alive technique) towards P1, using the recommended keep-alive frequency indicated by the "keep" parameter value.
当Alice收到响应时，她从她的Via头字段确定P1愿意接收与注册相关联的保留有效信息。在注册到期或Alice发送注册刷新请求之前，Alice然后使用“keep”（保持）参数值指示的建议保持活动频率向P1发送定期保持活动（在本例中使用STUN保持活动技术）。
Alice P1 REGISTRAR
| | |
|--- REGISTER------------->| |
| Via: Alice;keep | |
| |--- REGISTER-------------->|
| | Via: P1 |
| | Via: Alice;keep |
| | |
| |<-- 200 OK ----------------|
| | Via: P1 |
| | Via: Alice;keep |
|<-- 200 OK ---------------| |
| Via: Alice;keep=30 | |
| | |
| | |
| *** Timeout *** |
| | |
|=== STUN request ========>| |
|<== STUN response ========| |
| | |
| *** Timeout *** |
| | |
|=== STUN request ========>| |
|<== STUN response ========| |
| | |
Alice P1 REGISTRAR
| | |
|--- REGISTER------------->| |
| Via: Alice;keep | |
| |--- REGISTER-------------->|
| | Via: P1 |
| | Via: Alice;keep |
| | |
| |<-- 200 OK ----------------|
| | Via: P1 |
| | Via: Alice;keep |
|<-- 200 OK ---------------| |
| Via: Alice;keep=30 | |
| | |
| | |
| *** Timeout *** |
| | |
|=== STUN request ========>| |
|<== STUN response ========| |
| | |
| *** Timeout *** |
| | |
|=== STUN request ========>| |
|<== STUN response ========| |
| | |
Figure 1: Example Call Flow
图1：示例调用流
Figure 2 shows an example where Alice sends an initial INVITE request for a dialog. She indicates willingness to send keep-alives by inserting a "keep" parameter in the Via header field of her request. The edge proxy (P1) adds itself to the dialog route set by adding itself to a Record-Route header field, before it forwards the request towards Bob.
图2显示了Alice发送对话框初始邀请请求的示例。她通过在请求的Via头字段中插入一个“keep”参数表示愿意发送keep alives。边缘代理（P1）在将请求转发给Bob之前，通过将自身添加到记录路由头字段，将自身添加到对话框路由集。
P1 is willing to receive keep-alives from Alice for the duration of the dialog, so when P1 receives the associated response it adds a "keep" parameter value, which indicates a recommended keep-alive frequency of 30 seconds, to Alice's Via header field, before it forwards the response towards Alice.
P1愿意在对话期间从Alice接收keep alives，因此当P1接收到相关响应时，它会在Alice的Via header字段中添加一个“keep”参数值，该参数值指示30秒的建议保持活动频率，然后再将响应转发给Alice。
When Alice receives the response, she determines from her Via header field that P1 is willing to receive keep-alives associated with the dialog. For the lifetime of the dialog, Alice then sends periodic keep-alives (in this example using the STUN keep-alive technique) towards P1, using the recommended keep-alive frequency indicated by the "keep" parameter value.
当Alice收到响应时，她通过她的Via头字段确定P1愿意接收与对话框相关联的keep alives。在对话框的生命周期内，Alice使用“keep”（保持）参数值指示的建议保持活动频率，向P1发送周期性保持活动（在本例中使用STUN保持活动技术）。
Alice P1 Bob
| | |
|--- INVITE -------------->| |
| Via: Alice;keep | |
| |--- INVITE --------------->|
| | Via: P1 |
| | Via: Alice;keep |
| | Record-Route: P1 |
| | |
| |<-- 200 OK ----------------|
| | Via: P1 |
| | Via: Alice;keep |
| | Record-Route: P1 |
|<-- 200 OK ---------------| |
| Via: Alice;keep=30 | |
| Record-Route: P1 | |
| | |
|--- ACK ----------------->| |
| | |
| |--- ACK ------------------>|
| | |
| *** Timeout *** |
| | |
|=== STUN request ========>| |
|<== STUN response ========| |
| | |
| *** Timeout *** |
| | |
|=== STUN request ========>| |
|<== STUN response ========| |
| | |
| | |
|--- BYE ----------------->| |
| | |
| |--- BYE ------------------>|
| | |
| |<-- 200 OK ----------------|
| | |
Alice P1 Bob
| | |
|--- INVITE -------------->| |
| Via: Alice;keep | |
| |--- INVITE --------------->|
| | Via: P1 |
| | Via: Alice;keep |
| | Record-Route: P1 |
| | |
| |<-- 200 OK ----------------|
| | Via: P1 |
| | Via: Alice;keep |
| | Record-Route: P1 |
|<-- 200 OK ---------------| |
| Via: Alice;keep=30 | |
| Record-Route: P1 | |
| | |
|--- ACK ----------------->| |
| | |
| |--- ACK ------------------>|
| | |
| *** Timeout *** |
| | |
|=== STUN request ========>| |
|<== STUN response ========| |
| | |
| *** Timeout *** |
| | |
|=== STUN request ========>| |
|<== STUN response ========| |
| | |
| | |
|--- BYE ----------------->| |
| | |
| |--- BYE ------------------>|
| | |
| |<-- 200 OK ----------------|
| | |
Figure 2: Example Call Flow
图2：示例调用流
Figure 3 shows an example where Alice sends an initial INVITE request for a dialog. She indicates willingness to send keep-alives by inserting a "keep" parameter in the Via header field of her request. In this scenario, the edge proxy (P1) does not add itself to a Record-Route header field (and so will not be added to the dialog route set) before forwarding the request towards Bob.
图3显示了Alice发送对话框初始邀请请求的示例。她通过在请求的Via头字段中插入一个“keep”参数表示愿意发送keep alives。在这种情况下，边缘代理（P1）在向Bob转发请求之前不会将自身添加到记录路由头字段（因此不会添加到对话框路由集）。
When Alice receives the response, she determines from the Via header field that P1 is not willing to receive keep-alives associated with the dialog from her. When the dialog route set has been established, Alice sends a mid-dialog UPDATE request towards Bob (since P1 did not insert itself in the dialog route set), and she once again indicates willingness to send keep-alives by inserting a "keep" parameter in the Via header field of her request. Bob supports the keep-alive mechanism, and is willing to receive keep-alives associated with the dialog from Alice, so he creates a response and adds a "keep" parameter value, which indicates a recommended keep-alive frequency of 30 seconds, to Alice's Via header field, before he forwards the response towards Alice.
当Alice收到响应时，她从Via标头字段确定P1不愿意从她那里接收与对话框相关联的keep alives。建立对话路由集后，Alice向Bob发送一个中间对话更新请求（因为P1没有在对话路由集中插入自身），并且她通过在请求的Via头字段中插入一个“keep”参数再次表示愿意发送keep alives。Bob支持keep-alive机制，并且愿意从Alice接收与对话框相关联的keep-alives，因此他创建了一个响应，并在Alice的Via标头字段中添加了一个“keep”参数值，该参数值表示建议的保持活动频率为30秒，然后将响应转发给Alice。
When Alice receives the response, she determines from her Via header field that Bob is willing to receive keep-alives associated with the dialog. For the lifetime of the dialog, Alice then sends periodic keep-alives (in this example using the STUN keep-alive technique) towards Bob, using the recommended keep-alive frequency indicated by the "keep" parameter value.
当Alice收到响应时，她通过她的Via头字段确定Bob愿意接收与对话框关联的keep alives。在对话框的生命周期内，Alice使用“keep”参数值指示的建议保持活动频率，向Bob发送定期保持活动（在本例中使用STUN保持活动技术）。
Alice P1 Bob
| | |
|--- INVITE -------------->| |
| Via: Alice;keep | |
| |--- INVITE --------------->|
| | Via: P1 |
| | Via: Alice;keep |
| | |
| |<-- 200 OK ----------------|
| | Via: P1 |
| | Via: Alice;keep |
|<-- 200 OK ---------------| |
| Via: Alice;keep | |
| | |
| |
|--- ACK --------------------------------------------->|
| |
|--- UPDATE ------------------------------------------>|
| Via: Alice;keep |
| |
|<-- 200 OK -------------------------------------------|
| Via: Alice;keep=30 |
| |
| |
| *** Timeout *** |
| |
|=== STUN request ====================================>|
|<== STUN response ====================================|
| |
| *** Timeout *** |
| |
|=== STUN request ====================================>|
|<== STUN response ====================================|
| |
| |
|--- BYE --------------------------------------------->|
| |
|<-- 200 OK -------------------------------------------|
| |
Alice P1 Bob
| | |
|--- INVITE -------------->| |
| Via: Alice;keep | |
| |--- INVITE --------------->|
| | Via: P1 |
| | Via: Alice;keep |
| | |
| |<-- 200 OK ----------------|
| | Via: P1 |
| | Via: Alice;keep |
|<-- 200 OK ---------------| |
| Via: Alice;keep | |
| | |
| |
|--- ACK --------------------------------------------->|
| |
|--- UPDATE ------------------------------------------>|
| Via: Alice;keep |
| |
|<-- 200 OK -------------------------------------------|
| Via: Alice;keep=30 |
| |
| |
| *** Timeout *** |
| |
|=== STUN request ====================================>|
|<== STUN response ====================================|
| |
| *** Timeout *** |
| |
|=== STUN request ====================================>|
|<== STUN response ====================================|
| |
| |
|--- BYE --------------------------------------------->|
| |
|<-- 200 OK -------------------------------------------|
| |
Figure 3: Example Call Flow
图3：示例调用流
This section extends the ABNF definition of via-params from [RFC3261] by adding a new Via header field parameter, "keep". The ABNF defined in this specification is conformant to RFC 5234 [RFC5234]. "EQUAL" is defined in RFC 3261. "DIGIT" is defined in RFC 5234.
本节通过添加新的via header字段参数“keep”，扩展了[RFC3261]中via参数的ABNF定义。本规范中定义的ABNF符合RFC 5234[RFC5234]。RFC 3261中定义了“相等”。“数字”在RFC 5234中定义。
via-params =/ keep
通过params=/keep
keep = "keep" [ EQUAL 1*(DIGIT) ]
keep=“keep”[等于1*（位数）]
This specification defines a new Via header field parameter called
"keep" in the "Header Field Parameters and Parameter Values"
sub-registry as per the registry created by [RFC3968]. The syntax is
defined in Section 8 of this document. IANA has registered the
following:
Predefined
Header Field Parameter Name Values Reference
---------------------- --------------------- ---------- ---------
Via keep No [RFC6223]
This specification defines a new Via header field parameter called
"keep" in the "Header Field Parameters and Parameter Values"
sub-registry as per the registry created by [RFC3968]. The syntax is
defined in Section 8 of this document. IANA has registered the
following:
Predefined
Header Field Parameter Name Values Reference
---------------------- --------------------- ---------- ---------
Via keep No [RFC6223]
SIP entities that send or receive keep-alives are often required to use a connection reuse mechanism, in order to ensure that requests sent in the reverse direction, towards the sender of the keep-alives, traverse NATs, etc. This specification does not define a connection reuse mechanism, and it does not address security issues related to connection reuse. SIP entities that wish to reuse connections need to use a dedicated connection reuse mechanism, in conjunction with the keep-alive negotiation mechanism.
发送或接收保持有效的SIP实体通常需要使用连接重用机制，以确保向保持有效的发送方反向发送的请求能够穿越NAT等。本规范未定义连接重用机制，而且它没有解决与连接重用相关的安全问题。希望重用连接的SIP实体需要使用专用的连接重用机制以及保持活动的协商机制。
Unless SIP messages are integrity protected hop-by-hop, e.g., using Transport Layer Security (TLS) [RFC5246] or Datagram Transport Layer Security (DTLS) [RFC4347], a man-in-the-middle can modify Via header fields used by two entities to negotiate the sending of keep-alives, e.g., by removing the designations used to indicate willingness to send and receive keep-alives, or by decreasing the timer value to a very low value, which might trigger additional resource consumption due to the frequently sent keep-alives.
除非SIP消息逐跳受到完整性保护，例如，使用传输层安全性（TLS）[RFC5246]或数据报传输层安全性（DTLS）[RFC4347]，否则中间人可以通过两个实体使用的报头字段进行修改，以协商保持有效性的发送，例如。，通过删除用于指示发送和接收保留有效信息意愿的名称，或将计时器值降低到非常低的值，这可能会由于频繁发送保留有效信息而引发额外的资源消耗。
The behaviors defined in Sections 4.3 and 4.4 require a SIP entity using the mechanism defined in this specification to place a value in the "keep" parameter in the topmost Via header field value of a response the SIP entity sends. They do not instruct the entity to place a value in a "keep" parameter of any request it forwards. In particular, a SIP proxy MUST NOT place a value into the "keep" parameter of the topmost Via header field value of a request it receives before forwarding it. A SIP proxy implementing this specification SHOULD remove any "keep" parameter values in any Via header field values below the topmost one in responses it receives before forwarding them.
第4.3节和第4.4节中定义的行为要求SIP实体使用本规范中定义的机制，在SIP实体发送的响应的最顶部Via header字段值的“keep”参数中放置一个值。它们不会指示实体在其转发的任何请求的“keep”参数中放置值。特别是，SIP代理在转发请求之前，不得将值放入其接收的请求的最顶层Via头字段值的“keep”参数中。实现此规范的SIP代理在转发响应之前，应删除任何Via头字段值中低于其接收的响应中最高值的任何“保留”参数值。
When requests are forwarded across multiple hops, it is possible for a malicious downstream SIP entity to tamper with the accrued values in the Via header field. The malicious SIP entity could place a value, or change an existing value in a "keep" parameter in any of the Via header field values -- not just the topmost value. A proxy implementation that simply forwards responses by stripping the topmost Via header field value and not inspecting the resulting new topmost Via header field value risks being adversely affected by such a malicious downstream SIP entity. In particular, such a proxy may start receiving STUN requests if it blindly forwards a response with a "keep" parameter with a value it did not create in the topmost Via header field.
当请求跨多个跃点转发时，恶意下游SIP实体可能篡改Via标头字段中的累积值。恶意SIP实体可以在任何Via标头字段值的“keep”参数中放置值或更改现有值，而不仅仅是最上面的值。通过剥离最顶端的Via报头字段值而不检查生成的新最顶端Via报头字段值来转发响应的代理实现可能会受到这种恶意下游SIP实体的不利影响。特别是，如果这种代理盲目地转发带有“keep”参数的响应，并且该参数的值不是它在最顶端的Via头字段中创建的，那么它可能会开始接收STUN请求。
To lower the chances of the malicious SIP entity's actions having adverse effects on such proxies, when a SIP entity sends STUN keep-alives to an adjacent downstream SIP entity and does not receive a response to those STUN messages (as described in Section 7.2.1 of RFC 5389 [RFC5389], it MUST stop sending keep-alives for the remaining duration of the dialog (if the sending of keep-alives were negotiated for a dialog) or until the sending of keep-alives is re-negotiated for the registration (if the sending keep-alives were negotiated for a registration).
为了降低恶意SIP实体的行为对此类代理产生不利影响的可能性，当SIP实体向相邻下游SIP实体发送STUN保持有效信息且未收到对这些STUN消息的响应时（如RFC 5389[RFC5389]第7.2.1节所述），它必须在对话的剩余时间内停止发送保留有效期（如果为对话协商发送保留有效期），或者直到为注册重新协商发送保留有效期（如果为注册协商发送保留有效期）。
Apart from the issues described above, this specification does not introduce security considerations in addition to those specified for keep-alives in [RFC5626].
除上述问题外，除[RFC5626]中为保持有效性规定的安全注意事项外，本规范未引入其他安全注意事项。
Thanks to Staffan Blau, Francois Audet, Hadriel Kaplan, Sean Schneyer, and Milo Orsic for their comments on the initial draft version of this document. Thanks to Juha Heinanen, Jiri Kuthan, Dean Willis, John Elwell, Paul Kyzivat, Peter Musgrave, Dale Worley, Adam Roach, and Robert Sparks for their comments on the sipcore mailing list. Thanks to Vijay Gurbani for providing text about the relationship with the connect reuse specification.
感谢Staffan Blau、Francois Audet、Hadriel Kaplan、Sean Schneyer和Milo Orsic对本文件初稿的评论。感谢Juha Heinanen、Jiri Kuthan、Dean Willis、John Elwell、Paul Kyzivat、Peter Musgrave、Dale Worley、Adam Roach和Robert Sparks在sipcore邮件列表上的评论。感谢Vijay Gurbani提供了关于与connect重用规范关系的文本。
[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月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT的会话遍历实用程序（STUN）”，RFC 5389，2008年10月。
[RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626]Jennings，C.，Ed.，Mahy，R.，Ed.，和F.Audet，Ed.，“在会话启动协议（SIP）中管理客户端启动的连接”，RFC 56262009年10月。
[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月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]Rescorla，E.和N.Modadugu，“数据报传输层安全”，RFC 4347，2006年4月。
[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月。
[RFC5923] Gurbani, V., Ed., Mahy, R., and B. Tate, "Connection Reuse in the Session Initiation Protocol (SIP)", RFC 5923, June 2010.
[RFC5923]Gurbani，V.，Ed.，Mahy，R.，和B.Tate，“会话启动协议（SIP）中的连接重用”，RFC 59232010年6月。
Author's Address
作者地址
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: christer.holmberg@ericsson.com
EMail: christer.holmberg@ericsson.com