Network Working Group J. Rosenberg
Request for Comments: 3581 dynamicsoft
Category: Standards Track H. Schulzrinne
Columbia University
August 2003
Network Working Group J. Rosenberg
Request for Comments: 3581 dynamicsoft
Category: Standards Track H. Schulzrinne
Columbia University
August 2003
An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing
用于对称响应路由的会话启动协议（SIP）的扩展
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
The Session Initiation Protocol (SIP) operates over UDP and TCP, among others. When used with UDP, responses to requests are returned to the source address the request came from, and to the port written into the topmost Via header field value of the request. This behavior is not desirable in many cases, most notably, when the client is behind a Network Address Translator (NAT). This extension defines a new parameter for the Via header field, called "rport", that allows a client to request that the server send the response back to the source IP address and port from which the request originated.
会话启动协议（SIP）在UDP和TCP等协议上运行。当与UDP一起使用时，对请求的响应将返回到请求来源的源地址，并返回到通过请求头字段值写入最顶端的端口。这种行为在许多情况下是不可取的，尤其是当客户端位于网络地址转换器（NAT）后面时。此扩展为Via标头字段定义了一个新参数，称为“rport”，该参数允许客户端请求服务器将响应发送回源IP地址和发起请求的端口。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 3
4. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 4
5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Problem Definition . . . . . . . . . . . . . . . . . . . 8
9.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . 8
9.3. Brittleness Introduced by this Specification . . . . . . 9
9.4. Requirements for a Long Term Solution . . . . . . . . . 10
9.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 11
12. Intellectual Property and Copyright Statements . . . . . . . . 11
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 3
4. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 4
5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Problem Definition . . . . . . . . . . . . . . . . . . . 8
9.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . 8
9.3. Brittleness Introduced by this Specification . . . . . . 9
9.4. Requirements for a Long Term Solution . . . . . . . . . 10
9.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 11
12. Intellectual Property and Copyright Statements . . . . . . . . 11
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
The Session Initiation Protocol (SIP) [1] operates over UDP and TCP. When used with UDP, responses to requests are returned to the source address the request came from, and to the port written into the topmost Via header field value of the request. This results in a "hybrid" way of computing the destination of the response. Half of the information (specifically, the IP address) is taken from the IP packet headers, and the other half (specifically, the port) from the SIP message headers. SIP operates in this manner so that a server can listen for all messages, both requests and responses, on a single IP address and port. This helps improve scalability. However, this behavior is not desirable in many cases, most notably, when the client is behind a NAT. In that case, the response will not properly traverse the NAT, since it will not match the binding established with the request.
会话启动协议（SIP）[1]在UDP和TCP上运行。当与UDP一起使用时，对请求的响应将返回到请求来源的源地址，并返回到通过请求头字段值写入最顶端的端口。这导致了一种计算响应目的地的“混合”方式。一半的信息（特别是IP地址）来自IP数据包头，另一半（特别是端口）来自SIP消息头。SIP以这种方式运行，因此服务器可以在单个IP地址和端口上侦听所有消息，包括请求和响应。这有助于提高可伸缩性。然而，在许多情况下，这种行为是不可取的，最明显的是，当客户端位于NAT之后时。在这种情况下，响应将不会正确地遍历NAT，因为它将不匹配与请求建立的绑定。
Furthermore, there is currently no way for a client to examine a response and determine the source port that the server saw in the corresponding request. Currently, SIP provides the client with the source IP address that the server saw in the request, but not the port. The source IP address is conveyed in the "received" parameter in the topmost Via header field value of the response. This information has proved useful for basic NAT traversal, debugging
此外，客户端目前无法检查响应并确定服务器在相应请求中看到的源端口。目前，SIP向客户端提供服务器在请求中看到的源IP地址，但不提供端口。源IP地址在响应的最顶端Via标头字段值的“received”参数中传输。事实证明，这些信息对于基本的NAT遍历和调试非常有用
purposes, and support of multi-homed hosts. However, it is incomplete without the port information.
多宿主主机的用途和支持。但是，如果没有端口信息，它是不完整的。
This extension defines a new parameter for the Via header field, called "rport", that allows a client to request that the server send the response back to the source IP address and port where the request came from. The "rport" parameter is analogous to the "received" parameter, except "rport" contains a port number, not the IP address.
此扩展为Via header字段定义了一个新参数，称为“rport”，该参数允许客户端请求服务器将响应发送回请求来自的源IP地址和端口。“rport”参数与“received”参数类似，只是“rport”包含端口号，而不是IP地址。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[2]中的描述进行解释，并指出合规实施的要求级别。
The client behavior specified here affects the transport processing defined in Section 18.1 of SIP (RFC 3261) [1].
此处指定的客户端行为会影响SIP（RFC 3261）[1]第18.1节中定义的传输处理。
A client, compliant to this specification (clients include UACs and proxies), MAY include an "rport" parameter in the top Via header field value of requests it generates. This parameter MUST have no value; it serves as a flag to indicate to the server that this extension is supported and requested for the transaction.
符合本规范的客户端（客户端包括UAC和代理）可以在其生成的请求的顶部Via头字段值中包含“rport”参数。此参数不能有值；它用作一个标志，向服务器指示事务支持并请求此扩展。
When the client sends the request, if the request is sent using UDP, the client MUST be prepared to receive the response on the same IP address and port it used to populate the source IP address and source port of the request. For backwards compatibility, the client MUST still be prepared to receive a response on the port indicated in the sent-by field of the topmost Via header field value, as specified in Section 18.1.1 of SIP [1].
当客户机发送请求时，如果使用UDP发送请求，则客户机必须准备在用于填充请求的源IP地址和源端口的相同IP地址和端口上接收响应。为了向后兼容，客户机仍必须准备好在SIP[1]第18.1.1节中规定的最顶层Via标头字段值的sent by字段中指示的端口上接收响应。
When there is a NAT between the client and server, the request will create (or refresh) a binding in the NAT. This binding must remain in existence for the duration of the transaction in order for the client to receive the response. Most UDP NAT bindings appear to have a timeout of about one minute. This exceeds the duration of non-INVITE transactions. Therefore, responses to a non-INVITE request will be received while the binding is still in existence. INVITE transactions can take an arbitrarily long amount of time to complete. As a result, the binding may expire before a final response is received. To keep the binding fresh, the client SHOULD retransmit its INVITE every 20 seconds or so. These retransmissions will need to take place even after receiving a provisional response.
当客户端和服务器之间存在NAT时，请求将在NAT中创建（或刷新）绑定。此绑定必须在事务期间保持存在，以便客户端接收响应。大多数UDP NAT绑定的超时时间大约为一分钟。这超出了非邀请事务的持续时间。因此，当绑定仍然存在时，将接收对非INVITE请求的响应。INVITE事务可能需要任意长的时间才能完成。因此，绑定可能在收到最终响应之前过期。为了保持绑定的新鲜度，客户机应该每隔20秒左右重新传输其INVITE。即使在收到临时响应后，也需要进行这些重传。
A UA MAY execute the binding lifetime discovery algorithm in Section 10.2 of RFC 3489 [4] to determine the actual binding lifetime in the NAT. If it is longer than 1 minute, the client SHOULD increase the interval for request retransmissions up to half of the discovered lifetime. If it is shorter than one minute, it SHOULD decrease the interval for request retransmissions to half of the discovered lifetime. Note that discovery of binding lifetimes can be unreliable. See Section 14.3 of RFC 3489 [4].
UA可执行RFC 3489[4]第10.2节中的绑定生存期发现算法，以确定NAT中的实际绑定生存期。如果超过1分钟，客户端应将请求重新传输的间隔增加到发现生存期的一半。如果时间短于一分钟，则应将请求重新传输的时间间隔减少到发现生存期的一半。请注意，绑定生存期的发现可能不可靠。参见RFC 3489[4]第14.3节。
The server behavior specified here affects the transport processing defined in Section 18.2 of SIP [1].
此处指定的服务器行为会影响SIP[1]第18.2节中定义的传输处理。
When a server compliant to this specification (which can be a proxy or UAS) receives a request, it examines the topmost Via header field value. If this Via header field value contains an "rport" parameter with no value, it MUST set the value of the parameter to the source port of the request. This is analogous to the way in which a server will insert the "received" parameter into the topmost Via header field value. In fact, the server MUST insert a "received" parameter containing the source IP address that the request came from, even if it is identical to the value of the "sent-by" component. Note that this processing takes place independent of the transport protocol.
当符合此规范的服务器（可以是代理服务器或UAS）收到请求时，它将通过头字段值检查最上面的值。如果此Via标头字段值包含一个没有值的“rport”参数，则必须将该参数的值设置为请求的源端口。这类似于服务器将“received”参数插入最顶端的Via头字段值的方式。事实上，服务器必须插入一个“received”参数，该参数包含请求来自的源IP地址，即使它与“sent by”组件的值相同。请注意，此处理独立于传输协议进行。
When a server attempts to send a response, it examines the topmost Via header field value of that response. If the "sent-protocol" component indicates an unreliable unicast transport protocol, such as UDP, and there is no "maddr" parameter, but there is both a "received" parameter and an "rport" parameter, the response MUST be sent to the IP address listed in the "received" parameter, and the port in the "rport" parameter. The response MUST be sent from the same address and port that the corresponding request was received on. This effectively adds a new processing step between bullets two and three in Section 18.2.2 of SIP [1].
当服务器尝试发送响应时，它会检查该响应的最顶端Via头字段值。如果“发送协议”组件指示不可靠的单播传输协议（如UDP），并且没有“maddr”参数，但同时存在“已接收”参数和“rport”参数，则必须将响应发送到“已接收”参数中列出的IP地址和“rport”参数中列出的端口。响应必须从接收相应请求的相同地址和端口发送。这有效地在SIP[1]第18.2.2节中的项目符号2和项目符号3之间添加了一个新的处理步骤。
The response must be sent from the same address and port that the request was received on in order to traverse symmetric NATs. When a server is listening for requests on multiple ports or interfaces, it will need to remember the one on which the request was received. For a stateful proxy, storing this information for the duration of the transaction is not an issue. However, a stateless proxy does not store state between a request and its response, and therefore cannot remember the address and port on which a request was received. To properly implement this specification, a stateless proxy can encode the destination address and port of a request into the Via header field value that it inserts. When the response arrives, it can extract this information and use it to forward the response.
为了遍历对称NAT，必须从接收请求的相同地址和端口发送响应。当服务器在多个端口或接口上侦听请求时，它需要记住接收请求的端口或接口。对于有状态代理，在事务期间存储此信息不是问题。但是，无状态代理不存储请求与其响应之间的状态，因此无法记住接收请求的地址和端口。为了正确实现此规范，无状态代理可以将请求的目标地址和端口编码到它插入的Via头字段值中。当响应到达时，它可以提取此信息并使用它转发响应。
The syntax for the "rport" parameter is:
“rport”参数的语法为：
response-port = "rport" [EQUAL 1*DIGIT]
响应端口=“rport”[等于1*位]
This extends the existing definition of the Via header field parameters, so that its BNF now looks like:
这扩展了Via header字段参数的现有定义，因此其BNF现在看起来像：
via-params = via-ttl / via-maddr
/ via-received / via-branch
/ response-port / via-extension
via-params = via-ttl / via-maddr
/ via-received / via-branch
/ response-port / via-extension
A client sends an INVITE to a proxy server which looks like, in part:
客户机向代理服务器发送一个邀请，部分如下：
INVITE sip:user@example.com SIP/2.0
Via: SIP/2.0/UDP 10.1.1.1:4540;rport;branch=z9hG4bKkjshdyff
INVITE sip:user@example.com SIP/2.0
Via: SIP/2.0/UDP 10.1.1.1:4540;rport;branch=z9hG4bKkjshdyff
This INVITE is sent with a source port of 4540 and a source IP address of 10.1.1.1. The proxy is at 192.0.2.2 (proxy.example.com), listening on both port 5060 and 5070. The client sends the request to port 5060. The request passes through a NAT on the way to the proxy, so that the source IP address appears as 192.0.2.1 and the source port as 9988. The proxy forwards the request, but not before appending a value to the "rport" parameter in the proxied request:
发送此INVITE时，源端口为4540，源IP地址为10.1.1.1。代理位于192.0.2.2（proxy.example.com），监听端口5060和5070。客户端将请求发送到端口5060。请求在到达代理的途中通过NAT，因此源IP地址显示为192.0.2.1，源端口显示为9988。代理转发请求，但在向代理请求中的“rport”参数追加值之前：
INVITE sip:user@example.com SIP/2.0
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77
Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988
;branch=z9hG4bKkjshdyff
INVITE sip:user@example.com SIP/2.0
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77
Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988
;branch=z9hG4bKkjshdyff
This request generates a response which arrives at the proxy:
此请求生成一个到达代理的响应：
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77
Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988
;branch=z9hG4bKkjshdyff
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77
Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988
;branch=z9hG4bKkjshdyff
The proxy strips its top Via header field value, and then examines the next one. It contains both a "received" parameter and an "rport" parameter. The server follows the rules specified in Section 4 and sends the response to IP address 192.0.2.1, port 9988, and sends it from port 5060 on 192.0.2.2:
代理通过头字段值剥离其顶部，然后检查下一个。它同时包含“received”参数和“rport”参数。服务器遵循第4节中指定的规则，将响应发送到IP地址192.0.2.1端口9988，并从192.0.2.2上的端口5060发送：
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988
;branch=z9hG4bKkjshdyff
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988
;branch=z9hG4bKkjshdyff
This packet matches the binding created by the initial request. Therefore, the NAT rewrites the destination address of this packet back to 10.1.1.1, and the destination port back to 4540. It forwards this response to the client, which is listening for the response on that address and port. The client properly receives the response.
此数据包与初始请求创建的绑定匹配。因此，NAT将该数据包的目的地址重写回10.1.1.1，目的端口重写回4540。它将此响应转发给正在侦听该地址和端口上的响应的客户端。客户端正确地接收响应。
When a server uses this specification, responses that it sends will now include the source port where the request came from. In some instances, the source address and port of a request are sensitive information. If they are sensitive, requests SHOULD be protected by using SIP over TLS [1]. In such a case, this specification does not provide any response routing functions (as these only work with TCP); it merely provides the client with information about the source port as seen by the server.
当服务器使用此规范时，它发送的响应现在将包括请求来自的源端口。在某些情况下，请求的源地址和端口是敏感信息。如果请求是敏感的，则应使用SIP over TLS[1]来保护请求。在这种情况下，本规范不提供任何响应路由功能（因为这些功能仅适用于TCP）；它只向客户机提供服务器看到的源端口信息。
It is possible that an attacker might try to disrupt service to a client by acting as a man-in-the-middle, modifying the "rport" parameter in a Via header in a request sent by a client. Removal of this parameter will prevent clients from behind NATs from receiving service. The addition of the parameter will generally have no impact. Of course, if an attacker is capable of launching a man-in-the-middle attack, there are many other ways of denying service, such as merely discarding the request. Therefore, this attack does not seem significant.
攻击者可能会充当中间人，在客户端发送的请求中修改Via标头中的“rport”参数，从而试图中断对客户端的服务。删除此参数将阻止NAT后面的客户端接收服务。添加该参数通常不会产生影响。当然，如果攻击者能够发起中间人攻击，则有许多其他拒绝服务的方法，例如仅丢弃请求。因此，这种攻击似乎并不重要。
There are no IANA considerations associated with this specification.
没有与本规范相关的IANA注意事项。
The IAB has studied a class of protocols referred to as Unilateral Self Address Fixing (UNSAF) protocols [5]. These protocols allow a client behind a NAT to learn the IP address and port that a NAT will allocate for a particular request, in order to use this information in application layer protocols. An example of an UNSAF protocol is the Simple Traversal of UDP Through NATs (STUN) [4].
IAB研究了一类称为单边自地址固定（UNSAF）协议的协议[5]。这些协议允许NAT后面的客户机了解NAT将为特定请求分配的IP地址和端口，以便在应用层协议中使用这些信息。UNSAF协议的一个例子是UDP通过NAT的简单遍历（STUN）[4]。
Any protocol is an UNSAF protocol if it reveals, to a client, the source IP address and port of a packet sent through that NAT. Although not designed for that purpose, this specification can be used as an UNSAF protocol. Using the "rport" parameter (defined here) and the "received" parameter (defined in RFC 3261 [1]) in the topmost Via header field value of a response, a client sending a request can learn its address as it was seen by the server which sent the response.
任何协议都是UNSAF协议，如果它向客户端显示通过该NAT发送的数据包的源IP地址和端口。尽管本规范并非为此目的而设计，但可作为UNSAF协议使用。使用响应最顶端的Via头字段值中的“rport”参数（此处定义）和“received”参数（在RFC 3261[1]中定义），发送请求的客户端可以了解发送响应的服务器看到的地址。
There are two uses of this information. The first is for registrations. Consider a client behind a NAT wishing to register with a proxy/registrar on the other side of the NAT. The client must provide, in its registration, the address at which it should receive incoming SIP requests from the proxy. However, since the client is located behind a NAT, none of the addresses on any of its interfaces will be reachable from the proxy. If the client can provide the proxy with an address that the proxy can reach, the client can receive incoming requests. Using this specification, a client behind a NAT can learn its address and port as seen by the proxy which receives a REGISTER request. The client can then perform an additional registration, using this address in a Contact header. This would allow a client to receive incoming requests, such as INVITE, on the IP address and port it used to populate the source IP address and port of the registration it sent. This approach will only work when servers send requests to a UA from the same address and port on which the REGISTER itself was received.
此信息有两种用途。第一个是注册。考虑NAT后面的客户端希望在NAT的另一侧注册代理/登记器。客户端必须在其注册中提供从代理接收传入SIP请求的地址。但是，由于客户机位于NAT后面，因此其任何接口上的地址都无法从代理访问。如果客户端可以向代理提供代理可以访问的地址，则客户端可以接收传入的请求。使用此规范，NAT后面的客户机可以了解接收注册请求的代理所看到的地址和端口。然后，客户端可以使用联系人标头中的此地址执行附加注册。这将允许客户端在用于填充其发送的源IP地址和注册端口的IP地址和端口上接收传入请求，如INVITE。只有当服务器从接收寄存器本身的相同地址和端口向UA发送请求时，这种方法才会起作用。
In many cases, the server to whom the registration is sent won't be the registrar itself, but rather a proxy which then sends the request to the registrar. In such a case, any incoming requests for the client must traverse the proxy to whom the registration was directly sent. The Path header extension to SIP [3] allows the proxy to indicate that it must be on the path of such requests.
在许多情况下，注册发送到的服务器不是注册器本身，而是一个代理，然后将请求发送给注册器。在这种情况下，客户端的任何传入请求都必须遍历直接向其发送注册的代理。SIP[3]的路径头扩展允许代理指示它必须位于此类请求的路径上。
The second usage is for record routing, to address the same problem as above, but between two proxies. A proxy behind a NAT which forwards a request to a server can use OPTIONS, for example, to learn its address as seen by that server. This address can be placed into the Record-Route header field of requests sent to that server. This would allow the proxy to receive requests from that server on the same IP address and port it used to populate the source IP address and port of the OPTIONS request.
第二个用途是记录路由，以解决与上述相同的问题，但在两个代理之间。NAT后面的代理将请求转发给服务器，它可以使用选项，例如，了解该服务器看到的地址。此地址可以放在发送到该服务器的请求的记录路由头字段中。这将允许代理在用于填充选项请求的源IP地址和端口的相同IP地址和端口上接收来自该服务器的请求。
Because of this potential usage, this document must consider the issues raised in [5].
由于这一潜在用途，该文件必须考虑在[ 5 ]中提出的问题。
From [5], any UNSAF proposal must provide:
从[5]开始，任何UNSAF提案必须提供：
Precise definition of a specific, limited-scope problem that is to be solved with the UNSAF proposal. A short term fix should not be generalized to solve other problems; this is why "short term fixes usually aren't".
精确定义一个具体的、范围有限的问题，该问题将通过UNSAF提案解决。短期解决方案不应泛化为解决其他问题；这就是为什么“短期修复通常不是”。
This specification is primarily aimed at allowing SIP responses to be received when a request is sent through a NAT. In this primary application, this specification is not an UNSAF proposal. However, as a side effect of this capability, this specification can be used as an UNSAF protocol. In that usage, it would address two issues:
本规范主要旨在允许通过NAT发送请求时接收SIP响应。在这一主要应用中，本规范不是UNSAF提案。但是，作为此功能的一个副作用，此规范可以用作UNSAF协议。在这种用法中，它将解决两个问题：
o Provide a client with an address that it could use in the Contact header of a REGISTER request when it is behind a NAT.
o 为客户端提供一个地址，当客户端位于NAT之后时，它可以在注册请求的联系人标头中使用该地址。
o Provide a proxy with an address that it could use in a Record-Route header in a request, when it is behind a NAT.
o 为代理提供一个地址，当代理位于NAT之后时，它可以在请求的记录路由头中使用该地址。
From [5], any UNSAF proposal must provide:
从[5]开始，任何UNSAF提案必须提供：
Description of an exit strategy/transition plan. The better short term fixes are the ones that will naturally see less and less use as the appropriate technology is deployed.
退出战略/过渡计划的说明。更好的短期修复方法是，随着适当技术的部署，自然会看到越来越少的使用。
The SIP working group has recognized that the usage of this specification to support registrations and record-routing through NATs is not appropriate. It has a number of known problems which are documented below. The way to eliminate potential usage of this specification for address fixing is to provide a proper solution to the problems that might motivate the usage of this specification for address fixing. Specifically, appropriate solutions for registrations and record-routing in the presence of NATs need to be developed. These solutions would not rely on address fixing.
SIP工作组已经认识到，使用本规范来支持通过NAT的注册和记录路由是不合适的。它有许多已知的问题，这些问题记录在下面。消除此规范用于地址固定的潜在用途的方法是为可能促使使用此规范进行地址固定的问题提供适当的解决方案。具体而言，需要为NAT中的注册和记录路由开发适当的解决方案。这些解决方案不会依赖于地址固定。
Requirements for such solutions are already under development [6].
此类解决方案的需求已经在开发中[6]。
Implementors of this specification are encouraged to follow this work for better solutions for registrations and record-routing through NAT.
鼓励本规范的实施者遵循这项工作，以获得通过NAT进行注册和记录路由的更好解决方案。
From [5], any UNSAF proposal must provide:
从[5]开始，任何UNSAF提案必须提供：
Discussion of specific issues that may render systems more "brittle". For example, approaches that involve using data at multiple network layers create more dependencies, increase debugging challenges, and make it harder to transition.
讨论可能使系统更“脆弱”的具体问题。例如，涉及在多个网络层使用数据的方法会产生更多的依赖性，增加调试挑战，并使转换更加困难。
This specification, if used for address fixing, introduces several points of brittleness into a SIP system:
如果用于地址固定，本规范会在SIP系统中引入几个脆弱点：
o If used for UDP registrations, a client will need to frequently re-register in order to keep the NAT bindings fresh. In many cases, these registrations will need to take place nearly one hundred times more frequently than the typical refresh interval of a registration. This introduces load into the system and hampers scalability.
o 如果用于UDP注册，客户端将需要经常重新注册以保持NAT绑定的新鲜。在许多情况下，这些注册需要比注册的典型刷新间隔频繁近百倍。这会将负载引入系统并妨碍可扩展性。
o A client cannot accurately determine the binding lifetime of a NAT it is registering (or record-routing) through. Therefore, there may be periods of unreachability that occur between the time a binding expires and the next registration or OPTIONS refresh is sent. This may result in missed calls, messages, or other information.
o 客户端无法准确地确定它正在注册（或记录路由）的NAT的绑定生存期。因此，在绑定到期和发送下一次注册或选项刷新之间可能会出现无法访问的时间段。这可能会导致未接来电、信息或其他信息。
o If the NAT is of the symmetric variety [4], a client will only be able to use its address to receive requests from the server it has sent the request to. If that server is one of many servers in a cluster, the client may not be able to receive requests from other servers in the cluster. This may result in missed calls, messages, or other information.
o 如果NAT是对称类型[4]，则客户端将只能使用其地址从其发送请求的服务器接收请求。如果该服务器是群集中多个服务器之一，则客户端可能无法接收来自群集中其他服务器的请求。这可能会导致未接来电、信息或其他信息。
o If the NAT is of the symmetric variety [4], a client will only be able to use its address to receive requests if the server sends requests to the client from the same address and port the server received the registrations on. This server behavior is not mandated by RFC 3261 [1], although it appears to be common in practice.
o 如果NAT是对称类型[4]，则只有当服务器从服务器接收注册的相同地址和端口向客户端发送请求时，客户端才能使用其地址接收请求。RFC 3261[1]没有强制要求这种服务器行为，尽管它在实践中似乎很常见。
o If the registrar and the server to whom the client sent its REGISTER request are not the same, the approach will only work if the server uses the Path header field [3]. There is not an easy and reliable way for the server to determine that the Path header should be used for a registration. Using Path when the address in the topmost Via header field is a private address will usually work, but may result in usage of Path when it is not actually needed.
o If the registrar and the server to whom the client sent its REGISTER request are not the same, the approach will only work if the server uses the Path header field [3]. There is not an easy and reliable way for the server to determine that the Path header should be used for a registration. Using Path when the address in the topmost Via header field is a private address will usually work, but may result in usage of Path when it is not actually needed.translate error, please retry
From [5], any UNSAF proposal must provide:
从[5]开始，任何UNSAF提案必须提供：
Identify requirements for longer term, sound technical solutions -- contribute to the process of finding the right longer term solution.
确定长期、可靠的技术解决方案的需求——为找到正确的长期解决方案的过程做出贡献。
The brittleness described in Section 9.3 has led us to the following requirements for a long term solution:
第9.3节中描述的脆性导致我们需要以下长期解决方案：
The client should not need to specify its address. Registrations and record routing require the client to specify the address at which it should receive requests. A sound technical solution should allow a client to explicitly specify that it wants to receive incoming requests on the connection over which the outgoing request was sent. In this way, the client does not need to specify its address.
客户端不需要指定其地址。注册和记录路由要求客户端指定接收请求的地址。合理的技术解决方案应该允许客户端明确指定它希望在发送传出请求的连接上接收传入请求。这样，客户端就不需要指定其地址。
The solution must deal with clusters of servers. In many commercially deployed SIP systems, there will be multiple servers, each at different addresses and ports, handling incoming requests for a client. The solution must explicitly consider this case.
解决方案必须处理服务器集群。在许多商业部署的SIP系统中，将有多个服务器，每个服务器位于不同的地址和端口，处理客户端的传入请求。解决方案必须明确地考虑这种情况。
The solution must not require increases in network load. There cannot be a penalty for a sound technical solution.
解决方案不得要求增加网络负载。健全的技术解决方案不会受到惩罚。
From [5], any UNSAF proposal must provide:
从[5]开始，任何UNSAF提案必须提供：
Discussion of the impact of the noted practical issues with existing, deployed NA[P]Ts and experience reports.
与现有的、已部署的NA[P]Ts和经验报告讨论指出的实际问题的影响。
To our knowledge, at the time of writing, there is only very limited usage of this specification for address fixing. Therefore, no specific practical issues have been raised.
据我们所知，在撰写本文时，此规范用于地址固定的用途非常有限。因此，没有提出具体的实际问题。
The authors would like to thank Rohan Mahy and Allison Mankin for their comments and contributions to this work.
作者要感谢Rohan Mahy和Allison Mankin对这项工作的评论和贡献。
[1] 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.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
[3] Willis，D.和B.Hoeneisen，“用于注册非相邻联系人的会话启动协议（SIP）扩展头字段”，RFC 3327，2002年12月。
[4] 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.
[4] Rosenberg，J.，Weinberger，J.，Huitema，C.和R.Mahy，“STUN-通过网络地址转换器（NAT）简单遍历用户数据报协议（UDP）”，RFC 3489，2003年3月。
[5] Daigle, L., Ed., and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[5] Daigle，L.，Ed.，和IAB，“网络地址转换中单边自地址固定（UNSAF）的IAB考虑”，RFC 34242002年11月。
[6] Mahy, R., "Requirements for Connection Reuse in the Session Initiation Protocol (SIP)", Work in Progress.
[6] Mahy，R.，“会话启动协议（SIP）中的连接重用要求”，正在进行中。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 US
Jonathan Rosenberg dynamicsoft 600美国新泽西州帕西帕尼拉尼德斯广场07054
Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net
Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027 US
Henning Schulzrinne哥伦比亚大学M/S 0401 1214美国纽约州阿姆斯特丹大道10027号
EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。