Internet Engineering Task Force (IETF) P. Martinsen
Request for Comments: 7982 T. Reddy
Category: Standards Track Cisco
ISSN: 2070-1721 D. Wing
Internet Engineering Task Force (IETF) P. Martinsen
Request for Comments: 7982 T. Reddy
Category: Standards Track Cisco
ISSN: 2070-1721 D. Wing
V. Singh callstats.io September 2016
V.Singh callstats.io 2016年9月
Measurement of Round-Trip Time and Fractional Loss Using Session Traversal Utilities for NAT (STUN)
使用NAT（STUN）会话遍历实用程序测量往返时间和部分损失
Abstract
摘要
A host with multiple interfaces needs to choose the best interface for communication. Oftentimes, this decision is based on a static configuration and does not consider the path characteristics, which may affect the user experience.
具有多个接口的主机需要选择最佳的通信接口。通常，该决策基于静态配置，并且不考虑可能影响用户体验的路径特征。
This document describes a mechanism for an endpoint to measure the path characteristics fractional loss and RTT using Session Traversal Utilities for NAT (STUN) messages.
本文档描述了端点使用NAT（STUN）消息的会话遍历实用程序来测量路径特征分数丢失和RTT的机制。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc7982.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7982.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4
3. Measuring RTT and Fractional Loss . . . . . . . . . . . . . . 4
3.1. TRANSACTION_TRANSMIT_COUNTER Attribute . . . . . . . . . 4
3.2. Usage in Requests . . . . . . . . . . . . . . . . . . . . 5
3.3. Usage in Responses . . . . . . . . . . . . . . . . . . . 5
3.4. Example Operation . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4
3. Measuring RTT and Fractional Loss . . . . . . . . . . . . . . 4
3.1. TRANSACTION_TRANSMIT_COUNTER Attribute . . . . . . . . . 4
3.2. Usage in Requests . . . . . . . . . . . . . . . . . . . . 5
3.3. Usage in Responses . . . . . . . . . . . . . . . . . . . 5
3.4. Example Operation . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
This document extends STUN [RFC5389] to make it possible to correlate STUN responses to specific requests when retransmits occur. This assists the client in determining path characteristics like round-trip time (RTT) and fractional packet loss.
本文档对STUN[RFC5389]进行了扩展，以便在发生重传时将STUN响应与特定请求关联起来。这有助于客户机确定路径特征，如往返时间（RTT）和部分数据包丢失。
The TRANSACTION_TRANSMIT_COUNTER attribute introduced in Section 3.1 can be used in Interactive Connectivity Establishment (ICE) [RFC5245] connectivity checks (STUN Binding request and response). It can also be used with Traversal Using Relays around NAT (TURN) [RFC5766] by adding this attribute to Allocate requests and responses to measure loss and RTT between the client and the respective TURN server.
第3.1节中介绍的事务传输计数器属性可用于交互式连接建立（ICE）[RFC5245]连接检查（STUN绑定请求和响应）。通过添加此属性来分配请求和响应，以测量客户端和相应TURN服务器之间的损耗和RTT，它还可以与使用NAT（TURN）[RFC5766]周围中继的遍历一起使用。
ICE is a mechanism commonly used in Voice over IP (VoIP) applications to traverse NATs, and it uses a static prioritization formula to order the candidate pairs and perform connectivity checks, in which the most preferred address pairs are tested first, and when a sufficiently good pair is discovered, that pair is used for communications and then further connectivity tests are stopped.
ICE是IP语音（VoIP）应用程序中常用的穿越NAT的机制，它使用静态优先级公式对候选对排序并执行连接检查，其中首先测试最首选的地址对，当发现足够好的地址对时，该对用于通信，然后停止进一步的连接测试。
When multiple paths are available for communication, the endpoint sends ICE connectivity checks across each path (candidate pair). Choosing the path with the lowest round-trip time is a reasonable approach, but retransmits can cause an otherwise good path to appear flawed. However, STUN's retransmission algorithm [RFC5389] cannot determine the round-trip time (RTT) if a STUN request packet is retransmitted because each request and retransmission packet is identical. Further, several STUN requests may be sent before the connectivity between candidate pairs are ascertained (see Section 16 of [RFC5245]). To resolve the issue of identical request and response packets in a STUN transaction, this document changes the retransmission behavior for idempotent packets. Using the mechanism described herein, a client can determine RTT as well as get a hint regarding which path direction caused packet loss. This is achieved by defining a new STUN attribute and requires compliant STUN (TURN and ICE) endpoints to count request packets.
当多条路径可用于通信时，端点跨每条路径（候选对）发送ICE连接检查。选择往返时间最少的路径是一种合理的方法，但重新传输可能会导致其他良好路径出现缺陷。然而，如果STUN请求数据包被重新传输，则STUN的重传算法[RFC5389]无法确定往返时间（RTT），因为每个请求和重传数据包是相同的。此外，在确定候选对之间的连通性之前，可以发送多个STUN请求（参见[RFC5245]第16节）。为了解决STUN事务中相同请求和响应数据包的问题，本文档更改了幂等数据包的重传行为。使用本文描述的机制，客户机可以确定RTT，并获得关于哪个路径方向导致分组丢失的提示。这是通过定义一个新的STUN属性来实现的，并且需要兼容的STUN（TURN和ICE）端点来计算请求数据包。
The mechanisms described in this document can be used by the controlling agent to influence the ICE candidate pair selection. How ICE will actually use this information to improve the active candidate pair selection is outside the scope of this document.
控制代理可以使用本文中描述的机制来影响ICE候选对的选择。ICE如何实际使用此信息来改进活动候选对选择超出了本文档的范围。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This specification uses terminology defined in ICE [RFC5245] and STUN [RFC5389].
本规范使用ICE[RFC5245]和STUN[RFC5389]中定义的术语。
This document defines a new comprehension-optional STUN attribute TRANSACTION_TRANSMIT_COUNTER with a STUN Type 0x8025. This type is in the comprehension-optional range, which means that STUN agents can safely ignore the attribute. If ICE is in use, it will fall back to normal procedures.
本文档使用STUN类型0x8025定义了一个新的可选STUN属性事务传输计数器。此类型在“理解”可选范围内，这意味着眩晕代理可以安全地忽略该属性。如果使用冰，它将回到正常程序。
If a client wishes to measure RTT, it inserts the TRANSACTION_TRANSMIT_COUNTER attribute in a STUN request. In this attribute, the client sends the number of times the STUN request is transmitted with the same transaction ID. The server would echo back the transmission count in the response so that the client can distinguish between STUN responses coming from retransmitted requests. Hence, the endpoint can use the STUN requests and responses to determine the round-trip time (RTT). The server may also convey the number of responses it has sent for the STUN request to the client. Further, this information enables the client to get a hint regarding in which direction the packet loss occurred. In some cases, it is impossible to distinguish between packet reordering and packet loss. However, if this information is collected as network metrics from several clients over a longer time period, it will be easier to detect a pattern that can provide useful information.
如果客户机希望测量RTT，它会在STUN请求中插入事务\u传输\u计数器属性。在此属性中，客户端发送STUN请求的次数是使用相同的事务ID发送的。服务器将在响应中回显传输计数，以便客户端能够区分来自重新传输的请求的STUN响应。因此，端点可以使用STUN请求和响应来确定往返时间（RTT）。服务器还可以将其针对STUN请求发送的响应数传递给客户端。此外，该信息使客户机能够获得关于发生分组丢失的方向的提示。在某些情况下，无法区分数据包重新排序和数据包丢失。但是，如果在较长的时间段内将这些信息作为网络度量从多个客户端收集，则更容易检测出能够提供有用信息的模式。
The TRANSACTION_TRANSMIT_COUNTER attribute in a STUN request takes a 32-bit value. This document updates one of the STUN message structuring rules explained in Section 6 of [RFC5389] wherein retransmission of the same request reuses the same transaction ID and is bit-wise identical to the previous request. For idempotent packets, the Req and Resp fields in the TRANSACTION_TRANSMIT_COUNTER attribute will be incremented by 1 by the client or server for every transmission with the same transaction ID. Any retransmitted STUN request MUST be bit-wise identical to the previous request except for the values in the TRANSACTION_TRANSMIT_COUNTER attribute.
STUN请求中的事务\u传输\u计数器属性采用32位值。本文档更新了[RFC5389]第6节中解释的STUN消息结构规则之一，其中相同请求的重新传输重用相同的事务ID，并且在位上与先前的请求相同。对于幂等数据包，对于具有相同事务ID的每次传输，客户端或服务器会将事务传输计数器属性中的Req和Resp字段增加1。除事务传输计数器属性中的值外，任何重新传输的STUN请求必须在位上与前一个请求相同。
The IANA-assigned STUN type for the new attribute is 0x8025.
IANA为新属性指定的STUN类型为0x8025。
The format of the value in the TRANSACTION_TRANSMIT_COUNTER attribute in the request is:
请求中事务\传输\计数器属性中的值格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (Padding) | Req | Resp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (Padding) | Req | Resp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: TRANSACTION_TRANSMIT_COUNTER Attribute in Request
图1：请求中的事务\传输\计数器属性
The fields are described below:
这些字段描述如下：
Req: Number of times the request is transmitted with the same transaction ID to the server.
Req：使用相同事务ID将请求传输到服务器的次数。
Resp: Number of times a response with the same transaction ID is sent from the server. MUST be set to zero in requests and ignored by the receiver.
Resp：从服务器发送具有相同事务ID的响应的次数。在请求中必须设置为零，并被接收方忽略。
The padding is necessary to hit the 32-bit boundary needed for STUN attributes. The padding bits are ignored, but to allow for future reuse of these bits, they MUST be set to zero.
填充是达到晕眩属性所需的32位边界所必需的。将忽略填充位，但为了将来重用这些位，必须将它们设置为零。
When sending a STUN request, the TRANSACTION_TRANSMIT_COUNTER Attribute allows a client to indicate to the server that it wants to measure RTT and get a hint about the direction of any packet loss.
发送STUN请求时，TRANSACTION_TRANSMIT_COUNTER属性允许客户机向服务器指示它要测量RTT，并获取有关任何数据包丢失方向的提示。
The client MUST populate the Req value in the TRANSACTION_TRANSMIT_COUNTER. This value MUST reflect the number of requests that have been transmitted to the server. Therefore, the initial value for the first request sent is 1. The first retransmit will set the value to 2 and so on.
客户机必须在事务传输计数器中填充Req值。此值必须反映已传输到服务器的请求数。因此，发送的第一个请求的初始值为1。第一次重新传输将把值设置为2，依此类推。
The Resp field in the attribute MUST be set to zero in the request.
在请求中，属性中的Resp字段必须设置为零。
When a server receives a STUN request that includes a TRANSACTION_TRANSMIT_COUNTER attribute, it processes the request as per the STUN protocol [RFC5389] plus the specific rules mentioned here. The server checks the following:
当服务器接收到包含事务传输计数器属性的STUN请求时，它将根据STUN协议[RFC5389]和此处提到的特定规则处理该请求。服务器将检查以下各项：
o If the TRANSACTION_TRANSMIT_COUNTER attribute is not recognized, ignore the attribute because its type indicates that it is comprehension-optional. This should be the existing behavior as explained in Section 7.3 of [RFC5389].
o 如果事务\传输\计数器属性无法识别，请忽略该属性，因为其类型指示该属性是可选的。这应该是[RFC5389]第7.3节中解释的现有行为。
o The server that supports the TRANSACTION_TRANSMIT_COUNTER attribute MUST echo back the Req field in the response using a TRANSACTION_TRANSMIT_COUNTER attribute.
o 支持事务传输计数器属性的服务器必须使用事务传输计数器属性回显响应中的Req字段。
o If the server is stateless or does not want to remember the transaction ID, then it populates value 0 for the Resp field in the TRANSACTION_TRANSMIT_COUNTER attribute sent in the response. If the server is stateful, then it populates the Resp field with the number of responses it has sent for the STUN request.
o 如果服务器无状态或不想记住事务ID，则会在响应中发送的事务\传输\计数器属性中为Resp字段填充值0。如果服务器是有状态的，那么它将用它为STUN请求发送的响应数填充Resp字段。
A client that receives a STUN response with a TRANSACTION_TRANSMIT_COUNTER can check the values in the Req field to accurately calculate the RTT if retransmits are occurring.
使用事务传输计数器接收STUN响应的客户端可以检查Req字段中的值，以便在发生重新传输时准确计算RTT。
If the server sending the STUN response is stateless, the value of the Resp field will always be 0. If the server keeps state of the numbers of STUN requests with that same transaction ID, the value will reflect how many packets the server has seen and responded to. This gives the client a hint about in which direction loss occurred. See Section 3.4 for more details.
如果发送STUN响应的服务器是无状态的，Resp字段的值将始终为0。如果服务器保持具有相同事务ID的STUN请求数的状态，则该值将反映服务器已看到并响应的数据包数。这会向客户机提示丢失发生的方向。详见第3.4节。
An example operation, when a server is stateful, is described in Figure 2. In the first case, all the requests and responses are received correctly.
图2中描述了服务器有状态时的示例操作。在第一种情况下，所有请求和响应都被正确接收。
In the case of upstream loss, the first request is lost, but the second one is received correctly. The client, upon receiving the response, notes that while two requests were sent, only one was received by the server. The server also realizes that the value in the Req field does not match the number of received requests, therefore one request was lost. This may also occur at startup in the presence of firewalls or NATs that block unsolicited incoming traffic.
在上游丢失的情况下，第一个请求丢失，但第二个请求正确接收。客户端在收到响应时注意到，虽然发送了两个请求，但服务器只接收到一个请求。服务器还意识到Req字段中的值与接收到的请求数不匹配，因此丢失了一个请求。在防火墙或NAT阻止未经请求的传入流量的情况下，这也可能发生在启动时。
In the case of downstream loss, the responses get lost, the client expecting multiple responses notes that, while the server responded to three requests, only one response was received.
在下游丢失的情况下，响应会丢失，客户机希望得到多个响应。客户机注意到，当服务器响应三个请求时，只收到一个响应。
In the case of loss in both directions, requests and responses get lost in tandem, the server notes that one request packet was not received, while the client expecting three responses received only one, and then it notes that one request and response packet were lost.
在双向丢失的情况下，请求和响应同时丢失，服务器注意到没有收到一个请求数据包，而期望收到三个响应的客户端只收到一个，然后它注意到一个请求和响应数据包丢失。
| Normal | Upstream loss | Downstream loss | Both upstream &|
| | | | downstream loss|
| Client Server | Client Server | Client Server | Client Server |
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
| 1 1,1 | 1 x | 1 1,1 | 1 x |
| 1,1 | | x | |
| | 2 2,1 | 2 2,2 | 2 2,1 |
| | 2,1 | x | x |
| | | 3 3,3 | 3 3,2 |
| | | 3,3 | 3,2 |
| Normal | Upstream loss | Downstream loss | Both upstream &|
| | | | downstream loss|
| Client Server | Client Server | Client Server | Client Server |
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
| 1 1,1 | 1 x | 1 1,1 | 1 x |
| 1,1 | | x | |
| | 2 2,1 | 2 2,2 | 2 2,1 |
| | 2,1 | x | x |
| | | 3 3,3 | 3 3,2 |
| | | 3,3 | 3,2 |
Figure 2: Retransmit Operation between Client and Server
图2：客户端和服务器之间的重新传输操作
Another example is when the client sends two requests but the second request arrives at the server before the first request because of out-of-order delivery. In this case, the stateful server populates value 1 for the Resp field in the TRANSACTION_TRANSMIT_COUNTER attribute sent in response to the second request and value 2 for the Resp field in the TRANSACTION_TRANSMIT_COUNTER attribute sent in response to the first request.
另一个例子是，客户端发送两个请求，但由于无序交付，第二个请求在第一个请求之前到达服务器。在这种情况下，有状态服务器为响应第二个请求而发送的事务传输计数器属性中的Resp字段填充值1，为响应第一个请求而发送的事务传输计数器属性中的Resp字段填充值2。
The intention with this mechanism is not to carry out comprehensive and accurate measurements regarding in what direction loss is occurring. In some cases, it might not be able to distinguish the difference between downstream loss and packet reordering.
该机制的目的不是对损失发生的方向进行全面和准确的测量。在某些情况下，它可能无法区分下游丢失和数据包重新排序之间的区别。
This document defines the TRANSACTION_TRANSMIT_COUNTER STUN attribute, described in Section 3. IANA has allocated the comprehension-optional codepoint 0x8025 for this attribute.
本文档定义了第3节中描述的事务传输计数器STUN属性。IANA已为此属性分配了可选代码点0x8025。
Security considerations discussed in [RFC5389] are to be taken into account. STUN requires that the 96-bit transaction ID be uniformly and randomly chosen from the interval 0 .. 2**96-1, and be cryptographically strong. This is good enough security against an off-path attacker. An on-path attacker can either inject a fake response or modify the values in the TRANSACTION_TRANSMIT_COUNTER attribute to mislead the client and server. This attack can be mitigated using STUN authentication. As the
应考虑[RFC5389]中讨论的安全注意事项。STUN要求从间隔0中统一随机地选择96位事务ID。。2**96-1，且加密能力强。这对于非路径攻击者来说已经足够安全了。路径上的攻击者可以注入虚假响应或修改事务\u传输\u计数器属性中的值，以误导客户端和服务器。使用STUN身份验证可以减轻此攻击。作为
TRANSACTION_TRANSMIT_COUNTER is expected to be used between peers using ICE, and ICE uses a STUN short-term credential mechanism, the risk of an on-path attack influencing the messages is minimal. If the TRANSACTION_TRANSMIT_COUNTER is used with an Allocate request, one of the following mechanisms can be used to prevent attackers from trying to impersonate a TURN server and sending a bogus TRANSACTION_TRANSMIT_COUNTER attribute in the Allocate response: 1) the STUN long-term credential mechanism, 2) the STUN Extension for Third-Party Authorization [RFC7635], or 3) a TLS or DTLS connection between the TURN client and the TURN server. However, an attacker could corrupt, remove, or delay an ICE request or response, in order to discourage that path from being used.
事务_传输_计数器预计将在使用ICE的对等方之间使用，并且ICE使用STUN短期凭证机制，影响消息的路径攻击风险最小。如果事务\u传输\u计数器与分配请求一起使用，则可以使用以下机制之一防止攻击者试图模拟TURN服务器并在分配响应中发送虚假事务\u传输\u计数器属性：1）STUN长期凭证机制，2）第三方授权的STUN扩展[RFC7635]，或3）TURN客户端和TURN服务器之间的TLS或DTLS连接。但是，攻击者可以破坏、删除或延迟ICE请求或响应，以阻止该路径被使用。
If not encrypted, the information sent in any STUN packet can potentially be observed passively and used for reconnaissance and later attacks.
如果未加密，任何STEN数据包中发送的信息都可能被被动观察，并用于侦察和后续攻击。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, <http://www.rfc-editor.org/info/rfc5245>.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 5245，DOI 10.17487/RFC5245，2010年4月<http://www.rfc-editor.org/info/rfc5245>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <http://www.rfc-editor.org/info/rfc5389>.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT（STUN）的会话遍历实用程序”，RFC 5389，DOI 10.17487/RFC5389，2008年10月<http://www.rfc-editor.org/info/rfc5389>.
[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, DOI 10.17487/RFC5766, April 2010, <http://www.rfc-editor.org/info/rfc5766>.
[RFC5766]Mahy，R.，Matthews，P.，和J.Rosenberg，“使用NAT周围的中继进行遍历（TURN）：NAT（STUN）会话遍历实用程序的中继扩展”，RFC 5766，DOI 10.17487/RFC5766，2010年4月<http://www.rfc-editor.org/info/rfc5766>.
[RFC7635] Reddy, T., Patil, P., Ravindranath, R., and J. Uberti, "Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization", RFC 7635, DOI 10.17487/RFC7635, August 2015, <http://www.rfc-editor.org/info/rfc7635>.
[RFC7635]Reddy，T.，Patil，P.，Ravindranath，R.，和J.Uberti，“第三方授权NAT（STUN）扩展的会话遍历实用程序”，RFC 7635，DOI 10.17487/RFC7635，2015年8月<http://www.rfc-editor.org/info/rfc7635>.
Acknowledgements
致谢
Thanks to Brandon Williams, Simon Perreault, Aijun Wang, Martin Thomson, Oleg Moskalenko, Ram Mohan Ravindranath, Spencer Dawkins, Suresh Krishnan, Ben Campbell, Mirja Kuehlewind, Lionel Morand, Kathleen Moriarty, and Alissa Cooper for their valuable input and comments.
感谢Brandon Williams、Simon Perreault、Aijun Wang、Martin Thomson、Oleg Moskalenko、Ram Mohan Ravindranath、Spencer Dawkins、Suresh Krishnan、Ben Campbell、Mirja Kuehlewind、Lionel Morand、Kathleen Moriarty和Alissa Cooper的宝贵意见。
Authors' Addresses
作者地址
Paal-Erik Martinsen Cisco Systems, Inc. Philip Pedersens vei 22 Lysaker, Akershus 1325 Norway
Paal Erik Martinsen思科系统有限公司Philip Pedersens vei 22 Lysaker，挪威阿克苏
Email: palmarti@cisco.com
Email: palmarti@cisco.com
Tirumaleswar Reddy Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India
Tirumaleswar Reddy Cisco Systems，Inc.印度卡纳塔克邦班加罗尔外环路瓦图尔霍布里萨贾普尔马拉塔利塞斯纳商业园560103
Email: tireddy@cisco.com
Email: tireddy@cisco.com
Dan Wing
丹荣
Email: dwing-ietf@fuggles.com
Email: dwing-ietf@fuggles.com
Varun Singh CALLSTATS I/O Oy Runeberginkatu 4c A 4 Helsinki 00100 Finland
Varun Singh CALLSTATS I/O Oy Runeberginkatu 4c A 4赫尔辛基00100芬兰
Email: varun@callstats.io
URI: https://www.callstats.io/about
Email: varun@callstats.io
URI: https://www.callstats.io/about