Internet Engineering Task Force (IETF) C. Boulton
Request for Comments: 6314 NS-Technologies
Category: Informational J. Rosenberg
ISSN: 2070-1721 Skype
G. Camarillo
Ericsson
F. Audet
Skype
July 2011
Internet Engineering Task Force (IETF) C. Boulton
Request for Comments: 6314 NS-Technologies
Category: Informational J. Rosenberg
ISSN: 2070-1721 Skype
G. Camarillo
Ericsson
F. Audet
Skype
July 2011
NAT Traversal Practices for Client-Server SIP
客户端服务器SIP的NAT遍历实践
Abstract
摘要
Traversal of the Session Initiation Protocol (SIP) and the sessions it establishes through Network Address Translators (NATs) is a complex problem. Currently, there are many deployment scenarios and traversal mechanisms for media traffic. This document provides concrete recommendations and a unified method for NAT traversal as well as documents corresponding flows.
会话初始化协议（SIP）及其通过网络地址转换器（NAT）建立的会话的遍历是一个复杂的问题。目前，有许多媒体流量的部署场景和遍历机制。本文档提供了NAT遍历的具体建议和统一方法，以及相应流程的文档。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6314.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6314.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您在以下方面的权利和限制：
to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
请参阅本文件。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Solution Technology Outline Description . . . . . . . . . . . 8
4.1. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Symmetric Response . . . . . . . . . . . . . . . . . . 8
4.1.2. Client-Initiated Connections . . . . . . . . . . . . . 9
4.2. Media Traversal . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . 10
4.2.2. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.3. STUN/TURN/ICE . . . . . . . . . . . . . . . . . . . . 11
5. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . . . 12
5.1. Basic NAT SIP Signaling Traversal . . . . . . . . . . . . 12
5.1.1. Registration (Registrar/Edge Proxy Co-Located) . . . . 12
5.1.2. Registration(Registrar/Edge Proxy Not Co-Located) . . 16
5.1.3. Initiating a Session . . . . . . . . . . . . . . . . . 19
5.1.4. Receiving an Invitation to a Session . . . . . . . . . 22
5.2. Basic NAT Media Traversal . . . . . . . . . . . . . . . . 27
5.2.1. Endpoint-Independent NAT . . . . . . . . . . . . . . . 28
5.2.2. Address/Port-Dependent NAT . . . . . . . . . . . . . . 48
6. IPv4-IPv6 Transition . . . . . . . . . . . . . . . . . . . . . 57
6.1. IPv4-IPv6 Transition for SIP Signaling . . . . . . . . . . 57
7. Security Considerations . . . . . . . . . . . . . . . . . . . 57
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
9.1. Normative References . . . . . . . . . . . . . . . . . . . 58
9.2. Informative References . . . . . . . . . . . . . . . . . . 59
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Solution Technology Outline Description . . . . . . . . . . . 8
4.1. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Symmetric Response . . . . . . . . . . . . . . . . . . 8
4.1.2. Client-Initiated Connections . . . . . . . . . . . . . 9
4.2. Media Traversal . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . 10
4.2.2. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.3. STUN/TURN/ICE . . . . . . . . . . . . . . . . . . . . 11
5. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . . . 12
5.1. Basic NAT SIP Signaling Traversal . . . . . . . . . . . . 12
5.1.1. Registration (Registrar/Edge Proxy Co-Located) . . . . 12
5.1.2. Registration(Registrar/Edge Proxy Not Co-Located) . . 16
5.1.3. Initiating a Session . . . . . . . . . . . . . . . . . 19
5.1.4. Receiving an Invitation to a Session . . . . . . . . . 22
5.2. Basic NAT Media Traversal . . . . . . . . . . . . . . . . 27
5.2.1. Endpoint-Independent NAT . . . . . . . . . . . . . . . 28
5.2.2. Address/Port-Dependent NAT . . . . . . . . . . . . . . 48
6. IPv4-IPv6 Transition . . . . . . . . . . . . . . . . . . . . . 57
6.1. IPv4-IPv6 Transition for SIP Signaling . . . . . . . . . . 57
7. Security Considerations . . . . . . . . . . . . . . . . . . . 57
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
9.1. Normative References . . . . . . . . . . . . . . . . . . . 58
9.2. Informative References . . . . . . . . . . . . . . . . . . 59
NAT (Network Address Translator) traversal has long been identified as a complex problem when considered in the context of the Session Initiation Protocol (SIP) [RFC3261] and its associated media such as the Real-time Transport Protocol (RTP) [RFC3550]. The problem is exacerbated by the variety of NATs that are available in the marketplace today and the large number of potential deployment scenarios. Details of different NATs behavior can be found in "NAT Behavioral Requirements for Unicast UDP" [RFC4787].
在会话发起协议（SIP）[RFC3261]及其相关媒体（如实时传输协议（RTP）[RFC3550]的上下文中，NAT（网络地址转换器）遍历一直被认为是一个复杂的问题。如今市场上提供的各种NAT以及大量潜在部署场景加剧了这一问题。有关不同NAT行为的详细信息，请参见“单播UDP的NAT行为要求”[RFC4787]。
The IETF has been active on many specifications for the traversal of NATs, including Session Traversal Utilities for NAT (STUN) [RFC5389], Interactive Connectivity Establishment (ICE) [RFC5245], symmetric response [RFC3581], symmetric RTP [RFC4961], Traversal Using Relay NAT (TURN) [RFC5766], SIP Outbound [RFC5626], the Session Description Protocol (SDP) attribute for RTP Control Protocol (RTCP) [RFC3605], "Multiplexing RTP Data and Control Packets on a Single Port" [RFC5761], and others. Each of these represents a part of the solution, but none of them gives the overall context for how the NAT traversal problem is decomposed and solved through this collection of specifications. This document serves to meet that need. It should be noted that this document intentionally does not invoke 'Best Current Practice' machinery as defined in RFC 2026 [RFC2026].
IETF在NAT穿越的许多规范上都是活跃的，包括NAT（STUN）[RFC5389]、交互式连接建立（ICE）[RFC5245]、对称响应[RFC3581]、对称RTP[RFC4961]、使用中继NAT（TURN）的穿越[RFC5766]、SIP出站[RFC5626]，RTP控制协议（RTCP）[RFC3605]、“在单个端口上多路复用RTP数据和控制数据包”[RFC5761]等的会话描述协议（SDP）属性。其中的每一个都代表了解决方案的一部分，但是没有一个给出NAT遍历问题是如何通过这些规范集合分解和解决的总体上下文。本文件旨在满足这一需要。应注意，本文件无意引用RFC 2026[RFC2026]中定义的“最佳现行做法”机制。
The document is split into two distinct sections as follows:
本文件分为以下两个不同部分：
o Section 4 provides a definitive set of best common practices to demonstrate the traversal of SIP and its associated media through NAT devices.
o 第4节提供了一组确定的最佳通用实践，以演示通过NAT设备遍历SIP及其相关媒体。
o Section 5 provides non-normative examples representing interactions of SIP using various NAT type deployments.
o 第5节提供了表示使用各种NAT类型部署的SIP交互的非规范性示例。
The document does not propose any new functionality but does draw on existing solutions for both core SIP signaling and media traversal (as defined in Section 4).
本文件未提出任何新功能，但在核心SIP信令和媒体遍历（如第4节所定义）方面借鉴了现有解决方案。
The best practices described in this document are for traditional "client-server"-style SIP. This term refers to the traditional use of the SIP protocol where User Agents talk to a series of intermediaries on a path to connect to a remote User Agent. It seems likely that other groups using SIP, for example, peer-to-peer SIP (P2PSIP), will recommend these same practices between a P2PSIP client and a P2PSIP peer, but will recommend different practices for use between peers in a peer-to-peer network.
本文档中描述的最佳实践适用于传统的“客户机-服务器”式SIP。该术语指的是SIP协议的传统用法，其中用户代理与路径上的一系列中介进行对话，以连接到远程用户代理。使用SIP的其他组（例如，对等SIP（P2PSIP））可能会在P2PSIP客户机和P2PSIP对等机之间推荐这些相同的实践，但会在对等网络中的对等机之间推荐不同的实践。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
It should be noted that the use of the term 'Endpoint-Independent NAT' in this document refers to a NAT that is both Endpoint-Independent Filtering and Endpoint-Independent Mapping per the definitions in RFC 4787 [RFC4787].
应注意，本文件中使用的术语“端点独立NAT”指的是根据RFC 4787[RFC4787]中的定义既是端点独立过滤又是端点独立映射的NAT。
The traversal of SIP through NATs can be split into two categories that both require attention: the core SIP signaling and associated media traversal. This document assumes NATs that do not contain SIP-aware Application Layer Gateways (ALGs), which makes much of the issues discussed in the document not applicable. ALGs have limitations (as per RFC 4787 [RFC4787] Section 7, RFC 3424 [RFC3424], and [RFC5245] Section 18.6), and experience shows they can have an adverse impact on the functionality of SIP. This includes problems such as requiring the media and signaling to traverse the same device and not working with encrypted signaling and/or payload.
通过NAT的SIP遍历可分为两类，这两类都需要注意：核心SIP信令和相关媒体遍历。本文档假设NAT不包含SIP感知应用层网关（ALG），这使得本文档中讨论的许多问题不适用。ALG有限制（根据RFC 4787[RFC4787]第7节、RFC 3424[RFC3424]和[RFC5245]第18.6节），经验表明，它们可能对SIP的功能产生不利影响。这包括诸如要求媒体和信令穿越同一设备以及不使用加密信令和/或有效负载等问题。
The use of non-TURN-based media intermediaries is not considered in this document. More information can be obtained from [RFC5853] and [MIDDLEBOXES].
本文件不考虑使用非回合制媒体中介。更多信息可从[RFC5853]和[Middlebox]获得。
The core SIP signaling has a number of issues when traversing through NATs.
当穿越NAT时，核心SIP信令有许多问题。
SIP response routing over UDP as defined in RFC 3261 [RFC3261] without extensions causes the response to be delivered to the source IP address specified in the topmost Via header, or the 'received' parameter of the topmost 'Via' header. The port is extracted from the SIP 'Via' header to complete the IP address/port combination for returning the SIP response. While the destination for the response is correct, the port contained in the SIP 'Via' header represents the listening port of the originating client and not the port representing the open pinhole on the NAT. This results in responses being sent back to the NAT but to a port that is likely not open for SIP traffic. The SIP response will then be dropped at the NAT. This is illustrated in Figure 1, which depicts a SIP response being returned to port 5060.
RFC 3261[RFC3261]中定义的UDP上的SIP响应路由（不带扩展）会导致将响应发送到最顶端的Via标头中指定的源IP地址，或最顶端的Via标头的“received”参数。端口从SIP“Via”头中提取，以完成IP地址/端口组合以返回SIP响应。虽然响应的目标是正确的，但SIP“Via”头中包含的端口表示发起客户端的侦听端口，而不是表示NAT上打开的针孔的端口。这导致响应被发送回NAT，但发送到可能不开放SIP通信的端口。然后，SIP响应将在NAT上丢弃。图1说明了这一点，它描述了返回到端口5060的SIP响应。
Private NAT Public
Network | Network
|
|
-------- SIP Request |open port 10923 --------
| |-------------------->--->-----------------------| |
| | | | |
| Client | |port 5060 SIP Response | Proxy |
| | x<------------------------| |
| | | | |
-------- | --------
|
|
|
Private NAT Public
Network | Network
|
|
-------- SIP Request |open port 10923 --------
| |-------------------->--->-----------------------| |
| | | | |
| Client | |port 5060 SIP Response | Proxy |
| | x<------------------------| |
| | | | |
-------- | --------
|
|
|
Figure 1: Failed Response
图1：失败的响应
Secondly, there are two cases where new requests reuse existing connections. The first is when using a reliable, connection-oriented transport protocol such as TCP, SIP has an inherent mechanism that results in SIP responses reusing the connection that was created/used for the corresponding transactional request. The SIP protocol does not provide a mechanism that allows new requests generated in the reverse direction of the originating client to use, for example, the existing TCP connection created between the client and the server during registration. This results in the registered contact address not being bound to the "connection" in the case of TCP. Requests are then blocked at the NAT, as illustrated in Figure 2. The second case is when using an unreliable transport protocol such as UDP where external NAT mappings need to be reused to reach a SIP entity on the private side of the network.
其次，有两种情况下，新请求重用现有连接。第一种是当使用可靠的、面向连接的传输协议（如TCP）时，SIP具有一种固有的机制，导致SIP响应重用为相应事务请求创建/使用的连接。SIP协议不提供允许在发起客户端的相反方向生成的新请求使用（例如）注册期间在客户端和服务器之间创建的现有TCP连接的机制。这导致注册的联系人地址在TCP情况下不绑定到“连接”。然后在NAT上阻止请求，如图2所示。第二种情况是使用不可靠的传输协议（如UDP）时，需要重用外部NAT映射以到达网络专用端的SIP实体。
Private NAT Public
Network | Network
|
|
-------- (UAC 8023) REGISTER/Response (UAS 5060) --------
| |-------------------->---<-----------------------| |
| | | | |
| Client | |5060 INVITE (UAC 8015)| Proxy |
| | x<------------------------| |
| | | | |
-------- | --------
|
|
|
Private NAT Public
Network | Network
|
|
-------- (UAC 8023) REGISTER/Response (UAS 5060) --------
| |-------------------->---<-----------------------| |
| | | | |
| Client | |5060 INVITE (UAC 8015)| Proxy |
| | x<------------------------| |
| | | | |
-------- | --------
|
|
|
Figure 2: Failed Request
图2：失败的请求
In Figure 2, the original REGISTER request is sent from the client on port 8023 and received by the proxy on port 5060, establishing a connection and opening a pinhole in the NAT. The generation of a new request from the proxy results in a request destined for the registered entity (contact IP address) that is not reachable from the public network. This results in the new SIP request attempting to create a connection to a private network address. This problem would be solved if the original connection were reused. While this problem has been discussed in the context of connection-oriented protocols such as TCP, the problem exists for SIP signaling using any transport protocol. The impact of connection reuse of connection-oriented transports (TCP, TLS, etc.) is discussed in more detail in the connection reuse specification [RFC5923]. The approach proposed for this problem in Section 4 of this document is relevant for all SIP signaling in conjunction with connection reuse, regardless of the transport protocol.
在图2中，原始注册请求从端口8023上的客户端发送，并由端口5060上的代理接收，从而建立连接并在NAT中打开一个针孔。从代理生成新请求会导致以注册实体（联系人IP地址）为目的地的请求无法从公共网络访问。这导致新的SIP请求尝试创建到专用网络地址的连接。如果重新使用原始连接，此问题将得到解决。虽然已经在面向连接的协议（如TCP）的上下文中讨论了这个问题，但是使用任何传输协议的SIP信令都存在这个问题。连接重用规范[RFC5923]更详细地讨论了面向连接的传输（TCP、TLS等）的连接重用的影响。本文档第4节中针对该问题提出的方法与所有SIP信令以及连接重用相关，而与传输协议无关。
NAT policy can dictate that connections should be closed after a period of inactivity. This period of inactivity may vary from a number of seconds to hours. SIP signaling cannot be relied upon to keep connections alive for the following two reasons. Firstly, SIP entities can sometimes have no signaling traffic for long periods of time, which has the potential to exceed the inactivity timer, and this can lead to problems where endpoints are not available to receive incoming requests as the connection has been closed. Secondly, if a low inactivity timer is specified, SIP signaling is not appropriate as a keep-alive mechanism as it has the potential to add a large amount of traffic to the network, which uses up valuable resources and also requires processing at a SIP stack, which is also a waste of processing resources.
NAT策略可以规定在一段时间不活动后应关闭连接。这段不活动的时间可能从几秒到几小时不等。由于以下两个原因，不能依靠SIP信令保持连接的活动状态。首先，SIP实体有时可能长时间没有信令流量，这有可能超过非活动计时器，这可能导致端点在连接关闭时无法接收传入请求的问题。其次，如果指定了低非活动计时器，则SIP信令不适合作为保持活动的机制，因为它可能会向网络添加大量流量，这会消耗宝贵的资源，并且还需要在SIP堆栈上进行处理，这也是对处理资源的浪费。
Media associated with SIP calls also has problems traversing NAT. RTP [RFC3550] runs over UDP and is one of the most common media transport types used in SIP signaling. Negotiation of RTP occurs with a SIP session establishment using the Session Description Protocol (SDP) [RFC4566] and a SIP offer/answer exchange [RFC3264]. During a SIP offer/answer exchange, an IP address and port combination are specified by each client in a session as a means of receiving media such as RTP. The problem arises when a client advertises its address to receive media and it exists in a private network that is not accessible from outside the NAT. Figure 3 illustrates this problem.
与SIP呼叫关联的媒体在穿越NAT时也存在问题。RTP[RFC3550]通过UDP运行，是SIP信令中使用的最常见的媒体传输类型之一。RTP的协商通过使用会话描述协议（SDP）[RFC4566]和SIP提供/应答交换[RFC3264]的SIP会话建立来进行。在SIP提供/应答交换期间，会话中的每个客户端指定IP地址和端口组合作为接收媒体（例如RTP）的手段。当客户机公布其地址以接收媒体，而该地址存在于NAT外部无法访问的专用网络中时，就会出现问题。图3说明了这个问题。
NAT Public Network NAT
| |
| |
| |
-------- | SIP Signaling Session | --------
| |---------------------->Proxy<-------------------| |
| | | | | |
| Client | | | | Client |
| A |>=====>RTP>==Unknown Address==>X | | B |
| | | X<==Unknown Address==<RTP<===<| |
-------- | | --------
| |
| |
| |
NAT Public Network NAT
| |
| |
| |
-------- | SIP Signaling Session | --------
| |---------------------->Proxy<-------------------| |
| | | | | |
| Client | | | | Client |
| A |>=====>RTP>==Unknown Address==>X | | B |
| | | X<==Unknown Address==<RTP<===<| |
-------- | | --------
| |
| |
| |
Figure 3: Failed Media
图3：失败的介质
The connection addresses of the clients behind the NATs will nominally contain a private IPv4 address that is not routable across the public Internet. Exacerbating matters even more would be the tendency of Client A to send media to a destination address it received in the signaling confirmation message -- an address that may actually correspond to a host within the private network who is suddenly faced with incoming RTP packets (likewise, Client B may send media to a host within its private network who did not solicit these packets). Finally, to complicate the problem even further, a number of different NAT topologies with different default behaviors increases the difficulty of arriving at a unified approach. This problem exists for all media transport protocols that might be NATted (e.g., TCP, UDP, the Stream Control Transmission Protocol (SCTP), the Datagram Congestion Control Protocol (DCCP)).
NAT后面的客户端的连接地址名义上包含一个私有IPv4地址，该地址不能通过公共互联网路由。更糟糕的是，客户端A倾向于将媒体发送到它在信令确认消息中接收到的目的地地址——该地址实际上可能对应于私有网络中突然面临传入RTP数据包的主机（类似地，客户端B可以向其专用网络中未请求这些数据包的主机发送媒体）最后，使问题更加复杂的是，许多具有不同默认行为的不同NAT拓扑增加了达成统一方法的难度。此问题适用于所有可能进行NAT的媒体传输协议（例如TCP、UDP、流控制传输协议（SCTP）），数据报拥塞控制协议（DCCP））。
In general, the problems associated with NAT traversal can be categorized as follows.
一般来说，与NAT遍历相关的问题可以分类如下。
For signaling:
对于信号：
o Responses do not reuse the NAT mapping and filtering entries created by the request.
o 响应不会重用由请求创建的NAT映射和筛选条目。
o Inbound requests are filtered out by the NAT because there is no long-term connection between the client and the proxy.
o 入站请求被NAT过滤掉，因为客户端和代理之间没有长期连接。
For media:
对于媒体：
o Each endpoint has a variety of addresses that can be used to reach it (e.g., native interface address, public NATted address). In different situations, a different pair of (local endpoint, remote endpoint) addresses should be used, and it is not clear when to use which pair.
o 每个端点都有各种可用于访问它的地址（例如，本机接口地址、公共NATED地址）。在不同的情况下，应该使用不同的一对（本地端点、远程端点）地址，并且不清楚何时使用哪一对。
o Many NATs filter inbound packets if the local endpoint has not recently sent an outbound packet to the sender.
o 如果本地端点最近没有向发送方发送出站数据包，则许多NAT会过滤入站数据包。
o Classic RTCP usage is to run RTCP on the next highest port. However, NATs do not necessarily preserve port adjacency.
o 经典的RTCP用法是在下一个最高端口上运行RTCP。但是，NAT不一定保持端口邻接。
o Classic RTP and RTCP usage is to use different 5-tuples for traffic in each direction. Though not really a problem, doing this through NATs is more work than using the same 5-tuple in both directions.
o 经典的RTP和RTCP用法是对每个方向的流量使用不同的5元组。虽然这不是一个真正的问题，但通过NAT实现这一点要比在两个方向上使用相同的5元组做更多的工作。
As mentioned previously, the traversal of SIP through existing NATs can be divided into two discrete problem areas: getting the SIP signaling across NATs and enabling media as specified by SDP in a SIP offer/answer exchange to flow between endpoints.
如前所述，通过现有NAT对SIP的遍历可分为两个离散的问题区域：跨NAT获取SIP信令和使SIP提供/应答交换中SDP指定的媒体能够在端点之间流动。
SIP signaling has two areas that result in transactional failure when traversing through NATs, as described in Section 3 of this document. The remaining sub-sections describe appropriate solutions that result in SIP signaling traversal through NATs, regardless of transport protocol. It is advised that SIP-compliant entities follow the guidelines presented in this section to enable traversal of SIP signaling through NATs.
SIP信令有两个方面，在穿越NAT时会导致事务失败，如本文档第3节所述。剩下的小节描述了导致通过NAT进行SIP信令遍历的适当解决方案，而不考虑传输协议。建议符合SIP的实体遵循本节中介绍的指导原则，以便能够通过NAT遍历SIP信令。
As described in Section 3 of this document, when using an unreliable transport protocol such as UDP, SIP responses are sent to the IP address and port combination contained in the SIP 'Via' header field (or default port for the appropriate transport protocol if not present). Figure 4 illustrates the response traversal through the open pinhole using Symmetric techniques defined in RFC 3581 [RFC3581].
如本文件第3节所述，当使用不可靠的传输协议（如UDP）时，SIP响应将发送到SIP“Via”头字段中包含的IP地址和端口组合（或适当传输协议的默认端口，如果不存在）。图4说明了使用RFC 3581[RFC3581]中定义的对称技术通过开放针孔的响应遍历。
Private NAT Public
Network | Network
|
|
-------- | --------
| | | | |
| |send request---------------------------------->| |
| Client |<---------------------------------send response| SIP |
| A | | | Proxy |
| | | | |
-------- | --------
|
|
|
Private NAT Public
Network | Network
|
|
-------- | --------
| | | | |
| |send request---------------------------------->| |
| Client |<---------------------------------send response| SIP |
| A | | | Proxy |
| | | | |
-------- | --------
|
|
|
Figure 4: Symmetric Response
图4：对称响应
The outgoing request from Client A opens a pinhole in the NAT. The SIP Proxy would normally respond to the port available in the SIP 'Via' header, as illustrated in Figure 1. The SIP Proxy honors the 'rport' parameter in the SIP 'Via' header and routes the response to the port from which it was sent. The exact functionality for this method of response traversal is called 'Symmetric Response', and the details are documented in RFC 3581 [RFC3581]. Additional requirements are imposed on SIP entities in RFC 3581 [RFC3581] such as listening and sending SIP requests/responses from the same port.
来自客户端A的传出请求会在NAT中打开一个针孔。SIP代理通常会响应SIP“Via”头中可用的端口，如图1所示。SIP代理接受SIP“Via”头中的“rport”参数，并将响应路由到发送它的端口。这种响应遍历方法的确切功能称为“对称响应”，详细信息记录在RFC 3581[RFC3581]中。RFC 3581[RFC3581]中对SIP实体提出了附加要求，例如从同一端口侦听和发送SIP请求/响应。
The second problem with SIP signaling, as defined in Section 3 and illustrated in Figure 2, is to allow incoming requests to be properly routed.
SIP信令的第二个问题（如第3节所定义和图2所示）是允许正确路由传入请求。
Guidelines for devices such as User Agents that can only generate outbound connections through NATs are documented in "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)" [RFC5626]. The document provides techniques that use a unique User Agent instance identifier (instance-id) in association with a flow identifier (reg-id). The combination of the two identifiers provides a key to a particular connection (both UDP and TCP) that is stored in association with registration bindings. On receiving an incoming request to a SIP Address-Of-Record (AOR), a proxy/registrar routes to the associated flow created by the registration and thus a route through NATs. It also provides a keep-alive mechanism for clients to keep NAT bindings alive. This is achieved by multiplexing a ping-pong mechanism over the SIP signaling connection (STUN for UDP and
关于诸如只能通过NAT生成出站连接的用户代理之类的设备的指南，请参见“在会话启动协议（SIP）中管理客户端启动的连接”[RFC5626]。本文档提供了使用唯一的用户代理实例标识符（实例id）和流标识符（reg id）的技术。这两个标识符的组合为与注册绑定关联存储的特定连接（UDP和TCP）提供密钥。在接收到对SIP记录地址（AOR）的传入请求时，代理/注册器路由到由注册创建的关联流，从而路由到NAT。它还为客户端提供了保持NAT绑定活动的机制。这是通过在SIP信令连接上多路复用乒乓机制来实现的（STUN用于UDP和
CRLF/operating system keepalive for reliable transports like TCP). Usage of [RFC5626] is RECOMMENDED. This mechanism is not transport specific and should be used for any transport protocol.
CRLF/操作系统保持可靠传输（如TCP）。建议使用[RFC5626]。此机制不是特定于传输的，应用于任何传输协议。
Even if the SIP Outbound mechanism is not used, clients generating SIP requests SHOULD use the same IP address and port (i.e., socket) for both transmission and receipt of SIP messages. Doing so allows for the vast majority of industry provided solutions to properly function (e.g., NAT traversal that is Session Border Control (SBC) hosted). Deployments should also consider the mechanism described in the Connection Reuse [RFC5923] specification for routing bidirectional messages securely between trusted SIP Proxy servers.
即使没有使用SIP出站机制，生成SIP请求的客户端也应该使用相同的IP地址和端口（即套接字）来传输和接收SIP消息。这样做可以让绝大多数行业提供的解决方案正常运行（例如，承载会话边界控制（SBC）的NAT遍历）。部署还应该考虑在连接重用[RCF59223 ]规范中描述的用于在可信SIP代理服务器之间安全地路由双向消息的机制。
The issues of media traversal through NATs is not straightforward and requires the combination of a number of traversal methodologies. The technologies outlined in the remainder of this section provide the required solution set.
通过NAT的媒体遍历问题并不简单，需要多种遍历方法的组合。本节剩余部分概述的技术提供了所需的解决方案集。
The primary problem identified in Section 3 of this document is that internal IP address/port combinations cannot be reached from the public side of NATs. In the case of media such as RTP, this will result in no audio traversing NATs (as illustrated in Figure 3). To overcome this problem, a technique called 'Symmetric RTP/RTCP' [RFC4961] can be used. This involves a SIP endpoint both sending and receiving RTP/RTCP traffic from the same IP address/port combination. When operating behind a NAT and using the 'latching' technique described in [MIDDLEBOXES], SIP User Agents MUST implement Symmetric RTP/RTCP. This allows traversal of RTP across the NAT.
本文档第3节中确定的主要问题是无法从NAT的公共端访问内部IP地址/端口组合。在诸如RTP这样的媒体的情况下，这将导致没有音频穿越NAT（如图3所示）。为了克服这个问题，可以使用一种称为“对称RTP/RTCP”[RFC4961]的技术。这涉及SIP端点从同一IP地址/端口组合发送和接收RTP/RTCP流量。当在NAT后面操作并使用[Middlebox]中描述的“锁存”技术时，SIP用户代理必须实现对称RTP/RTCP。这允许跨NAT遍历RTP。
Normal practice when selecting a port for defining RTP Control Protocol (RTCP) [RFC3550] is for consecutive-order numbering (i.e., select an incremented port for RTCP from that used for RTP). This assumption causes RTCP traffic to break when traversing certain types of NATs due to various reasons (e.g., already allocated port, randomized port allocation). To combat this problem, a specific address and port need to be specified in the SDP rather than relying on such assumptions. RFC 3605 [RFC3605] defines an SDP attribute that is included to explicitly specify transport connection information for RTCP so a separate, explicit NAT binding can be set up for the purpose. The address details can be obtained using any appropriate method including those detailed in this section (e.g., STUN, TURN, ICE).
选择用于定义RTP控制协议（RTCP）的端口时的正常做法[RFC3550]用于连续订单编号（即，从用于RTP的端口中为RTCP选择递增端口）。由于各种原因（例如，已分配的端口、随机端口分配），此假设导致RTCP流量在穿越某些类型的NAT时中断。为了解决这个问题，需要在SDP中指定特定的地址和端口，而不是依赖这些假设。RFC 3605[RFC3605]定义了一个SDP属性，该属性用于显式指定RTCP的传输连接信息，因此可以为此目的设置单独的显式NAT绑定。地址详细信息可以使用任何适当的方法获得，包括本节中详述的方法（例如，眩晕、转身、ICE）。
A further enhancement to RFC 3605 [RFC3605] is defined in [RFC5761], which specifies 'muxing' both RTP and RTCP on the same IP/PORT combination.
[RFC5761]中定义了对RFC 3605[RFC3605]的进一步增强，该增强指定在同一IP/端口组合上同时“muxing”RTP和RTCP。
ICE, STUN, and TURN are a suite of 3 inter-related protocols that combine to provide a complete media traversal solution for NATs. The following sections provide details of each component part.
ICE、STUN和TURN是一套由3个相互关联的协议组成的套件，它们结合起来为NAT提供了一个完整的媒体穿越解决方案。以下各节提供了每个组成部分的详细信息。
Session Traversal Utilities for NAT or STUN is defined in RFC 5389 [RFC5389]. STUN is a lightweight tool kit and protocol that provides details of the external IP address/port combination used by the NAT device to represent the internal entity on the public facing side of NATs. On learning of such an external representation, a client can use it accordingly as the connection address in SDP to provide NAT traversal. Using terminology defined in "NAT Behavioral Requirements for Unicast UDP" [RFC4787], STUN does work with Endpoint-Independent Mapping but does not work with either Address-Dependent Mapping or Address and Port-Dependent Mapping type NATs. Using STUN with either of the previous two NAT mappings to probe for the external IP address/port representation will provide a different result to that required for traversal by an alternative SIP entity. The IP address/ port combination deduced for the STUN server would be blocked for RTP packets from the remote SIP User Agent.
NAT或STUN的会话遍历实用程序在RFC 5389[RFC5389]中定义。STUN是一个轻量级工具包和协议，提供NAT设备用于表示NAT面向公众端的内部实体的外部IP地址/端口组合的详细信息。在了解到这种外部表示后，客户机可以相应地将其用作SDP中的连接地址，以提供NAT遍历。使用“单播UDP的NAT行为要求”[RFC4787]中定义的术语，STUN可以使用与端点无关的映射，但不能使用与地址相关的映射或与地址和端口相关的映射类型NAT。将STUN与前两个NAT映射中的任何一个一起使用，以探测外部IP地址/端口表示，将提供不同于由替代SIP实体进行遍历所需的结果。对于来自远程SIP用户代理的RTP数据包，STUN服务器的IP地址/端口组合将被阻止。
As mentioned in Section 4.1.2, STUN is also used as a client-to-server keep-alive mechanism to refresh NAT bindings.
如第4.1.2节所述，STUN还用作客户端到服务器的保持活动机制，以刷新NAT绑定。
As described in Section 4.2.3.1, the STUN protocol does not work for UDP traversal through certain identified NAT mappings. 'Traversal Using Relays around NAT' is a usage of the STUN protocol for deriving (from a TURN server) an address that will be used to relay packets towards a client. TURN provides an external address (globally routable) at a TURN server that will act as a media relay that attempts to allow traffic to reach the associated internal address. The full details of the TURN specification are defined in [RFC5766]. A TURN service will almost always provide media traffic to a SIP entity, but it is RECOMMENDED that this method would only be used as a last resort and not as a general mechanism for NAT traversal. This is because using TURN has high performance costs when relaying media traffic and can lead to unwanted latency.
如第4.2.3.1节所述，STUN协议不适用于通过某些已识别NAT映射进行UDP遍历。”使用NAT周围的中继进行遍历’是使用STUN协议来派生（从TURN服务器）地址，该地址将用于向客户端中继数据包。TURN在TURN服务器上提供一个外部地址（全局可路由），该地址将充当媒体中继，尝试允许流量到达相关的内部地址。转弯规范的全部细节在[RFC5766]中定义。TURN服务几乎总是向SIP实体提供媒体流量，但建议仅将此方法用作最后手段，而不是NAT遍历的一般机制。这是因为在中继媒体流量时，使用TURN具有较高的性能成本，并可能导致不必要的延迟。
Interactive Connectivity Establishment (ICE) is the RECOMMENDED method for traversal of existing NATs if Symmetric RTP and media latching are not sufficient. ICE is a methodology for using existing technologies such as STUN, TURN, and any other protocol compliant with Unilateral Self-Address Fixing (NSAF) [RFC3424] to provide a unified solution. This is achieved by obtaining as many representative IP address/port combinations as possible using technologies such as STUN/TURN (note: an ICE endpoint can also use other mechanisms (e.g., the NAT Port Mapping Protocol [NAT-PMP], Universal Plug and Play Internet Gateway Device [UPnP-IGD]) to learn public IP addresses and ports, and populate a=candidate lines with that information). Once the addresses are accumulated, they are all included in the SDP exchange in a new media attribute called 'candidate'. Each candidate SDP attribute entry has detailed connection information including a media address, priority, and transport protocol. The appropriate IP address/port combinations are used in the order specified by the priority. A client compliant to the ICE specification will then locally run STUN servers on all addresses being advertised using ICE. Each instance will undertake connectivity checks to ensure that a client can successfully receive media on the advertised address. Only connections that pass the relevant connectivity checks are used for media exchange. The full details of the ICE methodology are in [RFC5245].
如果对称RTP和媒体锁存不足，建议使用交互式连接建立（ICE）方法遍历现有NAT。ICE是一种使用现有技术（如STUN、TURN和任何其他符合单边自地址固定（NSAF）[RFC3424]的协议）来提供统一解决方案的方法。这是通过使用STUN/TURN等技术获得尽可能多的代表性IP地址/端口组合来实现的（注：ICE端点也可以使用其他机制（例如NAT端口映射协议[NAT-PMP]、通用即插即用互联网网关设备[UPnP IGD]）了解公共IP地址和端口，并用该信息填充a=候选行）。一旦这些地址被累积，它们都将被包含在SDP交换中，并被称为“候选”的新媒体属性中。每个候选SDP属性条目都有详细的连接信息，包括媒体地址、优先级和传输协议。按照优先级指定的顺序使用适当的IP地址/端口组合。然后，符合ICE规范的客户端将在使用ICE发布的所有地址上本地运行STUN服务器。每个实例都将进行连接检查，以确保客户机能够成功接收广告地址上的媒体。只有通过相关连接检查的连接才能用于媒体交换。ICE方法的全部细节见[RFC5245]。
This section of the document includes detailed NAT traversal scenarios for both SIP signaling and the associated media. Signaling NAT traversal is achieved using [RFC5626].
本文档的这一部分包括SIP信令和相关媒体的详细NAT穿越场景。使用[RFC5626]实现信令NAT穿越。
The following sub-sections concentrate on SIP signaling traversal of NATs. The scenarios include traversal for both reliable and unreliable transport protocols.
以下小节主要介绍NAT的SIP信令遍历。这些场景包括可靠和不可靠传输协议的遍历。
The set of scenarios in this section document basic signaling traversal of a SIP REGISTER method through NATs.
本节中的场景集记录了通过NAT的SIP寄存器方法的基本信令遍历。
Registrar/
Bob NAT Edge Proxy
| | |
|(1) REGISTER | |
|----------------->| |
| | |
| |(1) REGISTER |
| |----------------->|
| | |
|*************************************|
| Create Outbound Connection Tuple |
|*************************************|
| | |
| |(2) 200 OK |
| |<-----------------|
| | |
|(2) 200 OK | |
|<-----------------| |
| | |
Registrar/
Bob NAT Edge Proxy
| | |
|(1) REGISTER | |
|----------------->| |
| | |
| |(1) REGISTER |
| |----------------->|
| | |
|*************************************|
| Create Outbound Connection Tuple |
|*************************************|
| | |
| |(2) 200 OK |
| |<-----------------|
| | |
|(2) 200 OK | |
|<-----------------| |
| | |
Figure 5: UDP Registration
图5:UDP注册
In this example, the client sends a SIP REGISTER request through a NAT. The client will include an 'rport' parameter as described in Section 4.1.1 of this document for allowing traversal of UDP responses. The original request as illustrated in (1) in Figure 5 is a standard SIP REGISTER message:
在本例中，客户端通过NAT发送SIP注册请求。客户端将包括一个“rport”参数，如本文档第4.1.1节所述，用于允许遍历UDP响应。图5中（1）所示的原始请求是标准SIP寄存器消息：
Message 1:
信息1：
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2;rport;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
Contact: <sip:bob@192.168.1.2 >;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/UDP 192.168.1.2;rport;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
Contact: <sip:bob@192.168.1.2 >;reg-id=1
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0
This SIP transaction now generates a SIP 200 OK response, as depicted in (2) from Figure 5:
该SIP事务现在生成SIP 200 OK响应，如图5（2）所示：
Message 2:
信息2：
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.2;rport=8050;branch=z9hG4bKnashds7;
received=172.16.3.4
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.168.1.2 >;reg-id=1;expires=3600
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.2;rport=8050;branch=z9hG4bKnashds7;
received=172.16.3.4
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.168.1.2 >;reg-id=1;expires=3600
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0
The response will be sent to the address appearing in the 'received' parameter of the SIP 'Via' header (address 172.16.3.4). The response will not be sent to the port deduced from the SIP 'Via' header, as per standard SIP operation but will be sent to the value that has been stamped in the 'rport' parameter of the SIP 'Via' header (port 8050). For the response to successfully traverse the NAT, all of the conventions defined in RFC 3581 [RFC3581] are to be obeyed. Make note of both the 'reg-id' and 'sip.instance' contact header parameters. They are used to establish an outbound connection tuple as defined in [RFC5626]. The connection tuple creation is clearly shown in Figure 5. This ensures that any inbound request that causes a registration lookup will result in the reuse of the connection path established by the registration. This removes the need to manipulate contact header URIs to represent a globally routable address as perceived on the public side of a NAT.
响应将发送到SIP“Via”头的“received”参数中出现的地址（地址172.16.3.4）。根据标准SIP操作，响应将不会发送到从SIP“Via”报头推断出的端口，而是发送到SIP“Via”报头（端口8050）的“rport”参数中压印的值。为使响应成功穿越NAT，应遵守RFC 3581[RFC3581]中定义的所有约定。记下'reg id'和'sip.instance'联系人标头参数。它们用于建立[RFC5626]中定义的出站连接元组。连接元组的创建如图5所示。这将确保导致注册查找的任何入站请求都将导致重新使用注册所建立的连接路径。这样就不需要操纵联系人头URI来表示NAT公共端感知的全局可路由地址。
Registrar/
Bob NAT Edge Proxy
| | |
|(1) REGISTER | |
|----------------->| |
| | |
| |(1) REGISTER |
| |----------------->|
| | |
|*************************************|
| Create Outbound Connection Tuple |
|*************************************|
| | |
| |(2) 200 OK |
| |<-----------------|
| | |
|(2) 200 OK | |
|<-----------------| |
| | |
Registrar/
Bob NAT Edge Proxy
| | |
|(1) REGISTER | |
|----------------->| |
| | |
| |(1) REGISTER |
| |----------------->|
| | |
|*************************************|
| Create Outbound Connection Tuple |
|*************************************|
| | |
| |(2) 200 OK |
| |<-----------------|
| | |
|(2) 200 OK | |
|<-----------------| |
| | |
Figure 6
图6
Traversal of SIP REGISTER requests/responses using a reliable, connection-oriented protocol such as TCP does not require any additional core SIP signaling extensions, beyond the procedures defined in [RFC5626]. SIP responses will reuse the connection created for the initial REGISTER request, (1) from Figure 6:
除了[RFC5626]中定义的过程外，使用可靠的、面向连接的协议（如TCP）遍历SIP寄存器请求/响应不需要任何额外的核心SIP信令扩展。SIP响应将重用为初始注册请求（1）创建的连接，如图6所示：
Message 1:
信息1：
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP 192.168.1.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
Contact: <sip:bob@192.168.1.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.168.1.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
Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=1
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0
Message 2:
信息2：
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.1.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.168.1.2;transport=tcp>;reg-id=1;expires=3600
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.1.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.168.1.2;transport=tcp>;reg-id=1;expires=3600
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0
This example was included to show the inclusion of the 'sip.instance' contact header parameter as defined in the SIP Outbound specification [RFC5626]. This creates an association tuple as described in the previous example for future inbound requests directed at the newly created registration binding with the only difference that the association is with a TCP connection, not a UDP pinhole binding.
包含此示例是为了显示包含sip出站规范[RFC5626]中定义的“sip.instance”联系人标头参数。这将为指向新创建的注册绑定的未来入站请求创建一个关联元组（如前一示例中所述），唯一的区别是关联是TCP连接，而不是UDP针孔绑定。
This section demonstrates traversal mechanisms when the Registrar component is not co-located with the edge proxy element. The procedures described in this section are identical, regardless of transport protocol, so only one example will be documented in the form of TCP.
本节演示当注册器组件与边缘代理元素不在同一位置时的遍历机制。无论传输协议如何，本节中描述的过程都是相同的，因此仅以TCP的形式记录一个示例。
Bob NAT Edge Proxy Registrar
| | | |
|(1) REGISTER | | |
|----------------->| | |
| | | |
| |(1) REGISTER | |
| |----------------->| |
| | | |
| | |(2) REGISTER |
| | |----------------->|
| | | |
|*************************************| |
| Create Outbound Connection Tuple | |
|*************************************| |
| | | |
| | |(3) 200 OK |
| | |<-----------------|
| |(4)200 OK | |
| |<-----------------| |
| | | |
|(4)200 OK | | |
|<-----------------| | |
| | | |
Bob NAT Edge Proxy Registrar
| | | |
|(1) REGISTER | | |
|----------------->| | |
| | | |
| |(1) REGISTER | |
| |----------------->| |
| | | |
| | |(2) REGISTER |
| | |----------------->|
| | | |
|*************************************| |
| Create Outbound Connection Tuple | |
|*************************************| |
| | | |
| | |(3) 200 OK |
| | |<-----------------|
| |(4)200 OK | |
| |<-----------------| |
| | | |
|(4)200 OK | | |
|<-----------------| | |
| | | |
Figure 7: Registration (Registrar/Proxy Not Co-Located)
图7：登记（登记员/代理人不在同一地点）
This scenario builds on the previous example in Section 5.1.1.2. The primary difference is that the REGISTER request is routed onwards from a proxy server to a separated Registrar. The important message to note is (1) in Figure 7. The edge proxy, on receiving a REGISTER request that contains a 'sip.instance' media feature tag, forms a unique flow identifier token as discussed in [RFC5626]. At this point, the proxy server routes the SIP REGISTER message to the Registrar. The proxy will create the connection tuple as described in SIP Outbound at the same moment as the co-located example, but for subsequent messages to arrive at the proxy, the proxy needs to indicate its need to remain in the SIP signaling path. To achieve this, the proxy inserts to REGISTER message (2) a SIP 'Path' extension header, as defined in RFC 3327 [RFC3327]. The previously created flow association token is inserted in a position within the Path header where it can easily be retrieved at a later point when receiving messages to be routed to the registration binding (in this case the user part of the SIP URI). The REGISTER message of (1) includes a SIP 'Route' header for the edge proxy.
此场景基于第5.1.1.2节中的前一个示例。主要区别在于注册请求从代理服务器路由到单独的注册器。需要注意的重要消息是图7中的（1）。边缘代理在接收到包含“sip.instance”媒体功能标签的注册请求时，形成一个唯一的流标识符令牌，如[RFC5626]中所述。此时，代理服务器将SIP REGISTER消息路由到注册器。代理将在同一时刻创建SIP Outbound中所述的连接元组（与同一位置的示例相同），但对于要到达代理的后续消息，代理需要指示其需要保留在SIP信令路径中。为了实现这一点，代理插入一个SIP“Path”扩展头以注册消息（2），如RFC 3327[RFC3327]中所定义。先前创建的流关联令牌被插入路径头中的某个位置，在稍后接收要路由到注册绑定的消息时（在本例中是SIP URI的用户部分），可以在该位置轻松检索该令牌。（1）的注册消息包括边缘代理的SIP“路由”头。
Message 1:
信息1：
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP 192.168.1.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.168.1.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.168.1.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.168.1.2;transport=tcp>;reg-id=1
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0
When proxied in (2) looks as follows:
当在（2）中进行代理时，如下所示：
Message 2:
信息2：
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP ep1.example.com;branch=z9hG4bKnuiqisi
Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7
Max-Forwards: 69
From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com>
Call-ID: 16CB75F21C70
CSeq: 1 REGISTER
Supported: path, outbound
Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=1
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Path: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob>
Content-Length: 0
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP ep1.example.com;branch=z9hG4bKnuiqisi
Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7
Max-Forwards: 69
From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com>
Call-ID: 16CB75F21C70
CSeq: 1 REGISTER
Supported: path, outbound
Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=1
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Path: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob>
Content-Length: 0
This REGISTER request results in the Path header being stored along with the AOR and its associated binding at the Registrar. The URI contained in the Path header will be inserted as a pre-loaded SIP 'Route' header into any request that arrives at the Registrar and is directed towards the associated AOR binding. This all but guarantees that all requests for the new registration will be forwarded to the edge proxy. In our example, the user part of the SIP 'Path' header URI that was inserted by the edge proxy contains the unique token identifying the flow to the client. On receiving subsequent requests, the edge proxy will examine the user part of the pre-loaded SIP 'Route' header and extract the unique flow token for use in its connection tuple comparison, as defined in the SIP Outbound specification [RFC5626]. An example that builds on this scenario (showing an inbound request to the AOR) is detailed in Section 5.1.4.2 of this document.
此注册请求导致路径头与AOR及其关联绑定一起存储在注册器中。路径头中包含的URI将作为预加载的SIP“Route”头插入到到达注册器的任何请求中，并指向相关的AOR绑定。这几乎保证了所有新注册请求都将转发到边缘代理。在我们的示例中，由边缘代理插入的SIP“Path”头URI的用户部分包含标识到客户端的流的唯一令牌。在接收到后续请求时，边缘代理将检查预加载的SIP“Route”报头的用户部分，并提取唯一流令牌，以便在其连接元组比较中使用，如SIP出站规范[RFC5626]中所定义。本文档第5.1.4.2节详细介绍了基于此场景的示例（显示了对AOR的入站请求）。
This section covers basic SIP signaling when initiating a call from behind a NAT.
本节介绍从NAT后面发起呼叫时的基本SIP信令。
Initiating a call using UDP (the edge proxy and authoritative proxy functionality are co-located).
使用UDP发起呼叫（边缘代理和权威代理功能位于同一位置）。
Edge Proxy/
Bob NAT Auth. Proxy Alice
| | | |
|(1) INVITE | | |
|----------------->| | |
| | | |
| |(1) INVITE | |
| |----------------->| |
| | | |
| | |(2) INVITE |
| | |---------------->|
| | | |
| | |(3)180 RINGING |
| | |<----------------|
| | | |
| |(4)180 RINGING | |
| |<-----------------| |
| | | |
|(4)180 RINGING | | |
|<-----------------| | |
| | | |
| | |(5)200 OK |
| | |<----------------|
| | | |
| |(6)200 OK | |
| |<-----------------| |
| | | |
|(6)200 OK | | |
|<-----------------| | |
| | | |
|(7)ACK | | |
|----------------->| | |
| | | |
| |(7)ACK | |
| |----------------->| |
| | | |
| | |(8) ACK |
| | |---------------->|
| | | |
Edge Proxy/
Bob NAT Auth. Proxy Alice
| | | |
|(1) INVITE | | |
|----------------->| | |
| | | |
| |(1) INVITE | |
| |----------------->| |
| | | |
| | |(2) INVITE |
| | |---------------->|
| | | |
| | |(3)180 RINGING |
| | |<----------------|
| | | |
| |(4)180 RINGING | |
| |<-----------------| |
| | | |
|(4)180 RINGING | | |
|<-----------------| | |
| | | |
| | |(5)200 OK |
| | |<----------------|
| | | |
| |(6)200 OK | |
| |<-----------------| |
| | | |
|(6)200 OK | | |
|<-----------------| | |
| | | |
|(7)ACK | | |
|----------------->| | |
| | | |
| |(7)ACK | |
| |----------------->| |
| | | |
| | |(8) ACK |
| | |---------------->|
| | | |
Figure 8: Initiating a Session - UDP
图8：启动会话-UDP
The initiating client generates an INVITE request that is to be sent through the NAT to a proxy server. The INVITE message is represented in Figure 8 by (1) and is as follows:
发起客户端生成一个INVITE请求，该请求将通过NAT发送到代理服务器。图8中的INVITE消息由（1）表示，如下所示：
Message 1:
信息1：
INVITE sip:alice@a.example SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2;rport;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Bob <sip:bob@example.com>;tag=ldw22z
To: Alice <sip:alice@a.example>
Call-ID: 95KGsk2V/Eis9LcpBYy3
CSeq: 1 INVITE
Supported: outbound
Route: <sip:ep1.example.com;lr>
Contact: <sip:bob@192.168.1.2;ob>
Content-Type: application/sdp
Content-Length: ...
INVITE sip:alice@a.example SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2;rport;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Bob <sip:bob@example.com>;tag=ldw22z
To: Alice <sip:alice@a.example>
Call-ID: 95KGsk2V/Eis9LcpBYy3
CSeq: 1 INVITE
Supported: outbound
Route: <sip:ep1.example.com;lr>
Contact: <sip:bob@192.168.1.2;ob>
Content-Type: application/sdp
Content-Length: ...
[SDP not shown]
[未显示SDP]
There are a number of points to note with this message:
此消息有许多要点需要注意：
1. Firstly, as with the registration example in Section 5.1.1.1, responses to this request will not automatically pass back through a NAT, so the SIP 'Via' header 'rport' is included as described in the Section 4.1.1 ("Symmetric Response") and defined in RFC 3581 [RFC3581].
1. 首先，与第5.1.1.1节中的注册示例一样，对该请求的响应不会自动通过NAT传回，因此SIP“Via”头“rport”包括在第4.1.1节（“对称响应”）中，并在RFC 3581[RFC3581]中定义。
2. Secondly, the 'ob' parameter is added to the 'Contact' header to ensure that all subsequent requests are sent to the same flow; alternatively, a Globally Routable User Agent URI (GRUU) might have been used. See Section 4.3 of [RFC5626].
2. 其次，“ob”参数被添加到“Contact”头中，以确保所有后续请求都发送到相同的流；或者，可能使用了全局可路由用户代理URI（GRUU）。参见[RFC5626]第4.3节。
In (2), the proxy inserts itself in the 'Via' header, adds the 'rport' port number and the 'received' parameter in the previous 'Via' header, removes the 'Route' header, and inserts a Record-Route with a token.
在（2）中，代理将自身插入“Via”头中，在前一个“Via”头中添加“rport”端口号和“received”参数，删除“Route”头，并插入带有令牌的记录路由。
Message 2:
信息2：
INVITE sip:alice@172.16.1.4 SIP/2.0
Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4bKnuiqisi
Via: SIP/2.0/UDP 192.168.1.2;rport=8050;branch=z9hG4bKnashds7;
received=172.16.3.4
Max-Forwards: 69
From: Bob <sip:bob@example.com>;tag=ldw22z
To: Alice <sip:alice@a.example>
Call-ID: 95KGsk2V/Eis9LcpBYy3
CSeq: 1 INVITE
Supported: outbound
Record-Route: <sip:3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com;lr>
Contact: <sip:bob@192.168.1.2;ob>
Content-Type: application/sdp
Content-Length: ...
INVITE sip:alice@172.16.1.4 SIP/2.0
Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4bKnuiqisi
Via: SIP/2.0/UDP 192.168.1.2;rport=8050;branch=z9hG4bKnashds7;
received=172.16.3.4
Max-Forwards: 69
From: Bob <sip:bob@example.com>;tag=ldw22z
To: Alice <sip:alice@a.example>
Call-ID: 95KGsk2V/Eis9LcpBYy3
CSeq: 1 INVITE
Supported: outbound
Record-Route: <sip:3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com;lr>
Contact: <sip:bob@192.168.1.2;ob>
Content-Type: application/sdp
Content-Length: ...
[SDP not shown]
[未显示SDP]
When using a reliable transport such as TCP, the call flow and procedures for traversing a NAT are almost identical to those described in Section 5.1.3.1. The primary difference when using reliable transport protocols is that symmetric response [RFC3581] is not required for SIP responses to traverse a NAT. RFC 3261 [RFC3261] defines procedures for SIP response messages to be sent back on the same connection on which the request arrived. See Section 9.5 of [RFC5626] for an example flow of an outgoing call.
当使用TCP等可靠传输时，穿越NAT的调用流和过程与第5.1.3.1节中描述的几乎相同。使用可靠传输协议时的主要区别在于，SIP响应穿越NAT时不需要对称响应[RFC3581]。RFC 3261[RFC3261]定义了在请求到达的同一连接上发回SIP响应消息的过程。有关传出呼叫的示例流程，请参见[RFC5626]第9.5节。
This section details scenarios where a client behind a NAT receives an inbound request through a NAT. These scenarios build on the previous registration scenario from Sections 5.1.1 and 5.1.2 in this document.
本节详细介绍NAT后面的客户端通过NAT接收入站请求的场景。这些场景基于本文档第5.1.1节和第5.1.2节中先前的注册场景。
The SIP signaling on the interior of the network (behind the user's proxy) is not impacted directly by the transport protocol, so only one example scenario is necessary. The example uses UDP and follows on from the registration installed in the example from Section 5.1.1.1.
网络内部（用户代理后面）的SIP信令不受传输协议的直接影响，因此只需要一个示例场景。该示例使用UDP，并遵循第5.1.1.1节示例中安装的注册。
Edge Proxy
Bob NAT Auth. Proxy Alice
| | | |
|*******************************************************|
| Registration Binding Installed in |
| Section 5.1.1.1 |
|*******************************************************|
| | | |
| | |(1)INVITE |
| | |<----------------|
| | | |
| |(2)INVITE | |
| |<-----------------| |
| | | |
|(2)INVITE | | |
|<-----------------| | |
| | | |
| | | |
Edge Proxy
Bob NAT Auth. Proxy Alice
| | | |
|*******************************************************|
| Registration Binding Installed in |
| Section 5.1.1.1 |
|*******************************************************|
| | | |
| | |(1)INVITE |
| | |<----------------|
| | | |
| |(2)INVITE | |
| |<-----------------| |
| | | |
|(2)INVITE | | |
|<-----------------| | |
| | | |
| | | |
Figure 9: Receiving an Invitation to a Session
图9：接收会话邀请
An INVITE request arrives at the authoritative proxy with a destination pointing to the AOR of that inserted in Section 5.1.1.1. The message is illustrated by (1) in Figure 9 and looks as follows:
INVITE请求到达权威代理，目标指向第5.1.1.1节中插入的AOR。该消息如图9中的（1）所示，如下所示：
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d
Max-Forwards: 70
From: External Alice <sip:alice@example.com>;tag=02935
To: Bob <sip:bob@example.com>
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Contact: <sip:alice@172.16.1.4>
Content-Type: application/sdp
Content-Length: ..
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d
Max-Forwards: 70
From: External Alice <sip:alice@example.com>;tag=02935
To: Bob <sip:bob@example.com>
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Contact: <sip:alice@172.16.1.4>
Content-Type: application/sdp
Content-Length: ..
[SDP not shown]
[未显示SDP]
The INVITE request matches the registration binding previously installed at the Registrar and the INVITE Request-URI is rewritten to the selected onward address. The proxy then examines the Request-URI of the INVITE and compares with its list of connection tuples. It uses the incoming AOR to commence the check for associated open connections/mappings. Once matched, the proxy checks to see if the unique instance identifier (+sip.instance) associated with the binding equals the same instance identifier associated with that connection tuple. The request is then dispatched on the appropriate binding. This is message (2) from Figure 9 and is as follows:
INVITE请求与先前安装在注册器上的注册绑定相匹配，INVITE请求URI被重写到所选的转发地址。然后，代理检查INVITE的请求URI，并将其与连接元组列表进行比较。它使用传入的AOR开始检查相关的开放连接/映射。匹配后，代理将检查与绑定关联的唯一实例标识符（+sip.instance）是否等于与该连接元组关联的相同实例标识符。然后在适当的绑定上调度请求。这是来自图9的消息（2），如下所示：
INVITE sip:bob@192.168.1.2 SIP/2.0
Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4kmlds893jhsd
Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d
Max-Forwards: 69
From: Alice <sip:alice@example.com>;tag=02935
To: client bob <sip:bob@example.com>
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Contact: <sip:alice@172.16.1.4>
Content-Type: application/sdp
Content-Length: ..
INVITE sip:bob@192.168.1.2 SIP/2.0
Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4kmlds893jhsd
Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d
Max-Forwards: 69
From: Alice <sip:alice@example.com>;tag=02935
To: client bob <sip:bob@example.com>
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Contact: <sip:alice@172.16.1.4>
Content-Type: application/sdp
Content-Length: ..
[SDP not shown]
[未显示SDP]
It is a standard SIP INVITE request with no additional functionality. The major difference is that this request will not be forwarded to the address specified in the Request-URI, as standard SIP rules would enforce, but will be sent on the flow associated with the registration binding (lookup procedures in RFC 3263 [RFC3263] are overridden by RFC 5626 [RFC5626]). This then allows the original connection/mapping from the initial registration process to be reused.
这是一个标准的SIP INVITE请求，没有附加功能。主要区别在于，该请求不会转发到请求URI中指定的地址，因为标准SIP规则将强制执行，而是在与注册绑定相关联的流上发送（RFC 3263[RFC3263]中的查找过程被RFC 5626[RFC5626]覆盖）。这样就可以重用初始注册过程中的原始连接/映射。
The core SIP signaling associated with this call flow is not impacted directly by the transport protocol, so only one example scenario is necessary. The example uses UDP and follows on from the registration installed in the example from Section 5.1.2.
与此呼叫流相关联的核心SIP信令不受传输协议的直接影响，因此只需要一个示例场景。该示例使用UDP，并遵循第5.1.2节示例中安装的注册。
Bob NAT Edge Proxy Auth. Proxy Alice
| | | | |
|***********************************************************|
| Registration Binding Installed in |
| Section 5.1.2 |
|***********************************************************|
| | | | |
| | | |(1)INVITE |
| | | |<-------------|
| | | | |
| | |(2)INVITE | |
| | |<-------------| |
| | | | |
| |(3)INVITE | | |
| |<-------------| | |
| | | | |
|(3)INVITE | | | |
|<-------------| | | |
| | | | |
| | | | |
Bob NAT Edge Proxy Auth. Proxy Alice
| | | | |
|***********************************************************|
| Registration Binding Installed in |
| Section 5.1.2 |
|***********************************************************|
| | | | |
| | | |(1)INVITE |
| | | |<-------------|
| | | | |
| | |(2)INVITE | |
| | |<-------------| |
| | | | |
| |(3)INVITE | | |
| |<-------------| | |
| | | | |
|(3)INVITE | | | |
|<-------------| | | |
| | | | |
| | | | |
Figure 10: Registrar/Proxy Not Co-located
图10：登记员/代理人不在同一地点
An INVITE request arrives at the authoritative proxy with a destination pointing to the AOR of that inserted in Section 5.1.2. The message is illustrated by (1) in Figure 10 and looks as follows:
INVITE请求到达权威代理，目标指向第5.1.2节中插入的AOR。该消息如图10中的（1）所示，如下所示：
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d
Max-Forwards: 70
From: Alice <sip:alice@example.com>;tag=02935
To: Bob <sip:bob@example.com>
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Contact: <sip:external@172.16.1.4>
Content-Type: application/sdp
Content-Length: ..
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d
Max-Forwards: 70
From: Alice <sip:alice@example.com>;tag=02935
To: Bob <sip:bob@example.com>
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Contact: <sip:external@172.16.1.4>
Content-Type: application/sdp
Content-Length: ..
[SDP not shown]
[未显示SDP]
The INVITE request matches the registration binding previously installed at the Registrar and the INVITE Request-URI is rewritten to the selected onward address. The Registrar also identifies that a SIP 'Path' header was associated with the registration and pushes it into the INVITE request in the form of a pre-loaded SIP Route header. It then forwards the request on to the proxy identified in the SIP Route header as shown in (2) from Figure 10:
INVITE请求与先前安装在注册器上的注册绑定相匹配，INVITE请求URI被重写到所选的转发地址。注册器还确定SIP“路径”头与注册关联，并以预加载SIP路由头的形式将其推送到INVITE请求中。然后，它将请求转发到SIP路由头中标识的代理上，如图10中的（2）所示：
INVITE sip:bob@client.example.com SIP/2.0
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK74fmljnc
Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d
Route: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob>
Max-Forwards: 69
From: Alice <sip:alice@example.net>;tag=02935
To: Bob <sip:Bob@example.com>
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Contact: <sip:alice@172.16.1.4>
Content-Type: application/sdp
Content-Length: ..
INVITE sip:bob@client.example.com SIP/2.0
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK74fmljnc
Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d
Route: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob>
Max-Forwards: 69
From: Alice <sip:alice@example.net>;tag=02935
To: Bob <sip:Bob@example.com>
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Contact: <sip:alice@172.16.1.4>
Content-Type: application/sdp
Content-Length: ..
[SDP not shown]
[未显示SDP]
The request then arrives at the outbound proxy for the client. The proxy examines the Request-URI of the INVITE in conjunction with the flow token that it previously inserted into the user part of the 'Path' header SIP URI (which now appears in the user part of the Route header in the incoming INVITE). The proxy locates the appropriate flow and sends the message to the client, as shown in (3) from Figure 10:
然后，请求到达客户端的出站代理。代理将检查INVITE的请求URI以及它先前插入到“Path”头SIP URI的用户部分的流令牌（现在显示在传入INVITE的路由头的用户部分）。代理定位适当的流并将消息发送到客户端，如图10中的（3）所示：
INVITE sip:bob@192.168.1.2 SIP/2.0
Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4nsi30dncmnl
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK74fmljnc
Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d
Record-Route: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr>
Max-Forwards: 68
From: Alice <sip:Alice@example.net>;tag=02935
To: bob <sip:bob@example.com>
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Contact: <sip:alice@172.16.1.4>
Content-Type: application/sdp
Content-Length: ..
INVITE sip:bob@192.168.1.2 SIP/2.0
Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4nsi30dncmnl
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK74fmljnc
Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d
Record-Route: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr>
Max-Forwards: 68
From: Alice <sip:Alice@example.net>;tag=02935
To: bob <sip:bob@example.com>
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Contact: <sip:alice@172.16.1.4>
Content-Type: application/sdp
Content-Length: ..
[SDP not shown]
[未显示SDP]
It is a standard SIP INVITE request with no additional functionality at the originator. The major difference is that this request will not follow the address specified in the Request-URI when it reaches the outbound proxy, as standard SIP rules would enforce, but will be sent on the flow associated with the registration binding as indicated in the Route header (lookup procedures in RFC 3263 [RFC3263] are overridden). This then allows the original connection/ mapping from the initial registration to the outbound proxy to be reused.
这是一个标准的SIP INVITE请求，在发起方没有附加功能。主要区别在于，当该请求到达出站代理时，它不会遵循请求URI中指定的地址，因为标准SIP规则将强制执行，而是将在与注册绑定相关联的流上发送，如路由头中所示（RFC 3263[RFC3263]中的查找过程被覆盖）。这样就可以重用从初始注册到出站代理的原始连接/映射。
This section provides example scenarios to demonstrate basic media traversal using the techniques outlined earlier in this document.
本节提供了使用本文档前面概述的技术演示基本媒体遍历的示例场景。
In the flow diagrams, STUN messages have been annotated for simplicity as follows:
在流程图中，为了简单起见，对STUN消息进行了注释，如下所示：
o The "Src" attribute represents the source transport address of the message.
o “Src”属性表示消息的源传输地址。
o The "Dest" attribute represents the destination transport address of the message.
o “Dest”属性表示消息的目标传输地址。
o The "Map" attribute represents the server reflexive (XOR-MAPPED-ADDRESS STUN attribute) transport address.
o “Map”属性表示服务器自反（XOR-MAPPED-ADDRESS STUN属性）传输地址。
o The "Rel" attribute represents the relayed (RELAY-ADDRESS STUN attribute) transport address.
o “Rel”属性表示中继（中继地址STUN属性）传输地址。
The meaning of each STUN attribute is extensively explained in the core STUN [RFC5389] and TURN [RFC5766] specifications.
每个眩晕属性的含义在核心眩晕[RFC5389]和回合[RFC5766]规范中有详细说明。
A number of ICE SDP attributes have also been included in some of the examples. Detailed information on individual attributes can be obtained from the core ICE specification [RFC5245].
一些示例中还包括许多ICE SDP属性。有关单个属性的详细信息可从堆芯ICE规范[RFC5245]中获得。
The examples also contain a mechanism for representing transport addresses. It would be confusing to include representations of network addresses in the call flows and would make them hard to follow. For this reason, network addresses will be represented using the following annotation. The first component will contain the representation of the client responsible for the address. For example, in the majority of the examples "L" (left client), "R" (right client), "NAT-PUB" (NAT public), "PRIV" (Private), and "STUN-PUB" (STUN public) are used. To allow for multiple addresses from the same network element, each representation can also be followed by a number. These can also be used in combination. For example, "L-NAT-PUB-1" would represent a public network address of the left-hand side NAT while "R-NAT-PUB-1" would represent a public network address of the right-hand side of the NAT. "L-PRIV-1" would represent a private network address of the left-hand side of the NAT while "R-PRIV-1" represents a private address of the right-hand side of the NAT.
这些示例还包含一种表示传输地址的机制。在呼叫流中包含网络地址的表示会让人感到困惑，并且会使它们难以理解。因此，网络地址将使用以下注释表示。第一个组件将包含负责地址的客户机的表示。例如，在大多数示例中，使用了“L”（左客户机）、“R”（右客户机）、“NAT-PUB”（NAT公共）、“PRIVE”（私人）和“STUN-PUB”（STUN公共）。为了允许来自同一网络元素的多个地址，每个表示后面还可以跟一个数字。这些也可以组合使用。例如，“L-NAT-PUB-1”将表示左侧NAT的公共网络地址，而“R-NAT-PUB-1”将表示右侧NAT的公共网络地址。“L-PRIV-1”表示NAT左侧的专用网络地址，“R-PRIV-1”表示NAT右侧的专用地址。
It should also be noted that, during the examples, it might be appropriate to signify an explicit part of a transport address. This is achieved by adding either the '.address' or '.port' tag on the end of the representation -- for example, 'L-PRIV-1.address' and 'L-PRIV-1.port'.
还应注意，在示例中，表示传输地址的显式部分可能是适当的。这是通过在表示的末尾添加“.address”或“.port”标记实现的，例如，“L-PRIV-1.address”和“L-PRIV-1.port”。
The use of '$' signifies variable parts in example SIP messages.
“$”的使用表示示例SIP消息中的可变部分。
This section demonstrates an example of a client both initiating and receiving calls behind an Endpoint-Independent NAT. An example is included for both STUN and ICE with ICE being the RECOMMENDED mechanism for media traversal.
本节演示了一个客户端在独立于端点的NAT之后发起和接收呼叫的示例。其中包括STUN和ICE的示例，ICE是媒体遍历的推荐机制。
At this time, there is no reliable test to determine if a host is behind an Endpoint-Independent Filtering NAT or an Endpoint-Independent Mapping NAT [RFC5780], and the sort of failure that occurs in this situation is described in Section 5.2.2.1. For this reason, ICE is RECOMMENDED over the mechanism described in this section.
此时，没有可靠的测试来确定主机是否位于端点独立过滤NAT或端点独立映射NAT[RFC5780]之后，并且在第5.2.2.1节中描述了这种情况下发生的故障类型。因此，建议在本节所述的机构上使用ICE。
It is possible to traverse media through an Endpoint-Independent NAT using STUN. The remainder of this section provides simplified examples of the 'Binding Discovery' STUN as defined in [RFC5389]. The STUN messages have been simplified and do not include 'Shared Secret' requests used to obtain the temporary username and password.
可以使用STUN通过与端点无关的NAT遍历媒体。本节剩余部分提供了[RFC5389]中定义的“绑定发现”STUN的简化示例。STUN消息已被简化，不包括用于获取临时用户名和密码的“共享机密”请求。
The following example demonstrates media traversal through a NAT with Endpoint-Independent Mapping properties using the STUN 'Binding Discovery' usage. It is assumed in this example that the STUN client and SIP Client are co-located on the same physical machine. Note that some SIP signaling messages have been left out for simplicity.
下面的示例演示了使用STUN“绑定发现”用法通过具有端点无关映射属性的NAT进行媒体遍历。在此示例中，假设STUN客户端和SIP客户端位于同一物理机器上。注意，为了简单起见，省略了一些SIP信令消息。
Client NAT STUN [..]
Server
| | | |
|(1) BIND Req | | |
|Src=L-PRIV-1 | | |
|Dest=STUN-PUB | | |
|----------------->| | |
| | | |
| |(2) BIND Req | |
| |Src=NAT-PUB-1 | |
| |Dest=STUN-PUB | |
| |----------------->| |
| | | |
| |(3) BIND Resp | |
| |<-----------------| |
| |Src=STUN-PUB | |
| |Dest=NAT-PUB-1 | |
| |Map=NAT-PUB-1 | |
| | | |
|(4) BIND Resp | | |
|<-----------------| | |
|Src=STUN-PUB | | |
|Dest=L-PRIV-1 | | |
|Map=NAT-PUB-1 | | |
| | | |
|(5) BIND Req | | |
|Src=L-PRIV-2 | | |
|Dest=STUN-PUB | | |
|----------------->| | |
| | | |
| |(6) BIND Req | |
| |Src=NAT-PUB-2 | |
| |Dest=STUN-PUB | |
| |----------------->| |
| | | |
| |(7) BIND Resp | |
| |<-----------------| |
| |Src=STUN-PUB | |
| |Dest=NAT-PUB-2 | |
| |Map=NAT-PUB-2 | |
| | | |
|(8) BIND Resp | | |
|<-----------------| | |
|Src=STUN-PUB | | |
|Dest=L-PRIV-2 | | |
|Map=NAT-PUB-2 | | |
| | | |
Client NAT STUN [..]
Server
| | | |
|(1) BIND Req | | |
|Src=L-PRIV-1 | | |
|Dest=STUN-PUB | | |
|----------------->| | |
| | | |
| |(2) BIND Req | |
| |Src=NAT-PUB-1 | |
| |Dest=STUN-PUB | |
| |----------------->| |
| | | |
| |(3) BIND Resp | |
| |<-----------------| |
| |Src=STUN-PUB | |
| |Dest=NAT-PUB-1 | |
| |Map=NAT-PUB-1 | |
| | | |
|(4) BIND Resp | | |
|<-----------------| | |
|Src=STUN-PUB | | |
|Dest=L-PRIV-1 | | |
|Map=NAT-PUB-1 | | |
| | | |
|(5) BIND Req | | |
|Src=L-PRIV-2 | | |
|Dest=STUN-PUB | | |
|----------------->| | |
| | | |
| |(6) BIND Req | |
| |Src=NAT-PUB-2 | |
| |Dest=STUN-PUB | |
| |----------------->| |
| | | |
| |(7) BIND Resp | |
| |<-----------------| |
| |Src=STUN-PUB | |
| |Dest=NAT-PUB-2 | |
| |Map=NAT-PUB-2 | |
| | | |
|(8) BIND Resp | | |
|<-----------------| | |
|Src=STUN-PUB | | |
|Dest=L-PRIV-2 | | |
|Map=NAT-PUB-2 | | |
| | | |
|(9)SIP INVITE | | |
|----------------->| | |
| | | |
| |(10)SIP INVITE | |
| |------------------------------------>|
| | | |
| | |(11)SIP 200 OK |
| |<------------------------------------|
| | | |
|(12)SIP 200 OK | | |
|<-----------------| | |
| | | |
|========================================================|
|>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>>|
|========================================================|
| |
|========================================================|
|<<<<<<<<<<<<Incoming Media sent to NAT-PUB-1<<<<<<<<<<<<|
|========================================================|
| |
|========================================================|
|>>>>>>>>>>>>Outgoing RTCP sent from L-PRIV-2>>>>>>>>>>>>|
|========================================================|
| |
|========================================================|
|<<<<<<<<<<<<Incoming RTCP sent to NAT-PUB-2<<<<<<<<<<<<<|
|========================================================|
| | | |
|(13)SIP ACK | | |
|----------------->| | |
| | | |
| |(14) SIP ACK | |
| |------------------------------------>|
| | | |
|(9)SIP INVITE | | |
|----------------->| | |
| | | |
| |(10)SIP INVITE | |
| |------------------------------------>|
| | | |
| | |(11)SIP 200 OK |
| |<------------------------------------|
| | | |
|(12)SIP 200 OK | | |
|<-----------------| | |
| | | |
|========================================================|
|>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>>|
|========================================================|
| |
|========================================================|
|<<<<<<<<<<<<Incoming Media sent to NAT-PUB-1<<<<<<<<<<<<|
|========================================================|
| |
|========================================================|
|>>>>>>>>>>>>Outgoing RTCP sent from L-PRIV-2>>>>>>>>>>>>|
|========================================================|
| |
|========================================================|
|<<<<<<<<<<<<Incoming RTCP sent to NAT-PUB-2<<<<<<<<<<<<<|
|========================================================|
| | | |
|(13)SIP ACK | | |
|----------------->| | |
| | | |
| |(14) SIP ACK | |
| |------------------------------------>|
| | | |
Figure 11: Endpoint-Independent NAT - Initiating
图11：端点无关NAT-启动
o On deciding to initiate a SIP voice session, the client starts a local STUN client on the interface and port that is to be used for media (send/receive). The STUN client generates a standard 'Binding Discovery' request as indicated in (1) from Figure 11 that also highlights the source address and port for which the client device wishes to obtain a mapping. The 'Binding Discovery' request is sent through the NAT towards the public Internet and STUN server.
o 在决定启动SIP语音会话时，客户端在用于媒体（发送/接收）的接口和端口上启动本地STUN客户端。STUN客户端生成标准的“绑定发现”请求，如图11中（1）所示，该请求还突出显示了客户端设备希望获得映射的源地址和端口。“绑定发现”请求通过NAT发送到公共Internet和STUN服务器。
o Message (2) traverses the NAT and breaks out onto the public Internet towards the public STUN server. Note that the source address of the 'Binding Discovery' request now represents the public address and port from the public side of the NAT.
o 消息（2）穿过NAT并进入公共互联网，指向公共STUN服务器。请注意，“绑定发现”请求的源地址现在表示NAT公共端的公共地址和端口。
o The STUN server receives the request and processes it appropriately. This results in a successful 'Binding Discovery' response being generated and returned (3). The message contains details of the XOR-mapped public address (contained in the STUN XOR-MAPPED-ADDRESS attribute) that is to be used by the originating client to receive media (see 'Map=NAT-PUB-1' from (3)).
o STUN服务器接收请求并进行适当的处理。这将导致生成并返回成功的“绑定发现”响应（3）。该消息包含XOR映射公共地址（包含在STUN XOR-mapped-address属性中）的详细信息，该地址将由发起客户端用于接收来自（3）的媒体（请参阅“Map=NAT-PUB-1”）。
o The 'Binding Discovery' response traverses back through the NAT using the path created by the 'Binding Discovery' request and presents the new XOR-mapped address to the client (4). At this point, the process is repeated to obtain a second XOR-mapped address (as shown in (5)-(8)) for a second local address (the address has changed from "L-PRIV-1" to "L-PRIV-2") for an RTCP port.
o “绑定发现”响应使用“绑定发现”请求创建的路径遍历NAT，并将新的XOR映射地址呈现给客户端（4）。此时，重复该过程以获得RTCP端口的第二本地地址（地址已从“L-PRIV-1”更改为“L-PRIV-2”）的第二个XOR映射地址（如（5）-（8）所示）。
o The client now constructs a SIP INVITE message (9). Note that traversal of SIP is not covered in this example and is discussed in Section 5.1. The INVITE request will use the addresses it has obtained in the previous STUN transactions to populate the SDP of the SIP INVITE as shown below:
o 客户端现在构造SIP INVITE消息（9）。请注意，本示例中未涉及SIP的遍历，第5.1节对此进行了讨论。INVITE请求将使用它在以前的STUN事务中获得的地址来填充SIP INVITE的SDP，如下所示：
v=0
o=test 2890844526 2890842807 IN IP4 $L-PRIV-1.address
c=IN IP4 $NAT-PUB-1.address
t=0 0
m=audio $NAT-PUB-1.port RTP/AVP 0
a=rtcp:$NAT-PUB-2.port
v=0
o=test 2890844526 2890842807 IN IP4 $L-PRIV-1.address
c=IN IP4 $NAT-PUB-1.address
t=0 0
m=audio $NAT-PUB-1.port RTP/AVP 0
a=rtcp:$NAT-PUB-2.port
o Note that the XOR-mapped address obtained from the 'Binding Discovery' transactions are inserted as the connection address for the SDP (c=$NAT-PUB-1.address). The Primary port for RTP is also inserted in the SDP (m=audio $NAT-PUB-1.port RTP/AVP 0). Finally, the port gained from the additional 'Binding Discovery' is placed in the RTCP attribute (as discussed in Section 4.2.2) for traversal of RTCP (a=rtcp:$NAT-PUB-2.port).
o 请注意，从“绑定发现”事务中获得的XOR映射地址被插入为SDP的连接地址（c=$NAT-PUB-1.address）。RTP的主端口也插入SDP中（m=audio$NAT-PUB-1.port RTP/AVP 0）。最后，从附加的“绑定发现”中获得的端口被放置在RTCP属性中（如第4.2.2节所述），用于遍历RTCP（a=RTCP:$NAT-PUB-2.port）。
o The SIP signaling then traverses the NAT and sets up the SIP session (9-12). Note that the left-hand client transmits media as soon as the 200 OK to the INVITE arrives at the client (12). Up until this point, the incoming media and RTCP to the left-hand
o 然后SIP信令穿过NAT并建立SIP会话（9-12）。注意，一旦对INVITE的200 OK到达客户端（12），左侧客户端就发送媒体。在此之前，传入的媒体和RTCP都位于左侧
client will not pass through the NAT as no outbound association has been created with the far-end client. Two-way media communication has now been established.
客户端将不会通过NAT，因为没有与远端客户端创建出站关联。双向媒体交流现已建立。
Receiving a session for an Endpoint-Independent NAT using the STUN 'Binding Discovery' usage is very similar to the example outlined in Section 5.2.1.1.1. Figure 12 illustrates the associated flow of messages.
使用STUN“绑定发现”用法接收与端点无关的NAT会话与第5.2.1.1.1节中概述的示例非常相似。图12说明了相关的消息流。
Client NAT STUN [..]
Server
| | | (1)SIP INVITE |
| |<------------------------------------|
| | | |
|(2) SIP INVITE | | |
|<-----------------| | |
| | | |
|(3) BIND Req | | |
|Src=L-PRIV-1 | | |
|Dest=STUN-PUB | | |
|----------------->| | |
| | | |
| |(4) BIND Req | |
| |Src=NAT-PUB-1 | |
| |Dest=STUN-PUB | |
| |----------------->| |
| | | |
| |(5) BIND Resp | |
| |<-----------------| |
| |Src=STUN-PUB | |
| |Dest=NAT-PUB-1 | |
| |Map=NAT-PUB-1 | |
| | | |
|(6) BIND Resp | | |
|<-----------------| | |
|Src=STUN-PUB | | |
|Dest=L-PRIV-1 | | |
|Map=NAT-PUB-1 | | |
| | | |
|(7) BIND Req | | |
|Src=L-PRIV-2 | | |
|Dest=STUN-PUB | | |
|----------------->| | |
| | | |
Client NAT STUN [..]
Server
| | | (1)SIP INVITE |
| |<------------------------------------|
| | | |
|(2) SIP INVITE | | |
|<-----------------| | |
| | | |
|(3) BIND Req | | |
|Src=L-PRIV-1 | | |
|Dest=STUN-PUB | | |
|----------------->| | |
| | | |
| |(4) BIND Req | |
| |Src=NAT-PUB-1 | |
| |Dest=STUN-PUB | |
| |----------------->| |
| | | |
| |(5) BIND Resp | |
| |<-----------------| |
| |Src=STUN-PUB | |
| |Dest=NAT-PUB-1 | |
| |Map=NAT-PUB-1 | |
| | | |
|(6) BIND Resp | | |
|<-----------------| | |
|Src=STUN-PUB | | |
|Dest=L-PRIV-1 | | |
|Map=NAT-PUB-1 | | |
| | | |
|(7) BIND Req | | |
|Src=L-PRIV-2 | | |
|Dest=STUN-PUB | | |
|----------------->| | |
| | | |
| |(8) BIND Req | |
| |Src=NAT-PUB-2 | |
| |Dest=STUN-PUB | |
| |----------------->| |
| | | |
| |(9) BIND Resp | |
| |<-----------------| |
| |Src=STUN-PUB | |
| |Dest=NAT-PUB-2 | |
| |Map=NAT-PUB-2 | |
| | | |
|(10) BIND Resp | | |
|<-----------------| | |
|Src=STUN-PUB | | |
|Dest=L-PRIV-2 | | |
|Map=NAT-PUB-2 | | |
| | | |
|(11)SIP 200 OK | | |
|----------------->| | |
| |(12)SIP 200 OK | |
| |------------------------------------>|
| | | |
|========================================================|
|>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>>|
|========================================================|
| | | |
|========================================================|
|<<<<<<<<<<<<<Incoming Media sent to L-PRIV-1<<<<<<<<<<<<|
|========================================================|
| | | |
|========================================================|
|>>>>>>>>>>>>Outgoing RTCP sent from L-PRIV-2>>>>>>>>>>>>|
|========================================================|
| | | |
|========================================================|
|<<<<<<<<<<<<<Incoming RTCP sent to L-PRIV-2<<<<<<<<<<<<<|
|========================================================|
| | | |
| | |(13)SIP ACK |
| |<------------------------------------|
| | | |
|(14)SIP ACK | | |
|<-----------------| | |
| | | |
| |(8) BIND Req | |
| |Src=NAT-PUB-2 | |
| |Dest=STUN-PUB | |
| |----------------->| |
| | | |
| |(9) BIND Resp | |
| |<-----------------| |
| |Src=STUN-PUB | |
| |Dest=NAT-PUB-2 | |
| |Map=NAT-PUB-2 | |
| | | |
|(10) BIND Resp | | |
|<-----------------| | |
|Src=STUN-PUB | | |
|Dest=L-PRIV-2 | | |
|Map=NAT-PUB-2 | | |
| | | |
|(11)SIP 200 OK | | |
|----------------->| | |
| |(12)SIP 200 OK | |
| |------------------------------------>|
| | | |
|========================================================|
|>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>>|
|========================================================|
| | | |
|========================================================|
|<<<<<<<<<<<<<Incoming Media sent to L-PRIV-1<<<<<<<<<<<<|
|========================================================|
| | | |
|========================================================|
|>>>>>>>>>>>>Outgoing RTCP sent from L-PRIV-2>>>>>>>>>>>>|
|========================================================|
| | | |
|========================================================|
|<<<<<<<<<<<<<Incoming RTCP sent to L-PRIV-2<<<<<<<<<<<<<|
|========================================================|
| | | |
| | |(13)SIP ACK |
| |<------------------------------------|
| | | |
|(14)SIP ACK | | |
|<-----------------| | |
| | | |
Figure 12: Endpoint-Independent NAT - Receiving
图12：端点独立NAT-接收
o On receiving an invitation to a SIP voice session (SIP INVITE request), the User Agent starts a local STUN client on the appropriate port on which it is to receive media. The STUN client generates a standard 'Binding Discovery' request as indicated in (3) from Figure 12 that also highlights the source address and port for which the client device wishes to obtain a mapping. The 'Binding Discovery' request is sent through the NAT towards the public Internet and STUN server.
o 收到SIP语音会话邀请（SIP INVITE request）后，用户代理将在接收媒体的相应端口上启动本地STUN客户端。STUN客户端生成标准的“绑定发现”请求，如图12中的（3）所示，该请求还突出显示了客户端设备希望获得映射的源地址和端口。“绑定发现”请求通过NAT发送到公共Internet和STUN服务器。
o 'Binding Discovery' message (4) traverses the NAT and breaks out onto the public Internet towards the public STUN server. Note that the source address of the STUN requests now represents the public address and port from the public side of the NAT.
o “绑定发现”消息（4）穿过NAT并进入公共互联网，到达公共STUN服务器。请注意，STUN请求的源地址现在表示NAT公共端的公共地址和端口。
o The STUN server receives the request and processes it appropriately. This results in a successful 'Binding Discovery' response being generated and returned (5). The message contains details of the mapped public address (contained in the STUN XOR-MAPPED-ADDRESS attribute) that is to be used by the originating client to receive media (see 'Map=NAT-PUB-1' from (5)).
o STUN服务器接收请求并进行适当的处理。这将导致生成并返回成功的“绑定发现”响应（5）。该消息包含源客户端用于接收媒体的映射公共地址（包含在STUN-XOR-mapped-address属性中）的详细信息（请参阅（5）中的“Map=NAT-PUB-1”）。
o The 'Binding Discovery' response traverses back through the NAT using the path created by the outgoing 'Binding Discovery' request and presents the new XOR-mapped address to the client (6). At this point, the process is repeated to obtain a second XOR-mapped address (as shown in (7)-(10)) for a second local address (local port has now changed and is represented by L-PRIV-2 in (7)) for an RTCP port.
o “绑定发现”响应使用传出的“绑定发现”请求创建的路径穿越NAT，并将新的XOR映射地址呈现给客户端（6）。此时，重复该过程以获得RTCP端口的第二本地地址（本地端口现在已更改，并由（7）中的L-PRIV-2表示）的第二XOR映射地址（如（7）-（10）所示）。
o The client now constructs a SIP 200 OK message (11) in response to the original SIP INVITE requests. Note that traversal of SIP is not covered in this example and is discussed in Section 5.1. SIP Provisional responses are also left out for simplicity. The 200 OK response will use the addresses it has obtained in the previous STUN transactions to populate the SDP of the SIP 200 OK as shown below:
o 客户端现在构造sip200ok消息（11）以响应原始SIP INVITE请求。请注意，本示例中未涉及SIP的遍历，第5.1节对此进行了讨论。为了简单起见，也省略了SIP临时响应。200 OK响应将使用它在之前的STUN事务中获得的地址来填充SIP 200 OK的SDP，如下所示：
v=0
o=test 2890844526 2890842807 IN IP4 $L-PRIV-1.address
c=IN IP4 $NAT-PUB-1.address
t=0 0
m=audio $NAT-PUB-1.port RTP/AVP 0
a=rtcp:$NAT-PUB-2.port
v=0
o=test 2890844526 2890842807 IN IP4 $L-PRIV-1.address
c=IN IP4 $NAT-PUB-1.address
t=0 0
m=audio $NAT-PUB-1.port RTP/AVP 0
a=rtcp:$NAT-PUB-2.port
o Note that the XOR-mapped address obtained from the initial 'Binding Discovery' transaction is inserted as the connection address for the SDP (c=NAT-PUB-1.address). The Primary port for RTP is also inserted in the SDP (m=audio NAT-PUB-1.port RTP/AVP
o 请注意，从初始“绑定发现”事务获得的XOR映射地址被插入为SDP的连接地址（c=NAT-PUB-1.address）。RTP的主端口也插入SDP中（m=音频NAT-PUB-1.port RTP/AVP
0). Finally, the port gained from the second 'Binding Discovery' is placed in the RTCP attribute (as discussed in Section 4.2.2) for traversal of RTCP (a=rtcp:NAT-PUB-2.port).
0). 最后，从第二个“绑定发现”中获得的端口被放置在RTCP属性中（如第4.2.2节所述），用于遍历RTCP（a=RTCP:NAT-PUB-2.port）。
o The SIP signaling then traverses the NAT and sets up the SIP session (11-14). Note that the left-hand client transmits media as soon as the 200 OK to the INVITE is sent to the User Agent Client (UAC) (11). Up until this point, the incoming media from the right-hand client will not pass through the NAT as no outbound association has been created with the far-end client. Two-way media communication has now been established.
o 然后，SIP信令穿过NAT并建立SIP会话（11-14）。注意，只要向用户代理客户端（UAC）发送对邀请的200 OK，左侧客户端就发送媒体（11）。在此之前，来自右侧客户端的传入媒体将不会通过NAT，因为没有与远端客户端创建出站关联。双向媒体交流现已建立。
The preferred solution for media traversal of NAT is using ICE, as described in Section 4.2.3.3, regardless of the NAT type. The following examples illustrate the traversal of an Endpoint-Independent NAT when initiating the session. The example only covers ICE in association with the 'Binding Discovery' and TURN. It is worth noting that the TURN server provides both STUN functions (to learn your public mapping) and TURN functions (media relaying). It is also worth noting that in the example described in Section 5.2.1.2.1, both SIP clients L and R are contacting the same TURN server. This is not necessary for ICE, STUN, TURN to function; all that is necessary is that the STUN and TURN server(s) be in the same addressing domain that is accessible on the Internet.
NAT介质穿越的首选解决方案是使用ICE，如第4.2.3.3节所述，无论NAT类型如何。以下示例演示了在启动会话时遍历与端点无关的NAT。本示例仅涉及与“绑定发现”和TURN相关的ICE。值得注意的是，TURN服务器提供了STUN功能（了解公共映射）和TURN功能（媒体中继）。还值得注意的是，在第5.2.1.2.1节中描述的示例中，SIP客户端L和R都在联系同一个TURN服务器。这是不必要的冰，眩晕，转向功能；所有必要的是，STUN和TURN服务器位于可在Internet上访问的同一寻址域中。
The following example demonstrates an initiating traversal through an Endpoint-Independent NAT using ICE.
下面的示例演示了使用ICE通过端点独立NAT发起的遍历。
L NAT STUN NAT R
Server
| | | | |
|(1) Alloc Req | | | |
|Src=L-PRIV-1 | | | |
|Dest=TURN-PUB-1 | | | |
|--------------->| | | |
| | | | |
| |(2) Alloc Req | | |
| |Src=L-NAT-PUB-1 | | |
| |Dest=TURN-PUB-1 | | |
| |--------------->| | |
| | | | |
| |(3) Alloc Resp | | |
| |<---------------| | |
| |Src=TURN-PUB-1 | | |
| |Dest=L-NAT-PUB-1| | |
| |Map=L-NAT-PUB-1 | | |
| |Rel=TURN-PUB-2 | | |
| | | | |
|(4) Alloc Resp | | | |
|<---------------| | | |
|Src=TURN-PUB-1 | | | |
|Dest=L-PRIV-1 | | | |
|Map=L-NAT-PUB-1 | | | |
|Rel=TURN-PUB-2 | | | |
| | | | |
|(5) Alloc Req | | | |
|Src=L-PRIV-2 | | | |
|Dest=TURN-PUB-1 | | | |
|--------------->| | | |
| | | | |
| |(6) Alloc Req | | |
| |Src=L-NAT-PUB-2 | | |
| |Dest=TURN-PUB-1 | | |
| |--------------->| | |
| | | | |
| |(7) Alloc Resp | | |
| |<---------------| | |
| |Src=TURN-PUB-1 | | |
| |Dest=NAT-PUB-2 | | |
| |Map=NAT-PUB-2 | | |
| |Rel=TURN-PUB-3 | | |
| | | | |
L NAT STUN NAT R
Server
| | | | |
|(1) Alloc Req | | | |
|Src=L-PRIV-1 | | | |
|Dest=TURN-PUB-1 | | | |
|--------------->| | | |
| | | | |
| |(2) Alloc Req | | |
| |Src=L-NAT-PUB-1 | | |
| |Dest=TURN-PUB-1 | | |
| |--------------->| | |
| | | | |
| |(3) Alloc Resp | | |
| |<---------------| | |
| |Src=TURN-PUB-1 | | |
| |Dest=L-NAT-PUB-1| | |
| |Map=L-NAT-PUB-1 | | |
| |Rel=TURN-PUB-2 | | |
| | | | |
|(4) Alloc Resp | | | |
|<---------------| | | |
|Src=TURN-PUB-1 | | | |
|Dest=L-PRIV-1 | | | |
|Map=L-NAT-PUB-1 | | | |
|Rel=TURN-PUB-2 | | | |
| | | | |
|(5) Alloc Req | | | |
|Src=L-PRIV-2 | | | |
|Dest=TURN-PUB-1 | | | |
|--------------->| | | |
| | | | |
| |(6) Alloc Req | | |
| |Src=L-NAT-PUB-2 | | |
| |Dest=TURN-PUB-1 | | |
| |--------------->| | |
| | | | |
| |(7) Alloc Resp | | |
| |<---------------| | |
| |Src=TURN-PUB-1 | | |
| |Dest=NAT-PUB-2 | | |
| |Map=NAT-PUB-2 | | |
| |Rel=TURN-PUB-3 | | |
| | | | |
|(8) Alloc Resp | | | |
|<---------------| | | |
|Src=TURN-PUB-1 | | | |
|Dest=L-PRIV-2 | | | |
|Map=L-NAT-PUB-2 | | | |
|Rel=TURN-PUB-3 | | | |
| | | | |
|(9) SIP INVITE | | | |
|------------------------------------------------->| |
| | | | |
| | | |(10) SIP INVITE |
| | | |--------------->|
| | | | |
| | | |(11) Alloc Req |
| | | |<---------------|
| | | |Src=R-PRIV-1 |
| | | |Dest=TURN-PUB-1 |
| | | | |
| | |(12) Alloc Req | |
| | |<---------------| |
| | |Src=R-NAT-PUB-1 | |
| | |Dest=TURN-PUB-1 | |
| | | | |
| | |(13) Alloc Res | |
| | |--------------->| |
| | |Src=TURN-PUB-1 | |
| | |Dest=R-NAT-PUB-1| |
| | |Map=R-NAT-PUB-1 | |
| | |Rel=TURN-PUB-4 | |
| | | | |
| | | |(14) Alloc Res |
| | | |--------------->|
| | | |Src=TURN-PUB-1 |
| | | |Dest=R-PRIV-1 |
| | | |Map=R-NAT-PUB-1 |
| | | |Rel=TURN-PUB-4 |
| | | | |
| | | |(15) Alloc Req |
| | | |<---------------|
| | | |Src=R-PRIV-2 |
| | | |Dest=TURN-PUB-1 |
| | | | |
| | |(16) Alloc Req | |
| | |<---------------| |
| | |Src=R-NAT-PUB-2 | |
| | |Dest=TURN-PUB-1 | |
| | | | |
|(8) Alloc Resp | | | |
|<---------------| | | |
|Src=TURN-PUB-1 | | | |
|Dest=L-PRIV-2 | | | |
|Map=L-NAT-PUB-2 | | | |
|Rel=TURN-PUB-3 | | | |
| | | | |
|(9) SIP INVITE | | | |
|------------------------------------------------->| |
| | | | |
| | | |(10) SIP INVITE |
| | | |--------------->|
| | | | |
| | | |(11) Alloc Req |
| | | |<---------------|
| | | |Src=R-PRIV-1 |
| | | |Dest=TURN-PUB-1 |
| | | | |
| | |(12) Alloc Req | |
| | |<---------------| |
| | |Src=R-NAT-PUB-1 | |
| | |Dest=TURN-PUB-1 | |
| | | | |
| | |(13) Alloc Res | |
| | |--------------->| |
| | |Src=TURN-PUB-1 | |
| | |Dest=R-NAT-PUB-1| |
| | |Map=R-NAT-PUB-1 | |
| | |Rel=TURN-PUB-4 | |
| | | | |
| | | |(14) Alloc Res |
| | | |--------------->|
| | | |Src=TURN-PUB-1 |
| | | |Dest=R-PRIV-1 |
| | | |Map=R-NAT-PUB-1 |
| | | |Rel=TURN-PUB-4 |
| | | | |
| | | |(15) Alloc Req |
| | | |<---------------|
| | | |Src=R-PRIV-2 |
| | | |Dest=TURN-PUB-1 |
| | | | |
| | |(16) Alloc Req | |
| | |<---------------| |
| | |Src=R-NAT-PUB-2 | |
| | |Dest=TURN-PUB-1 | |
| | | | |
| | |(17) Alloc Res | |
| | |--------------->| |
| | |Src=TURN-PUB-1 | |
| | |Dest=R-NAT-PUB-2| |
| | |Map=R-NAT-PUB-2 | |
| | |Rel=TURN-PUB-5 | |
| | | | |
| | | |(18) Alloc Res |
| | | |--------------->|
| | | |Src=TURN-PUB-1 |
| | | |Dest=R-PRIV-2 |
| | | |Map=R-NAT-PUB-2 |
| | | |Rel=TURN-PUB-5 |
| | | | |
| | | |(19) SIP 200 OK |
| |<-------------------------------------------------|
| | | | |
|(20) SIP 200 OK | | | |
|<---------------| | | |
| | | | |
|(21) SIP ACK | | | |
|------------------------------------------------->| |
| | | | |
| | | |(22) SIP ACK |
| | | |--------------->|
| | | | |
|(23) Bind Req | | | |
|------------------------>x | | |
|Src=L-PRIV-1 | | | |
|Dest=R-PRIV-1 | | | |
| | | | |
|(24) Bind Req | | | |
|--------------->| | | |
|Src=L-PRIV-1 | | | |
|Dest=R-NAT-PUB-1| | | |
| | | | |
| |(25) Bind Req | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-1 | | |
| |Dest=R-NAT-PUB-1| | |
| | | | |
| | | |(26) Bind Req |
| | | |--------------->|
| | | |Src=L-NAT-PUB-1 |
| | | |Dest=R-PRIV-1 |
| | | | |
| | |(17) Alloc Res | |
| | |--------------->| |
| | |Src=TURN-PUB-1 | |
| | |Dest=R-NAT-PUB-2| |
| | |Map=R-NAT-PUB-2 | |
| | |Rel=TURN-PUB-5 | |
| | | | |
| | | |(18) Alloc Res |
| | | |--------------->|
| | | |Src=TURN-PUB-1 |
| | | |Dest=R-PRIV-2 |
| | | |Map=R-NAT-PUB-2 |
| | | |Rel=TURN-PUB-5 |
| | | | |
| | | |(19) SIP 200 OK |
| |<-------------------------------------------------|
| | | | |
|(20) SIP 200 OK | | | |
|<---------------| | | |
| | | | |
|(21) SIP ACK | | | |
|------------------------------------------------->| |
| | | | |
| | | |(22) SIP ACK |
| | | |--------------->|
| | | | |
|(23) Bind Req | | | |
|------------------------>x | | |
|Src=L-PRIV-1 | | | |
|Dest=R-PRIV-1 | | | |
| | | | |
|(24) Bind Req | | | |
|--------------->| | | |
|Src=L-PRIV-1 | | | |
|Dest=R-NAT-PUB-1| | | |
| | | | |
| |(25) Bind Req | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-1 | | |
| |Dest=R-NAT-PUB-1| | |
| | | | |
| | | |(26) Bind Req |
| | | |--------------->|
| | | |Src=L-NAT-PUB-1 |
| | | |Dest=R-PRIV-1 |
| | | | |
| | | |(27) Bind Res |
| | | |<---------------|
| | | |Src=R-PRIV-1 |
| | | |Dest=L-NAT-PUB-1|
| | | |Map=L-NAT-PUB-1 |
| | | | |
| | |(28) Bind Res | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-1 | |
| | |Dest=L-NAT-PUB-1| |
| | |Map=L-NAT-PUB-1 | |
| | | | |
|(29) Bind Res | | | |
|<---------------| | | |
|Src=R-NAT-PUB-1 | | | |
|Dest=L-PRIV-1 | | | |
|Map=L-NAT-PUB-1 | | | |
| | | | |
|===================================================================|
|>>>>>>>>>>>>>>>>>>Outgoing RTP sent from L-PRIV-1 >>>>>>>>>>>>>>>>>|
|===================================================================|
| | | | |
| | | |(30) Bind Req |
| | | x<-----------------------|
| | | |Src=R-PRIV-1 |
| | | |Dest=L-PRIV-1 |
| | | | |
| | | |(31) Bind Req |
| | | |<---------------|
| | | |Src=R-PRIV-1 |
| | | |Dest=L-NAT-PUB-1|
| | | | |
| | |(32) Bind Req | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-1 | |
| | |Dest=L-NAT-PUB-1| |
| | | | |
|(33) Bind Req | | | |
|<---------------| | | |
|Src=R-NAT-PUB-1 | | | |
|Dest=L-PRIV-1 | | | |
| | | | |
|(34) Bind Res | | | |
|--------------->| | | |
|Src=L-PRIV-1 | | | |
|Dest=R-NAT-PUB-1| | | |
|Map=R-NAT-PUB-1 | | | |
| | | | |
| | | |(27) Bind Res |
| | | |<---------------|
| | | |Src=R-PRIV-1 |
| | | |Dest=L-NAT-PUB-1|
| | | |Map=L-NAT-PUB-1 |
| | | | |
| | |(28) Bind Res | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-1 | |
| | |Dest=L-NAT-PUB-1| |
| | |Map=L-NAT-PUB-1 | |
| | | | |
|(29) Bind Res | | | |
|<---------------| | | |
|Src=R-NAT-PUB-1 | | | |
|Dest=L-PRIV-1 | | | |
|Map=L-NAT-PUB-1 | | | |
| | | | |
|===================================================================|
|>>>>>>>>>>>>>>>>>>Outgoing RTP sent from L-PRIV-1 >>>>>>>>>>>>>>>>>|
|===================================================================|
| | | | |
| | | |(30) Bind Req |
| | | x<-----------------------|
| | | |Src=R-PRIV-1 |
| | | |Dest=L-PRIV-1 |
| | | | |
| | | |(31) Bind Req |
| | | |<---------------|
| | | |Src=R-PRIV-1 |
| | | |Dest=L-NAT-PUB-1|
| | | | |
| | |(32) Bind Req | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-1 | |
| | |Dest=L-NAT-PUB-1| |
| | | | |
|(33) Bind Req | | | |
|<---------------| | | |
|Src=R-NAT-PUB-1 | | | |
|Dest=L-PRIV-1 | | | |
| | | | |
|(34) Bind Res | | | |
|--------------->| | | |
|Src=L-PRIV-1 | | | |
|Dest=R-NAT-PUB-1| | | |
|Map=R-NAT-PUB-1 | | | |
| | | | |
| |(35) Bind Res | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-1 | | |
| |Dest=R-NAT-PUB-1| | |
| |Map=R-NAT-PUB-1 | | |
| | | | |
| | | |(36) Bind Res |
| | | |--------------->|
| | | |Src=L-NAT-PUB-1 |
| | | |Dest=R-PRIV-1 |
| | | |Map=R-NAT-PUB-1 |
| | | | |
|===================================================================|
|<<<<<<<<<<<<<<<<<<Outgoing RTP sent from R-PRIV-1 <<<<<<<<<<<<<<<<<|
|===================================================================|
|(37) Bind Req | | | |
|--------------->| | | |
|Src=L-PRIV-1 | | | |
|Dest=R-NAT-PUB-1| | | |
|USE-CANDIDATE | | | |
| | | | |
| |(38) Bind Req | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-1 | | |
| |Dest=R-NAT-PUB-1| | |
| |USE-CANDIDATE | | |
| | | | |
| | | |(39) Bind Req |
| | | |--------------->|
| | | |Src=L-NAT-PUB-1 |
| | | |Dest=R-PRIV-1 |
| | | |USE-CANDIDATE |
| | | | |
| | | |(40) Bind Res |
| | | |<---------------|
| | | |Src=R-PRIV-1 |
| | | |Dest=L-NAT-PUB-1|
| | | |Map=L-NAT-PUB-1 |
| | | | |
| | |(41) Bind Res | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-1 | |
| | |Dest=L-NAT-PUB-1| |
| | |Map=L-NAT-PUB-1 | |
| | | | |
| |(35) Bind Res | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-1 | | |
| |Dest=R-NAT-PUB-1| | |
| |Map=R-NAT-PUB-1 | | |
| | | | |
| | | |(36) Bind Res |
| | | |--------------->|
| | | |Src=L-NAT-PUB-1 |
| | | |Dest=R-PRIV-1 |
| | | |Map=R-NAT-PUB-1 |
| | | | |
|===================================================================|
|<<<<<<<<<<<<<<<<<<Outgoing RTP sent from R-PRIV-1 <<<<<<<<<<<<<<<<<|
|===================================================================|
|(37) Bind Req | | | |
|--------------->| | | |
|Src=L-PRIV-1 | | | |
|Dest=R-NAT-PUB-1| | | |
|USE-CANDIDATE | | | |
| | | | |
| |(38) Bind Req | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-1 | | |
| |Dest=R-NAT-PUB-1| | |
| |USE-CANDIDATE | | |
| | | | |
| | | |(39) Bind Req |
| | | |--------------->|
| | | |Src=L-NAT-PUB-1 |
| | | |Dest=R-PRIV-1 |
| | | |USE-CANDIDATE |
| | | | |
| | | |(40) Bind Res |
| | | |<---------------|
| | | |Src=R-PRIV-1 |
| | | |Dest=L-NAT-PUB-1|
| | | |Map=L-NAT-PUB-1 |
| | | | |
| | |(41) Bind Res | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-1 | |
| | |Dest=L-NAT-PUB-1| |
| | |Map=L-NAT-PUB-1 | |
| | | | |
|(42) Bind Res | | | |
|<---------------| | | |
|Src=R-NAT-PUB-1 | | | |
|Dest=L-PRIV-1 | | | |
|Map=L-NAT-PUB-1 | | | |
| | | | |
|(43) Bind Req | | | |
|--------------->| | | |
|Src=L-PRIV-2 | | | |
|Dest=R-NAT-PUB-2| | | |
| | | | |
| |(44) Bind Req | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-2 | | |
| |Dest=R-NAT-PUB-2| | |
| | | | |
| | | |(45) Bind Req |
| | | |--------------->|
| | | |Src=L-NAT-PUB-2 |
| | | |Dest=R-PRIV-2 |
| | | | |
| | | |(46) Bind Res |
| | | |<---------------|
| | | |Src=R-PRIV-2 |
| | | |Dest=L-NAT-PUB-2|
| | | |Map=L-NAT-PUB-2 |
| | | | |
| | |(47) Bind Res | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-2 | |
| | |Dest=L-NAT-PUB-2| |
| | |Map=L-NAT-PUB-2 | |
| | | | |
|(48) Bind Res | | | |
|<---------------| | | |
|Src=R-NAT-PUB-2 | | | |
|Dest=L-PRIV-2 | | | |
|Map=L-NAT-PUB-2 | | | |
| | | | |
|===================================================================|
|>>>>>>>>>>>>>>>>>>Outgoing RTCP sent from L-PRIV-2 >>>>>>>>>>>>>>>>|
|===================================================================|
| | | | |
| | | |(49) Bind Req |
| | | |<---------------|
| | | |Src=R-PRIV-2 |
| | | |Dest=L-NAT-PUB-2|
| | | | |
|(42) Bind Res | | | |
|<---------------| | | |
|Src=R-NAT-PUB-1 | | | |
|Dest=L-PRIV-1 | | | |
|Map=L-NAT-PUB-1 | | | |
| | | | |
|(43) Bind Req | | | |
|--------------->| | | |
|Src=L-PRIV-2 | | | |
|Dest=R-NAT-PUB-2| | | |
| | | | |
| |(44) Bind Req | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-2 | | |
| |Dest=R-NAT-PUB-2| | |
| | | | |
| | | |(45) Bind Req |
| | | |--------------->|
| | | |Src=L-NAT-PUB-2 |
| | | |Dest=R-PRIV-2 |
| | | | |
| | | |(46) Bind Res |
| | | |<---------------|
| | | |Src=R-PRIV-2 |
| | | |Dest=L-NAT-PUB-2|
| | | |Map=L-NAT-PUB-2 |
| | | | |
| | |(47) Bind Res | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-2 | |
| | |Dest=L-NAT-PUB-2| |
| | |Map=L-NAT-PUB-2 | |
| | | | |
|(48) Bind Res | | | |
|<---------------| | | |
|Src=R-NAT-PUB-2 | | | |
|Dest=L-PRIV-2 | | | |
|Map=L-NAT-PUB-2 | | | |
| | | | |
|===================================================================|
|>>>>>>>>>>>>>>>>>>Outgoing RTCP sent from L-PRIV-2 >>>>>>>>>>>>>>>>|
|===================================================================|
| | | | |
| | | |(49) Bind Req |
| | | |<---------------|
| | | |Src=R-PRIV-2 |
| | | |Dest=L-NAT-PUB-2|
| | | | |
| | |(50) Bind Req | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-2 | |
| | |Dest=L-NAT-PUB-2| |
| | | | |
|(51) Bind Req | | | |
|<---------------| | | |
|Src=R-NAT-PUB-2 | | | |
|Dest=L-PRIV-2 | | | |
| | | | |
|(52) Bind Res | | | |
|--------------->| | | |
|Src=L-PRIV-2 | | | |
|Dest=R-NAT-PUB-2| | | |
|Map=R-NAT-PUB-2 | | | |
| | | | |
| |(53) Bind Res | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-2 | | |
| |Dest=R-NAT-PUB-2| | |
| |Map=R-NAT-PUB-2 | | |
| | | | |
| | | |(54) Bind Res |
| | | |--------------->|
| | | |Src=L-NAT-PUB-2 |
| | | |Dest=R-PRIV-2 |
| | | |Map=R-NAT-PUB-2 |
| | | | |
|===================================================================|
|<<<<<<<<<<<<<<<<<<Outgoing RTCP sent from R-PRIV-2<<<<<<<<<<<<<<<<<|
|===================================================================|
|(55) Bind Req | | | |
|--------------->| | | |
|Src=L-PRIV-2 | | | |
|Dest=R-NAT-PUB-2| | | |
|USE-CANDIDATE | | | |
| | | | |
| |(56) Bind Req | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-2 | | |
| |Dest=R-NAT-PUB-2| | |
| |USE-CANDIDATE | | |
| | | | |
| | | |(57) Bind Req |
| | | |--------------->|
| | | |Src=L-NAT-PUB-2 |
| | | |Dest=R-PRIV-2 |
| | | |USE-CANDIDATE |
| | |(50) Bind Req | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-2 | |
| | |Dest=L-NAT-PUB-2| |
| | | | |
|(51) Bind Req | | | |
|<---------------| | | |
|Src=R-NAT-PUB-2 | | | |
|Dest=L-PRIV-2 | | | |
| | | | |
|(52) Bind Res | | | |
|--------------->| | | |
|Src=L-PRIV-2 | | | |
|Dest=R-NAT-PUB-2| | | |
|Map=R-NAT-PUB-2 | | | |
| | | | |
| |(53) Bind Res | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-2 | | |
| |Dest=R-NAT-PUB-2| | |
| |Map=R-NAT-PUB-2 | | |
| | | | |
| | | |(54) Bind Res |
| | | |--------------->|
| | | |Src=L-NAT-PUB-2 |
| | | |Dest=R-PRIV-2 |
| | | |Map=R-NAT-PUB-2 |
| | | | |
|===================================================================|
|<<<<<<<<<<<<<<<<<<Outgoing RTCP sent from R-PRIV-2<<<<<<<<<<<<<<<<<|
|===================================================================|
|(55) Bind Req | | | |
|--------------->| | | |
|Src=L-PRIV-2 | | | |
|Dest=R-NAT-PUB-2| | | |
|USE-CANDIDATE | | | |
| | | | |
| |(56) Bind Req | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-2 | | |
| |Dest=R-NAT-PUB-2| | |
| |USE-CANDIDATE | | |
| | | | |
| | | |(57) Bind Req |
| | | |--------------->|
| | | |Src=L-NAT-PUB-2 |
| | | |Dest=R-PRIV-2 |
| | | |USE-CANDIDATE |
| | | | |
| | | |(58) Bind Res |
| | | |<---------------|
| | | |Src=R-PRIV-2 |
| | | |Dest=L-NAT-PUB-2|
| | | |Map=L-NAT-PUB-2 |
| | | | |
| | |(59) Bind Res | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-2 | |
| | |Dest=L-NAT-PUB-2| |
| | |Map=L-NAT-PUB-2 | |
| | | | |
|(60) Bind Res | | | |
|<---------------| | | |
|Src=R-NAT-PUB-2 | | | |
|Dest=L-PRIV-2 | | | |
|Map=L-NAT-PUB-2 | | | |
| | | | |
| | | | |
|(61) SIP INVITE | | | |
|------------------------------------------------->| |
| | | | |
| | | |(62) SIP INVITE |
| | | |--------------->|
| | | | |
| | | |(63) SIP 200 OK |
| |<-------------------------------------------------|
| | | | |
|(64) SIP 200 OK | | | |
|<---------------| | | |
| | | | |
|(65) SIP ACK | | | |
|------------------------------------------------->| |
| | | | |
| | | |(66) SIP ACK |
| | | |--------------->|
| | | | |
| | | | |
| | | |(58) Bind Res |
| | | |<---------------|
| | | |Src=R-PRIV-2 |
| | | |Dest=L-NAT-PUB-2|
| | | |Map=L-NAT-PUB-2 |
| | | | |
| | |(59) Bind Res | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-2 | |
| | |Dest=L-NAT-PUB-2| |
| | |Map=L-NAT-PUB-2 | |
| | | | |
|(60) Bind Res | | | |
|<---------------| | | |
|Src=R-NAT-PUB-2 | | | |
|Dest=L-PRIV-2 | | | |
|Map=L-NAT-PUB-2 | | | |
| | | | |
| | | | |
|(61) SIP INVITE | | | |
|------------------------------------------------->| |
| | | | |
| | | |(62) SIP INVITE |
| | | |--------------->|
| | | | |
| | | |(63) SIP 200 OK |
| |<-------------------------------------------------|
| | | | |
|(64) SIP 200 OK | | | |
|<---------------| | | |
| | | | |
|(65) SIP ACK | | | |
|------------------------------------------------->| |
| | | | |
| | | |(66) SIP ACK |
| | | |--------------->|
| | | | |
Figure 13: Endpoint-Independent NAT with ICE
图13：具有ICE的端点独立NAT
o On deciding to initiate a SIP voice session, the SIP client L starts a local STUN client. The STUN client generates a TURN Allocate request as indicated in (1) from Figure 13 that also highlights the source address and port combination for which the client device wishes to obtain a mapping. The Allocate request is sent through the NAT towards the public Internet.
o 在决定发起SIP语音会话时，SIP客户端L启动本地STUN客户端。STUN客户端生成一个TURN Allocate请求，如图13中（1）所示，该请求还突出显示了客户端设备希望获得映射的源地址和端口组合。分配请求通过NAT发送到公共互联网。
o The Allocate message (2) traverses the NAT to the public Internet towards the public TURN server. Note that the source address of the Allocate request now represents the public address and port from the public side of the NAT (L-NAT-PUB-1).
o 分配消息（2）穿过NAT到公共互联网，朝向公共转向服务器。注意，分配请求的源地址现在表示NAT公共端的公共地址和端口（L-NAT-PUB-1）。
o The TURN server receives the Allocate request and processes it appropriately. This results in a successful Allocate response being generated and returned (3). The message contains details of the server reflexive address that is to be used by the originating client to receive media (see 'Map=L-NAT-PUB-1') from (3)). It also contains an appropriate TURN-relayed address that can be used at the STUN server (see 'Rel=TURN-PUB-2').
o TURN服务器接收分配请求并对其进行适当处理。这将导致生成并返回成功的分配响应（3）。该消息包含原始客户端用于从（3）接收媒体的服务器自反地址的详细信息（请参阅“Map=L-NAT-PUB-1”）。它还包含可在STUN服务器上使用的适当的回合中继地址（请参阅“Rel=TURN-PUB-2”）。
o The Allocate response traverses back through the NAT using the binding created by the initial Allocate request and presents the new mapped address to the client (4). The process is repeated and a second STUN derived set of addresses is obtained, as illustrated in (5)-(8) in Figure 13. At this point, the User Agent behind the NAT has pairs of derived external server reflexive and relayed representations. The client can also gather IP addresses and ports via other mechanisms (e.g., NAT-PMP [NAT-PMP], UPnP IGD [UPnP-IGD]) or similar.
o 分配响应使用初始分配请求创建的绑定遍历NAT，并将新映射的地址呈现给客户端（4）。重复该过程并获得第二个STUN派生的地址集，如图13中的（5）-（8）所示。此时，NAT后面的用户代理具有成对的派生外部服务器自反和中继表示。客户端还可以通过其他机制（例如NAT-PMP[NAT-PMP]、UPnP IGD[UPnP IGD]）或类似机制收集IP地址和端口。
o The client now constructs a SIP INVITE message (9). The INVITE request will use the addresses it has obtained in the previous STUN/TURN interactions to populate the SDP of the SIP INVITE. This should be carried out in accordance with the semantics defined in the ICE specification [RFC5245], as shown below in Figure 14:
o 客户端现在构造SIP INVITE消息（9）。INVITE请求将使用在之前的STUN/TURN交互中获得的地址来填充SIP INVITE的SDP。这应按照ICE规范[RFC5245]中定义的语义进行，如图14所示：
v=0
o=test 2890844526 2890842807 IN IP4 $L-PRIV-1
c=IN IP4 $L-PRIV-1.address
t=0 0
a=ice-pwd:$LPASS
a=ice-ufrag:$LUNAME
m=audio $L-PRIV-1.port RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=rtcp:$L-PRIV-2.port
a=candidate:$L1 1 UDP 2130706431 $L-PRIV-1.address $L-PRIV-1.port
typ host
a=candidate:$L1 2 UDP 2130706430 $L-PRIV-2.address $L-PRIV-2.port
typ host
a=candidate:$L2 1 UDP 1694498815 $L-NAT-PUB-1.address $L-NAT-PUB-1.port
typ srflx raddr $L-PRIV-1.address rport $L-PRIV-1.port
a=candidate:$L2 2 UDP 1694498814 $L-NAT-PUB-2.address $L-NAT-PUB-2.port
typ srflx raddr $L-PRIV-1.address rport $L-PRIV-2.port
a=candidate:$L3 1 UDP 16777215 $STUN-PUB-2.address $STUN-PUB-2.port
typ relay raddr $L-PRIV-1.address rport $L-PRIV-1.port
a=candidate:$L3 2 UDP 16777214 $STUN-PUB-3.address $STUN-PUB-3.port
typ relay raddr $L-PRIV-1.address rport $L-PRIV-2.port
v=0
o=test 2890844526 2890842807 IN IP4 $L-PRIV-1
c=IN IP4 $L-PRIV-1.address
t=0 0
a=ice-pwd:$LPASS
a=ice-ufrag:$LUNAME
m=audio $L-PRIV-1.port RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=rtcp:$L-PRIV-2.port
a=candidate:$L1 1 UDP 2130706431 $L-PRIV-1.address $L-PRIV-1.port
typ host
a=candidate:$L1 2 UDP 2130706430 $L-PRIV-2.address $L-PRIV-2.port
typ host
a=candidate:$L2 1 UDP 1694498815 $L-NAT-PUB-1.address $L-NAT-PUB-1.port
typ srflx raddr $L-PRIV-1.address rport $L-PRIV-1.port
a=candidate:$L2 2 UDP 1694498814 $L-NAT-PUB-2.address $L-NAT-PUB-2.port
typ srflx raddr $L-PRIV-1.address rport $L-PRIV-2.port
a=candidate:$L3 1 UDP 16777215 $STUN-PUB-2.address $STUN-PUB-2.port
typ relay raddr $L-PRIV-1.address rport $L-PRIV-1.port
a=candidate:$L3 2 UDP 16777214 $STUN-PUB-3.address $STUN-PUB-3.port
typ relay raddr $L-PRIV-1.address rport $L-PRIV-2.port
Figure 14: ICE SDP Offer
图14：ICE SDP报价
o The SDP has been constructed to include all the available candidates that have been assembled. The first set of candidates (as identified by Foundation $L1) contains two local addresses that have the highest priority. They are also encoded into the connection (c=) and media (m=) lines of the SDP. The second set of candidates, as identified by Foundation $L2, contains the two server reflexive addresses obtained from the STUN server for both RTP and RTCP traffic (identified by candidate-id $L2). This entry has been given a priority lower than the pair $L1 by the client. The third and final set of candidates represents the relayed addresses (as identified by $L3) obtained from the STUN server. This pair has the lowest priority and will be used as a last resort if both $L1 and $L2 fail.
o SDP已构建为包括所有已组装的可用候选程序。第一组候选（如基金会$ L1所标识）包含两个具有最高优先级的本地地址。它们也被编码到SDP的连接（c=）和媒体（m=）行中。第二组候选由基础$ L2标识，包含从STUN服务器获得的两个服务器自反地址，用于RTP和RTCP流量（由候选ID $L2标识）。客户端已将此条目的优先级设置为低于$L1对。第三组也是最后一组候选地址表示从STUN服务器获得的中继地址（由$L3标识）。此对具有最低优先级，如果$L1和$L2都失败，将作为最后手段使用。
o The SIP signaling then traverses the NAT and sets up the SIP session (9)-(10). On advertising a candidate address, the client should have a local STUN server running on each advertised candidate address. This is for the purpose of responding to incoming STUN connectivity checks.
o 然后SIP信令穿过NAT并建立SIP会话（9）-（10）。在公布候选地址时，客户端应在每个公布的候选地址上运行本地STUN服务器。这是为了响应传入的STUN连接检查。
o On receiving the SIP INVITE request (10) client R also starts local STUN servers on appropriate address/port combinations and gathers potential candidate addresses to be encoded into the SDP (as the originating client did). Steps (11-18) involve client R
o 在接收到SIP INVITE请求（10）时，客户机R还将在适当的地址/端口组合上启动本地STUN服务器，并收集要编码到SDP中的潜在候选地址（与原始客户机一样）。步骤（11-18）涉及客户R
carrying out the same steps as client L. This involves obtaining local, server reflexive, and relayed addresses. Client R is now ready to generate an appropriate answer in the SIP 200 OK message (19). The example answer follows in Figure 15:
执行与客户端L相同的步骤。这涉及获取本地、服务器自反和中继地址。客户端R现在准备在SIP 200 OK消息（19）中生成适当的应答。示例答案如图15所示：
v=0
o=test 3890844516 3890842803 IN IP4 $R-PRIV-1
c=IN IP4 $R-PRIV-1.address
t=0 0
a=ice-pwd:$RPASS
m=audio $R-PRIV-1.port RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=rtcp:$R-PRIV-2.port
a=candidate:$L1 1 UDP 2130706431 $R-PRIV-1.address $R-PRIV-1.port
typ host
a=candidate:$L1 2 UDP 2130706430 $R-PRIV-2.address $R-PRIV-2.port
typ host
a=candidate:$L2 1 UDP 1694498815 $R-NAT-PUB-1.address $R-NAT-PUB-1.port
typ srflx raddr $R-PRIV-1.address rport $R-PRIV-1.port
a=candidate:$L2 2 UDP 1694498814 $R-NAT-PUB-2.address $R-NAT-PUB-2.port
typ srflx raddr $R-PRIV-1.address rport $R-PRIV-1.port
a=candidate:$L3 1 UDP 16777215 $STUN-PUB-2.address $STUN-PUB-4.port
typ relay raddr $R-PRIV-1.address rport $R-PRIV-1.port
a=candidate:$L3 2 UDP 16777214 $STUN-PUB-3.address $STUN-PUB-5.port
typ relay raddr $R-PRIV-1.address rport $R-PRIV-1.port
v=0
o=test 3890844516 3890842803 IN IP4 $R-PRIV-1
c=IN IP4 $R-PRIV-1.address
t=0 0
a=ice-pwd:$RPASS
m=audio $R-PRIV-1.port RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=rtcp:$R-PRIV-2.port
a=candidate:$L1 1 UDP 2130706431 $R-PRIV-1.address $R-PRIV-1.port
typ host
a=candidate:$L1 2 UDP 2130706430 $R-PRIV-2.address $R-PRIV-2.port
typ host
a=candidate:$L2 1 UDP 1694498815 $R-NAT-PUB-1.address $R-NAT-PUB-1.port
typ srflx raddr $R-PRIV-1.address rport $R-PRIV-1.port
a=candidate:$L2 2 UDP 1694498814 $R-NAT-PUB-2.address $R-NAT-PUB-2.port
typ srflx raddr $R-PRIV-1.address rport $R-PRIV-1.port
a=candidate:$L3 1 UDP 16777215 $STUN-PUB-2.address $STUN-PUB-4.port
typ relay raddr $R-PRIV-1.address rport $R-PRIV-1.port
a=candidate:$L3 2 UDP 16777214 $STUN-PUB-3.address $STUN-PUB-5.port
typ relay raddr $R-PRIV-1.address rport $R-PRIV-1.port
Figure 15: ICE SDP Answer
图15:ICE SDP答案
o The two clients have now exchanged SDP using offer/answer and can now continue with the ICE processing -- User Agent L assuming the role controlling agent, as specified by ICE. The clients are now required to form their Candidate check lists to determine which will be used for the media streams. In this example, User Agent L's Foundation 1 is paired with User Agent R's Foundation 1, User Agent L's Foundation 2 is paired with User Agent R's Foundation 2, and finally User Agent L's Foundation 3 is paired with User Agent R's Foundation 3. User Agents L and R now have a complete candidate checklist. Both clients now use the algorithm provided in ICE to determine candidate pair priorities and sort into a list of decreasing priorities. In this example, both User Agents L and R will have lists that firstly specify the host address (Foundation $L1), then the server reflexive address (Foundation $L2), and lastly the relayed address (Foundation $L3). All candidate pairs have an associate state as specified in ICE. At this stage, all of the candidate pairs for User Agents L and R are initialized to the 'Frozen' state. The User Agents then scan the list and move the candidates to the 'Waiting' state. At this point, both clients will periodically, starting with the highest
o 这两个客户端现在已经使用offer/answer交换了SDP，并且现在可以继续ICE处理——用户代理L承担ICE指定的角色控制代理。客户机现在需要形成他们的候选检查列表，以确定哪些将用于媒体流。在这个示例中，用户代理L的基础1与用户代理R的基础1配对，用户代理L的基础2与用户代理R的基础2配对，并且最终用户代理L的基础3与用户代理R的基础3配对。用户代理L和R现在有一个完整的候选清单。现在，两个客户端都使用ICE中提供的算法来确定候选对优先级，并将其排序到一个优先级递减的列表中。在此示例中，用户代理L和R都将具有列表，这些列表首先指定主机地址（Foundation$L1），然后是服务器自反地址（Foundation$L2），最后是中继地址（Foundation$L3）。所有候选对都具有ICE中指定的关联状态。在此阶段，用户代理L和R的所有候选对都被初始化为“冻结”状态。然后，用户代理扫描列表并将候选项移动到“等待”状态。在这一点上，两个客户机都会定期更新，从最高级别开始
candidate pair priority, work their way down the list issuing STUN checks from the local candidate to the remote candidate (of the candidate pair). As a STUN check is attempted from each local candidate in the list, the candidate pair state transitions to 'In-Progress'. As illustrated in (23), client L constructs a STUN connectivity check in an attempt to validate the remote candidate address received in the SDP of the 200 OK (20) for the highest priority in the checklist. As a private address was specified in the active address in the SDP, the STUN connectivity check fails to reach its destination causing a STUN failure. Client L transitions the state for this candidate pair to 'Failed'. In the meantime, client L is attempting a STUN connectivity check for the second candidate pair in the returned SDP with the second highest priority (24). As can be seen from messages (24) to (29), the STUN Bind request is successful and returns a positive outcome for the connectivity check. Client L is now free to send media to the peer using the candidate pair. Immediately after sending its 200 OK, client R also carries out the same set of binding requests. It firstly (in parallel) tries to contact the active address contained in the SDP (30) which results in failure.
候选对优先级，从本地候选到远程候选（候选对的）进行眩晕检查。当试图对列表中的每个本地候选对象进行眩晕检查时，候选对象对状态将转换为“进行中”。如（23）所示，客户机L构建一个STUN连接检查，试图验证在200 OK（20）的SDP中接收到的远程候选地址是否为清单中的最高优先级。由于在SDP中的活动地址中指定了专用地址，因此STUN连接检查无法到达其目标，从而导致STUN失败。客户端L将此候选对的状态转换为“失败”。同时，客户端L正在尝试对返回的SDP中的第二个候选对进行STUN连接检查，该SDP具有第二高优先级（24）。从消息（24）到（29）可以看出，STUN绑定请求成功，并返回连接检查的肯定结果。客户端L现在可以自由地使用候选对向对等方发送媒体。在发送200OK之后，客户机R也立即执行相同的绑定请求集。它首先（并行）尝试联系SDP（30）中包含的活动地址，这导致失败。
o In the meantime, a successful response to a STUN connectivity check by User Agent R (27) results in a tentative check in the reverse direction -- this is illustrated by messages (31) to (36). Once this check has succeeded, User Agent R can transition the state of the appropriate candidate to 'Succeeded', and media can be sent (RTP). The previously (31-36) described check confirm on both sides (User Agents L and R) that connectivity can be achieved using the appropriate candidate pair. User Agent L, as the controlling client now sends another connectivity check for the candidate pair, this time including the 'USE-CANDIDATE' attribute as specified in ICE to signal the chosen candidate. This exchange is illustrated in messages (37) to (42).
o 同时，用户代理R（27）对STUN连接检查的成功响应将导致反向的试探性检查——消息（31）到（36）说明了这一点。一旦此检查成功，用户代理R可以将相应候选的状态转换为“成功”，并且可以发送媒体（RTP）。前面描述的（31-36）检查在两侧（用户代理L和R）确认可以使用适当的候选对实现连接。用户代理L，作为控制客户端，现在为候选对发送另一个连接检查，这次包括ICE中指定的“USE-candidate”属性，以向所选候选发送信号。该交换在消息（37）到（42）中说明。
o As part of the process in this example, both L and R will now complete the same connectivity checks for part 2 of the component named for the favored 'Foundation' selected for use with RTCP. The connectivity checks for part 2 of the candidate component are shown in L (43-48) and R (49-54). Once this has succeeded, User Agent L as the controlling client sends another connectivity check for the candidate pair. This time the 'USE-CANDIDATE' attribute is again specified to signal the chosen candidate for component 2.
o 作为本例中流程的一部分，L和R现在将完成与RTCP一起使用的首选“基础”组件第2部分相同的连接检查。候选组件第2部分的连接检查如L（43-48）和R（49-54）所示。一旦成功，作为控制客户端的用户代理L将为候选对发送另一个连接检查。这一次，再次指定“USE-CANDIDATE”属性，以表示为组件2选择的候选者。
o The candidates have now been fully verified (and selected), and as they are the highest priority, an updated offer (61-62) is now sent from the offerer (client L) to the answerer (client R) representing the new active candidates. The new offer would look as follows:
o 候选人现在已经得到充分验证（并被选中），由于他们是最高优先级的候选人，现在从报价人（客户L）向代表新活跃候选人的应答人（客户R）发送更新的报价（61-62）。新的报价如下：
v=0
o=test 2890844526 2890842808 IN IP4 $L-PRIV-1
c=IN IP4 $L-NAT-PUB-1.address
t=0 0
a=ice-pwd:$LPASS
a=ice-ufrag:$LUNAME
m=audio $L-NAT-PUB-1.port RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=rtcp:$L-NAT-PUB-2.port
a=candidate:$L2 1 UDP 2203948363 $L-NAT-PUB-1.address $L-NAT-PUB-1.port
typ srflx raddr $L-PRIV-1.address rport $L-PRIV-1.port
a=candidate:$L2 2 UDP 2172635342 $L-NAT-PUB-2.address $L-NAT-PUB-2.port
typ srflx raddr $L-PRIV-1.address rport $L-PRIV-2.port
v=0
o=test 2890844526 2890842808 IN IP4 $L-PRIV-1
c=IN IP4 $L-NAT-PUB-1.address
t=0 0
a=ice-pwd:$LPASS
a=ice-ufrag:$LUNAME
m=audio $L-NAT-PUB-1.port RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=rtcp:$L-NAT-PUB-2.port
a=candidate:$L2 1 UDP 2203948363 $L-NAT-PUB-1.address $L-NAT-PUB-1.port
typ srflx raddr $L-PRIV-1.address rport $L-PRIV-1.port
a=candidate:$L2 2 UDP 2172635342 $L-NAT-PUB-2.address $L-NAT-PUB-2.port
typ srflx raddr $L-PRIV-1.address rport $L-PRIV-2.port
Figure 16: ICE SDP Updated Offer
图16:ICE SDP更新报价
o The resulting answer (63-64) for R would look as follows:
o R的最终答案（63-64）如下所示：
v=0
o=test 3890844516 3890842804 IN IP4 $R-PRIV-1
c=IN IP4 $R-PRIV-1.address
t=0 0
a=ice-pwd:$RPASS
a=ice-ufrag:$RUNAME
m=audio $R-PRIV-1.port RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=rtcp:$R-PRIV-2.port
a=candidate:$L2 1 UDP 2984756463 $R-NAT-PUB-1.address $R-NAT-PUB-1.port
typ srflx raddr $R-PRIV-1.address rport $R-PRIV-1.port
a=candidate:$L2 2 UDP 2605968473 $R-NAT-PUB-2.address $R-NAT-PUB-2.port
typ srflx raddr $R-PRIV-1.address rport $R-PRIV-2.port
v=0
o=test 3890844516 3890842804 IN IP4 $R-PRIV-1
c=IN IP4 $R-PRIV-1.address
t=0 0
a=ice-pwd:$RPASS
a=ice-ufrag:$RUNAME
m=audio $R-PRIV-1.port RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=rtcp:$R-PRIV-2.port
a=candidate:$L2 1 UDP 2984756463 $R-NAT-PUB-1.address $R-NAT-PUB-1.port
typ srflx raddr $R-PRIV-1.address rport $R-PRIV-1.port
a=candidate:$L2 2 UDP 2605968473 $R-NAT-PUB-2.address $R-NAT-PUB-2.port
typ srflx raddr $R-PRIV-1.address rport $R-PRIV-2.port
Figure 17: ICE SDP Updated Answer
图17:ICE SDP更新答案
This section highlights that although using STUN techniques is the preferred mechanism for traversal of NAT, it does not solve every case. The use of basic STUN on its own will not guarantee traversal through every NAT type, hence the recommendation that ICE is the preferred option.
本节强调，尽管使用STUN技术是遍历NAT的首选机制，但它并不能解决所有情况。单独使用基本STUN并不能保证遍历每种NAT类型，因此建议首选ICE。
Client ADDRESS/PORT-Dependent STUN [..]
NAT Server
| | | |
|(1) BIND Req | | |
|Src=L-PRIV-1 | | |
|Dest=STUN-PUB | | |
|----------------->| | |
| |(2) BIND Req | |
| |Src=NAT-PUB-1 | |
| |Dest=STUN-PUB | |
| |----------------->| |
| | | |
| |(3) BIND Resp | |
| |<-----------------| |
| |Src=STUN-PUB | |
| |Dest=NAT-PUB-1 | |
| |Map=NAT-PUB-1 | |
| | | |
|(4) BIND Resp | | |
|<-----------------| | |
|Src=STUN-PUB | | |
|Dest=L-PRIV-1 | | |
|Map=NAT-PUB-1 | | |
| | | |
|(5)SIP INVITE | | |
|------------------------------------------------------->|
| | | |
| | |(6)SIP 200 OK |
| |<------------------------------------|
| | | |
|(7)SIP 200 OK | | |
|<-----------------| | |
| | | |
|========================================================|
|>>>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>|
|========================================================|
| | | |
| x=====================================|
| xIncoming Media sent to L-PRIV-1<<<<<<|
| x=====================================|
| | | |
|(8)SIP ACK | | |
|----------------->| | |
| |(9) SIP ACK | |
| |------------------------------------>|
| | | |
Client ADDRESS/PORT-Dependent STUN [..]
NAT Server
| | | |
|(1) BIND Req | | |
|Src=L-PRIV-1 | | |
|Dest=STUN-PUB | | |
|----------------->| | |
| |(2) BIND Req | |
| |Src=NAT-PUB-1 | |
| |Dest=STUN-PUB | |
| |----------------->| |
| | | |
| |(3) BIND Resp | |
| |<-----------------| |
| |Src=STUN-PUB | |
| |Dest=NAT-PUB-1 | |
| |Map=NAT-PUB-1 | |
| | | |
|(4) BIND Resp | | |
|<-----------------| | |
|Src=STUN-PUB | | |
|Dest=L-PRIV-1 | | |
|Map=NAT-PUB-1 | | |
| | | |
|(5)SIP INVITE | | |
|------------------------------------------------------->|
| | | |
| | |(6)SIP 200 OK |
| |<------------------------------------|
| | | |
|(7)SIP 200 OK | | |
|<-----------------| | |
| | | |
|========================================================|
|>>>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>|
|========================================================|
| | | |
| x=====================================|
| xIncoming Media sent to L-PRIV-1<<<<<<|
| x=====================================|
| | | |
|(8)SIP ACK | | |
|----------------->| | |
| |(9) SIP ACK | |
| |------------------------------------>|
| | | |
Figure 18: Address/Port-Dependent NAT with STUN - Failure
Figure 18: Address/Port-Dependent NAT with STUN - Failure
The example in Figure 18 is conveyed in the context of a client behind the Address/Port-Dependent NAT initiating a call. It should be noted that the same problem applies when a client receives a SIP invitation and is behind a Address/Port-Dependent NAT.
图18中的示例在发起调用的地址/端口相关NAT后面的客户机上下文中传输。应该注意的是，当客户端接收到SIP邀请并且位于依赖于地址/端口的NAT之后时，同样的问题也会出现。
o In Figure 18, the client behind the NAT obtains a server reflexive representation using standard STUN mechanisms (1)-(4) that have been used in previous examples in this document (e.g., Section 5.2.1.1.1).
o 在图18中，NAT背后的客户端使用标准STUN机制（1）-（4）获得服务器自反表示，该机制已在本文档前面的示例中使用（例如，第5.2.1.1.1节）。
o The external mapped address (server reflexive) obtained is also used in the outgoing SDP contained in the SIP INVITE request (5).
o 获得的外部映射地址（服务器自反）也用于SIP INVITE请求（5）中包含的传出SDP。
o In this example, the client is still able to send media to the external client. The problem occurs when the client outside the NAT tries to use the reflexive address supplied in the outgoing INVITE request to traverse media back through the Address/ Port-Dependent NAT.
o 在本例中，客户端仍然能够向外部客户端发送媒体。当NAT外部的客户机试图使用传出INVITE请求中提供的自反地址通过地址/端口相关NAT穿越介质时，就会出现问题。
o A Address/Port-Dependent NAT has differing rules from the Endpoint-Independent type of NAT (as defined in RFC 4787 [RFC4787]). For any internal IP address and port combination, data sent to a different external destination does not provide the same public mapping at the NAT. In Figure 18, the STUN query produced a valid external mapping for receiving media. This mapping, however, can only be used in the context of the original STUN request that was sent to the STUN server. Any packets that attempt to use the mapped address and that do not originate from the STUN server IP address and optionally port will be dropped at the NAT. Figure 18 shows the media being dropped at the NAT after (7) and before (8). This then leads to one-way audio.
o 与地址/端口相关的NAT具有与端点无关的NAT类型不同的规则（如RFC 4787[RFC4787]中所定义）。对于任何内部IP地址和端口组合，发送到不同外部目的地的数据不会在NAT上提供相同的公共映射。在图18中，STUN查询为接收媒体生成了有效的外部映射。但是，此映射只能在发送到STUN服务器的原始STUN请求的上下文中使用。任何试图使用映射地址且并非源自STUN服务器IP地址和可选端口的数据包都将在NAT上丢弃。图18显示了在（7）之后和（8）之前NAT丢弃的介质。这将导致单向音频。
As identified in Section 5.2.2.1, STUN provides a useful tool for the traversal of the majority of NATs but fails with Address/ Port-Dependent NAT. The TURN extensions [RFC5766] address this scenario. TURN extends STUN to allow a client to request a relayed address at the TURN server rather than a reflexive representation. This then introduces a media relay in the path for NAT traversal (as described in Section 4.2.3.2). The following example explains how TURN solves the previous failure when using STUN to traverse a Address/Port-Dependent NAT. It should be noted that TURN works most effectively when used in conjunction with ICE. Using TURN on its own results in all media being relayed through a TURN server; this is not efficient.
如第5.2.2.1节所述，STUN为大多数NAT的遍历提供了一个有用的工具，但因地址/端口相关NAT而失败。转弯扩展[RFC5766]解决了这种情况。TURN扩展了STUN，允许客户端在TURN服务器上请求中继地址，而不是自反表示。然后在NAT穿越路径中引入媒体中继（如第4.2.3.2节所述）。下面的示例解释了TURN如何解决使用STUN遍历依赖于地址/端口的NAT时出现的先前故障。应该注意的是，TURN与ICE结合使用时效果最好。使用TURN on本身会导致所有媒体通过TURN服务器中继；这是没有效率的。
L Address/Port-Dependent TURN [..]
NAT Server
| | | |
|(1) Alloc Req | | |
|Src=L-PRIV-1 | | |
|Dest=STUN-PUB-1 | | |
|----------------->| | |
| | | |
| |(2) Alloc Req | |
| |Src=NAT-PUB-1 | |
| |Dest=STUN-PUB-1 | |
| |----------------->| |
| | | |
| |(3) Alloc Resp | |
| |<-----------------| |
| |Src=STUN-PUB-1 | |
| |Dest=NAT-PUB-1 | |
| |Map=NAT-PUB-1 | |
| |Rel=STUN-PUB-2 | |
| | | |
|(4) Alloc Resp | | |
|<-----------------| | |
|Src=STUN-PUB-1 | | |
|Dest=L-PRIV-1 | | |
|Map=NAT-PUB-1 | | |
|Rel=STUN-PUB-2 | | |
| | | |
|(5) Alloc Req | | |
|Src=L-PRIV-2 | | |
|Dest=STUN-PUB-1 | | |
|----------------->| | |
| | | |
| |(6) Alloc Req | |
| |Src=NAT-PUB-2 | |
| |Dest=STUN-PUB-1 | |
| |----------------->| |
| | | |
| |(7) Alloc Resp | |
| |<-----------------| |
| |Src=STUN-PUB-1 | |
| |Dest=NAT-PUB-2 | |
| |Map=NAT-PUB-2 | |
| |Rel=STUN-PUB-3 | |
| | | |
|(8) Alloc Resp | | |
|<-----------------| | |
|Src=STUN-PUB-1 | | |
|Dest=L-PRIV-2 | | |
L Address/Port-Dependent TURN [..]
NAT Server
| | | |
|(1) Alloc Req | | |
|Src=L-PRIV-1 | | |
|Dest=STUN-PUB-1 | | |
|----------------->| | |
| | | |
| |(2) Alloc Req | |
| |Src=NAT-PUB-1 | |
| |Dest=STUN-PUB-1 | |
| |----------------->| |
| | | |
| |(3) Alloc Resp | |
| |<-----------------| |
| |Src=STUN-PUB-1 | |
| |Dest=NAT-PUB-1 | |
| |Map=NAT-PUB-1 | |
| |Rel=STUN-PUB-2 | |
| | | |
|(4) Alloc Resp | | |
|<-----------------| | |
|Src=STUN-PUB-1 | | |
|Dest=L-PRIV-1 | | |
|Map=NAT-PUB-1 | | |
|Rel=STUN-PUB-2 | | |
| | | |
|(5) Alloc Req | | |
|Src=L-PRIV-2 | | |
|Dest=STUN-PUB-1 | | |
|----------------->| | |
| | | |
| |(6) Alloc Req | |
| |Src=NAT-PUB-2 | |
| |Dest=STUN-PUB-1 | |
| |----------------->| |
| | | |
| |(7) Alloc Resp | |
| |<-----------------| |
| |Src=STUN-PUB-1 | |
| |Dest=NAT-PUB-2 | |
| |Map=NAT-PUB-2 | |
| |Rel=STUN-PUB-3 | |
| | | |
|(8) Alloc Resp | | |
|<-----------------| | |
|Src=STUN-PUB-1 | | |
|Dest=L-PRIV-2 | | |
|Map=NAT-PUB-2 | | |
|Rel=STUN-PUB-3 | | |
| | | |
|(9)SIP INVITE | | |
|----------------->| | |
| | | |
| |(10)SIP INVITE | |
| |------------------------------------>|
| | | |
| | |(11)SIP 200 OK |
| |<------------------------------------|
| | | |
|(12)SIP 200 OK | | |
|<-----------------| | |
| | | |
|========================================================|
|>>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>|
|========================================================|
| | | |
| | |==================|
| | |<<<Media Sent to<<|
| | |<<<<STUN-PUB-2<<<<|
| | |==================|
| | | |
|=====================================| |
|<Incoming Media Relayed to L-PRIV-1<<| |
|=====================================| |
| | | |
| | |==================|
| | |<<<RTCP Sent to<<>|
| | |<<<<STUN-PUB-3<<<<|
| | |==================|
| | | |
|=====================================| |
|<<Incoming RTCP Relayed to L-PRIV-2<<| |
|=====================================| |
| | | |
|(13)SIP ACK | | |
|----------------->| | |
| | | |
| |(14) SIP ACK | |
| |------------------------------------>|
| | | |
|Map=NAT-PUB-2 | | |
|Rel=STUN-PUB-3 | | |
| | | |
|(9)SIP INVITE | | |
|----------------->| | |
| | | |
| |(10)SIP INVITE | |
| |------------------------------------>|
| | | |
| | |(11)SIP 200 OK |
| |<------------------------------------|
| | | |
|(12)SIP 200 OK | | |
|<-----------------| | |
| | | |
|========================================================|
|>>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>|
|========================================================|
| | | |
| | |==================|
| | |<<<Media Sent to<<|
| | |<<<<STUN-PUB-2<<<<|
| | |==================|
| | | |
|=====================================| |
|<Incoming Media Relayed to L-PRIV-1<<| |
|=====================================| |
| | | |
| | |==================|
| | |<<<RTCP Sent to<<>|
| | |<<<<STUN-PUB-3<<<<|
| | |==================|
| | | |
|=====================================| |
|<<Incoming RTCP Relayed to L-PRIV-2<<| |
|=====================================| |
| | | |
|(13)SIP ACK | | |
|----------------->| | |
| | | |
| |(14) SIP ACK | |
| |------------------------------------>|
| | | |
Figure 19: Address/Port-Dependent NAT with TURN - Success
Figure 19: Address/Port-Dependent NAT with TURN - Success
o In this example, client L issues a TURN allocate request (1) to obtained a relay address at the STUN server. The request traverses through the Address/Port-Dependent NAT and reaches the STUN server (2). The STUN server generates an Allocate response (3) that contains both a server reflexive address (Map=NAT-PUB-1) of the client and also a relayed address (Rel=STUN-PUB-2). The relayed address maps to an address mapping on the STUN server that is bound to the public pinhole that has been opened on the NAT by the Allocate request. This results in any traffic sent to the TURN server relayed address (Rel=STUN-PUB-2) being forwarded to the external representation of the pinhole created by the Allocate request (NAT-PUB-1).
o 在本例中，客户机L发出TURN allocate请求（1）以获得STUN服务器上的中继地址。请求通过地址/端口相关NAT并到达STUN服务器（2）。STUN服务器生成一个分配响应（3），该响应包含客户端的服务器自反地址（Map=NAT-PUB-1）和中继地址（Rel=STUN-PUB-2）。中继地址映射到STUN服务器上的地址映射，该地址映射绑定到NAT上通过分配请求打开的公共针孔。这导致发送到TURN服务器中继地址（Rel=STUN-PUB-2）的任何通信量被转发到分配请求（NAT-PUB-1）创建的针孔的外部表示。
o The TURN derived address (STUN-PUB-2) arrives back at the originating client (4) in an Allocate response. This address can then be used in the SDP for the outgoing SIP INVITE request as shown in the following example (note that the example also includes client L obtaining a second relay address for use in the RTCP attribute (5-8)):
o 回合派生地址（STUN-PUB-2）在分配响应中返回到发起客户端（4）。然后，该地址可在SDP中用于传出SIP INVITE请求，如以下示例所示（注意，该示例还包括客户端L获取第二个中继地址以用于RTCP属性（5-8））：
v=0
o=test 2890844342 2890842164 IN IP4 $L-PRIV-1
c=IN IP4 $STUN-PUB-2.address
t=0 0
m=audio $STUN-PUB-2.port RTP/AVP 0
a=rtcp:$STUN-PUB-3.port
v=0
o=test 2890844342 2890842164 IN IP4 $L-PRIV-1
c=IN IP4 $STUN-PUB-2.address
t=0 0
m=audio $STUN-PUB-2.port RTP/AVP 0
a=rtcp:$STUN-PUB-3.port
o On receiving the INVITE request, the User Agent Server (UAS) is able to stream media and RTCP to the relay address (STUN-PUB-2 and STUN-PUB-3) at the STUN server. As shown in Figure 19 (between messages (12) and (13), the media from the UAS is directed to the relayed address at the STUN server. The STUN server then forwards the traffic to the open pinholes in the Address/Port-Dependent NAT (NAT-PUB-1 and NAT-PUB-2). The media traffic is then able to traverse the Address/Port-Dependent NAT and arrives back at client L.
o 在接收到INVITE请求时，用户代理服务器（UAS）能够将媒体和RTCP流式传输到STUN服务器上的中继地址（STUN-PUB-2和STUN-PUB-3）。如图19所示（在消息（12）和（13）之间），来自UAS的媒体被定向到STUN服务器上的中继地址。然后，STUN服务器将流量转发到地址/端口相关NAT（NAT-PUB-1和NAT-PUB-2）中的开放针孔。然后，媒体流量能够遍历依赖于地址/端口的NAT，并返回到客户端L。
o TURN on its own will work for Address/Port-Dependent and other types of NAT mentioned in this specification but should only be used as a last resort. The relaying of media through an external entity is not an efficient mechanism for NAT traversal and comes at a high processing cost.
o 打开它自己将适用于本规范中提到的地址/端口相关和其他类型的NAT，但只能作为最后手段使用。通过外部实体中继媒体不是NAT遍历的有效机制，并且处理成本很高。
The previous two examples have highlighted the problem with using core STUN for all forms of NAT traversal and a solution using TURN for the Address/Port-Dependent NAT case. The RECOMMENDED mechanism
前面的两个示例强调了在所有形式的NAT遍历中使用core STUN的问题，以及在依赖于地址/端口的NAT情况下使用TURN的解决方案。建议的机制
for traversing all varieties of NAT is using ICE, as detailed in Section 4.2.3.3. ICE makes use of core STUN, TURN and any other mechanism (e.g., NAT-PMP[NAT-PMP], UPnP IGD[UPnP-IGD]) to provide a list of prioritized addresses that can be used for media traffic. Detailed examples of ICE can be found in Section 5.2.1.2.1. These examples are associated with an Endpoint-Independent type NAT but can be applied to any NAT type variation, including Address/ Port-Dependent type NAT. The ICE procedures carried out are the same. For a list of candidate addresses, a client will choose where to send media dependent on the results of the STUN connectivity checks and associated priority (highest priority wins). It should be noted that the inclusion of a NAT displaying Address/Port-Dependent properties does not automatically result in relayed media. In fact, ICE processing will avoid use of media relay with the exception of two clients that both happen to be behind a NAT using Address/ Port-Dependent characteristics. The connectivity checks and associated selection algorithm enable traversal in this case. Figure 20 and the following description provide a guide as to how this is achieved using the ICE connectivity checks. This is an abbreviated example that assumes successful SIP offer/answer exchange and illustrates the connectivity check flow.
如第4.2.3.3节所述，为了穿越所有NAT，使用ICE。ICE利用core Stunk、TURN和任何其他机制（例如NAT-PMP[NAT-PMP]、UPnP IGD[UPnP IGD]）提供可用于媒体流量的优先地址列表。冰的详细示例见第5.2.1.2.1节。这些示例与端点无关的NAT类型相关联，但可以应用于任何NAT类型变体，包括地址/端口相关的NAT类型。执行的ICE程序相同。对于候选地址列表，客户端将根据STUN连接检查结果和相关优先级（最高优先级wins）选择将媒体发送到何处。应注意，包含显示地址/端口相关属性的NAT不会自动产生中继媒体。事实上，ICE处理将避免使用媒体中继，只有两个客户端例外，这两个客户端都恰好位于使用地址/端口相关特性的NAT后面。在这种情况下，连接性检查和关联的选择算法支持遍历。图20和以下描述提供了如何使用ICE连接检查实现这一点的指南。这是一个简短的示例，假设SIP提供/应答交换成功，并说明了连接检查流程。
L Address/Port-Dependent Endpoint-Independent R
L-NAT R-NAT
|========================================================|
| SIP OFFER/ANSWER EXCHANGE |
|========================================================|
| | | |
| | |(1)Bind Req |
| | |<-----------------|
| | |Src=R=PRIV-1 |
| | |Dest=L-NAT-PUB-1 |
| | | |
| |(2)Bind Req | |
| x<-----------------| |
| |Src=R-NAT-PUB-1 | |
| |Dest=L-NAT-PUB-1 | |
| | | |
|(3)Bind Req | | |
|----------------->| | |
|Src=L-PRIV-1 | | |
|Dest=R-NAT-PUB-1 | | |
| | | |
| |(4)Bind Req | |
| |----------------->| |
| |Src=L-NAT-PUB-1 | |
| |Dest=R-NAT-PUB-1 | |
| | | |
| | |(5)Bind Req |
| | |----------------->|
| | |Src=L-NAT-PUB-1 |
| | |Dest=R-PRIV-1 |
| | | |
| | |(6)Bind Resp |
| | |<-----------------|
| | |Src=R-PRIV-1 |
| | |Dest=L-NAT-PUB-1 |
| | | |
| |(7)Bind Resp | |
| |<-----------------| |
| |Src=R-NAT-PUB-1 | |
| |Dest=L-NAT-PUB-1 | |
| | | |
|(8)Bind Resp | | |
|<-----------------| | |
|Src=R-NAT-PUB-1 | | |
|Dest=L-PRIV-1 | | |
| | | |
L Address/Port-Dependent Endpoint-Independent R
L-NAT R-NAT
|========================================================|
| SIP OFFER/ANSWER EXCHANGE |
|========================================================|
| | | |
| | |(1)Bind Req |
| | |<-----------------|
| | |Src=R=PRIV-1 |
| | |Dest=L-NAT-PUB-1 |
| | | |
| |(2)Bind Req | |
| x<-----------------| |
| |Src=R-NAT-PUB-1 | |
| |Dest=L-NAT-PUB-1 | |
| | | |
|(3)Bind Req | | |
|----------------->| | |
|Src=L-PRIV-1 | | |
|Dest=R-NAT-PUB-1 | | |
| | | |
| |(4)Bind Req | |
| |----------------->| |
| |Src=L-NAT-PUB-1 | |
| |Dest=R-NAT-PUB-1 | |
| | | |
| | |(5)Bind Req |
| | |----------------->|
| | |Src=L-NAT-PUB-1 |
| | |Dest=R-PRIV-1 |
| | | |
| | |(6)Bind Resp |
| | |<-----------------|
| | |Src=R-PRIV-1 |
| | |Dest=L-NAT-PUB-1 |
| | | |
| |(7)Bind Resp | |
| |<-----------------| |
| |Src=R-NAT-PUB-1 | |
| |Dest=L-NAT-PUB-1 | |
| | | |
|(8)Bind Resp | | |
|<-----------------| | |
|Src=R-NAT-PUB-1 | | |
|Dest=L-PRIV-1 | | |
| | | |
| | |(9)Bind Req |
| | |<-----------------|
| | |Src=R-Priv-1 |
| | |Dest=L-NAT-PUB-1 |
| |(10)Bind Req | |
| |<-----------------| |
| |Src=R-NAT-PUB-1 | |
| |Dest=L-NAT-PUB-1 | |
| | | |
|(11)Bind Req | | |
|<-----------------| | |
|Src=R-NAT-PUB-1 | | |
|Dest=L-PRIV-1 | | |
| | | |
|(12)Bind Resp | | |
|----------------->| | |
|Src=L-PRIV-1 | | |
|Dest=L-NAT-PUB-1 | | |
| | | |
| |(13)Bind Resp | |
| |----------------->| |
| |Src=L-NAT-PUB-1 | |
| |Dest=R-NAT-PUB-1 | |
| | | |
| | |(14)Bind Resp |
| | |----------------->|
| | |Src=L-NAT-PUB-1 |
| | |Dest=R-PRIV-1 |
| | | |
| | |(9)Bind Req |
| | |<-----------------|
| | |Src=R-Priv-1 |
| | |Dest=L-NAT-PUB-1 |
| |(10)Bind Req | |
| |<-----------------| |
| |Src=R-NAT-PUB-1 | |
| |Dest=L-NAT-PUB-1 | |
| | | |
|(11)Bind Req | | |
|<-----------------| | |
|Src=R-NAT-PUB-1 | | |
|Dest=L-PRIV-1 | | |
| | | |
|(12)Bind Resp | | |
|----------------->| | |
|Src=L-PRIV-1 | | |
|Dest=L-NAT-PUB-1 | | |
| | | |
| |(13)Bind Resp | |
| |----------------->| |
| |Src=L-NAT-PUB-1 | |
| |Dest=R-NAT-PUB-1 | |
| | | |
| | |(14)Bind Resp |
| | |----------------->|
| | |Src=L-NAT-PUB-1 |
| | |Dest=R-PRIV-1 |
| | | |
Figure 20: Single Address/Port-Dependent NAT - Success
Figure 20: Single Address/Port-Dependent NAT - Success
In this abbreviated example, client R has already received a SIP INVITE request and is starting its connectivity checks with client L. Client R generates a connectivity check (1) and sends to client L's information as presented in the SDP offer. The request arrives at client L's Address/Port-Dependent NAT and fails to traverse as there is no NAT binding. This would then move the connectivity check to a failed state. In the meantime, client L has received the SDP answer in the SIP request and will also commence connectivity checks. A check is dispatched (3) to client R. The check is able to traverse the NAT due to the association set up in the previously failed check (1). The full Bind request/response is shown in steps (3)-(8). As part of a candidate pair, client R will now successfully be able to complete the checks, as illustrated in steps (9)-(14). The result is a successful pair of candidates that can be used without the need to relay any media.
在这个简短的示例中，客户端R已经收到SIP INVITE请求，并且正在启动与客户端L的连接检查。客户端R生成连接检查（1），并向客户端L发送SDP报价中显示的信息。请求到达客户端L的地址/端口相关NAT，由于没有NAT绑定，因此无法遍历。这将使连接检查进入失败状态。同时，客户端L已在SIP请求中接收到SDP应答，并将开始连接检查。向客户端R发送一个检查（3）。由于在先前失败的检查（1）中建立的关联，该检查能够遍历NAT。完整绑定请求/响应如步骤（3）-（8）所示。作为候选对的一部分，客户端R现在将能够成功地完成检查，如步骤（9）-（14）所示。结果是一对成功的候选者，无需转载任何媒体即可使用。
In conclusion, the only time media needs to be relayed is a result of clients both behind Address/Port-Dependent NATs. As you can see from the example in this section, neither side would be able to complete connectivity checks with the exception of the Relayed candidates.
总之，需要中继媒体的唯一时间是地址/端口相关NAT后面的客户端的结果。正如您从本节中的示例中所看到的，除了中继候选者之外，任何一方都无法完成连接检查。
This section describes how IPv6-only SIP User Agents can communicate with IPv4-only SIP User Agents. While the techniques discussed in this document primarily contain examples of traversing NATs to allow communications between hosts in private and public networks, they are by no means limited to such scenarios. The same NAT traversal techniques can also be used to establish communication in a heterogeneous network environment -- e.g., communication between an IPv4 host and an IPv6 host.
本节介绍仅限IPv6的SIP用户代理如何与仅限IPv4的SIP用户代理通信。虽然本文档中讨论的技术主要包含穿越NAT以允许私有和公共网络中的主机之间通信的示例，但它们绝不限于此类场景。同样的NAT穿越技术也可用于在异构网络环境中建立通信——例如，IPv4主机和IPv6主机之间的通信。
IPv4-IPv6 translations at the SIP level usually take place at dual-stack proxies that have both IPv4 and IPv6 DNS entries. Since these translations do not involve NATs that are placed in the middle of two SIP entities, they fall outside the scope of this document. A detailed description of this type of translation can be found in [RFC6157].
SIP级别的IPv4-IPv6转换通常在同时具有IPv4和IPv6 DNS条目的双堆栈代理上进行。由于这些翻译不涉及放置在两个SIP实体中间的NAT，它们不属于本文档的范围。此类翻译的详细说明见[RFC6157]。
There are no security considerations beyond the ones inherited by reference.
除了通过引用继承的安全注意事项外，没有其他安全注意事项。
The authors would like to thank the members of the IETF SIPPING WG for their comments and suggestions. Expert review and detailed contribution including text was provided by Dan Wing, who was supportive throughout.
作者要感谢IETF啜饮工作组成员的评论和建议。Dan Wing提供了专家评审和包括文本在内的详细贡献，他始终给予支持。
Detailed comments were provided by Vijay Gurbani, Kaiduan Xie, Remi Denis-Courmont, Hadriel Kaplan, Phillip Matthews, Spencer Dawkins, and Hans Persson.
维杰伊·古巴尼、谢开段、雷米·丹尼斯·库尔蒙、哈德里尔·卡普兰、菲利普·马修斯、斯宾塞·道金斯和汉斯·佩尔森提供了详细的评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[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月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，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月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[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月。
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.
[RFC3605]Huitema，C.，“会话描述协议（SDP）中的实时控制协议（RTCP）属性”，RFC3605，2003年10月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]Audet，F.和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, July 2007.
[RFC4961]Wing，D，“对称RTP/RTP控制协议（RTCP）”，BCP 131，RFC 49612007年7月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT的会话遍历实用程序（STUN）”，RFC 5389，2008年10月。
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626]Jennings，C.，Mahy，R.，和F.Audet，“在会话启动协议（SIP）中管理客户端启动的连接”，RFC 5626，2009年10月。
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5761]Perkins，C.和M.Westerlund，“在单个端口上多路传输RTP数据和控制数据包”，RFC 5761，2010年4月。
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC5766]Mahy，R.，Matthews，P.，和J.Rosenberg，“使用NAT周围的中继进行遍历（TURN）：NAT（STUN）会话遍历实用程序的中继扩展”，RFC 5766，2010年4月。
[RFC5923] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in the Session Initiation Protocol (SIP)", RFC 5923, June 2010.
[RFC5923]Gurbani，V.，Mahy，R.，和B.Tate，“会话启动协议（SIP）中的连接重用”，RFC 59232010年6月。
[MIDDLEBOXES] Stucker, B. and H. Tschofenig, "Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path", Work in Progress, July 2010.
[Middlebox]Stucker，B.和H.Tschofenig，“媒体路径上信令协议通信的中间盒交互分析”，正在进行的工作，2010年7月。
[NAT-PMP] Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", Work in Progress, April 2008.
[NAT-PMP]柴郡，S.，“NAT端口映射协议（NAT-PMP）”，正在进行的工作，2008年4月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC3424]Daigle，L.和IAB，“网络地址转换中单边自地址固定（UNSAF）的IAB考虑”，RFC 34242002年11月。
[RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)", RFC 5780, May 2010.
[RFC5780]MacDonald，D.和B.Lowekamp，“使用NAT会话遍历实用程序进行NAT行为发现（STUN）”，RFC 57802010年5月。
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, April 2010.
[RFC5853]Hautakorpi，J.，Camarillo，G.，Penfield，R.，Hawrylyshen，A.，和M.Bhatia，“会话启动协议（SIP）会话边界控制（SBC）部署的要求”，RFC 58532010年4月。
[RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 Transition in the Session Initiation Protocol (SIP)", RFC 6157, April 2011.
[RFC6157]Camarillo，G.，El Malki，K.，和V.Gurbani，“会话启动协议（SIP）中的IPv6转换”，RFC 6157，2011年4月。
[UPnP-IGD] UPnP Forum, "Universal Plug and Play Internet Gateway Device v1.0", 2000, <http://www.upnp.org/specs/gw/igd1/>.
[UPnP IGD]UPnP论坛，“通用即插即用互联网网关设备v1.0”，2000年<http://www.upnp.org/specs/gw/igd1/>.
Authors' Addresses
作者地址
Chris Boulton NS-Technologies
克里斯·博尔顿技术公司
EMail: chris@ns-technologies.com
EMail: chris@ns-technologies.com
Jonathan Rosenberg Skype
乔纳森·罗森伯格Skype
EMail: jdrosen@jdrosen.net
EMail: jdrosen@jdrosen.net
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Francois Audet Skype
弗朗索瓦·奥德特Skype
EMail: francois.audet@skype.net
EMail: francois.audet@skype.net