Network Working Group C. Jennings, Ed.
Request for Comments: 5626 Cisco Systems
Updates: 3261, 3327 R. Mahy, Ed.
Category: Standards Track Unaffiliated
F. Audet, Ed.
Skype Labs
October 2009
Network Working Group C. Jennings, Ed.
Request for Comments: 5626 Cisco Systems
Updates: 3261, 3327 R. Mahy, Ed.
Category: Standards Track Unaffiliated
F. Audet, Ed.
Skype Labs
October 2009
Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)
在会话启动协议（SIP）中管理客户端启动的连接
Abstract
摘要
The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections or to send asynchronous UDP datagrams to User Agents in order to deliver requests. However, in a large number of real deployments, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs) or the use of TLS with server-provided certificates, prevent servers from connecting to User Agents in this way. This specification defines behaviors for User Agents, registrars, and proxy servers that allow requests to be delivered on existing connections established by the User Agent. It also defines keep-alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections from the User Agent to its registrar.
会话启动协议（SIP）允许代理服务器启动TCP连接或向用户代理发送异步UDP数据报，以便传递请求。然而，在大量实际部署中，许多实际考虑因素（如防火墙和网络地址转换器（NAT）的存在或使用带有服务器提供的证书的TLS）会阻止服务器以这种方式连接到用户代理。此规范定义了用户代理、注册器和代理服务器的行为，允许在用户代理建立的现有连接上传递请求。它还定义了保持NAT绑定打开所需的保持活动的行为，并指定了从用户代理到其注册器的多个连接的使用。
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括简化的BSD许可证文本，如本规范第4.e节所述
the Trust Legal Provisions and are provided without warranty as described in the BSD License.
如BSD许可证所述，信托法律条款和担保条款不提供担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Summary of Mechanism . . . . . . . . . . . . . . . . . . . 6
3.2. Single Registrar and UA . . . . . . . . . . . . . . . . . 7
3.3. Multiple Connections from a User Agent . . . . . . . . . . 8
3.4. Edge Proxies . . . . . . . . . . . . . . . . . . . . . . . 10
3.5. Keep-Alive Technique . . . . . . . . . . . . . . . . . . . 11
3.5.1. CRLF Keep-Alive Technique . . . . . . . . . . . . . . 12
3.5.2. STUN Keep-Alive Technique . . . . . . . . . . . . . . 12
4. User Agent Procedures . . . . . . . . . . . . . . . . . . . . 13
4.1. Instance ID Creation . . . . . . . . . . . . . . . . . . . 13
4.2. Registrations . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Initial Registrations . . . . . . . . . . . . . . . . 14
4.2.2. Subsequent REGISTER Requests . . . . . . . . . . . . . 16
4.2.3. Third-Party Registrations . . . . . . . . . . . . . . 17
4.3. Sending Non-REGISTER Requests . . . . . . . . . . . . . . 17
4.4. Keep-Alives and Detecting Flow Failure . . . . . . . . . . 18
4.4.1. Keep-Alive with CRLF . . . . . . . . . . . . . . . . . 19
4.4.2. Keep-Alive with STUN . . . . . . . . . . . . . . . . . 21
4.5. Flow Recovery . . . . . . . . . . . . . . . . . . . . . . 21
5. Edge Proxy Procedures . . . . . . . . . . . . . . . . . . . . 22
5.1. Processing Register Requests . . . . . . . . . . . . . . . 22
5.2. Generating Flow Tokens . . . . . . . . . . . . . . . . . . 23
5.3. Forwarding Non-REGISTER Requests . . . . . . . . . . . . . 23
5.3.1. Processing Incoming Requests . . . . . . . . . . . . . 24
5.3.2. Processing Outgoing Requests . . . . . . . . . . . . . 24
5.4. Edge Proxy Keep-Alive Handling . . . . . . . . . . . . . . 25
6. Registrar Procedures . . . . . . . . . . . . . . . . . . . . . 25
7. Authoritative Proxy Procedures: Forwarding Requests . . . . . 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Summary of Mechanism . . . . . . . . . . . . . . . . . . . 6
3.2. Single Registrar and UA . . . . . . . . . . . . . . . . . 7
3.3. Multiple Connections from a User Agent . . . . . . . . . . 8
3.4. Edge Proxies . . . . . . . . . . . . . . . . . . . . . . . 10
3.5. Keep-Alive Technique . . . . . . . . . . . . . . . . . . . 11
3.5.1. CRLF Keep-Alive Technique . . . . . . . . . . . . . . 12
3.5.2. STUN Keep-Alive Technique . . . . . . . . . . . . . . 12
4. User Agent Procedures . . . . . . . . . . . . . . . . . . . . 13
4.1. Instance ID Creation . . . . . . . . . . . . . . . . . . . 13
4.2. Registrations . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Initial Registrations . . . . . . . . . . . . . . . . 14
4.2.2. Subsequent REGISTER Requests . . . . . . . . . . . . . 16
4.2.3. Third-Party Registrations . . . . . . . . . . . . . . 17
4.3. Sending Non-REGISTER Requests . . . . . . . . . . . . . . 17
4.4. Keep-Alives and Detecting Flow Failure . . . . . . . . . . 18
4.4.1. Keep-Alive with CRLF . . . . . . . . . . . . . . . . . 19
4.4.2. Keep-Alive with STUN . . . . . . . . . . . . . . . . . 21
4.5. Flow Recovery . . . . . . . . . . . . . . . . . . . . . . 21
5. Edge Proxy Procedures . . . . . . . . . . . . . . . . . . . . 22
5.1. Processing Register Requests . . . . . . . . . . . . . . . 22
5.2. Generating Flow Tokens . . . . . . . . . . . . . . . . . . 23
5.3. Forwarding Non-REGISTER Requests . . . . . . . . . . . . . 23
5.3.1. Processing Incoming Requests . . . . . . . . . . . . . 24
5.3.2. Processing Outgoing Requests . . . . . . . . . . . . . 24
5.4. Edge Proxy Keep-Alive Handling . . . . . . . . . . . . . . 25
6. Registrar Procedures . . . . . . . . . . . . . . . . . . . . . 25
7. Authoritative Proxy Procedures: Forwarding Requests . . . . . 27
8. STUN Keep-Alive Processing . . . . . . . . . . . . . . . . . . 28
8.1. Use with SigComp . . . . . . . . . . . . . . . . . . . . . 29
9. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 30
9.1. Subscription to Configuration Package . . . . . . . . . . 30
9.2. Registration . . . . . . . . . . . . . . . . . . . . . . . 32
9.3. Incoming Call and Proxy Crash . . . . . . . . . . . . . . 34
9.4. Re-Registration . . . . . . . . . . . . . . . . . . . . . 37
9.5. Outgoing Call . . . . . . . . . . . . . . . . . . . . . . 38
10. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
11.1. Flow-Timer Header Field . . . . . . . . . . . . . . . . . 40
11.2. "reg-id" Contact Header Field Parameter . . . . . . . . . 40
11.3. SIP/SIPS URI Parameters . . . . . . . . . . . . . . . . . 41
11.4. SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 41
11.5. 430 (Flow Failed) Response Code . . . . . . . . . . . . . 41
11.6. 439 (First Hop Lacks Outbound Support) Response Code . . . 42
11.7. Media Feature Tag . . . . . . . . . . . . . . . . . . . . 42
12. Security Considerations . . . . . . . . . . . . . . . . . . . 43
13. Operational Notes on Transports . . . . . . . . . . . . . . . 44
14. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 44
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
16.1. Normative References . . . . . . . . . . . . . . . . . . . 45
16.2. Informative References . . . . . . . . . . . . . . . . . . 47
Appendix A. Default Flow Registration Backoff Times . . . . . . . 49
Appendix B. ABNF . . . . . . . . . . . . . . . . . . . . . . . . 49
8. STUN Keep-Alive Processing . . . . . . . . . . . . . . . . . . 28
8.1. Use with SigComp . . . . . . . . . . . . . . . . . . . . . 29
9. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 30
9.1. Subscription to Configuration Package . . . . . . . . . . 30
9.2. Registration . . . . . . . . . . . . . . . . . . . . . . . 32
9.3. Incoming Call and Proxy Crash . . . . . . . . . . . . . . 34
9.4. Re-Registration . . . . . . . . . . . . . . . . . . . . . 37
9.5. Outgoing Call . . . . . . . . . . . . . . . . . . . . . . 38
10. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
11.1. Flow-Timer Header Field . . . . . . . . . . . . . . . . . 40
11.2. "reg-id" Contact Header Field Parameter . . . . . . . . . 40
11.3. SIP/SIPS URI Parameters . . . . . . . . . . . . . . . . . 41
11.4. SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 41
11.5. 430 (Flow Failed) Response Code . . . . . . . . . . . . . 41
11.6. 439 (First Hop Lacks Outbound Support) Response Code . . . 42
11.7. Media Feature Tag . . . . . . . . . . . . . . . . . . . . 42
12. Security Considerations . . . . . . . . . . . . . . . . . . . 43
13. Operational Notes on Transports . . . . . . . . . . . . . . . 44
14. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 44
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
16.1. Normative References . . . . . . . . . . . . . . . . . . . 45
16.2. Informative References . . . . . . . . . . . . . . . . . . 47
Appendix A. Default Flow Registration Backoff Times . . . . . . . 49
Appendix B. ABNF . . . . . . . . . . . . . . . . . . . . . . . . 49
There are many environments for SIP [RFC3261] deployments in which the User Agent (UA) can form a connection to a registrar or proxy but in which connections in the reverse direction to the UA are not possible. This can happen for several reasons, but the most likely is a NAT or a firewall in between the SIP UA and the proxy. Many such devices will only allow outgoing connections. This specification allows a SIP User Agent behind such a firewall or NAT to receive inbound traffic associated with registrations or dialogs that it initiates.
有许多用于SIP[RFC3261]部署的环境，在这些环境中，用户代理（UA）可以形成到注册器或代理的连接，但在这些环境中，不可能实现到UA的反向连接。发生这种情况可能有几个原因，但最有可能的原因是SIP UA和代理之间的NAT或防火墙。许多这样的设备只允许传出连接。该规范允许防火墙或NAT后面的SIP用户代理接收与其发起的注册或对话相关联的入站流量。
Most IP phones and personal computers get their network configurations dynamically via a protocol such as the Dynamic Host Configuration Protocol (DHCP) [RFC2131]. These systems typically do not have a useful name in the Domain Name System (DNS) [RFC1035], and they almost never have a long-term, stable DNS name that is appropriate for use in the subjectAltName of a certificate, as required by [RFC3261]. However, these systems can still act as a Transport Layer Security (TLS) [RFC5246] client and form outbound connections to a proxy or registrar that authenticates with a server certificate. The server can authenticate the UA using a shared secret in a digest challenge (as defined in Section 22 of RFC 3261) over that TLS connection. This specification allows a SIP User Agent who has to initiate the TLS connection to receive inbound traffic associated with registrations or dialogs that it initiates.
大多数IP电话和个人计算机通过协议（如动态主机配置协议（DHCP）[RFC2131]）动态获取网络配置。这些系统通常在域名系统（DNS）[RFC1035]中没有一个有用的名称，而且它们几乎从来没有一个长期稳定的DNS名称，按照[RFC3261]的要求，适合在证书的subjectAltName中使用。但是，这些系统仍然可以充当传输层安全性（TLS）[RFC5246]客户端，并与使用服务器证书进行身份验证的代理或注册器形成出站连接。服务器可以通过该TLS连接在摘要质询（如RFC 3261第22节中所定义）中使用共享密钥对UA进行身份验证。此规范允许必须启动TLS连接的SIP用户代理接收与其启动的注册或对话框相关联的入站流量。
The key idea of this specification is that when a UA sends a REGISTER request or a dialog-forming request, the proxy can later use this same network "flow" -- whether this is a bidirectional stream of UDP datagrams, a TCP connection, or an analogous concept in another transport protocol -- to forward any incoming requests that need to go to this UA in the context of the registration or dialog.
该规范的关键思想是，当UA发送注册请求或对话形成请求时，代理稍后可以使用相同的网络“流”——无论这是UDP数据报的双向流、TCP连接、，或者另一个传输协议中的类似概念——在注册或对话框的上下文中转发需要发送到此UA的任何传入请求。
For a UA to receive incoming requests, the UA has to connect to a server. Since the server can't connect to the UA, the UA has to make sure that a flow is always active. This requires the UA to detect when a flow fails. Since such detection takes time and leaves a window of opportunity for missed incoming requests, this mechanism allows the UA to register over multiple flows at the same time. This specification also defines two keep-alive schemes. The keep-alive mechanism is used to keep NAT bindings fresh, and to allow the UA to detect when a flow has failed.
UA要接收传入请求，必须连接到服务器。由于服务器无法连接到UA，UA必须确保流始终处于活动状态。这要求UA在流失败时进行检测。由于这种检测需要时间并为错过的传入请求留下机会窗口，因此该机制允许UA同时在多个流上注册。本规范还定义了两种保持活动的方案。keep-alive机制用于保持NAT绑定新鲜，并允许UA在流失败时检测。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Authoritative Proxy: A proxy that handles non-REGISTER requests for a specific Address-of-Record (AOR), performs the logical Location Server lookup described in [RFC3261], and forwards those requests to specific Contact URIs. (In [RFC3261], the role that is authoritative for REGISTER requests for a specific AOR is a Registration Server.)
权威代理：处理特定记录地址（AOR）的非注册请求、执行[RFC3261]中所述的逻辑位置服务器查找并将这些请求转发给特定联系人URI的代理。（在[RFC3261]中，对特定AOR的注册请求具有权威性的角色是注册服务器。）
Edge Proxy: An edge proxy is any proxy that is located topologically between the registering User Agent and the Authoritative Proxy. The "first" edge proxy refers to the first edge proxy encountered when a UA sends a request.
边缘代理：边缘代理是拓扑上位于注册用户代理和权威代理之间的任何代理。“第一个”边缘代理是指UA发送请求时遇到的第一个边缘代理。
Flow: A Flow is a transport-layer association between two hosts that is represented by the network address and port number of both ends and by the transport protocol. For TCP, a flow is equivalent to a TCP connection. For UDP a flow is a bidirectional stream of datagrams between a single pair of IP addresses and ports of both peers. With TCP, a flow often has a one-to-one correspondence with a single file descriptor in the operating system.
流：流是两台主机之间的传输层关联，由两端的网络地址和端口号以及传输协议表示。对于TCP，流相当于TCP连接。对于UDP，流是一对IP地址和两个对等端口之间的双向数据报流。对于TCP，流通常与操作系统中的单个文件描述符有一对一的对应关系。
Flow Token: An identifier that uniquely identifies a flow which can be included in a SIP URI (Uniform Resource Identifier [RFC3986]).
流令牌：唯一标识可包含在SIP URI中的流的标识符（统一资源标识符[RFC3986]）。
reg-id: This refers to the value of a new header field parameter value for the Contact header field. When a UA registers multiple times, each for a different flow, each concurrent registration gets a unique reg-id value.
reg id：这是指联系人标题字段的新标题字段参数值的值。当UA多次注册时，每个注册针对不同的流，每个并发注册都会获得唯一的reg id值。
instance-id: This specification uses the word instance-id to refer to the value of the "sip.instance" media feature tag which appears as a "+sip.instance" Contact header field parameter. This is a Uniform Resource Name (URN) that uniquely identifies this specific UA instance.
实例id：此规范使用单词instance id来表示“sip.instance”媒体功能标签的值，该标签显示为“+sip.instance”联系人标头字段参数。这是唯一标识此特定UA实例的统一资源名（URN）。
"ob" Parameter: The "ob" parameter is a SIP URI parameter that has a different meaning depending on context. In a Path header field value, it is used by the first edge proxy to indicate that a flow token was added to the URI. In a Contact or Route header field value, it indicates that the UA would like other requests in the same dialog to be routed over the same flow.
“ob”参数：“ob”参数是一个SIPURI参数，根据上下文具有不同的含义。在路径头字段值中，第一个边缘代理使用它来指示已将流令牌添加到URI。在Contact或Route header字段值中，它表示UA希望相同对话框中的其他请求通过相同的流进行路由。
outbound-proxy-set: A set of SIP URIs (Uniform Resource Identifiers) that represents each of the outbound proxies (often edge proxies) with which the UA will attempt to maintain a direct flow. The first URI in the set is often referred to as the primary outbound proxy and the second as the secondary outbound proxy. There is no difference between any of the URIs in this set, nor does the primary/secondary terminology imply that one is preferred over the other.
出站代理集：一组SIP URI（统一资源标识符），表示UA将尝试与之保持直接流的每个出站代理（通常为边缘代理）。集合中的第一个URI通常称为主出站代理，第二个URI称为辅助出站代理。此集合中的任何URI之间都没有区别，主/辅术语也不表示一个URI优于另一个URI。
The mechanisms defined in this document are useful in several scenarios discussed below, including the simple co-located registrar and proxy, a User Agent desiring multiple connections to a resource (for redundancy, for example), and a system that uses edge proxies.
本文档中定义的机制在下面讨论的几个场景中很有用，包括简单的同处注册器和代理、希望多个连接到资源的用户代理（例如，为了冗余）以及使用边缘代理的系统。
This entire section is non-normative.
这整个部分都是非规范性的。
Each UA has a unique instance-id that stays the same for this UA even if the UA reboots or is power cycled. Each UA can register multiple times over different flows for the same SIP Address of Record (AOR) to achieve high reliability. Each registration includes the instance-id for the UA and a reg-id label that is different for each flow. The registrar can use the instance-id to recognize that two different registrations both correspond to the same UA. The registrar can use the reg-id label to recognize whether a UA is creating a new flow or refreshing or replacing an old one, possibly after a reboot or a network failure.
每个UA都有一个唯一的实例id，该实例id对于该UA保持不变，即使UA重新启动或断电。每个UA可以在不同的流上多次注册相同的SIP记录地址（AOR），以实现高可靠性。每个注册包括UA的实例id和每个流不同的reg id标签。注册器可以使用实例id来识别两个不同的注册都对应于相同的UA。注册器可以使用reg id标签来识别UA是否正在创建新流或刷新或替换旧流，可能是在重新启动或网络故障之后。
When a proxy goes to route a message to a UA for which it has a binding, it can use any one of the flows on which a successful registration has been completed. A failure to deliver a request on a particular flow can be tried again on an alternate flow. Proxies can determine which flows go to the same UA by comparing the instance-id. Proxies can tell that a flow replaces a previously abandoned flow by looking at the reg-id.
当代理将消息路由到其具有绑定的UA时，它可以使用已成功注册的任何流。无法在特定流上传递请求时，可以在备用流上重试。代理可以通过比较实例id来确定哪些流流向同一UA。代理可以通过查看reg-id来判断流是否替换了先前放弃的流。
When sending a dialog-forming request, a UA can also ask its first edge proxy to route subsequent requests in that dialog over the same flow. This is necessary whether the UA has registered or not.
当发送对话形成请求时，UA还可以要求其第一个边缘代理通过相同的流路由该对话中的后续请求。无论UA是否已注册，这都是必要的。
UAs use a simple periodic message as a keep-alive mechanism to keep their flow to the proxy or registrar alive. For connection-oriented transports such as TCP this is based on carriage-return and line-feed
UAs使用一个简单的周期性消息作为保持活动的机制，以使其流向代理或注册器的流保持活动。对于面向连接的传输，如TCP，这基于回车和换行
sequences (CRLF), while for transports that are not connection oriented, this is accomplished by using a SIP-specific usage profile of STUN (Session Traversal Utilities for NAT) [RFC5389].
序列（CRLF），而对于不面向连接的传输，这是通过使用STUN（NAT会话遍历实用程序）[RFC5389]的SIP特定使用配置文件实现的。
In the topology shown below, a single server is acting as both a registrar and proxy.
在下面显示的拓扑中，一台服务器同时充当注册器和代理。
+-----------+
| Registrar |
| Proxy |
+-----+-----+
|
|
+----+--+
| User |
| Agent |
+-------+
+-----------+
| Registrar |
| Proxy |
+-----+-----+
|
|
+----+--+
| User |
| Agent |
+-------+
User Agents that form only a single flow continue to register normally but include the instance-id as described in Section 4.1. The UA also includes a "reg-id" Contact header field parameter that is used to allow the registrar to detect and avoid keeping invalid contacts when a UA reboots or reconnects after its old connection has failed for some reason.
仅形成单个流的用户代理继续正常注册，但包括第4.1节所述的实例id。UA还包括一个“reg id”联系人标头字段参数，该参数用于允许注册官在UA重新启动或在其旧连接因某种原因失败后重新连接时检测并避免保留无效联系人。
For clarity, here is an example. Bob's UA creates a new TCP flow to the registrar and sends the following REGISTER request.
为了清楚起见，这里有一个例子。Bob的UA创建一个新的TCP流到注册器，并发送以下注册请求。
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bK-bad0ce-11-1036
Max-Forwards: 70
From: Bob <sip:bob@example.com>;tag=d879h76
To: Bob <sip:bob@example.com>
Call-ID: 8921348ju72je840.204
CSeq: 1 REGISTER
Supported: path, outbound
Contact: <sip:line1@192.0.2.2;transport=tcp>; reg-id=1;
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000A95A0E128>"
Content-Length: 0
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bK-bad0ce-11-1036
Max-Forwards: 70
From: Bob <sip:bob@example.com>;tag=d879h76
To: Bob <sip:bob@example.com>
Call-ID: 8921348ju72je840.204
CSeq: 1 REGISTER
Supported: path, outbound
Contact: <sip:line1@192.0.2.2;transport=tcp>; reg-id=1;
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000A95A0E128>"
Content-Length: 0
The registrar challenges this registration to authenticate Bob. When the registrar adds an entry for this contact under the AOR for Bob, the registrar also keeps track of the connection over which it received this registration.
注册员挑战此注册以验证Bob。当注册官在Bob的AOR下为该联系人添加一个条目时，注册官还跟踪其收到该注册的连接。
The registrar saves the instance-id ("urn:uuid:00000000-0000-1000-8000-000A95A0E128") and reg-id ("1") along with the rest of the Contact header field. If the instance-id and reg-id are the same as a previous registration for the same AOR, the registrar replaces the old Contact URI and flow information. This allows a UA that has rebooted to replace its previous registration for each flow with minimal impact on overall system load.
注册器保存实例id（“urn:uuid:00000000-0000-1000-8000-000A95A0E128”）和注册id（“1”）以及联系人标头字段的其余部分。如果实例id和注册id与同一AOR的先前注册相同，则注册器将替换旧的联系人URI和流信息。这使得重新启动的UA能够在对整个系统负载影响最小的情况下，替换其以前对每个流的注册。
When Alice sends a request to Bob, his authoritative proxy selects the target set. The proxy forwards the request to elements in the target set based on the proxy's policy. The proxy looks at the target set and uses the instance-id to understand if two targets both end up routing to the same UA. When the proxy goes to forward a request to a given target, it looks and finds the flows over which it received the registration. The proxy then forwards the request over an existing flow, instead of resolving the Contact URI using the procedures in [RFC3263] and trying to form a new flow to that contact.
当Alice向Bob发送请求时，他的权威代理选择目标集。代理根据代理的策略将请求转发到目标集中的元素。代理查看目标集并使用实例id了解两个目标是否最终都路由到同一UA。当代理将请求转发给给定的目标时，它会查找并找到接收注册的流。然后，代理通过现有流转发请求，而不是使用[RFC3263]中的过程解析联系人URI并尝试向该联系人形成新的流。
As described in the next section, if the proxy has multiple flows that all go to this UA, the proxy can choose any one of the registration bindings for this AOR that has the same instance-id as the selected UA.
如下一节所述，如果代理具有多个流，所有这些流都流向此UA，则代理可以为此AOR选择与所选UA具有相同实例id的任何一个注册绑定。
There are various ways to deploy SIP to build a reliable and scalable system. This section discusses one such design that is possible with the mechanisms in this specification. Other designs are also possible.
有多种方法可以部署SIP来构建可靠且可扩展的系统。本节讨论了本规范中机制可能采用的一种此类设计。其他设计也是可能的。
In the example system below, the logical outbound proxy/registrar for the domain is running on two hosts that share the appropriate state and can both provide registrar and outbound proxy functionality for the domain. The UA will form connections to two of the physical hosts that can perform the authoritative proxy/registrar function for the domain. Reliability is achieved by having the UA form two TCP connections to the domain.
在下面的示例系统中，域的逻辑出站代理/注册器在两台主机上运行，这两台主机共享适当的状态，并且都可以为域提供注册器和出站代理功能。UA将与两个物理主机建立连接，这两个主机可以为域执行权威代理/注册功能。可靠性是通过UA与域形成两个TCP连接来实现的。
+-------------------+
| Domain |
| Logical Proxy/Reg |
| |
|+-----+ +-----+|
||Host1| |Host2||
|+-----+ +-----+|
+---\------------/--+
\ /
\ /
\ /
\ /
+------+
| User |
| Agent|
+------+
+-------------------+
| Domain |
| Logical Proxy/Reg |
| |
|+-----+ +-----+|
||Host1| |Host2||
|+-----+ +-----+|
+---\------------/--+
\ /
\ /
\ /
\ /
+------+
| User |
| Agent|
+------+
The UA is configured with multiple outbound proxy registration URIs. These URIs are configured into the UA through whatever the normal mechanism is to configure the proxy address and AOR in the UA. If the AOR is alice@example.com, the outbound-proxy-set might look something like "sip:primary.example.com" and "sip: secondary.example.com". Note that each URI in the outbound-proxy-set could resolve to several different physical hosts. The administrative domain that created these URIs should ensure that the two URIs resolve to separate hosts. These URIs are handled according to normal SIP processing rules, so mechanisms like DNS SRV [RFC2782] can be used to do load-balancing across a proxy farm. The approach in this document does not prevent future extensions, such as the SIP UA configuration framework [CONFIG-FMWK], from adding other ways for a User Agent to discover its outbound-proxy-set.
UA配置了多个出站代理注册URI。这些URI通过任何正常机制配置到UA中，以在UA中配置代理地址和AOR。如果AOR是alice@example.com，出站代理集可能看起来像“sip:primary.example.com”和“sip:secondary.example.com”。请注意，出站代理集中的每个URI都可以解析为多个不同的物理主机。创建这些URI的管理域应确保这两个URI解析为不同的主机。这些URI根据正常的SIP处理规则进行处理，因此可以使用DNS SRV[RFC2782]等机制跨代理服务器场进行负载平衡。本文档中的方法不会阻止将来的扩展，例如SIP UA配置框架[CONFIG-FMWK]，为用户代理添加其他方法来发现其出站代理集。
The domain also needs to ensure that a request for the UA sent to Host1 or Host2 is then sent across the appropriate flow to the UA. The domain might choose to use the Path header approach (as described in the next section) to store this internal routing information on Host1 or Host2.
域还需要确保发送到主机1或主机2的UA请求随后通过适当的流发送到UA。域可能会选择使用路径头方法（如下一节所述）在主机1或主机2上存储此内部路由信息。
When a single server fails, all the UAs that have a flow through it will detect a flow failure and try to reconnect. This can cause large loads on the server. When large numbers of hosts reconnect nearly simultaneously, this is referred to as the avalanche restart problem, and is further discussed in Section 4.5. The multiple flows to many servers help reduce the load caused by the avalanche restart. If a UA has multiple flows, and one of the servers fails, the UA delays a recommended amount of time before trying to form a new
当一台服务器发生故障时，所有通过该服务器的UAs都将检测到流故障并尝试重新连接。这可能会在服务器上造成较大的负载。当大量主机几乎同时重新连接时，这称为雪崩重启问题，将在第4.5节中进一步讨论。到多个服务器的多个流有助于减少雪崩重启造成的负载。如果UA有多个流，并且其中一个服务器出现故障，UA将在尝试形成新的流之前延迟建议的时间量
connection to replace the flow to the server that failed. By spreading out the time used for all the UAs to reconnect to a server, the load on the server farm is reduced.
用于替换到失败服务器的流的连接。通过分散所有UAs重新连接到服务器所用的时间，服务器场上的负载减少了。
Scalability is achieved by using DNS SRV [RFC2782] to load-balance the primary connection across a set of machines that can service the primary connection, and also using DNS SRV to load-balance across a separate set of machines that can service the secondary connection. The deployment here requires that DNS is configured with one entry that resolves to all the primary hosts and another entry that resolves to all the secondary hosts. While this introduces additional DNS configuration, the approach works and requires no additional SIP extensions to [RFC3263].
可伸缩性是通过使用DNS SRV[RFC2782]在一组可以为主连接提供服务的机器之间对主连接进行负载平衡，以及使用DNS SRV在一组可以为辅助连接提供服务的机器之间进行负载平衡来实现的。此处的部署要求DNS配置一个解析到所有主主机的条目和另一个解析到所有辅助主机的条目。虽然这引入了额外的DNS配置，但该方法可以工作，并且不需要对[RFC3263]进行额外的SIP扩展。
Another motivation for maintaining multiple flows between the UA and its registrar is related to multihomed UAs. Such UAs can benefit from multiple connections from different interfaces to protect against the failure of an individual access link.
在UA与其注册机构之间维持多个流的另一个动机与多宿UAs有关。这种UAs可以从来自不同接口的多个连接中获益，以防止单个接入链路出现故障。
Some SIP deployments use edge proxies such that the UA sends the REGISTER to an edge proxy that then forwards the REGISTER to the registrar. There could be a NAT or firewall between the UA and the edge proxy.
一些SIP部署使用边缘代理，使得UA将寄存器发送给边缘代理，然后边缘代理将寄存器转发给注册器。UA和边缘代理之间可能存在NAT或防火墙。
+---------+
|Registrar|
|Proxy |
+---------+
/ \
/ \
/ \
+-----+ +-----+
|Edge1| |Edge2|
+-----+ +-----+
\ /
\ /
----------------------------NAT/FW
\ /
\ /
+------+
|User |
|Agent |
+------+
+---------+
|Registrar|
|Proxy |
+---------+
/ \
/ \
/ \
+-----+ +-----+
|Edge1| |Edge2|
+-----+ +-----+
\ /
\ /
----------------------------NAT/FW
\ /
\ /
+------+
|User |
|Agent |
+------+
The edge proxy includes a Path header [RFC3327] so that when the proxy/registrar later forwards a request to this UA, the request is routed through the edge proxy.
边缘代理包括路径头[RFC3327]，因此当代理/注册器稍后将请求转发到此UA时，请求通过边缘代理路由。
These systems can use effectively the same mechanism as described in the previous sections but need to use the Path header. When the edge proxy receives a registration, it needs to create an identifier value that is unique to this flow (and not a subsequent flow with the same addresses) and put this identifier in the Path header URI. This identifier has two purposes. First, it allows the edge proxy to map future requests back to the correct flow. Second, because the identifier will only be returned if the user authenticates with the registrar successfully, it allows the edge proxy to indirectly check the user's authentication information via the registrar. The identifier is placed in the user portion of a loose route in the Path header. If the registration succeeds, the edge proxy needs to map future requests (that are routed to the identifier value from the Path header) to the associated flow.
这些系统可以有效地使用前面章节中描述的相同机制，但需要使用路径头。当边缘代理收到注册时，它需要创建此流（而不是具有相同地址的后续流）唯一的标识符值，并将此标识符放入路径头URI中。此标识符有两个用途。首先，它允许边缘代理将未来的请求映射回正确的流。第二，由于只有当用户成功与注册器进行身份验证时，才会返回标识符，因此它允许边缘代理通过注册器间接检查用户的身份验证信息。标识符放置在路径头中松散路由的用户部分。如果注册成功，边缘代理需要将未来的请求（从路径头路由到标识符值）映射到关联流。
The term edge proxy is often used to refer to deployments where the edge proxy is in the same administrative domain as the registrar. However, in this specification we use the term to refer to any proxy between the UA and the registrar. For example, the edge proxy may be inside an enterprise that requires its use, and the registrar could be from a service provider with no relationship to the enterprise. Regardless of whether they are in the same administrative domain, this specification requires that registrars and edge proxies support the Path header mechanism in [RFC3327].
术语边缘代理通常用于指边缘代理与注册器位于同一管理域中的部署。然而，在本规范中，我们使用该术语来指UA和注册机构之间的任何代理。例如，边缘代理可能位于需要使用它的企业内部，而注册者可能来自与企业没有关系的服务提供商。无论它们是否在同一管理域中，本规范要求注册器和边缘代理支持[RFC3327]中的路径头机制。
This document describes two keep-alive mechanisms: a CRLF keep-alive and a STUN keep-alive. Each of these mechanisms uses a client-to-server "ping" keep-alive and a corresponding server-to-client "pong" message. This ping-pong sequence allows the client, and optionally the server, to tell if its flow is still active and useful for SIP traffic. The server responds to pings by sending pongs. If the client does not receive a pong in response to its ping (allowing for retransmission for STUN as described in Section 4.4.2), it declares the flow dead and opens a new flow in its place.
本文档描述了两种保持活动的机制：CRLF保持活动和STUN保持活动。这些机制中的每一个都使用一个客户端到服务器的“ping”保持活动状态和一个对应的服务器到客户端的“pong”消息。此乒乓序列允许客户端和服务器（可选）判断其流是否仍然处于活动状态，是否对SIP流量有用。服务器通过发送乒乓球来响应ping。如果客户端没有收到响应其ping的pong（如第4.4.2节所述，允许对STUN进行重新传输），则会声明流已停止，并在其位置打开一个新流。
This document also suggests timer values for these client keep-alive mechanisms. These timer values were chosen to keep most NAT and firewall bindings open, to detect unresponsive servers within 2 minutes, and to mitigate against the avalanche restart problem. However, the client may choose different timer values to suit its needs, for example to optimize battery life. In some environments,
本文档还建议这些客户端保持活动机制的计时器值。选择这些计时器值是为了保持大多数NAT和防火墙绑定打开，在2分钟内检测无响应的服务器，并缓解雪崩重启问题。然而，客户端可以选择不同的定时器值以满足其需要，例如优化电池寿命。在某些环境中，
the server can also keep track of the time since a ping was received over a flow to guess the likelihood that the flow is still useful for delivering SIP messages.
服务器还可以跟踪自通过流接收到ping以来的时间，以猜测该流是否仍然有助于传递SIP消息。
When the UA detects that a flow has failed or that the flow definition has changed, the UA needs to re-register and will use the back-off mechanism described in Section 4.5 to provide congestion relief when a large number of agents simultaneously reboot.
当UA检测到流失败或流定义已更改时，UA需要重新注册，并将使用第4.5节中描述的退避机制，以在大量代理同时重新启动时提供拥塞缓解。
A keep-alive mechanism needs to keep NAT bindings refreshed; for connections, it also needs to detect failure of a connection; and for connectionless transports, it needs to detect flow failures including changes to the NAT public mapping. For connection-oriented transports such as TCP [RFC0793] and SCTP [RFC4960], this specification describes a keep-alive approach based on sending CRLFs. For connectionless transport, such as UDP [RFC0768], this specification describes using STUN [RFC5389] over the same flow as the SIP traffic to perform the keep-alive.
keep-alive机制需要刷新NAT绑定；对于连接，它还需要检测连接故障；对于无连接传输，它需要检测流故障，包括对NAT公共映射的更改。对于TCP[RFC0793]和SCTP[RFC4960]等面向连接的传输，本规范描述了一种基于发送CRLF的保持活动的方法。对于无连接传输，如UDP[RFC0768]，本规范描述了在与SIP通信相同的流上使用STUN[RFC5389]来执行保持活动。
UAs and Proxies are also free to use native transport keep-alives; however, the application may not be able to set these timers on a per-connection basis, and the server certainly cannot make any assumption about what values are used. Use of native transport keep-alives is outside the scope of this document.
UAs和代理也可以自由使用本地传输保持活动；但是，应用程序可能无法在每个连接的基础上设置这些计时器，服务器当然无法对使用的值做出任何假设。本机传输保持有效性的使用不在本文档的范围内。
This approach can only be used with connection-oriented transports such as TCP or SCTP. The client periodically sends a double-CRLF (the "ping") then waits to receive a single CRLF (the "pong"). If the client does not receive a "pong" within an appropriate amount of time, it considers the flow failed.
这种方法只能用于面向连接的传输，如TCP或SCTP。客户端定期发送一个双CRLF（“ping”），然后等待接收一个CRLF（“pong”）。如果客户端在适当的时间内没有收到“pong”，则认为流失败。
Note: Sending a CRLF over a connection-oriented transport is backwards compatible (because of requirements in Section 7.5 of [RFC3261]), but only implementations which support this specification will respond to a "ping" with a "pong".
注：通过面向连接的传输发送CRLF是向后兼容的（因为[RFC3261]第7.5节中有要求），但只有支持本规范的实现才会对“ping”和“pong”做出响应。
This approach can only be used for connection-less transports, such as UDP.
这种方法只能用于无连接的传输，如UDP。
For connection-less transports, a flow definition could change because a NAT device in the network path reboots and the resulting public IP address or port mapping for the UA changes. To detect this, STUN requests are sent over the same flow that is being used
对于无连接传输，流定义可能会更改，因为网络路径中的NAT设备会重新启动，并且UA的公共IP地址或端口映射也会更改。要检测到这一点，通过正在使用的相同流发送STUN请求
for the SIP traffic. The proxy or registrar acts as a limited Session Traversal Utilities for NAT (STUN) [RFC5389] server on the SIP signaling port.
对于SIP流量。代理或注册器充当SIP信令端口上NAT（STUN）[RFC5389]服务器的有限会话遍历实用程序。
Note: The STUN mechanism is very robust and allows the detection of a changed IP address and port. Many other options were considered, but the SIP Working Group selected the STUN-based approach. Approaches using SIP requests were abandoned because many believed that good performance and full backwards compatibility using this method were mutually exclusive.
注意：STUN机制非常健壮，允许检测更改的IP地址和端口。考虑了许多其他选项，但SIP工作组选择了基于STUN的方法。使用SIP请求的方法被放弃，因为许多人认为使用这种方法的良好性能和完全向后兼容性是互斥的。
Each UA MUST have an Instance Identifier Uniform Resource Name (URN) [RFC2141] that uniquely identifies the device. Usage of a URN provides a persistent and unique name for the UA instance. It also provides an easy way to guarantee uniqueness within the AOR. This URN MUST be persistent across power cycles of the device. The instance ID MUST NOT change as the device moves from one network to another.
每个UA必须具有唯一标识设备的实例标识符统一资源名（URN）[RFC2141]。URN的使用为UA实例提供了一个持久且唯一的名称。它还提供了一种简单的方法来保证AOR中的唯一性。此URN必须在设备的整个电源周期内保持不变。当设备从一个网络移动到另一个网络时，实例ID不得更改。
A UA SHOULD create a Universally Unique Identifier (UUID) URN [RFC4122] as its instance-id. The UUID URN allows for non-centralized computation of a URN based on time, unique names (such as a MAC address), or a random number generator.
UA应创建一个通用唯一标识符（UUID）URN[RFC4122]作为其实例id。UUID URN允许基于时间、唯一名称（如MAC地址）或随机数生成器对URN进行非集中计算。
Note: A device like a "soft phone", when first installed, can generate a UUID [RFC4122] and then save this in persistent storage for all future use. For a device such as a "hard phone", which will only ever have a single SIP UA present, the UUID can include the MAC address and be generated at any time because it is guaranteed that no other UUID is being generated at the same time on that physical device. This means the value of the time component of the UUID can be arbitrarily selected to be any time less than the time when the device was manufactured. A time of 0 (as shown in the example in Section 3.2) is perfectly legal as long as the device knows no other UUIDs were generated at this time on this device.
注意：像“软电话”这样的设备，在第一次安装时，可以生成UUID[RFC4122]，然后将其保存在永久性存储器中以供将来使用。对于诸如“硬电话”之类的设备，其将仅存在单个SIP UA，UUID可以包括MAC地址，并且可以在任何时候生成，因为可以保证在该物理设备上不会同时生成其他UUID。这意味着UUID的时间分量的值可以任意选择为小于设备制造时的任何时间。时间为0（如第3.2节中的示例所示）是完全合法的，只要设备知道此时没有在此设备上生成其他UUID。
If a URN scheme other than UUID is used, the UA MUST only use URNs for which an RFC (from the IETF stream) defines how the specific URN needs to be constructed and used in the "+sip.instance" Contact header field parameter for outbound behavior.
如果使用UUID以外的URN方案，UA必须仅使用RFC（来自IETF流）定义如何构造特定URN并在“+sip.instance”联系人标头字段参数中用于出站行为的URN。
To convey its instance-id in both requests and responses, the UA includes a "sip.instance" media feature tag as a UA characteristic [RFC3840]. This media feature tag is encoded in the Contact header field as the "+sip.instance" Contact header field parameter. One case where a UA could prefer to omit the "sip.instance" media feature tag is when it is making an anonymous request or some other privacy concern requires that the UA not reveal its identity.
为了在请求和响应中传递其实例id，UA包括“sip.instance”媒体特性标签作为UA特性[RFC3840]。此媒体功能标签在联系人标头字段中编码为“+sip.instance”联系人标头字段参数。UA可能更愿意省略“sip.instance”媒体功能标签的一种情况是，当UA发出匿名请求或其他隐私问题时，UA不需要透露其身份。
Note: [RFC3840] defines equality rules for callee capabilities parameters, and according to that specification, the "sip.instance" media feature tag will be compared by case-sensitive string comparison. This means that the URN will be encapsulated by angle brackets ("<" and ">") when it is placed within the quoted string value of the "+sip.instance" Contact header field parameter. The case-sensitive matching rules apply only to the generic usages defined in the callee capabilities [RFC3840] and the caller preferences [RFC3841] specifications. When the instance ID is used in this specification, it is "extracted" from the value in the "sip.instance" media feature tag. Thus, equality comparisons are performed using the rules for URN equality that are specific to the scheme in the URN. If the element performing the comparisons does not understand the URN scheme, it performs the comparisons using the lexical equality rules defined in [RFC2141]. Lexical equality could result in two URNs being considered unequal when they are actually equal. In this specific usage of URNs, the only element that provides the URN is the SIP UA instance identified by that URN. As a result, the UA instance has to provide lexically equivalent URNs in each registration it generates. This is likely to be normal behavior in any case; clients are not likely to modify the value of the instance ID so that it remains functionally equivalent to (yet lexicographically different from) previous registrations.
注意：[RFC3840]为被调用方功能参数定义相等规则，根据该规范，“sip.instance”媒体功能标签将通过区分大小写的字符串比较进行比较。这意味着，当URN放在“+sip.instance”联系人标头字段参数的带引号的字符串值内时，它将被尖括号（“<”和“>”）封装。区分大小写的匹配规则仅适用于被调用方功能[RFC3840]和调用方首选项[RFC3841]规范中定义的通用用法。在本规范中使用实例ID时，它是从“sip.instance”媒体功能标签中的值中“提取”出来的。因此，使用特定于URN中方案的URN相等规则执行相等比较。如果执行比较的元素不理解URN方案，则使用[RFC2141]中定义的词法相等规则执行比较。词法相等可能导致两个URN在实际相等时被视为不相等。在URN的这种特定用法中，提供URN的唯一元素是由该URN标识的SIP UA实例。因此，UA实例必须在其生成的每个注册中提供词汇等效的URN。这在任何情况下都可能是正常行为；客户端不太可能修改实例ID的值，从而使其在功能上与以前的注册相同（但在词典编纂上有所不同）。
At configuration time, UAs obtain one or more SIP URIs representing the default outbound-proxy-set. This specification assumes the set is determined via any of a number of configuration mechanisms, and future specifications can define additional mechanisms such as using DNS to discover this set. How the UA is configured is outside the scope of this specification. However, a UA MUST support sets with at least two outbound proxy URIs and SHOULD support sets with up to four URIs.
在配置时，UAs获取一个或多个代表默认出站代理集的SIPURI。本规范假设该集合是通过许多配置机制中的任何一种来确定的，未来的规范可以定义其他机制，例如使用DNS来发现该集合。UA的配置方式不在本规范的范围内。但是，UA必须支持至少具有两个出站代理URI的集，并且应支持最多具有四个URI的集。
For each outbound proxy URI in the set, the User Agent Client (UAC) SHOULD send a REGISTER request using this URI as the default outbound proxy. (Alternatively, the UA could limit the number of flows formed to conserve battery power, for example). If the set has more than one URI, the UAC MUST send a REGISTER request to at least two of the default outbound proxies from the set. UAs that support this specification MUST include the outbound option tag in a Supported header field in a REGISTER request. Each of these REGISTER requests will use a unique Call-ID. Forming the route set for the request is outside the scope of this document, but typically results in sending the REGISTER such that the topmost Route header field contains a loose route to the outbound proxy URI.
对于集合中的每个出站代理URI，用户代理客户端（UAC）应使用此URI作为默认出站代理发送注册请求。（或者，UA可以限制形成的流量数量，以节省电池电量，例如）。如果集合具有多个URI，UAC必须向集合中至少两个默认出站代理发送注册请求。支持此规范的UAs必须在注册请求中的受支持标头字段中包含出站选项标记。这些注册请求中的每一个都将使用一个唯一的Call-ID。为请求生成路由集超出了本文档的范围，但通常会导致发送注册，以便最顶端的路由头字段包含到出站代理URI的松散路由。
REGISTER requests, other than those described in Section 4.2.3, MUST include an instance-id media feature tag as specified in Section 4.1.
除第4.2.3节所述之外，注册请求必须包括第4.1节规定的实例id媒体功能标签。
A UAC conforming to this specification MUST include in the Contact header field, a "reg-id" parameter that is distinct from other "reg-id" parameters used in other registrations that use the same "+sip.instance" Contact header field parameter and AOR. Each one of these registrations will form a new flow from the UA to the proxy. The sequence of reg-id values does not have to be sequential but MUST be exactly the same sequence of reg-id values each time the UA instance power cycles or reboots, so that the reg-id values will collide with the previously used reg-id values. This is so the registrar can replace the older registrations.
符合本规范的UAC必须在联系人标头字段中包含一个“reg id”参数，该参数不同于使用相同“+sip.instance”联系人标头字段参数和AOR的其他注册中使用的其他“reg id”参数。每个注册都将形成从UA到代理的新流程。reg id值的顺序不必是连续的，但每次UA实例通电或重新启动时必须是完全相同的reg id值顺序，以便reg id值与以前使用的reg id值发生冲突。这样，注册官就可以替换旧的注册。
Note: The UAC can situationally decide whether to request outbound behavior by including or omitting the "reg-id" Contact header field parameter. For example, imagine the outbound-proxy-set contains two proxies in different domains, EP1 and EP2. If an outbound-style registration succeeded for a flow through EP1, the UA might decide to include 'outbound' in its Require header field when registering with EP2, in order to ensure consistency. Similarly, if the registration through EP1 did not support outbound, the UA might not register with EP2 at all.
注意：UAC可以通过包括或省略“reg id”Contact header字段参数来决定是否请求出站行为。例如，假设出站代理集包含不同域中的两个代理：EP1和EP2。如果通过EP1的流的出站样式注册成功，UA可能会在向EP2注册时决定在其Require头字段中包含“outbound”，以确保一致性。类似地，如果通过EP1注册不支持出站，UA可能根本不向EP2注册。
The UAC MUST support the Path header [RFC3327] mechanism, and indicate its support by including the 'path' option-tag in a Supported header field value in its REGISTER requests. Other than optionally examining the Path vector in the response, this is all that is required of the UAC to support Path.
UAC必须支持路径头[RFC3327]机制，并通过在其寄存器请求中支持的头字段值中包含“Path”选项标记来表示其支持。除了可选地检查响应中的路径向量之外，这是UAC支持路径所需的全部内容。
The UAC examines successful registration responses for the presence of an outbound option-tag in a Require header field value. Presence of this option-tag indicates that the registrar is compliant with this specification, and that any edge proxies which needed to participate are also compliant. If the registrar did not support
UAC检查成功的注册响应是否在Require头字段值中存在出站选项标记。此选项标记的存在表明注册器符合此规范，并且需要参与的任何边缘代理也符合此规范。如果书记官长不支持
outbound, the UA has potentially registered an un-routable contact. It is the responsibility of the UA to remove any inappropriate Contacts.
出站时，UA可能已注册了无法路由的联系人。UA有责任删除任何不适当的联系人。
If outbound registration succeeded, as indicated by the presence of the outbound option-tag in the Require header field of a successful registration response, the UA begins sending keep-alives as described in Section 4.4.
如果出站注册成功，如成功注册响应的Require header字段中出现的出站选项标记所示，UA将开始发送keep alives，如第4.4节所述。
Note: The UA needs to honor 503 (Service Unavailable) responses to registrations as described in [RFC3261] and [RFC3263]. In particular, implementors should note that when receiving a 503 (Service Unavailable) response with a Retry-After header field, the UA is expected to wait the indicated amount of time and retry the registration. A Retry-After header field value of 0 is valid and indicates the UA is expected to retry the REGISTER request immediately. Implementations need to ensure that when retrying the REGISTER request, they revisit the DNS resolution results such that the UA can select an alternate host from the one chosen the previous time the URI was resolved.
注：UA需要遵守[RFC3261]和[RFC3263]中所述的503（服务不可用）注册响应。具体而言，实施者应注意，当接收到带有Retry After标头字段的503（服务不可用）响应时，UA应等待指示的时间量并重试注册。标头字段值0后重试有效，表示UA应立即重试注册请求。实现需要确保在重试注册请求时，重新访问DNS解析结果，以便UA可以从上次解析URI时选择的主机中选择备用主机。
If the registering UA receives a 439 (First Hop Lacks Outbound Support) response to a REGISTER request, it MAY re-attempt registration without using the outbound mechanism (subject to local policy at the client). If the client has one or more alternate outbound proxies available, it MAY re-attempt registration through such outbound proxies. See Section 11.6 for more information on the 439 response code.
如果注册UA接收到对注册请求的439（第一跳缺少出站支持）响应，则它可以在不使用出站机制的情况下重新尝试注册（取决于客户端的本地策略）。如果客户端有一个或多个备用出站代理可用，则可以通过此类出站代理重新尝试注册。有关439响应代码的更多信息，请参见第11.6节。
Registrations for refreshing a binding and for removing a binding use the same instance-id and reg-id values as the corresponding initial registration where the binding was added. Registrations that merely refresh an existing binding are sent over the same flow as the original registration where the binding was added.
用于刷新绑定和删除绑定的注册使用与添加绑定的相应初始注册相同的实例id和注册表id值。仅刷新现有绑定的注册将通过与添加绑定的原始注册相同的流发送。
If a re-registration is rejected with a recoverable error response, for example by a 503 (Service Unavailable) containing a Retry-After header, the UAC SHOULD NOT tear down the corresponding flow if the flow uses a connection-oriented transport such as TCP. As long as "pongs" are received in response to "pings", the flow SHOULD be kept active until a non-recoverable error response is received. This prevents unnecessary closing and opening of connections.
如果使用可恢复的错误响应拒绝重新注册，例如通过包含Retry After标头的503（服务不可用），则如果流使用面向连接的传输（如TCP），UAC不应中断相应的流。只要收到响应“ping”的“pong”，流就应该保持活动状态，直到收到不可恢复的错误响应。这样可以防止不必要的连接关闭和打开。
In an initial registration or re-registration, a UA MUST NOT include a "reg-id" header field parameter in the Contact header field if the registering UA is not the same instance as the UA referred to by the target Contact header field. (This practice is occasionally used to install forwarding policy into registrars.)
在初始注册或重新注册中，如果注册UA与目标联系人标头字段引用的UA不是同一实例，则UA不得在联系人标头字段中包含“reg id”标头字段参数。（这种做法偶尔用于将转发策略安装到注册器中。）
A UAC also MUST NOT include an instance-id feature tag or "reg-id" Contact header field parameter in a request to un-register all Contacts (a single Contact header field value with the value of "*").
UAC也不得在取消注册所有联系人的请求中包含实例id功能标记或“注册id”联系人标头字段参数（单个联系人标头字段值为“*”）。
When a UAC is about to send a request, it first performs normal processing to select the next hop URI. The UA can use a variety of techniques to compute the route set and accordingly the next hop URI. Discussion of these techniques is outside the scope of this document. UAs that support this specification SHOULD include the outbound option tag in a Supported header field in a request that is not a REGISTER request.
当UAC即将发送请求时，它首先执行正常处理以选择下一跳URI。UA可以使用各种技术来计算路由集以及相应的下一跳URI。对这些技术的讨论超出了本文档的范围。支持此规范的UAs应在非注册请求的请求中的受支持标头字段中包含出站选项标记。
The UAC performs normal DNS resolution on the next hop URI (as described in [RFC3263]) to find a protocol, IP address, and port. For protocols that don't use TLS, if the UAC has an existing flow to this IP address, and port with the correct protocol, then the UAC MUST use the existing connection. For TLS protocols, there MUST also be a match between the host production in the next hop and one of the URIs contained in the subjectAltName in the peer certificate. If the UAC cannot use one of the existing flows, then it SHOULD form a new flow by sending a datagram or opening a new connection to the next hop, as appropriate for the transport protocol.
UAC对下一跳URI（如[RFC3263]中所述）执行正常DNS解析，以查找协议、IP地址和端口。对于不使用TLS的协议，如果UAC具有到此IP地址的现有流，并且端口具有正确的协议，则UAC必须使用现有连接。对于TLS协议，下一跳中的主机生产与对等证书中subjectAltName中包含的一个URI之间也必须匹配。如果UAC不能使用现有流中的一个，那么它应该通过发送数据报或打开到下一跳的新连接来形成一个新的流，这对于传输协议来说是合适的。
Typically, a UAC using the procedures of this document and sending a dialog-forming request will want all subsequent requests in the dialog to arrive over the same flow. If the UAC is using a Globally Routable UA URI (GRUU) [RFC5627] that was instantiated using a Contact header field value that included an "ob" parameter, the UAC sends the request over the flow used for registration, and subsequent requests will arrive over that same flow. If the UAC is not using such a GRUU, then the UAC adds an "ob" parameter to its Contact header field value. This will cause all subsequent requests in the dialog to arrive over the flow instantiated by the dialog-forming request. This case is typical when the request is sent prior to registration, such as in the initial subscription dialog for the configuration framework [CONFIG-FMWK].
通常，UAC使用本文档中的过程并发送对话框形成请求时，希望对话框中的所有后续请求通过相同的流到达。如果UAC正在使用全局可路由UA URI（GRUU）[RFC5627]，该URI是使用包含“ob”参数的联系人标头字段值实例化的，UAC将通过用于注册的流发送请求，后续请求将通过该流到达。如果UAC没有使用这样的GRUU，则UAC会在其联系人标头字段值中添加一个“ob”参数。这将导致对话框中的所有后续请求通过对话框形成请求实例化的流到达。当在注册之前发送请求时，例如在配置框架[CONFIG-FMWK]的初始订阅对话框中，这种情况是典型的。
Note: If the UAC wants a UDP flow to work through NATs or firewalls, it still needs to put the 'rport' parameter [RFC3581] in its Via header field value, and send from the port it is prepared to receive on. More general information about NAT traversal in SIP is described in [NAT-SCEN].
注意：如果UAC希望UDP流通过NAT或防火墙工作，它仍然需要将“rport”参数[RFC3581]放入其Via标头字段值中，并从准备接收的端口发送。有关SIP中NAT遍历的更多一般信息，请参见[NAT-SCEN]。
Keep-alives are used for refreshing NAT/firewall bindings and detecting flow failure. Flows can fail for many reasons including the rebooting of NATs and the crashing of edge proxies.
Keep alives用于刷新NAT/防火墙绑定和检测流故障。流失败的原因有很多，包括重新启动NAT和边缘代理崩溃。
As described in Section 4.2, a UA that registers will begin sending keep-alives after an appropriate registration response. A UA that does not register (for example, a PSTN gateway behind a firewall) can also send keep-alives under certain circumstances.
如第4.2节所述，注册的UA将在适当的注册响应后开始发送keep alives。未注册的UA（例如，防火墙后的PSTN网关）在某些情况下也可以发送保持有效。
Under specific circumstances, a UAC might be allowed to send STUN keep-alives even if the procedures in Section 4.2 were not completed, provided that there is an explicit indication that the target first-hop SIP node supports STUN keep-alives. For example, this applies to a non-registering UA or to a case where the UA registration succeeded, but the response did not include the outbound option-tag in the Require header field.
在特定情况下，即使第4.2节中的程序未完成，UAC也可能被允许发送STUN保持有效，前提是有明确指示表明目标第一跳SIP节点支持STUN保持有效。例如，这适用于未注册UA或UA注册成功但响应未在Require header字段中包含outbound选项标记的情况。
Note: A UA can "always" send a double CRLF (a "ping") over connection-oriented transports as this is already allowed by Section 7.5 of [RFC3261]. However a UA that did not register using outbound registration cannot expect a CRLF in response (a "pong") unless the UA has an explicit indication that CRLF keep-alives are supported as described in this section. Likewise, a UA that did not successfully register with outbound procedures needs explicit indication that the target first-hop SIP node supports STUN keep-alives before it can send any STUN messages.
注：UA可以通过面向连接的传输“始终”发送双CRLF（“ping”），因为[RFC3261]第7.5节已经允许这样做。但是，未使用出站注册进行注册的UA不能期望CRLF响应（“pong”），除非UA明确表示支持CRLF保持有效，如本节所述。同样，未成功注册出站过程的UA需要明确指示目标第一跳SIP节点支持STUN保持有效，然后才能发送任何STUN消息。
A configuration option indicating keep-alive support for a specific target is considered an explicit indication. If these conditions are satisfied, the UA sends its keep-alives according to the same guidelines as those used when UAs register; these guidelines are described below.
指示对特定目标保持活动支持的配置选项被视为明确指示。如果这些条件得到满足，UA将根据与UAs注册时使用的相同指南发送其保存证明；这些准则如下所述。
The UA needs to detect when a specific flow fails. The UA actively tries to detect failure by periodically sending keep-alive messages using one of the techniques described in Sections 4.4.1 or 4.4.2. If a flow with a registration has failed, the UA follows the procedures in Section 4.2 to form a new flow to replace the failed one.
UA需要检测特定流何时失败。UA通过使用第4.4.1节或第4.4.2节所述的技术之一定期发送保持活动的消息，主动尝试检测故障。如果注册流程失败，UA将按照第4.2节中的程序形成新流程以替换失败流程。
When a successful registration response contains the Flow-Timer header field, the value of this header field is the number of seconds the server is prepared to wait without seeing keep-alives before it could consider the corresponding flow dead. Note that the server would wait for an amount of time larger than the Flow-Timer in order to have a grace period to account for transport delay. The UA MUST send keep-alives at least as often as this number of seconds. If the UA uses the server-recommended keep-alive frequency it SHOULD send its keep-alives so that the interval between each keep-alive is randomly distributed between 80% and 100% of the server-provided time. For example, if the server suggests 120 seconds, the UA would send each keep-alive with a different frequency between 95 and 120 seconds.
当一个成功的注册响应包含流计时器头字段时，这个头字段的值是服务器准备等待的秒数，而不必看到保留的别号，在它可以考虑相应的流死之前。请注意，服务器将等待比流计时器更长的时间，以便有一个宽限期来说明传输延迟。UA必须发送保持有效信息的频率至少与此秒数相同。如果UA使用服务器建议的保持活动频率，则应发送其保持活动，以便每次保持活动之间的间隔随机分布在服务器提供时间的80%到100%之间。例如，如果服务器建议120秒，UA将以95到120秒之间的不同频率发送每个keep alive。
If no Flow-Timer header field was present in a register response for this flow, the UA can send keep-alives at its discretion. The sections below provide RECOMMENDED default values for these keep-alives.
如果此流的寄存器响应中不存在流计时器标头字段，UA可自行决定发送保持有效。以下各节提供了这些keep alives的推荐默认值。
The client needs to perform normal [RFC3263] SIP DNS resolution on the URI from the outbound-proxy-set to pick a transport. Once a transport is selected, the UA selects the keep-alive approach that is recommended for that transport.
客户端需要对出站代理集中的URI执行正常[RFC3263]SIP DNS解析以选择传输。一旦选择了一个传输，UA将选择建议用于该传输的保持活动方式。
Section 4.4.1 describes a keep-alive mechanism for connection-oriented transports such as TCP or SCTP. Section 4.4.2 describes a keep-alive mechanism for connection-less transports such as UDP. Support for other transports such as DCCP [RFC4340] is for further study.
第4.4.1节描述了面向连接的传输（如TCP或SCTP）的保持活动机制。第4.4.2节描述了用于UDP等无连接传输的保持活动机制。对其他传输（如DCCP[RFC4340]）的支持有待进一步研究。
This approach MUST only be used with connection oriented transports such as TCP or SCTP; it MUST NOT be used with connection-less transports such as UDP.
这种方法只能用于面向连接的传输，如TCP或SCTP；它不能与UDP等无连接传输一起使用。
A User Agent that forms flows checks if the configured URI to which the UA is connecting resolves to a connection-oriented transport (e.g., TCP and TLS over TCP).
形成流的用户代理检查UA所连接的配置URI是否解析为面向连接的传输（例如TCP和TCP上的TLS）。
For this mechanism, the client "ping" is a double-CRLF sequence, and the server "pong" is a single CRLF, as defined in the ABNF below:
对于这种机制，客户端“ping”是一个双CRLF序列，而服务器“pong”是一个单CRLF，如以下ABNF中所定义：
CRLF = CR LF
double-CRLF = CR LF CR LF
CR = %x0D
LF = %x0A
CRLF = CR LF
double-CRLF = CR LF CR LF
CR = %x0D
LF = %x0A
The "ping" and "pong" need to be sent between SIP messages and cannot be sent in the middle of a SIP message. If sending over TLS, the CRLFs are sent inside the TLS protected channel. If sending over a SigComp [RFC3320] compressed data stream, the CRLF keep-alives are sent inside the compressed stream. The double CRLF is considered a single SigComp message. The specific mechanism for representing these characters is an implementation-specific matter to be handled by the SigComp compressor at the sending end.
“ping”和“乓”需要在SIP消息之间发送，不能在SIP消息的中间发送。如果通过TLS发送，CRLF将在受TLS保护的通道内发送。如果通过SigComp[RFC3320]压缩数据流发送，则CRLF保持有效性将在压缩流内发送。双CRLF被视为单个SigComp消息。表示这些字符的特定机制是一个特定于实现的问题，由发送端的SigComp压缩器处理。
If a pong is not received within 10 seconds after sending a ping (or immediately after processing any incoming message being received when that 10 seconds expires), then the client MUST treat the flow as failed. Clients MUST support this CRLF keep-alive.
如果在发送ping后的10秒内没有收到pong（或者在10秒内处理接收到的任何传入消息后立即收到pong），则客户端必须将流视为失败。客户端必须支持此CRLF保持活动状态。
Note: This value of 10-second timeout was selected to be long enough that it allows plenty of time for a server to send a response even if the server is temporarily busy with an administrative activity. At the same time, it was selected to be small enough that a UA registered to two redundant servers with unremarkable hardware uptime could still easily provide very high levels of overall reliability. Although some Internet protocols are designed for round-trip times over 10 seconds, SIP for real-time communications is not really usable in these type of environments as users often abandon calls before waiting much more than a few seconds.
注意：选择此10秒超时值的时间足够长，即使服务器暂时忙于管理活动，服务器也有足够的时间发送响应。同时，它被选择为足够小，以至于注册到两个冗余服务器的UA（硬件正常运行时间不显著）仍然可以轻松提供非常高的总体可靠性。尽管一些Internet协议设计的往返时间超过10秒，但用于实时通信的SIP在此类环境中并不真正可用，因为用户通常会在等待几秒钟以上之前放弃呼叫。
When a Flow-Timer header field is not provided in the most recent success registration response, the proper selection of keep-alive frequency is primarily a trade-off between battery usage and availability. The UA MUST select a random number between a fixed or configurable upper bound and a lower bound, where the lower bound is 20% less then the upper bound. The fixed upper bound or the default configurable upper bound SHOULD be 120 seconds (95 seconds for the lower bound) where battery power is not a concern and 840 seconds (672 seconds for the lower bound) where battery power is a concern. The random number will be different for each keep-alive "ping".
如果在最近的成功注册响应中未提供Flow Timer header字段，则保持活动频率的正确选择主要是电池使用和可用性之间的权衡。UA必须在固定或可配置的上限和下限之间选择一个随机数，其中下限比上限小20%。固定上限或默认可配置上限应为120秒（下限为95秒），电池电量不受影响；840秒（下限为672秒），电池电量受影响。对于每个保持活动状态的“ping”，随机数将不同。
Note on selection of time values: the 120-second upper bound was chosen based on the idea that for a good user experience, failures normally will be detected in this amount of time and a new connection will be set up. The 14-minute upper bound for battery-powered devices was selected based on NATs with TCP timeouts as low as 15 minutes. Operators that wish to change the relationship between load on servers and the expected time that a user might not receive inbound communications will probably adjust this time. The 95-second lower bound was chosen so that the jitter introduced will result in a relatively even load on the servers after 30 minutes.
关于时间值选择的注意事项：选择120秒上限是基于这样一种想法，即为了获得良好的用户体验，通常会在这段时间内检测到故障，并将建立新的连接。电池供电设备的14分钟上限是基于NAT选择的，TCP超时低至15分钟。希望更改服务器负载与用户可能无法接收入站通信的预期时间之间关系的操作员可能会调整此时间。选择95秒下限是为了使引入的抖动在30分钟后在服务器上产生相对均匀的负载。
This approach MUST only be used with connection-less transports, such as UDP; it MUST NOT be used for connection-oriented transports such as TCP and SCTP.
这种方法只能用于无连接的传输，如UDP；它不能用于面向连接的传输，如TCP和SCTP。
A User Agent that forms flows checks if the configured URI to which the UA is connecting resolves to use the UDP transport. The UA can periodically perform keep-alive checks by sending STUN [RFC5389] Binding Requests over the flow as described in Section 8. Clients MUST support STUN-based keep-alives.
形成流的用户代理将检查UA所连接的配置URI是否解析为使用UDP传输。UA可以通过第8节所述的流程发送STUN[RFC5389]绑定请求，定期执行保持活动状态检查。客户必须支持基于STUN的keep alives。
When a Flow-Timer header field is not included in a successful registration response, the time between each keep-alive request SHOULD be a random number between 24 and 29 seconds.
如果成功注册响应中未包含Flow Timer标头字段，则每个保持活动请求之间的时间应为24到29秒之间的随机数。
Note on selection of time values: the upper bound of 29 seconds was selected, as many NATs have UDP timeouts as low as 30 seconds. The 24-second lower bound was selected so that after 10 minutes the jitter introduced by different timers will make the keep-alive requests unsynchronized to evenly spread the load on the servers. Note that the short NAT timeouts with UDP have a negative impact on battery life.
关于时间值选择的注意事项：选择了29秒的上限，因为许多NAT的UDP超时低至30秒。选择24秒下限是为了在10分钟后，不同计时器引入的抖动将使保持活动的请求不同步，以便在服务器上均匀分布负载。请注意，UDP短NAT超时会对电池寿命产生负面影响。
If a STUN Binding Error Response is received, or if no Binding Response is received after 7 retransmissions (16 times the STUN "RTO" timer -- where RTO is an estimate of round-trip time), the UA considers the flow failed. If the XOR-MAPPED-ADDRESS in the STUN Binding Response changes, the UA MUST treat this event as a failure on the flow.
如果收到STUN绑定错误响应，或者如果在7次重新传输后（STUN“RTO”计时器的16倍——其中RTO是往返时间的估计值）没有收到绑定响应，UA认为流失败。如果STUN绑定响应中的XOR映射地址发生更改，UA必须将此事件视为流上的故障。
When a flow used for registration (through a particular URI in the outbound-proxy-set) fails, the UA needs to form a new flow to replace the old flow and replace any registrations that were previously sent over this flow. Each new registration MUST have the same reg-id value as the registration it replaces. This is done in much the same way as forming a brand new flow as described in Section 4.2; however, if there is a failure in forming this flow, the UA needs to wait a certain amount of time before retrying to form a flow to this particular next hop.
当用于注册的流（通过出站代理集中的特定URI）失败时，UA需要形成一个新流来替换旧流，并替换先前通过该流发送的任何注册。每个新注册必须具有与其替换的注册相同的注册id值。这与形成第4.2节所述的全新流程的方式大致相同；然而，如果形成该流失败，则UA需要等待一定的时间，然后再尝试形成到该特定下一跳的流。
The amount of time to wait depends if the previous attempt at establishing a flow was successful. For the purposes of this section, a flow is considered successful if outbound registration succeeded, and if keep-alives are in use on this flow, at least one subsequent keep-alive response was received.
等待的时间量取决于上次建立流的尝试是否成功。就本节而言，如果出站注册成功，则流被视为成功，并且如果此流上使用了keep alives，则至少会收到一个后续keep alive响应。
The number of seconds to wait is computed in the following way. If all of the flows to every URI in the outbound proxy set have failed, the base-time is set to a lower value (with a default of 30 seconds); otherwise, in the case where at least one of the flows has not failed, the base-time is set to a higher value (with a default of 90 seconds). The upper-bound wait time (W) is computed by taking two raised to the power of the number of consecutive registration failures for that URI, and multiplying this by the base-time, up to a configurable maximum time (with a default of 1800 seconds).
等待的秒数按以下方式计算。如果到出站代理集中每个URI的所有流都失败，则基本时间设置为较低的值（默认值为30秒）；否则，在至少一个流没有失败的情况下，基本时间设置为更高的值（默认值为90秒）。上界等待时间（W）的计算方法是：取2乘以该URI的连续注册失败次数的幂，并将其乘以基本时间，直至可配置的最长时间（默认值为1800秒）。
W = min (max-time, (base-time * (2 ^ consecutive-failures)))
W = min (max-time, (base-time * (2 ^ consecutive-failures)))
These times MAY be configurable in the UA. The three times are:
这些时间可以在UA中配置。这三次是：
o max-time with a default of 1800 seconds
o 最大时间，默认值为1800秒
o base-time (if all failed) with a default of 30 seconds
o 基本时间（如果全部失败），默认值为30秒
o base-time (if all have not failed) with a default of 90 seconds
o 基本时间（如果所有操作都未失败），默认值为90秒
For example, if the base-time is 30 seconds, and there were three failures, then the upper-bound wait time is min(1800, 30*(2^3)) or 240 seconds. The actual amount of time the UA waits before retrying registration (the retry delay time) is computed by selecting a uniform random time between 50 and 100% of the upper-bound wait time. The UA MUST wait for at least the value of the retry delay time before trying another registration to form a new flow for that URI (a 503 response to an earlier failed registration attempt with a Retry-After header field value may cause the UA to wait longer).
例如，如果基本时间为30秒，并且有三次故障，则上限等待时间为分钟（1800，30*（2^3））或240秒。UA在重试注册之前等待的实际时间量（重试延迟时间）通过选择上限等待时间的50%到100%之间的统一随机时间来计算。UA必须至少等待重试延迟时间的值，然后再尝试另一次注册，以形成该URI的新流（503对先前失败的注册尝试的响应，带有retry After标头字段值，可能会导致UA等待更长时间）。
To be explicitly clear on the boundary conditions: when the UA boots, it immediately tries to register. If this fails and no registration on other flows succeed, the first retry happens somewhere between 30 and 60 seconds after the failure of the first registration request. If the number of consecutive-failures is large enough that the maximum of 1800 seconds is reached, the UA will keep trying indefinitely with a random time of 15 to 30 minutes between each attempt.
要明确边界条件：当UA启动时，它会立即尝试注册。如果此操作失败，并且在其他流上没有成功注册，则第一次重试将在第一次注册请求失败后的30到60秒之间发生。如果连续故障的数量足够大，达到最大1800秒，UA将无限期地继续尝试，每次尝试之间的随机时间为15到30分钟。
When an edge proxy receives a registration request with a "reg-id" header field parameter in the Contact header field, it needs to determine if it (the edge proxy) will have to be visited for any subsequent requests sent to the User Agent identified in the Contact header field, or not. If the edge proxy is the first hop, as
当边缘代理接收到联系人标头字段中带有“reg id”标头字段参数的注册请求时，它需要确定是否需要访问它（边缘代理）以获取发送给联系人标头字段中标识的用户代理的任何后续请求。如果边缘代理是第一个跃点，如
indicated by the Via header field, it MUST insert its URI in a Path header field value as described in [RFC3327]. If it is not the first hop, it might still decide to add itself to the Path header based on local policy. In addition, if the edge proxy is the first SIP node after the UAC, the edge proxy either MUST store a "flow token" (containing information about the flow from the previous hop) in its Path URI or reject the request. The flow token MUST be an identifier that is unique to this network flow. The flow token MAY be placed in the userpart of the URI. In addition, the first node MUST include an "ob" URI parameter in its Path header field value. If the edge proxy is not the first SIP node after the UAC it MUST NOT place an "ob" URI parameter in a Path header field value. The edge proxy can determine if it is the first hop by examining the Via header field.
由Via头字段指示，它必须在路径头字段值中插入其URI，如[RFC3327]中所述。如果不是第一个跃点，它可能仍然决定根据本地策略将自己添加到路径头。此外，如果边缘代理是UAC之后的第一个SIP节点，则边缘代理必须在其路径URI中存储“流令牌”（包含来自上一跳的流的信息），或者拒绝请求。流令牌必须是此网络流唯一的标识符。流令牌可以放在URI的用户部分。此外，第一个节点必须在其路径头字段值中包含“ob”URI参数。如果边缘代理不是UAC之后的第一个SIP节点，则它不得在路径头字段值中放置“ob”URI参数。边缘代理可以通过检查Via头字段来确定它是否是第一个跃点。
A trivial but impractical way to satisfy the flow token requirement in Section 5.1 involves storing a mapping between an incrementing counter and the connection information; however, this would require the edge proxy to keep an infeasible amount of state. It is unclear when this state could be removed, and the approach would have problems if the proxy crashed and lost the value of the counter. A stateless example is provided below. A proxy can use any algorithm it wants as long as the flow token is unique to a flow, the flow can be recovered from the token, and the token cannot be modified by attackers.
满足第5.1节中的流令牌要求的一种简单但不切实际的方法涉及存储递增计数器和连接信息之间的映射；但是，这需要边缘代理保持不可行的状态量。目前尚不清楚何时可以删除此状态，如果代理崩溃并丢失计数器的值，该方法将出现问题。下面提供了一个无状态示例。代理可以使用它想要的任何算法，只要流令牌对流是唯一的，流可以从令牌中恢复，并且攻击者不能修改令牌。
Example Algorithm: When the proxy boots, it selects a 20-octet crypto random key called K that only the edge proxy knows. A byte array, called S, is formed that contains the following information about the flow the request was received on: an enumeration indicating the protocol, the local IP address and port, the remote IP address and port. The HMAC of S is computed using the key K and the HMAC-SHA1-80 algorithm, as defined in [RFC2104]. The concatenation of the HMAC and S are base64 encoded, as defined in [RFC4648], and used as the flow identifier. When using IPv4 addresses, this will result in a 32-octet identifier.
示例算法：当代理启动时，它选择一个称为K的20个八位组的加密随机密钥，该密钥只有边缘代理知道。形成一个名为S的字节数组，其中包含有关接收请求的流的以下信息：指示协议的枚举、本地IP地址和端口、远程IP地址和端口。根据[RFC2104]中的定义，使用密钥K和HMAC-SHA1-80算法计算S的HMAC。HMAC和S的串联采用base64编码，如[RFC4648]中所定义，并用作流标识符。使用IPv4地址时，这将产生32个八位字节的标识符。
When an edge proxy receives a request, it applies normal routing procedures with the following additions. If the edge proxy receives a request where the edge proxy is the host in the topmost Route header field value, and the Route header field value contains a flow token, the proxy follows the procedures of this section. Otherwise the edge proxy skips the procedures in this section, removes itself from the Route header field, and continues processing the request.
当边缘代理收到请求时，它将应用常规路由过程，并添加以下内容。如果边缘代理收到一个请求，其中边缘代理是最顶端的路由头字段值中的主机，并且路由头字段值包含流令牌，则代理将遵循本节的过程。否则，边缘代理将跳过本节中的过程，从Route header字段中删除自身，并继续处理请求。
The proxy decodes the flow token and compares the flow in the flow token with the source of the request to determine if this is an "incoming" or "outgoing" request.
代理对流令牌进行解码，并将流令牌中的流与请求源进行比较，以确定这是“传入”还是“传出”请求。
If the flow in the flow token identified by the topmost Route header field value matches the source IP address and port of the request, the request is an "outgoing" request; otherwise, it is an "incoming" request.
如果由最顶层路由头字段值标识的流令牌中的流与请求的源IP地址和端口匹配，则该请求为“传出”请求；否则，它是一个“传入”请求。
If the Route header value contains an "ob" URI parameter, the Route header was probably copied from the Path header in a registration. If the Route header value contains an "ob" URI parameter, and the request is a new dialog-forming request, the proxy needs to adjust the route set to ensure that subsequent requests in the dialog can be delivered over a valid flow to the UA instance identified by the flow token.
如果路由标头值包含“ob”URI参数，则路由标头可能是从注册中的路径标头复制的。如果Route header值包含一个“ob”URI参数，并且请求是一个新的对话框形成请求，则代理需要调整路由集，以确保对话框中的后续请求可以通过有效流传递到由流令牌标识的UA实例。
Note: A simple approach to satisfy this requirement is for the proxy to add a Record-Route header field value that contains the flow-token, by copying the URI in the Route header minus the "ob" parameter.
注意：满足此要求的一种简单方法是代理通过复制路由头中的URI减去“ob”参数来添加包含流令牌的记录路由头字段值。
Next, whether the Route header field contained an "ob" URI parameter or not, the proxy removes the Route header field value and forwards the request over the 'logical flow' identified by the flow token, that is known to deliver data to the specific target UA instance. If the flow token has been tampered with, the proxy SHOULD send a 403 (Forbidden) response. If the flow no longer exists, the proxy SHOULD send a 430 (Flow Failed) response to the request.
接下来，无论路由头字段是否包含“ob”URI参数，代理都会删除路由头字段值，并通过流令牌标识的“逻辑流”转发请求，该流令牌已知用于向特定目标UA实例传递数据。如果流令牌已被篡改，则代理应发送403（禁止）响应。如果流不再存在，代理应该向请求发送430（流失败）响应。
Proxies that used the example algorithm described in Section 5.2 to form a flow token follow the procedures below to determine the correct flow. To decode the flow token, take the flow identifier in the user portion of the URI and base64 decode it, then verify the HMAC is correct by recomputing the HMAC and checking that it matches. If the HMAC is not correct, the request has been tampered with.
使用第5.2节中描述的示例算法来形成流令牌的代理遵循以下步骤来确定正确的流。要解码流令牌，请获取URI的用户部分中的流标识符并对其进行base64解码，然后通过重新计算HMAC并检查其匹配来验证HMAC是否正确。如果HMAC不正确，则表示请求已被篡改。
For mid-dialog requests to work with outbound UAs, the requests need to be forwarded over some valid flow to the appropriate UA instance. If the edge proxy receives an outgoing dialog-forming request, the edge proxy can use the presence of the "ob" URI parameter in the UAC's Contact URI (or topmost Route header field) to determine if the edge proxy needs to assist in mid-dialog request routing.
对于与出站UAs一起工作的mid对话请求，需要通过一些有效流将请求转发到相应的UA实例。如果边缘代理接收到传出的对话形成请求，则边缘代理可以使用UAC的联系人URI（或最顶端的路由头字段）中是否存在“ob”URI参数来确定边缘代理是否需要协助中间对话请求路由。
Implementation note: Specific procedures at the edge proxy to ensure that mid-dialog requests are routed over an existing flow are not part of this specification. However, an approach such as having the edge proxy add a Record-Route header with a flow token is one way to ensure that mid-dialog requests are routed over the correct flow.
实施说明：在边缘代理上确保mid对话请求通过现有流路由的特定过程不属于本规范的一部分。但是，让边缘代理添加带有流令牌的记录路由头等方法是确保mid对话请求通过正确流路由的一种方法。
All edge proxies compliant with this specification MUST implement support for STUN NAT keep-alives on their SIP UDP ports as described in Section 8.
符合本规范的所有边缘代理必须在其SIP UDP端口上实现对STUN NAT保持有效性的支持，如第8节所述。
When a server receives a double CRLF sequence between SIP messages on a connection-oriented transport such as TCP or SCTP, it MUST immediately respond with a single CRLF over the same connection.
当服务器在面向连接的传输（如TCP或SCTP）上收到SIP消息之间的双CRLF序列时，它必须立即通过同一连接使用单个CRLF进行响应。
The last proxy to forward a successful registration response to a UA MAY include a Flow-Timer header field if the response contains the outbound option-tag in a Require header field value in the response. The reason a proxy would send a Flow-Timer is if it wishes to detect flow failures proactively and take appropriate action (e.g., log alarms, provide alternative treatment if incoming requests for the UA are received, etc.). The server MUST wait for an amount of time larger than the Flow-Timer in order to have a grace period to account for transport delay.
如果响应中的Require header字段值中包含出站选项标记，则将成功注册响应转发给UA的最后一个代理可以包括Flow Timer header字段。代理发送流量计时器的原因是，如果它希望主动检测流量故障并采取适当的措施（例如，记录警报，在收到UA的传入请求时提供替代处理，等等）。服务器必须等待比流计时器长的时间，以便有一个宽限期来说明传输延迟。
This specification updates the definition of a binding in [RFC3261], Section 10 and [RFC3327], Section 5.3.
本规范更新了[RFC3261]第10节和[RFC3327]第5.3节中的绑定定义。
Registrars that implement this specification MUST support the Path header mechanism [RFC3327].
实现此规范的注册器必须支持路径头机制[RFC3327]。
When receiving a REGISTER request, the registrar MUST check from its Via header field if the registrar is the first hop or not. If the registrar is not the first hop, it MUST examine the Path header of the request. If the Path header field is missing or it exists but the first URI does not have an "ob" URI parameter, then outbound processing MUST NOT be applied to the registration. In this case, the following processing applies: if the REGISTER request contains the reg-id and the outbound option tag in a Supported header field, then the registrar MUST respond to the REGISTER request with a 439 (First Hop Lacks Outbound Support) response; otherwise, the registrar MUST ignore the "reg-id" parameter of the Contact header. See Section 11.6 for more information on the 439 response code.
当接收到注册请求时，注册器必须从其Via头字段检查注册器是否为第一跳。如果注册器不是第一个跃点，它必须检查请求的路径头。如果路径头字段丢失或存在，但第一个URI没有“ob”URI参数，则出站处理不得应用于注册。在这种情况下，应用以下处理：如果注册请求在受支持的报头字段中包含注册id和出站选项标记，则注册器必须使用439（第一跳缺少出站支持）响应来响应注册请求；否则，注册者必须忽略联系人标题的“reg id”参数。有关439响应代码的更多信息，请参见第11.6节。
A Contact header field value with an instance-id media feature tag but no "reg-id" header field parameter is valid (this combination will result in the creation of a GRUU, as described in the GRUU specification [RFC5627]), but one with a reg-id but no instance-id is not valid. If the registrar processes a Contact header field value with a reg-id but no instance-id, it simply ignores the reg-id parameter.
带有实例id媒体功能标签但没有“reg id”头字段参数的联系人头字段值是有效的（这种组合将导致创建GRUU，如GRUU规范[RFC5627]所述），但带有reg id但没有实例id的联系人头字段值无效。如果注册器处理带有reg id但没有实例id的联系人标头字段值，它将忽略reg id参数。
A registration containing a "reg-id" header field parameter and a non-zero expiration is used to register a single UA instance over a single flow, and can also de-register any Contact header fields with zero expiration. Therefore, if the Contact header field contains more than one header field value with a non-zero expiration and any of these header field values contain a "reg-id" Contact header field parameter, the entire registration SHOULD be rejected with a 400 (Bad Request) response. The justification for recommending rejection versus making it mandatory is that the receiver is allowed by [RFC3261] to squelch (not respond to) excessively malformed or malicious messages.
包含“reg id”标头字段参数和非零过期的注册用于在单个流上注册单个UA实例，还可以注销任何具有零过期的联系人标头字段。因此，如果联系人标头字段包含多个标头字段值，且过期时间不为零，并且这些标头字段值中的任何一个包含“reg id”联系人标头字段参数，则整个注册应以400（错误请求）响应被拒绝。建议拒绝而非强制拒绝的理由是[RFC3261]允许接收方压制（不响应）格式过度错误或恶意的消息。
If the Contact header did not contain a "reg-id" Contact header field parameter or if that parameter was ignored (as described above), the registrar MUST NOT include the outbound option-tag in the Require header field of its response.
如果联系人标头不包含“reg id”联系人标头字段参数，或者如果忽略了该参数（如上所述），则注册员不得在其响应的Require header字段中包含出站选项标记。
The registrar MUST be prepared to receive, simultaneously for the same AOR, some registrations that use instance-id and reg-id and some registrations that do not. The registrar MAY be configured with local policy to reject any registrations that do not include the instance-id and reg-id, or with Path header field values that do not contain the "ob" URI parameter. If the Contact header field does not contain a "+sip.instance" Contact header field parameter, the registrar processes the request using the Contact binding rules in [RFC3261].
对于同一AOR，注册器必须准备好同时接收使用实例id和注册id的一些注册和不使用实例id和注册id的一些注册。注册器可以配置本地策略以拒绝不包括实例id和注册id的任何注册，或者配置不包含“ob”URI参数的路径头字段值。如果联系人标头字段不包含“+sip.instance”联系人标头字段参数，则注册官使用[RFC3261]中的联系人绑定规则处理请求。
When a "+sip.instance" Contact header field parameter and a "reg-id" Contact header field parameter are present in a Contact header field of a REGISTER request (after the Contact header validation as described above), the corresponding binding is between an AOR and the combination of the instance-id (from the "+sip.instance" Contact header parameter) and the value of "reg-id" Contact header field parameter parameter. The registrar MUST store in the binding the Contact URI, all the Contact header field parameters, and any Path header field values. (Even though the Contact URI is not used for binding comparisons, it is still needed by the authoritative proxy to form the target set.) Provided that the UAC had included an outbound option-tag (defined in Section 11.4) in a Supported header field
当“+sip.instance”联系人标头字段参数和“reg id”联系人标头字段参数出现在注册请求的联系人标头字段中时（在如上所述的联系人标头验证之后），相应的绑定在AOR和实例id的组合（来自“+sip.instance”）之间联系人标题参数）和“reg id”联系人标题字段参数的值。注册器必须在绑定中存储联系人URI、所有联系人头字段参数和任何路径头字段值。（即使联系人URI未用于绑定比较，但权威代理仍需要它来形成目标集。）前提是UAC已在支持的标头字段中包含出站选项标记（在第11.4节中定义）
value in the REGISTER request, the registrar MUST include the outbound option-tag in a Require header field value in its response to that REGISTER request.
值，则注册器必须在其对该注册请求的响应中的Require header字段值中包含出站选项标记。
If the UAC has a direct flow with the registrar, the registrar MUST store enough information to uniquely identify the network flow over which the request arrived. For common operating systems with TCP, this would typically be just the handle to the file descriptor where the handle would become invalid if the TCP session was closed. For common operating systems with UDP this would typically be the file descriptor for the local socket that received the request, the local interface, and the IP address and port number of the remote side that sent the request. The registrar MAY store this information by adding itself to the Path header field with an appropriate flow token.
如果UAC与注册器有直接流，则注册器必须存储足够的信息，以唯一标识请求到达的网络流。对于使用TCP的常见操作系统，这通常只是文件描述符的句柄，如果TCP会话关闭，该句柄将变得无效。对于使用UDP的常见操作系统，这通常是接收请求的本地套接字的文件描述符、本地接口以及发送请求的远程端的IP地址和端口号。注册器可以通过使用适当的流令牌将自身添加到路径头字段来存储该信息。
If the registrar receives a re-registration for a specific combination of AOR, and instance-id and reg-id values, the registrar MUST update any information that uniquely identifies the network flow over which the request arrived if that information has changed, and SHOULD update the time the binding was last updated.
如果注册器接收到AOR、实例id和注册id值的特定组合的重新注册，则注册器必须更新唯一标识请求到达的网络流的任何信息（如果该信息已更改），并应更新绑定上次更新的时间。
To be compliant with this specification, registrars that can receive SIP requests directly from a UAC without intervening edge proxies MUST implement the same keep-alive mechanisms as edge proxies (Section 5.4). Registrars with a direct flow with a UA MAY include a Flow-Timer header in a 2xx class registration response that includes the outbound option-tag in the Require header.
为了符合本规范，可以直接从UAC接收SIP请求而不干预边缘代理的注册商必须实现与边缘代理相同的保持活动机制（第5.4节）。具有UA的直接流的注册器可以在2xx类注册响应中包括流定时器报头，该响应在Require报头中包括出站选项标签。
When a proxy uses the location service to look up a registration binding and then proxies a request to a particular contact, it selects a contact to use normally, with a few additional rules:
当代理使用位置服务查找注册绑定，然后将请求代理给特定联系人时，它会选择一个正常使用的联系人，并附加一些规则：
o The proxy MUST NOT populate the target set with more than one contact with the same AOR and instance-id at a time.
o 代理一次不得使用多个具有相同AOR和实例id的联系人填充目标集。
o If a request for a particular AOR and instance-id fails with a 430 (Flow Failed) response, the proxy SHOULD replace the failed branch with another target (if one is available) with the same AOR and instance-id, but a different reg-id.
o 如果对特定AOR和实例id的请求因430（流失败）响应而失败，则代理应使用具有相同AOR和实例id但不同reg-id的另一个目标（如果有）替换失败的分支。
o If the proxy receives a final response from a branch other than a 408 (Request Timeout) or a 430 (Flow Failed) response, the proxy MUST NOT forward the same request to another target representing the same AOR and instance-id. The targeted instance has already provided its response.
o 如果代理从408（请求超时）或430（流失败）响应以外的分支接收到最终响应，则代理不得将相同的请求转发到表示相同AOR和实例id的另一个目标。目标实例已提供其响应。
The proxy uses the next-hop target of the message and the value of any stored Path header field vector in the registration binding to decide how to forward and populate the Route header in the request. If the proxy is co-located with the registrar and stored information about the flow to the UA that created the binding, then the proxy MUST send the request over the same 'logical flow' saved with the binding, since that flow is known to deliver data to the specific target UA instance's network flow that was saved with the binding.
代理使用消息的下一跳目标和注册绑定中存储的任何路径头字段向量的值来决定如何转发和填充请求中的路由头。如果代理与注册器位于同一位置，并将有关流的信息存储到创建绑定的UA，则代理必须通过与绑定保存的相同“逻辑流”发送请求，因为已知该流将数据传送到与绑定保存的特定目标UA实例的网络流。
Implementation note: Typically this means that for TCP, the request is sent on the same TCP socket that received the REGISTER request. For UDP, the request is sent from the same local IP address and port over which the registration was received, to the same IP address and port from which the REGISTER was received.
实现说明：通常这意味着对于TCP，请求在接收注册请求的同一TCP套接字上发送。对于UDP，请求从接收注册的同一本地IP地址和端口发送到接收注册的同一IP地址和端口。
If a proxy or registrar receives information from the network that indicates that no future messages will be delivered on a specific flow, then the proxy MUST invalidate all the bindings in the target set that use that flow (regardless of AOR). Examples of this are a TCP socket closing or receiving a destination unreachable ICMP error on a UDP flow. Similarly, if a proxy closes a file descriptor, it MUST invalidate all the bindings in the target set with flows that use that file descriptor.
如果代理或注册器从网络接收到的信息表明未来不会在特定流上传递任何消息，则代理必须使目标集中使用该流的所有绑定无效（无论AOR如何）。例如，TCP套接字关闭或接收UDP流上的目标不可访问ICMP错误。类似地，如果代理关闭文件描述符，它必须使目标集中使用该文件描述符的流的所有绑定无效。
This section describes changes to the SIP transport layer that allow SIP and STUN [RFC5389] Binding Requests to be mixed over the same flow. This constitutes a new STUN usage. The STUN messages are used to verify that connectivity is still available over a UDP flow, and to provide periodic keep-alives. These STUN keep-alives are always sent to the next SIP hop. STUN messages are not delivered end-to-end.
本节描述对SIP传输层的更改，这些更改允许在同一流上混合SIP和STUN[RFC5389]绑定请求。这构成了一种新的眩晕用法。STUN消息用于验证UDP流上的连接是否仍然可用，并提供定期保持有效性。这些晕眩信号总是发送到下一个SIP-hop。晕眩消息不是端到端传递的。
The only STUN messages required by this usage are Binding Requests, Binding Responses, and Binding Error Responses. The UAC sends Binding Requests over the same UDP flow that is used for sending SIP messages. These Binding Requests do not require any STUN attributes. The corresponding Binding Responses do not require any STUN attributes except the XOR-MAPPED-ADDRESS. The UAS, proxy, or registrar responds to a valid Binding Request with a Binding Response that MUST include the XOR-MAPPED-ADDRESS attribute.
此用法所需的唯一STUN消息是绑定请求、绑定响应和绑定错误响应。UAC通过用于发送SIP消息的相同UDP流发送绑定请求。这些绑定请求不需要任何STUN属性。相应的绑定响应不需要任何STUN属性，XOR映射地址除外。UAS、代理或注册器使用绑定响应来响应有效的绑定请求，绑定响应必须包括XOR-MAPPED-ADDRESS属性。
If a server compliant to this section receives SIP requests on a given interface and UDP port, it MUST also provide a limited version of a STUN server on the same interface and UDP port.
如果符合本节要求的服务器在给定接口和UDP端口上接收SIP请求，则还必须在同一接口和UDP端口上提供STUN服务器的有限版本。
Note: It is easy to distinguish STUN and SIP packets sent over UDP, because the first octet of a STUN Binding method has a value of 0 or 1, while the first octet of a SIP message is never a 0 or 1.
注意：很容易区分通过UDP发送的STUN和SIP数据包，因为STUN绑定方法的第一个八位组的值为0或1，而SIP消息的第一个八位组永远不是0或1。
Because sending and receiving binary STUN data on the same ports used for SIP is a significant and non-backwards compatible change to RFC 3261, this section requires a number of checks before sending STUN messages to a SIP node. If a SIP node sends STUN requests (for example, due to incorrect configuration) despite these warnings, the node could be blacklisted for UDP traffic.
由于在用于SIP的相同端口上发送和接收二进制STUN数据是对RFC 3261的重大且不向后兼容的更改，因此本节要求在向SIP节点发送STUN消息之前进行大量检查。如果SIP节点不顾这些警告发送STUN请求（例如，由于配置不正确），该节点可能会因UDP流量而被列入黑名单。
A SIP node MUST NOT send STUN requests over a flow unless it has an explicit indication that the target next-hop SIP server claims to support this specification. UACs MUST NOT use an ambiguous configuration option such as "Work through NATs?" or "Do keep-alives?" to imply next-hop STUN support. A UAC MAY use the presence of an "ob" URI parameter in the Path header in a registration response as an indication that its first edge proxy supports the keep-alives defined in this document.
SIP节点不得通过流发送STUN请求，除非其明确指示目标下一跳SIP服务器声称支持此规范。UACs不得使用模棱两可的配置选项，如“通过NAT工作”或“保持生命？”来暗示下一跳眩晕支持。UAC可以使用注册响应中路径报头中存在的“ob”URI参数作为其第一边缘代理支持本文档中定义的保持有效性的指示。
Note: Typically, a SIP node first sends a SIP request and waits to receive a 2xx class response over a flow to a new target destination, before sending any STUN messages. When scheduled for the next NAT refresh, the SIP node sends a STUN request to the target.
注意：通常，SIP节点在发送任何STUN消息之前，首先发送SIP请求并等待通过流接收2xx类响应到新的目标目的地。当计划下一次NAT刷新时，SIP节点向目标发送STUN请求。
Once a flow is established, failure of a STUN request (including its retransmissions) is considered a failure of the underlying flow. For SIP over UDP flows, if the XOR-MAPPED-ADDRESS returned over the flow changes, this indicates that the underlying connectivity has changed, and is considered a flow failure.
一旦建立了流，STUN请求的失败（包括其重新传输）被视为基础流的失败。对于UDP上的SIP流，如果通过流返回的XOR-MAPPED-ADDRESS发生更改，则表示基础连接已更改，并被视为流故障。
The SIP keep-alive STUN usage requires no backwards compatibility with [RFC3489].
SIP keep alive STUN的使用不需要与[RFC3489]向后兼容。
When STUN is used together with SigComp [RFC3320] compressed SIP messages over the same flow, the STUN messages are simply sent uncompressed, "outside" of SigComp. This is supported by multiplexing STUN messages with SigComp messages by checking the two topmost bits of the message. These bits are always one for SigComp, or zero for STUN.
当STUN与SigComp[RFC3320]压缩SIP消息在同一个流上一起使用时，STUN消息只需在SigComp的“外部”以未压缩的方式发送。通过检查消息的两个最高位，将STUN消息与SigComp消息进行多路复用来支持这一点。这些位对于SigComp总是一位，对于STUN总是零位。
Note: All SigComp messages contain a prefix (the five most significant bits of the first byte are set to one) that does not occur in UTF-8 [RFC3629] encoded text messages, so for
注意：所有SigComp消息都包含一个前缀（第一个字节的五个最高有效位被设置为一），该前缀不会出现在UTF-8[RFC3629]编码的文本消息中，因此
applications that use this encoding (or ASCII encoding) it is possible to multiplex uncompressed application messages and SigComp messages on the same UDP port. The most significant two bits of every STUN Binding method are both zeroes. This, combined with the magic cookie, aids in differentiating STUN packets from other protocols when STUN is multiplexed with other protocols on the same port.
使用此编码（或ASCII编码）的应用程序可以在同一UDP端口上多路传输未压缩的应用程序消息和SigComp消息。每个STUN绑定方法的最高有效位都是零。当STUN与同一端口上的其他协议多路复用时，这与magic cookie相结合，有助于区分STUN数据包与其他协议。
Below is an example message flow illustrating most of the concepts discussed in this specification. In many cases, Via, Content-Length, and Max-Forwards headers are omitted for brevity and readability.
下面是一个示例消息流，说明了本规范中讨论的大多数概念。在许多情况下，为了简洁易读，省略了Via、Content-Length和Max-Forwards头。
In these examples, "EP1" and "EP2" are outbound proxies, and "Proxy" is the authoritativeProxy.
在这些示例中，“EP1”和“EP2”是出站代理，“Proxy”是authoritiveproxy。
The section is subdivided into independent calls flows; however, they are structured in sequential order of a hypothetical sequence of call flows.
该部分细分为独立的调用流；然而，它们是按照假设的调用流序列的顺序构造的。
If the outbound proxy set is already configured on Bob's UA, then this subsection can be skipped. Otherwise, if the outbound proxy set is learned through the configuration package, Bob's UA sends a SUBSCRIBE request for the UA profile configuration package [CONFIG-FMWK]. This request is a poll (Expires is zero). After receiving the NOTIFY request, Bob's UA fetches the external configuration using HTTPS (not shown) and obtains a configuration file that contains the outbound-proxy-set "sip:ep1.example.com;lr" and "sip:ep2.example.com;lr".
如果已在Bob的UA上配置出站代理集，则可以跳过此小节。否则，如果通过配置包学习出站代理集，Bob的UA将发送UA配置文件配置包[CONFIG-FMWK]的订阅请求。此请求是一个轮询（Expires为零）。在收到通知请求后，Bob的UA使用HTTPS（未显示）获取外部配置，并获取一个配置文件，其中包含出站代理集“sip:ep1.example.com；lr”和“sip:ep2.example.com；lr”。
[----example.com domain-------------------------]
Bob EP1 EP2 Proxy Config
| | | | |
1)|SUBSCRIBE->| | | |
2)| |---SUBSCRIBE Event: ua-profile ->|
3)| |<--200 OK -----------------------|
4)|<--200 OK--| | | |
5)| |<--NOTIFY------------------------|
6)|<--NOTIFY--| | | |
7)|---200 OK->| | | |
8)| |---200 OK ---------------------->|
| | | | |
[----example.com domain-------------------------]
Bob EP1 EP2 Proxy Config
| | | | |
1)|SUBSCRIBE->| | | |
2)| |---SUBSCRIBE Event: ua-profile ->|
3)| |<--200 OK -----------------------|
4)|<--200 OK--| | | |
5)| |<--NOTIFY------------------------|
6)|<--NOTIFY--| | | |
7)|---200 OK->| | | |
8)| |---200 OK ---------------------->|
| | | | |
In this example, the DNS server happens to be configured so that sip: example.com resolves to EP1 and EP2.
在本例中，DNS服务器的配置恰好使sip:example.com解析为EP1和EP2。
Example Message #1:
示例消息#1：
SUBSCRIBE sip:00000000-0000-1000-8000-AABBCCDDEEFF@example.com
SIP/2.0
Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnlsdkdj2
Max-Forwards: 70
From: <anonymous@example.com>;tag=23324
To: <sip:00000000-0000-1000-8000-AABBCCDDEEFF@example.com>
Call-ID: nSz1TWN54x7My0GvpEBj
CSeq: 1 SUBSCRIBE
Event: ua-profile ;profile-type=device
;vendor="example.com";model="uPhone";version="1.1"
Expires: 0
Supported: path, outbound
Accept: message/external-body, application/x-uPhone-config
Contact: <sip:192.0.2.2;transport=tcp;ob>
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0
SUBSCRIBE sip:00000000-0000-1000-8000-AABBCCDDEEFF@example.com
SIP/2.0
Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnlsdkdj2
Max-Forwards: 70
From: <anonymous@example.com>;tag=23324
To: <sip:00000000-0000-1000-8000-AABBCCDDEEFF@example.com>
Call-ID: nSz1TWN54x7My0GvpEBj
CSeq: 1 SUBSCRIBE
Event: ua-profile ;profile-type=device
;vendor="example.com";model="uPhone";version="1.1"
Expires: 0
Supported: path, outbound
Accept: message/external-body, application/x-uPhone-config
Contact: <sip:192.0.2.2;transport=tcp;ob>
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0
In message #2, EP1 adds the following Record-Route header:
在消息#2中，EP1添加了以下记录路由头：
Record-Route:
<sip:GopIKSsn0oGLPXRdV9BAXpT3coNuiGKV@ep1.example.com;lr>
Record-Route:
<sip:GopIKSsn0oGLPXRdV9BAXpT3coNuiGKV@ep1.example.com;lr>
In message #5, the configuration server sends a NOTIFY with an external URL for Bob to fetch his configuration. The NOTIFY has a Subscription-State header that ends the subscription.
在消息#5中，配置服务器发送带有外部URL的通知，以便Bob获取其配置。NOTIFY具有结束订阅的订阅状态标头。
Message #5
信息#5
NOTIFY sip:192.0.2.2;transport=tcp;ob SIP/2.0
Via: SIP/2.0/TCP 192.0.2.5;branch=z9hG4bKn81dd2
Max-Forwards: 70
To: <anonymous@example.com>;tag=23324
From: <sip:00000000-0000-1000-8000-AABBCCDDEEFF@example.com>;tag=0983
Call-ID: nSz1TWN54x7My0GvpEBj
CSeq: 1 NOTIFY
Route: <sip:GopIKSsn0oGLPXRdV9BAXpT3coNuiGKV@ep1.example.com;lr>
Subscription-State: terminated;reason=timeout
Event: ua-profile
Content-Type: message/external-body; access-type="URL"
;expiration="Thu, 01 Jan 2009 09:00:00 UTC"
;URL="http://example.com/uPhone.cfg"
;size=9999;hash=10AB568E91245681AC1B
Content-Length: 0
NOTIFY sip:192.0.2.2;transport=tcp;ob SIP/2.0
Via: SIP/2.0/TCP 192.0.2.5;branch=z9hG4bKn81dd2
Max-Forwards: 70
To: <anonymous@example.com>;tag=23324
From: <sip:00000000-0000-1000-8000-AABBCCDDEEFF@example.com>;tag=0983
Call-ID: nSz1TWN54x7My0GvpEBj
CSeq: 1 NOTIFY
Route: <sip:GopIKSsn0oGLPXRdV9BAXpT3coNuiGKV@ep1.example.com;lr>
Subscription-State: terminated;reason=timeout
Event: ua-profile
Content-Type: message/external-body; access-type="URL"
;expiration="Thu, 01 Jan 2009 09:00:00 UTC"
;URL="http://example.com/uPhone.cfg"
;size=9999;hash=10AB568E91245681AC1B
Content-Length: 0
EP1 receives this NOTIFY request, strips off the Route header, extracts the flow-token, calculates the correct flow, and forwards the request (message #6) over that flow to Bob.
EP1接收该通知请求，剥离路由头，提取流令牌，计算正确的流，并通过该流将请求（消息#6）转发给Bob。
Bob's UA fetches the configuration file and learns the outbound proxy set.
Bob的UA获取配置文件并学习出站代理集。
Now that Bob's UA is configured with the outbound-proxy-set whether through configuration or using the configuration framework procedures of the previous section, Bob's UA sends REGISTER requests through each edge proxy in the set. Once the registrations succeed, Bob's UA begins sending CRLF keep-alives about every 2 minutes.
现在，无论是通过配置还是使用上一节的配置框架过程，Bob的UA都配置了出站代理集，Bob的UA通过该集中的每个边缘代理发送注册请求。一旦注册成功，Bob的UA大约每2分钟发送一次CRLF keep alives。
Bob EP1 EP2 Proxy Alice
| | | | |
9)|-REGISTER->| | | |
10)| |---REGISTER-->| |
11)| |<----200 OK---| |
12)|<-200 OK---| | | |
13)|----REGISTER---->| | |
14)| | |--REG-->| |
15)| | |<-200---| |
16)|<----200 OK------| | |
| | | | |
| about 120 seconds later... |
| | | | |
17)|--2CRLF--->| | | |
18)|<--CRLF----| | | |
19)|------2CRLF----->| | |
20)|<------CRLF------| | |
| | | | |
Bob EP1 EP2 Proxy Alice
| | | | |
9)|-REGISTER->| | | |
10)| |---REGISTER-->| |
11)| |<----200 OK---| |
12)|<-200 OK---| | | |
13)|----REGISTER---->| | |
14)| | |--REG-->| |
15)| | |<-200---| |
16)|<----200 OK------| | |
| | | | |
| about 120 seconds later... |
| | | | |
17)|--2CRLF--->| | | |
18)|<--CRLF----| | | |
19)|------2CRLF----->| | |
20)|<------CRLF------| | |
| | | | |
In message #9, Bob's UA sends its first registration through the first edge proxy in the outbound-proxy-set by including a loose route. The UA includes an instance-id and reg-id in its Contact header field value. Note the option-tags in the Supported header.
在消息#9中，Bob的UA通过包含松散路由的出站代理集中的第一个边缘代理发送其第一次注册。UA在其联系人标头字段值中包含实例id和注册id。请注意受支持标题中的选项标记。
Message #9
信息#9
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com>
Call-ID: 16CB75F21C70
CSeq: 1 REGISTER
Supported: path, outbound
Route: <sip:ep1.example.com;lr>
Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=1
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com>
Call-ID: 16CB75F21C70
CSeq: 1 REGISTER
Supported: path, outbound
Route: <sip:ep1.example.com;lr>
Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=1
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0
Message #10 is similar. EP1 removes the Route header field value, decrements Max-Forwards, and adds its Via header field value. Since EP1 is the first edge proxy, it adds a Path header with a flow token and includes the "ob" parameter.
信息#10类似。EP1删除路由头字段值，递减最大转发，并添加其Via头字段值。由于EP1是第一个边缘代理，它添加了一个带有流令牌的路径头，并包含“ob”参数。
Path: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob>
Path: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob>
Since the response to the REGISTER (message #11) contains the outbound option-tag in the Require header field, Bob's UA will know that the registrar used outbound binding rules. The response also contains the currently active Contacts, and the Path for the current registration.
由于对寄存器的响应（消息#11）包含Require header字段中的outbound选项标记，Bob的UA将知道注册器使用了outbound绑定规则。响应还包含当前活动的联系人以及当前注册的路径。
Message #11
信息#11
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.0.2.15;branch=z9hG4bKnuiqisi
Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnashds7
From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com>;tag=6AF99445E44A
Call-ID: 16CB75F21C70
CSeq: 1 REGISTER
Supported: path, outbound
Require: outbound
Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=1;expires=3600
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Path: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob>
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.0.2.15;branch=z9hG4bKnuiqisi
Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnashds7
From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com>;tag=6AF99445E44A
Call-ID: 16CB75F21C70
CSeq: 1 REGISTER
Supported: path, outbound
Require: outbound
Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=1;expires=3600
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Path: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob>
Content-Length: 0
The second registration through EP2 (message #13) is similar except that the Call-ID has changed, the reg-id is 2, and the Route header goes through EP2.
通过EP2的第二次注册（消息#13）类似，只是呼叫ID已更改，注册ID为2，路由头通过EP2。
Message #13
信息#13
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnqr9bym
Max-Forwards: 70
From: Bob <sip:bob@example.com>;tag=755285EABDE2
To: Bob <sip:bob@example.com>
Call-ID: E05133BD26DD
CSeq: 1 REGISTER
Supported: path, outbound
Route: <sip:ep2.example.com;lr>
Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=2
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnqr9bym
Max-Forwards: 70
From: Bob <sip:bob@example.com>;tag=755285EABDE2
To: Bob <sip:bob@example.com>
Call-ID: E05133BD26DD
CSeq: 1 REGISTER
Supported: path, outbound
Route: <sip:ep2.example.com;lr>
Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=2
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0
Likewise in message #14, EP2 adds a Path header with flow token and "ob" parameter.
同样，在消息#14中，EP2添加了一个带有流令牌和“ob”参数的路径头。
Path: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr;ob>
Path: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr;ob>
Message #16 tells Bob's UA that outbound registration was successful, and shows both Contacts. Note that only the Path corresponding to the current registration is returned.
消息#16告诉Bob的UA出站注册成功，并显示两个联系人。请注意，只返回与当前注册对应的路径。
Message #16
信息#16
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnqr9bym
From: Bob <sip:bob@example.com>;tag=755285EABDE2
To: Bob <sip:bob@example.com>;tag=49A9AD0B3F6A
Call-ID: E05133BD26DD
Supported: path, outbound
Require: outbound
CSeq: 1 REGISTER
Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=1;expires=3600
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=2;expires=3600
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Path: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr;ob>
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnqr9bym
From: Bob <sip:bob@example.com>;tag=755285EABDE2
To: Bob <sip:bob@example.com>;tag=49A9AD0B3F6A
Call-ID: E05133BD26DD
Supported: path, outbound
Require: outbound
CSeq: 1 REGISTER
Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=1;expires=3600
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=2;expires=3600
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Path: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr;ob>
Content-Length: 0
In this example, after registration, EP1 crashes and reboots. Before Bob's UA notices that its flow to EP1 is no longer responding, Alice calls Bob. Bob's authoritative proxy first tries the flow to EP1,
在本例中，注册后，EP1崩溃并重新启动。在Bob的UA注意到其到EP1的流不再响应之前，Alice打电话给Bob。Bob的权威代理首先尝试流向EP1，
but EP1 no longer has a flow to Bob, so it responds with a 430 (Flow Failed) response. The proxy removes the stale registration and tries the next binding for the same instance.
但是EP1不再有一个到Bob的流，所以它以430（流失败）响应进行响应。代理将删除过时的注册，并为同一实例尝试下一个绑定。
Bob EP1 EP2 Proxy Alice
| | | | |
| CRASH X | | |
| Reboot | | |
| | | | |
21)| | | |<-INVITE-|
22)| |<---INVITE----| |
23)| |----430------>| |
24)| | |<-INVITE| |
25)|<---INVITE-------| | |
26)|----200 OK------>| | |
27)| | |200 OK->| |
28)| | | |-200 OK->|
29)| | |<----------ACK----|
30)|<---ACK----------| | |
| | | | |
31)| | |<----------BYE----|
32)|<---BYE----------| | |
33)|----200 OK------>| | |
34)| | |--------200 OK--->|
| | | | |
Bob EP1 EP2 Proxy Alice
| | | | |
| CRASH X | | |
| Reboot | | |
| | | | |
21)| | | |<-INVITE-|
22)| |<---INVITE----| |
23)| |----430------>| |
24)| | |<-INVITE| |
25)|<---INVITE-------| | |
26)|----200 OK------>| | |
27)| | |200 OK->| |
28)| | | |-200 OK->|
29)| | |<----------ACK----|
30)|<---ACK----------| | |
| | | | |
31)| | |<----------BYE----|
32)|<---BYE----------| | |
33)|----200 OK------>| | |
34)| | |--------200 OK--->|
| | | | |
Message #21
信息#21
INVITE sip:bob@example.com SIP/2.0
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
INVITE sip:bob@example.com SIP/2.0
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Bob's proxy rewrites the Request-URI to the Contact URI used in Bob's registration, and places the path for one of the registrations towards Bob's UA instance into a Route header field. This Route goes through EP1.
Bob的代理将请求URI重写为Bob注册中使用的联系人URI，并将其中一个注册指向Bob的UA实例的路径放入Route header字段中。这条路线经过EP1。
Message #22
信息#22
INVITE sip:bob@192.0.2.2;transport=tcp SIP/2.0
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Route: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob>
INVITE sip:bob@192.0.2.2;transport=tcp SIP/2.0
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Route: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob>
Since EP1 just rebooted, it does not have the flow described in the flow token. It returns a 430 (Flow Failed) response.
由于EP1刚刚重新启动，它没有流令牌中描述的流。它返回一个430（流失败）响应。
Message #23
信息#23
SIP/2.0 430 Flow Failed
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
SIP/2.0 430 Flow Failed
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
The proxy deletes the binding for this path and tries to forward the INVITE again, this time with the path through EP2.
代理删除此路径的绑定并再次尝试转发邀请，这次是通过EP2的路径。
Message #24
信息#24
INVITE sip:bob@192.0.2.2;transport=tcp SIP/2.0
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Route: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr;ob>
INVITE sip:bob@192.0.2.2;transport=tcp SIP/2.0
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Route: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr;ob>
In message #25, EP2 needs to add a Record-Route header field value, so that any subsequent in-dialog messages from Alice's UA arrive at Bob's UA. EP2 can determine it needs to Record-Route since the request is a dialog-forming request and the Route header contained a flow token and an "ob" parameter. This Record-Route information is passed back to Alice's UA in the responses (messages #26, 27, and 28).
在消息#25中，EP2需要添加一个记录路由头字段值，以便来自Alice的UA的任何后续对话内消息到达Bob的UA。EP2可以确定它需要记录路由，因为该请求是一个形成对话框的请求，路由头包含一个流令牌和一个“ob”参数。该记录路由信息在响应（消息#26、27和28）中传递回Alice的UA。
Message #25
信息#25
INVITE sip:bob@192.0.2.2;transport=tcp SIP/2.0
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Record-Route:
<sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr>
INVITE sip:bob@192.0.2.2;transport=tcp SIP/2.0
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Record-Route:
<sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr>
Message #26
信息#26
SIP/2.0 200 OK
To: Bob <sip:bob@example.com>;tag=skduk2
From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Record-Route:
<sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr>
SIP/2.0 200 OK
To: Bob <sip:bob@example.com>;tag=skduk2
From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Record-Route:
<sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr>
At this point, both UAs have the correct route-set for the dialog. Any subsequent requests in this dialog will route correctly. For example, the ACK request in message #29 is sent from Alice's UA directly to EP2. The BYE request in message #31 uses the same route-set.
此时，两个UAs都为对话框设置了正确的路由。此对话框中的任何后续请求都将正确路由。例如，消息#29中的ACK请求直接从Alice的UA发送到EP2。消息#31中的BYE请求使用相同的路由集。
Message #29
信息#29
ACK sip:bob@192.0.2.2;transport=tcp SIP/2.0
To: Bob <sip:bob@example.com>;tag=skduk2
From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 ACK
Route: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr>
ACK sip:bob@192.0.2.2;transport=tcp SIP/2.0
To: Bob <sip:bob@example.com>;tag=skduk2
From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 ACK
Route: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr>
Message #31
信息#31
BYE sip:bob@192.0.2.2;transport=tcp SIP/2.0
To: Bob <sip:bob@example.com>;tag=skduk2
From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 2 BYE
Route: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr>
BYE sip:bob@192.0.2.2;transport=tcp SIP/2.0
To: Bob <sip:bob@example.com>;tag=skduk2
From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 2 BYE
Route: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr>
Somewhat later, Bob's UA sends keep-alives to both its edge proxies, but it discovers that the flow with EP1 failed. Bob's UA re-registers through EP1 using the same reg-id and Call-ID it previously used.
稍后，Bob的UA将keep alives发送到它的两个边缘代理，但它发现使用EP1的流失败。Bob的UA使用之前使用的相同注册id和呼叫id通过EP1重新注册。
Bob EP1 EP2 Proxy Alice
| | | | |
35)|------2CRLF----->| | |
36)|<------CRLF------| | |
37)|--2CRLF->X | | | |
| | | | |
38)|-REGISTER->| | | |
39)| |---REGISTER-->| |
40)| |<----200 OK---| |
41)|<-200 OK---| | | |
| | | | |
Bob EP1 EP2 Proxy Alice
| | | | |
35)|------2CRLF----->| | |
36)|<------CRLF------| | |
37)|--2CRLF->X | | | |
| | | | |
38)|-REGISTER->| | | |
39)| |---REGISTER-->| |
40)| |<----200 OK---| |
41)|<-200 OK---| | | |
| | | | |
Message #38
信息#38
REGISTER sip:example.com SIP/2.0
From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com>
Call-ID: 16CB75F21C70
CSeq: 2 REGISTER
Supported: path, outbound
Route: <sip:ep1.example.com;lr>
Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=1
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
REGISTER sip:example.com SIP/2.0
From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com>
Call-ID: 16CB75F21C70
CSeq: 2 REGISTER
Supported: path, outbound
Route: <sip:ep1.example.com;lr>
Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=1
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
In message #39, EP1 inserts a Path header with a new flow token:
在消息#39中，EP1插入带有新流令牌的路径头：
Path: <sip:3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com;lr;ob>
Path: <sip:3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com;lr;ob>
Finally, Bob makes an outgoing call to Alice. Bob's UA includes an "ob" parameter in its Contact URI in message #42. EP1 adds a Record-Route with a flow-token in message #43. The route-set is returned to Bob in the response (messages #45, 46, and 47), and either Bob or Alice can send in-dialog requests.
最后，鲍勃给爱丽丝打了一个外线电话。Bob的UA在消息#42中的联系人URI中包含一个“ob”参数。EP1在消息#43中添加带有流令牌的记录路由。路由集在响应中返回给Bob（消息#45、46和47），Bob或Alice都可以发送对话请求。
Bob EP1 EP2 Proxy Alice
| | | | |
42)|--INVITE-->| | | |
43)| |---INVITE---->| |
44)| | | |-INVITE->|
45)| | | |<--200---|
46)| |<----200 OK---| |
47)|<-200 OK---| | | |
48)|--ACK----->| | | |
49)| |-----ACK--------------->|
| | | | |
50)|-- BYE---->| | | |
51)| |-----------BYE--------->|
52)| |<----------200 OK-------|
53)|<--200 OK--| | | |
| | | | |
Bob EP1 EP2 Proxy Alice
| | | | |
42)|--INVITE-->| | | |
43)| |---INVITE---->| |
44)| | | |-INVITE->|
45)| | | |<--200---|
46)| |<----200 OK---| |
47)|<-200 OK---| | | |
48)|--ACK----->| | | |
49)| |-----ACK--------------->|
| | | | |
50)|-- BYE---->| | | |
51)| |-----------BYE--------->|
52)| |<----------200 OK-------|
53)|<--200 OK--| | | |
| | | | |
Message #42
信息#42
INVITE sip:alice@a.example SIP/2.0
From: Bob <sip:bob@example.com>;tag=ldw22z
To: Alice <sip:alice@a.example>
Call-ID: 95KGsk2V/Eis9LcpBYy3
CSeq: 1 INVITE
Route: <sip:ep1.example.com;lr>
Contact: <sip:bob@192.0.2.2;transport=tcp;ob>
INVITE sip:alice@a.example SIP/2.0
From: Bob <sip:bob@example.com>;tag=ldw22z
To: Alice <sip:alice@a.example>
Call-ID: 95KGsk2V/Eis9LcpBYy3
CSeq: 1 INVITE
Route: <sip:ep1.example.com;lr>
Contact: <sip:bob@192.0.2.2;transport=tcp;ob>
In message #43, EP1 adds the following Record-Route header.
在消息#43中，EP1添加了以下记录路由头。
Record-Route:
<sip:3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com;lr>
Record-Route:
<sip:3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com;lr>
When EP1 receives the BYE (message #50) from Bob's UA, it can tell that the request is an "outgoing" request (since the source of the request matches the flow in the flow token) and simply deletes its Route header field value and forwards the request on to Alice's UA.
当EP1从Bob的UA收到BYE（消息#50）时，它可以判断该请求是一个“传出”请求（因为请求的源与流令牌中的流相匹配），并简单地删除其路由头字段值并将请求转发到Alice的UA。
Message #50
信息#50
BYE sip:alice@a.example SIP/2.0
From: Bob <sip:bob@example.com>;tag=ldw22z
To: Alice <sip:alice@a.example>;tag=plqus8
Call-ID: 95KGsk2V/Eis9LcpBYy3
CSeq: 2 BYE
Route: <sip:3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com;lr>
Contact: <sip:bob@192.0.2.2;transport=tcp;ob>
BYE sip:alice@a.example SIP/2.0
From: Bob <sip:bob@example.com>;tag=ldw22z
To: Alice <sip:alice@a.example>;tag=plqus8
Call-ID: 95KGsk2V/Eis9LcpBYy3
CSeq: 2 BYE
Route: <sip:3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com;lr>
Contact: <sip:bob@192.0.2.2;transport=tcp;ob>
This specification defines a new header field "Flow-Timer", and new Contact header field parameters, "reg-id" and "+sip.instance". The grammar includes the definitions from [RFC3261]. Flow-Timer is an extension-header from the message-header in the [RFC3261] ABNF.
本规范定义了一个新的标题字段“Flow Timer”，以及新的联系人标题字段参数“reg id”和“+sip.instance”。语法包括[RFC3261]中的定义。Flow Timer是[RFC3261]ABNF中消息头的扩展头。
The ABNF [RFC5234] is:
ABNF[RFC5234]是：
Flow-Timer = "Flow-Timer" HCOLON 1*DIGIT
Flow Timer=“Flow Timer”HCOLON 1*位
contact-params =/ c-p-reg / c-p-instance
contact-params =/ c-p-reg / c-p-instance
c-p-reg = "reg-id" EQUAL 1*DIGIT ; 1 to (2^31 - 1)
c-p-reg = "reg-id" EQUAL 1*DIGIT ; 1 to (2^31 - 1)
c-p-instance = "+sip.instance" EQUAL
DQUOTE "<" instance-val ">" DQUOTE
c-p-instance = "+sip.instance" EQUAL
DQUOTE "<" instance-val ">" DQUOTE
instance-val = 1*uric ; defined in RFC 3261
instance-val = 1*uric ; defined in RFC 3261
The value of the reg-id MUST NOT be 0 and MUST be less than 2^31.
注册表id的值不能为0，并且必须小于2^31。
This specification defines a new SIP header field "Flow-Timer" whose syntax is defined in Section 10.
本规范定义了一个新的SIP头字段“Flow Timer”，其语法在第10节中定义。
Header Name compact Reference
----------------- ------- ---------
Flow-Timer [RFC5626]
Header Name compact Reference
----------------- ------- ---------
Flow-Timer [RFC5626]
This specification defines a new Contact header field parameter called reg-id in the "Header Field Parameters and Parameter Values" sub-registry as per the registry created by [RFC3968]. The syntax is defined in Section 10. The required information is:
本规范根据[RFC3968]创建的注册表，在“header field Parameters and parameter Values”（标题字段参数和参数值）子注册表中定义了名为reg id的新联系人标题字段参数。第10节对语法进行了定义。所需资料如下：
Predefined
Header Field Parameter Name Values Reference
---------------------- --------------------- ---------- ---------
Contact reg-id No [RFC5626]
Predefined
Header Field Parameter Name Values Reference
---------------------- --------------------- ---------- ---------
Contact reg-id No [RFC5626]
This specification augments the "SIP/SIPS URI Parameters" sub-registry as per the registry created by [RFC3969]. The required information is:
本规范根据[RFC3969]创建的注册表扩充了“SIP/SIPS URI参数”子注册表。所需资料如下：
Parameter Name Predefined Values Reference
-------------- ----------------- ---------
ob No [RFC5626]
Parameter Name Predefined Values Reference
-------------- ----------------- ---------
ob No [RFC5626]
This specification registers a new SIP option tag, as per the guidelines in Section 27.1 of [RFC3261].
根据[RFC3261]第27.1节中的指南，本规范注册了一个新的SIP选项标签。
Name: outbound
姓名：出站
Description: This option-tag is used to identify UAs and registrars that support extensions for Client-Initiated Connections. A UA places this option in a Supported header to communicate its support for this extension. A registrar places this option-tag in a Require header to indicate to the registering User Agent that the registrar used registrations using the binding rules defined in this extension.
描述：此选项标签用于标识支持客户端启动连接扩展的UAs和注册器。UA将此选项放置在受支持的标头中，以传达其对此扩展的支持。注册器将此选项标记放置在Require头中，以向注册用户代理指示注册器使用了使用此扩展中定义的绑定规则的注册。
This document registers a new SIP response code (430 Flow Failed), as per the guidelines in Section 27.4 of [RFC3261]. This response code is used by an edge proxy to indicate to the Authoritative Proxy that a specific flow to a UA instance has failed. Other flows to the same instance could still succeed. The Authoritative Proxy SHOULD attempt to forward to another target (flow) with the same instance-id and AOR. Endpoints should never receive a 430 response. If an endpoint receives a 430 response, it should treat it as a 400 (Bad Request) per normal procedures, as in Section 8.1.3.2 of [RFC3261]. This response code is defined by the following information, which has been added to the method and response-code sub-registry under the SIP Parameters registry.
根据[RFC3261]第27.4节中的指南，本文件注册了一个新的SIP响应代码（430流失败）。边缘代理使用此响应代码向权威代理指示到UA实例的特定流已失败。到同一实例的其他流仍然可以成功。权威代理应尝试转发到具有相同实例id和AOR的另一个目标（流）。端点永远不应该收到430响应。如果端点收到430响应，则应按照正常程序将其视为400（错误请求），如[RFC3261]第8.1.3.2节所述。此响应代码由以下信息定义，这些信息已添加到SIP参数注册表下的方法和响应代码子注册表中。
Response Code Reference
------------------------------------------ ---------
Request Failure 4xx
430 Flow Failed [RFC5626]
Response Code Reference
------------------------------------------ ---------
Request Failure 4xx
430 Flow Failed [RFC5626]
This document registers a new SIP response code (439 First Hop Lacks Outbound Support), as per the guidelines in Section 27.4 of [RFC3261]. This response code is used by a registrar to indicate that it supports the 'outbound' feature described in this specification, but that the first outbound proxy that the user is attempting to register through does not. Note that this response code is only appropriate in the case that the registering User Agent advertises support for outbound processing by including the outbound option tag in a Supported header field. Proxies MUST NOT send a 439 response to any requests that do not contain a "reg-id" parameter and an outbound option tag in a Supported header field. This response code is defined by the following information, which has been added to the method and response-code sub-registry under the SIP Parameters registry.
根据[RFC3261]第27.4节中的指南，本文件注册了一个新的SIP响应代码（439第一跳缺少出站支持）。注册商使用此响应代码表示它支持本规范中描述的“出站”功能，但用户试图注册的第一个出站代理不支持。请注意，此响应代码仅适用于注册用户代理通过在受支持的标头字段中包含outbound选项标记来宣传对出站处理的支持的情况。代理不得向在受支持的标头字段中不包含“reg id”参数和出站选项标记的任何请求发送439响应。此响应代码由以下信息定义，这些信息已添加到SIP参数注册表下的方法和响应代码子注册表中。
Response Code Reference
------------------------------------------ ---------
Request Failure 4xx
439 First Hop Lacks Outbound Support [RFC&rfc.number;]
Response Code Reference
------------------------------------------ ---------
Request Failure 4xx
439 First Hop Lacks Outbound Support [RFC&rfc.number;]
This section registers a new media feature tag, per the procedures defined in [RFC2506]. The tag is placed into the sip tree, which is defined in [RFC3840].
本节按照[RFC2506]中定义的程序注册一个新的媒体功能标签。标签被放置在sip树中，sip树在[RFC3840]中定义。
Media feature tag name: sip.instance
媒体功能标签名称：sip.instance
ASN.1 Identifier: 23
ASN.1标识符：23
Summary of the media feature indicated by this tag: This feature tag contains a string containing a URN that indicates a unique identifier associated with the UA instance registering the Contact.
此标记指示的媒体功能摘要：此功能标记包含一个字符串，其中包含一个URN，表示与注册联系人的UA实例关联的唯一标识符。
Values appropriate for use with this feature tag: String (equality relationship).
适用于此功能标记的值：字符串（相等关系）。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application, for describing the capabilities of a device, such as a phone or PDA.
该特征标签主要用于以下应用、协议、服务或协商机制：该特征标签在通信应用中最有用，用于描述诸如电话或PDA之类的设备的能力。
Examples of typical use: Routing a call to a specific device.
典型用途示例：将呼叫路由到特定设备。
Related standards or documents: RFC 5626
相关标准或文件：RFC 5626
Security Considerations: This media feature tag can be used in ways which affect application behaviors. For example, the SIP caller preferences extension [RFC3841] allows for call routing decisions to be based on the values of these parameters. Therefore, if an attacker can modify the values of this tag, they might be able to affect the behavior of applications. As a result, applications that utilize this media feature tag SHOULD provide a means for ensuring its integrity. Similarly, this feature tag should only be trusted as valid when it comes from the user or User Agent described by the tag. As a result, protocols for conveying this feature tag SHOULD provide a mechanism for guaranteeing authenticity.
安全注意事项：此媒体功能标签可用于影响应用程序行为的方式。例如，SIP呼叫者偏好扩展[RFC3841]允许呼叫路由决策基于这些参数的值。因此，如果攻击者可以修改此标记的值，则可能会影响应用程序的行为。因此，使用此媒体功能标签的应用程序应提供确保其完整性的方法。类似地，只有当此功能标签来自标签所描述的用户或用户代理时，才应将其视为有效。因此，传输此功能标签的协议应该提供一种保证真实性的机制。
One of the key security concerns in this work is making sure that an attacker cannot hijack the sessions of a valid user and cause all calls destined to that user to be sent to the attacker. Note that the intent is not to prevent existing active attacks on SIP UDP and TCP traffic, but to ensure that no new attacks are added by introducing the outbound mechanism.
这项工作中的一个关键安全问题是确保攻击者不能劫持有效用户的会话，并导致发送给该用户的所有呼叫都发送给攻击者。请注意，其目的不是防止对SIP UDP和TCP流量的现有主动攻击，而是通过引入出站机制确保不会添加新的攻击。
The simple case is when there are no edge proxies. In this case, the only time an entry can be added to the routing for a given AOR is when the registration succeeds. SIP already protects against attackers being able to successfully register, and this scheme relies on that security. Some implementers have considered the idea of just saving the instance-id without relating it to the AOR with which it registered. This idea will not work because an attacker's UA can impersonate a valid user's instance-id and hijack that user's calls.
最简单的情况是没有边缘代理。在这种情况下，只有在注册成功时，才能将条目添加到给定AOR的路由中。SIP已经能够防止攻击者成功注册，该方案依赖于该安全性。一些实现者考虑了只保存实例id而不将其与注册的AOR关联的想法。这种想法行不通，因为攻击者的UA可以模拟有效用户的实例id并劫持该用户的调用。
The more complex case involves one or more edge proxies. When a UA sends a REGISTER request through an edge proxy on to the registrar, the edge proxy inserts a Path header field value. If the registration is successfully authenticated, the registrar stores the value of the Path header field. Later, when the registrar forwards a request destined for the UA, it copies the stored value of the Path header field into the Route header field of the request and forwards the request to the edge proxy.
更复杂的情况涉及一个或多个边缘代理。当UA通过边缘代理向注册器发送注册请求时，边缘代理将插入路径头字段值。如果注册成功通过身份验证，注册器将存储路径头字段的值。稍后，当注册器转发以UA为目的地的请求时，它将路径报头字段的存储值复制到请求的路由报头字段中，并将请求转发给边缘代理。
The only time an edge proxy will route over a particular flow is when it has received a Route header that has the flow identifier information that it has created. An incoming request would have gotten this information from the registrar. The registrar will only save this information for a given AOR if the registration for the AOR has been successful; and the registration will only be successful if
边缘代理在特定流上路由的唯一时间是在它接收到包含其创建的流标识符信息的路由头时。传入请求将从注册官处获得此信息。只有在AOR注册成功的情况下，注册官才会为特定AOR保存此信息；只有在以下情况下，注册才会成功
the UA can correctly authenticate. Even if an attacker has spoofed some bad information in the Path header sent to the registrar, the attacker will not be able to get the registrar to accept this information for an AOR that does not belong to the attacker. The registrar will not hand out this bad information to others, and others will not be misled into contacting the attacker.
UA可以正确地进行身份验证。即使攻击者在发送给注册器的路径头中伪造了一些错误信息，攻击者也无法让注册器接受不属于攻击者的AOR的此信息。注册者不会将此不良信息分发给其他人，也不会误导其他人与攻击者联系。
The Security Considerations discussed in [RFC3261] and [RFC3327] are also relevant to this document. For the security considerations of generating flow tokens, please also see Section 5.2. A discussion of preventing the avalanche restart problem is in Section 4.5.
[RFC3261]和[RFC3327]中讨论的安全注意事项也与本文件相关。有关生成流令牌的安全注意事项，请参见第5.2节。第4.5节讨论了防止雪崩重启问题。
This document does not change the mandatory-to-implement security mechanisms in SIP. User Agents are already required to implement Digest authentication while support of TLS is recommended; proxy servers are already required to implement Digest and TLS.
本文档不会更改在SIP中实现安全机制的强制要求。用户代理已经被要求实现摘要认证，同时建议支持TLS；已经需要代理服务器来实现摘要和TLS。
This entire section is non-normative.
这整个部分都是非规范性的。
[RFC3261] requires proxies, registrars, and User Agents to implement both TCP and UDP but deployments can chose which transport protocols they want to use. Deployments need to be careful in choosing what transports to use. Many SIP features and extensions, such as large presence notification bodies, result in SIP requests that can be too large to be reasonably transported over UDP. [RFC3261] states that when a request is too large for UDP, the device sending the request attempts to switch over to TCP. It is important to note that when using outbound, this will only work if the UA has formed both UDP and TCP outbound flows. This specification allows the UA to do so, but in most cases it will probably make more sense for the UA to form a TCP outbound connection only, rather than forming both UDP and TCP flows. One of the key reasons that many deployments choose not to use TCP has to do with the difficulty of building proxies that can maintain a very large number of active TCP connections. Many deployments today use SIP in such a way that the messages are small enough that they work over UDP but they can not take advantage of all the functionality SIP offers. Deployments that use only UDP outbound connections are going to fail with sufficiently large SIP messages.
[RFC3261]需要代理、注册器和用户代理来实现TCP和UDP，但部署可以选择要使用的传输协议。在选择要使用的传输时，部署需要谨慎。许多SIP功能和扩展（如大型状态通知机构）会导致SIP请求过大，无法通过UDP进行合理传输。[RFC3261]指出，当请求对于UDP来说太大时，发送请求的设备会尝试切换到TCP。重要的是要注意，当使用出站时，这仅在UA同时形成UDP和TCP出站流的情况下才起作用。此规范允许UA这样做，但在大多数情况下，UA仅形成TCP出站连接可能更有意义，而不是同时形成UDP和TCP流。许多部署选择不使用TCP的一个关键原因是难以构建能够维护大量活动TCP连接的代理。如今，许多部署使用SIP的方式使得消息足够小，可以通过UDP工作，但它们无法利用SIP提供的所有功能。仅使用UDP出站连接的部署将因SIP消息足够大而失败。
This specification was developed to meet the following requirements:
本规范旨在满足以下要求：
1. Must be able to detect that a UA supports these mechanisms.
1. 必须能够检测UA是否支持这些机制。
2. Support UAs behind NATs.
2. 支持NATs背后的UAs。
3. Support TLS to a UA without a stable DNS name or IP address.
3. 支持没有稳定DNS名称或IP地址的UA的TLS。
4. Detect failure of a connection and be able to correct for this.
4. 检测连接故障并能够对此进行纠正。
5. Support many UAs simultaneously rebooting.
5. 支持多个UAs同时重启。
6. Support a NAT rebooting or resetting.
6. 支持NAT重新启动或重置。
7. Minimize initial startup load on a proxy.
7. 最小化代理上的初始启动负载。
8. Support architectures with edge proxies.
8. 支持带有边缘代理的体系结构。
Francois Audet acted as document shepherd for this document, tracking hundreds of comments and incorporating many grammatical fixes as well as prodding the editors to "get on with it". Jonathan Rosenberg, Erkki Koivusalo, and Byron Campen provided many comments and useful text. Dave Oran came up with the idea of using the most recent registration first in the proxy. Alan Hawrylyshen co-authored the document that formed the initial text of this specification. Additionally, many of the concepts here originated at a connection reuse meeting at IETF 60 that included the authors, Jon Peterson, Jonathan Rosenberg, Alan Hawrylyshen, and Paul Kyzivat. The TCP design team consisting of Chris Boulton, Scott Lawrence, Rajnish Jain, Vijay K. Gurbani, and Ganesh Jayadevan provided input and text. Nils Ohlmeier provided many fixes and initial implementation experience. In addition, thanks to the following folks for useful comments: Francois Audet, Flemming Andreasen, Mike Hammer, Dan Wing, Srivatsa Srinivasan, Dale Worely, Juha Heinanen, Eric Rescorla, Lyndsay Campbell, Christer Holmberg, Kevin Johns, Jeroen van Bemmel, Derek MacDonald, Dean Willis, and Robert Sparks.
弗朗索瓦·奥德特（Francois Audet）是这份文件的文件守护者，他跟踪了数百条评论，加入了许多语法修正，并敦促编辑们“继续做下去”。乔纳森·罗森博格、埃尔基·科维瓦萨洛和拜伦·坎本提供了许多评论和有用的文本。Dave Oran提出了在代理中首先使用最新注册的想法。Alan Hawrylyshen与他人共同编写了构成本规范初始文本的文件。此外，这里的许多概念起源于IETF 60的连接重用会议，其中包括作者Jon Peterson、Jonathan Rosenberg、Alan Hawrylyshen和Paul Kyzivat。由Chris Boulton、Scott Lawrence、Rajnish Jain、Vijay K.Gurbani和Ganesh Jayadevan组成的TCP设计团队提供了输入和文本。Nils Ohlmeier提供了许多修复和初始实施经验。此外，感谢以下人士提供的有用意见：弗朗索瓦·奥德特、弗莱明·安德里亚森、迈克·哈默、丹·温、斯利瓦萨·斯里尼瓦桑、戴尔·沃利、朱哈·海纳南、埃里克·雷斯科拉、林赛·坎贝尔、克里斯特·霍姆伯格、凯文·约翰斯、杰伦·范贝梅尔、德里克·麦克唐纳、迪安·威利斯和罗伯特·斯帕克斯。
[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月。
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2141]Moats，R.，“瓮语法”，RFC 21411997年5月。
[RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999.
[RFC2506]Holtman，K.，Mutz，A.，和T.Hardie，“媒体功能标签注册程序”，BCP 31，RFC 2506，1999年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月。
[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月。
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
[RFC3327]Willis，D.和B.Hoeneisen，“用于注册非相邻联系人的会话启动协议（SIP）扩展头字段”，RFC 3327，2002年12月。
[RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing", RFC 3581, August 2003.
[RFC3581]Rosenberg，J.和H.Schulzrinne，“对称响应路由会话启动协议（SIP）的扩展”，RFC 3581，2003年8月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3840]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，2004年8月。
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[RFC3841]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“会话启动协议（SIP）的呼叫方偏好”，RFC 38412004年8月。
[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月。
[RFC3969] 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.
[RFC3969]Camarillo，G.“会话启动协议（SIP）的Internet分配号码管理机构（IANA）统一资源标识符（URI）参数注册表”，BCP 99，RFC 3969，2004年12月。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[RFC4122]Leach，P.，Mealling，M.和R.Salz，“通用唯一标识符（UUID）URN名称空间”，RFC 4122，2005年7月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和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月。
[CONFIG-FMWK] Petrie, D. and S. Channabasappa, Ed., "A Framework for Session Initiation Protocol User Agent Profile Delivery", Work in Progress, February 2008.
[CONFIG-FMWK]Petrie，D.和S.Channabasappa，Ed.，“会话启动协议用户代理配置文件交付框架”，正在进行的工作，2008年2月。
[NAT-SCEN] Boulton, C., Rosenberg, J., Camarillo, G., and F. Audet, "Best Current Practices for NAT Traversal for Client-Server SIP", Work in Progress, September 2008.
[NAT-SCEN]Boulton，C.，Rosenberg，J.，Camarillo，G.，和F.Audet，“客户端-服务器SIP NAT遍历的最佳当前实践”，正在进行的工作，2008年9月。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z., and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003.
[RFC3320]Price，R.，Bormann，C.，Christofferson，J.，Hannu，H.，Liu，Z.，和J.Rosenberg，“信号压缩（SigComp）”，RFC3320，2003年1月。
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[RFC3489]Rosenberg，J.，Weinberger，J.，Huitema，C.，和R.Mahy，“STUN-通过网络地址转换器（NAT）简单遍历用户数据报协议（UDP）”，RFC 3489，2003年3月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 43402006年3月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
[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月。
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[RFC5627]Rosenberg，J.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理URI（GRUUs）”，RFC 5627，2009年10月。
The base-time used for the flow re-registration backoff times described in Section 4.5 are configurable. If the base-time-all-fail value is set to the default of 30 seconds and the base-time-not-failed value is set to the default of 90 seconds, the following table shows the resulting amount of time the UA will wait to retry registration.
第4.5节中描述的用于流重新注册退避时间的基准时间是可配置的。如果基本时间所有失败值设置为默认值30秒，而基本时间未失败值设置为默认值90秒，则下表显示UA将等待重试注册的时间。
+-------------------+--------------------+---------------------+
| # of reg failures | all flows unusable | > 1 non-failed flow |
+-------------------+--------------------+---------------------+
| 0 | 0 s | 0 s |
| 1 | 30-60 s | 90-180 s |
| 2 | 1-2 min | 3-6 min |
| 3 | 2-4 min | 6-12 min |
| 4 | 4-8 min | 12-24 min |
| 5 | 8-16 min | 15-30 min |
| 6 or more | 15-30 min | 15-30 min |
+-------------------+--------------------+---------------------+
+-------------------+--------------------+---------------------+
| # of reg failures | all flows unusable | > 1 non-failed flow |
+-------------------+--------------------+---------------------+
| 0 | 0 s | 0 s |
| 1 | 30-60 s | 90-180 s |
| 2 | 1-2 min | 3-6 min |
| 3 | 2-4 min | 6-12 min |
| 4 | 4-8 min | 12-24 min |
| 5 | 8-16 min | 15-30 min |
| 6 or more | 15-30 min | 15-30 min |
+-------------------+--------------------+---------------------+
This appendix contains the ABNF defined earlier in this document.
本附录包含本文件前面定义的ABNF。
CRLF = CR LF
double-CRLF = CR LF CR LF
CR = %x0D
LF = %x0A
CRLF = CR LF
double-CRLF = CR LF CR LF
CR = %x0D
LF = %x0A
Flow-Timer = "Flow-Timer" HCOLON 1*DIGIT
Flow Timer=“Flow Timer”HCOLON 1*位
contact-params =/ c-p-reg / c-p-instance
contact-params =/ c-p-reg / c-p-instance
c-p-reg = "reg-id" EQUAL 1*DIGIT ; 1 to (2^31 - 1)
c-p-reg = "reg-id" EQUAL 1*DIGIT ; 1 to (2^31 - 1)
c-p-instance = "+sip.instance" EQUAL
DQUOTE "<" instance-val ">" DQUOTE
c-p-instance = "+sip.instance" EQUAL
DQUOTE "<" instance-val ">" DQUOTE
instance-val = 1*uric ; defined in RFC 3261
instance-val = 1*uric ; defined in RFC 3261
Authors' Addresses
作者地址
Cullen Jennings (editor) Cisco Systems 170 West Tasman Drive Mailstop SJC-21/2 San Jose, CA 95134 USA
Cullen Jennings（编辑）思科系统170西塔斯曼大道邮递站SJC-21/2美国加利福尼亚州圣何塞95134
Phone: +1 408 902-3341
EMail: fluffy@cisco.com
Phone: +1 408 902-3341
EMail: fluffy@cisco.com
Rohan Mahy (editor) Unaffiliated
Rohan Mahy（编辑）无关联
EMail: rohan@ekabal.com
EMail: rohan@ekabal.com
Francois Audet (editor) Skype Labs
弗朗索瓦·奥德特（编辑）Skype实验室
EMail: francois.audet@skypelabs.com
EMail: francois.audet@skypelabs.com