Internet Engineering Task Force (IETF) R. Mahy
Request for Comments: 5766 Unaffiliated
Category: Standards Track P. Matthews
ISSN: 2070-1721 Alcatel-Lucent
J. Rosenberg
jdrosen.net
April 2010
Internet Engineering Task Force (IETF) R. Mahy
Request for Comments: 5766 Unaffiliated
Category: Standards Track P. Matthews
ISSN: 2070-1721 Alcatel-Lucent
J. Rosenberg
jdrosen.net
April 2010
Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)
使用NAT周围的中继进行遍历（TURN）：NAT会话遍历实用程序的中继扩展（STUN）
Abstract
摘要
If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address.
如果主机位于NAT后面，则在某些情况下，该主机可能无法直接与其他主机（对等机）通信。在这些情况下，主机必须使用充当通信中继的中间节点的服务。该规范定义了一个称为TURN（使用NAT周围的中继进行遍历）的协议，该协议允许主机控制中继的操作，并使用中继与对等方交换数据包。TURN与其他一些中继控制协议的不同之处在于，它允许客户端使用单个中继地址与多个对等方通信。
The TURN protocol was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it also can be used without ICE.
TURN协议被设计为用于NAT穿越的ICE（交互式连接建立）方法的一部分，尽管它也可以在没有ICE的情况下使用。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5766.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5766.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
2.1. Transports . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Allocations . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Permissions . . . . . . . . . . . . . . . . . . . . . . . 11
2.4. Send Mechanism . . . . . . . . . . . . . . . . . . . . . . 12
2.5. Channels . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6. Unprivileged TURN Servers . . . . . . . . . . . . . . . . 15
2.7. Avoiding IP Fragmentation . . . . . . . . . . . . . . . . 16
2.8. RTP Support . . . . . . . . . . . . . . . . . . . . . . . 17
2.9. Anycast Discovery of Servers . . . . . . . . . . . . . . . 17
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 18
4. General Behavior . . . . . . . . . . . . . . . . . . . . . . . 19
5. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. Creating an Allocation . . . . . . . . . . . . . . . . . . . . 23
6.1. Sending an Allocate Request . . . . . . . . . . . . . . . 23
6.2. Receiving an Allocate Request . . . . . . . . . . . . . . 24
6.3. Receiving an Allocate Success Response . . . . . . . . . . 28
6.4. Receiving an Allocate Error Response . . . . . . . . . . . 29
7. Refreshing an Allocation . . . . . . . . . . . . . . . . . . . 31
7.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 31
7.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 31
7.3. Receiving a Refresh Response . . . . . . . . . . . . . . . 32
8. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 32
9. CreatePermission . . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Forming a CreatePermission Request . . . . . . . . . . . . 34
9.2. Receiving a CreatePermission Request . . . . . . . . . . . 34
9.3. Receiving a CreatePermission Response . . . . . . . . . . 35
10. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 35
10.1. Forming a Send Indication . . . . . . . . . . . . . . . . 35
10.2. Receiving a Send Indication . . . . . . . . . . . . . . . 35
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
2.1. Transports . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Allocations . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Permissions . . . . . . . . . . . . . . . . . . . . . . . 11
2.4. Send Mechanism . . . . . . . . . . . . . . . . . . . . . . 12
2.5. Channels . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6. Unprivileged TURN Servers . . . . . . . . . . . . . . . . 15
2.7. Avoiding IP Fragmentation . . . . . . . . . . . . . . . . 16
2.8. RTP Support . . . . . . . . . . . . . . . . . . . . . . . 17
2.9. Anycast Discovery of Servers . . . . . . . . . . . . . . . 17
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 18
4. General Behavior . . . . . . . . . . . . . . . . . . . . . . . 19
5. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. Creating an Allocation . . . . . . . . . . . . . . . . . . . . 23
6.1. Sending an Allocate Request . . . . . . . . . . . . . . . 23
6.2. Receiving an Allocate Request . . . . . . . . . . . . . . 24
6.3. Receiving an Allocate Success Response . . . . . . . . . . 28
6.4. Receiving an Allocate Error Response . . . . . . . . . . . 29
7. Refreshing an Allocation . . . . . . . . . . . . . . . . . . . 31
7.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 31
7.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 31
7.3. Receiving a Refresh Response . . . . . . . . . . . . . . . 32
8. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 32
9. CreatePermission . . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Forming a CreatePermission Request . . . . . . . . . . . . 34
9.2. Receiving a CreatePermission Request . . . . . . . . . . . 34
9.3. Receiving a CreatePermission Response . . . . . . . . . . 35
10. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 35
10.1. Forming a Send Indication . . . . . . . . . . . . . . . . 35
10.2. Receiving a Send Indication . . . . . . . . . . . . . . . 35
10.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . . 36
10.4. Receiving a Data Indication . . . . . . . . . . . . . . . 37
11. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
11.1. Sending a ChannelBind Request . . . . . . . . . . . . . . 39
11.2. Receiving a ChannelBind Request . . . . . . . . . . . . . 39
11.3. Receiving a ChannelBind Response . . . . . . . . . . . . . 40
11.4. The ChannelData Message . . . . . . . . . . . . . . . . . 41
11.5. Sending a ChannelData Message . . . . . . . . . . . . . . 41
11.6. Receiving a ChannelData Message . . . . . . . . . . . . . 42
11.7. Relaying Data from the Peer . . . . . . . . . . . . . . . 43
12. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . . 43
13. New STUN Methods . . . . . . . . . . . . . . . . . . . . . . . 45
14. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . 45
14.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . . 45
14.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . . 46
14.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . . 46
14.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
14.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . . 46
14.6. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . . 46
14.7. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . . 47
14.8. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . . 47
14.9. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . . 48
15. New STUN Error Response Codes . . . . . . . . . . . . . . . . 48
16. Detailed Example . . . . . . . . . . . . . . . . . . . . . . . 48
17. Security Considerations . . . . . . . . . . . . . . . . . . . 55
17.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . . 55
17.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 55
17.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 56
17.1.3. Faked Refreshes and Permissions . . . . . . . . . . . 56
17.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . . 56
17.1.5. Impersonating a Server . . . . . . . . . . . . . . . 57
17.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . . 58
17.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 58
17.2. Firewall Considerations . . . . . . . . . . . . . . . . . 59
17.2.1. Faked Permissions . . . . . . . . . . . . . . . . . . 59
17.2.2. Blacklisted IP Addresses . . . . . . . . . . . . . . 60
17.2.3. Running Servers on Well-Known Ports . . . . . . . . . 60
17.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 60
17.3.1. DoS against TURN Server . . . . . . . . . . . . . . . 60
17.3.2. Anonymous Relaying of Malicious Traffic . . . . . . . 61
17.3.3. Manipulating Other Allocations . . . . . . . . . . . 61
17.4. Other Considerations . . . . . . . . . . . . . . . . . . . 61
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
19. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 62
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63
21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64
21.1. Normative References . . . . . . . . . . . . . . . . . . . 64
21.2. Informative References . . . . . . . . . . . . . . . . . . 64
10.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . . 36
10.4. Receiving a Data Indication . . . . . . . . . . . . . . . 37
11. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
11.1. Sending a ChannelBind Request . . . . . . . . . . . . . . 39
11.2. Receiving a ChannelBind Request . . . . . . . . . . . . . 39
11.3. Receiving a ChannelBind Response . . . . . . . . . . . . . 40
11.4. The ChannelData Message . . . . . . . . . . . . . . . . . 41
11.5. Sending a ChannelData Message . . . . . . . . . . . . . . 41
11.6. Receiving a ChannelData Message . . . . . . . . . . . . . 42
11.7. Relaying Data from the Peer . . . . . . . . . . . . . . . 43
12. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . . 43
13. New STUN Methods . . . . . . . . . . . . . . . . . . . . . . . 45
14. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . 45
14.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . . 45
14.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . . 46
14.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . . 46
14.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
14.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . . 46
14.6. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . . 46
14.7. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . . 47
14.8. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . . 47
14.9. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . . 48
15. New STUN Error Response Codes . . . . . . . . . . . . . . . . 48
16. Detailed Example . . . . . . . . . . . . . . . . . . . . . . . 48
17. Security Considerations . . . . . . . . . . . . . . . . . . . 55
17.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . . 55
17.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 55
17.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 56
17.1.3. Faked Refreshes and Permissions . . . . . . . . . . . 56
17.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . . 56
17.1.5. Impersonating a Server . . . . . . . . . . . . . . . 57
17.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . . 58
17.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 58
17.2. Firewall Considerations . . . . . . . . . . . . . . . . . 59
17.2.1. Faked Permissions . . . . . . . . . . . . . . . . . . 59
17.2.2. Blacklisted IP Addresses . . . . . . . . . . . . . . 60
17.2.3. Running Servers on Well-Known Ports . . . . . . . . . 60
17.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 60
17.3.1. DoS against TURN Server . . . . . . . . . . . . . . . 60
17.3.2. Anonymous Relaying of Malicious Traffic . . . . . . . 61
17.3.3. Manipulating Other Allocations . . . . . . . . . . . 61
17.4. Other Considerations . . . . . . . . . . . . . . . . . . . 61
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
19. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 62
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63
21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64
21.1. Normative References . . . . . . . . . . . . . . . . . . . 64
21.2. Informative References . . . . . . . . . . . . . . . . . . 64
A host behind a NAT may wish to exchange packets with other hosts, some of which may also be behind NATs. To do this, the hosts involved can use "hole punching" techniques (see [RFC5128]) in an attempt discover a direct communication path; that is, a communication path that goes from one host to another through intervening NATs and routers, but does not traverse any relays.
NAT后面的主机可能希望与其他主机交换数据包，其中一些主机也可能在NAT后面。为此，相关主机可以使用“打孔”技术（参见[RFC5128]）尝试发现直接通信路径；也就是说，通过中间的NAT和路由器从一台主机到另一台主机的通信路径，但不穿过任何中继。
As described in [RFC5128] and [RFC4787], hole punching techniques will fail if both hosts are behind NATs that are not well behaved. For example, if both hosts are behind NATs that have a mapping behavior of "address-dependent mapping" or "address- and port-dependent mapping", then hole punching techniques generally fail.
如[RFC5128]和[RFC4787]中所述，如果两台主机都位于性能不好的NAT后面，则穿孔技术将失败。例如，如果两台主机都位于具有“地址相关映射”或“地址和端口相关映射”映射行为的NAT之后，则穿孔技术通常会失败。
When a direct communication path cannot be found, it is necessary to use the services of an intermediate host that acts as a relay for the packets. This relay typically sits in the public Internet and relays packets between two hosts that both sit behind NATs.
当无法找到直接通信路径时，有必要使用充当数据包中继的中间主机的服务。该中继通常位于公共互联网中，并在两台主机之间中继数据包，这两台主机都位于NAT后面。
This specification defines a protocol, called TURN, that allows a host behind a NAT (called the TURN client) to request that another host (called the TURN server) act as a relay. The client can arrange for the server to relay packets to and from certain other hosts (called peers) and can control aspects of how the relaying is done. The client does this by obtaining an IP address and port on the server, called the relayed transport address. When a peer sends a packet to the relayed transport address, the server relays the packet to the client. When the client sends a data packet to the server, the server relays it to the appropriate peer using the relayed transport address as the source.
该规范定义了一个称为TURN的协议，该协议允许NAT后面的主机（称为TURN客户端）请求另一台主机（称为TURN服务器）充当中继。客户机可以安排服务器向某些其他主机（称为对等机）中继数据包，也可以控制中继的方式。客户端通过获取服务器上的IP地址和端口（称为中继传输地址）来实现这一点。当对等方向中继传输地址发送数据包时，服务器将数据包中继到客户端。当客户机向服务器发送数据包时，服务器使用中继传输地址作为源将其中继到适当的对等方。
A client using TURN must have some way to communicate the relayed transport address to its peers, and to learn each peer's IP address and port (more precisely, each peer's server-reflexive transport address, see Section 2). How this is done is out of the scope of the TURN protocol. One way this might be done is for the client and peers to exchange email messages. Another way is for the client and its peers to use a special-purpose "introduction" or "rendezvous" protocol (see [RFC5128] for more details).
使用TURN的客户端必须有某种方式将中继传输地址传送给其对等方，并了解每个对等方的IP地址和端口（更准确地说，每个对等方的服务器自反传输地址，请参见第2节）。如何做到这一点超出了TURN协议的范围。一种可能的方法是让客户端和对等方交换电子邮件消息。另一种方法是客户端及其对等方使用专用的“介绍”或“会合”协议（有关更多详细信息，请参阅[RFC5128]）。
If TURN is used with ICE [RFC5245], then the relayed transport address and the IP addresses and ports of the peers are included in the ICE candidate information that the rendezvous protocol must carry. For example, if TURN and ICE are used as part of a multimedia solution using SIP [RFC3261], then SIP serves the role of the rendezvous protocol, carrying the ICE candidate information inside the body of SIP messages. If TURN and ICE are used with some other
如果TURN与ICE[RFC5245]一起使用，则中继传输地址以及对等方的IP地址和端口包括在会合协议必须携带的ICE候选信息中。例如，如果TURN和ICE用作使用SIP[RFC3261]的多媒体解决方案的一部分，则SIP充当集合协议的角色，在SIP消息体中携带ICE候选信息。如果转弯和冰与其他车辆一起使用
rendezvous protocol, then [MMUSIC-ICE-NONSIP] provides guidance on the services the rendezvous protocol must perform.
会合协议，则[MMUSIC-ICE-NONSIP]提供会合协议必须执行的服务指南。
Though the use of a TURN server to enable communication between two hosts behind NATs is very likely to work, it comes at a high cost to the provider of the TURN server, since the server typically needs a high-bandwidth connection to the Internet. As a consequence, it is best to use a TURN server only when a direct communication path cannot be found. When the client and a peer use ICE to determine the communication path, ICE will use hole punching techniques to search for a direct path first and only use a TURN server when a direct path cannot be found.
尽管使用TURN服务器来实现NAT后面的两台主机之间的通信很有可能奏效，但TURN服务器提供商的成本很高，因为服务器通常需要与Internet的高带宽连接。因此，最好仅在找不到直接通信路径时使用TURN服务器。当客户端和对等方使用ICE确定通信路径时，ICE将首先使用打孔技术搜索直接路径，并且仅在找不到直接路径时使用TURN服务器。
TURN was originally invented to support multimedia sessions signaled using SIP. Since SIP supports forking, TURN supports multiple peers per relayed transport address; a feature not supported by other approaches (e.g., SOCKS [RFC1928]). However, care has been taken to make sure that TURN is suitable for other types of applications.
TURN最初是为了支持使用SIP发送信号的多媒体会话而发明的。由于SIP支持分叉，TURN支持每个中继传输地址的多个对等点；其他方法（例如SOCKS[RFC1928]）不支持的功能。但是，已注意确保TURN适用于其他类型的应用。
TURN was designed as one piece in the larger ICE approach to NAT traversal. Implementors of TURN are urged to investigate ICE and seriously consider using it for their application. However, it is possible to use TURN without ICE.
TURN被设计成NAT穿越的更大的ICE方法中的一部分。督促的实施者被敦促调查冰，并认真考虑使用它的应用。但是，可以在不加冰的情况下使用转弯。
TURN is an extension to the STUN (Session Traversal Utilities for NAT) protocol [RFC5389]. Most, though not all, TURN messages are STUN-formatted messages. A reader of this document should be familiar with STUN.
TURN是STUN（NAT会话遍历实用程序）协议[RFC5389]的扩展。大多数（尽管不是全部）TURN消息都是晕眩格式的消息。本文档的读者应该熟悉STUN。
This section gives an overview of the operation of TURN. It is non-normative.
本节概述TURN的操作。这是不规范的。
In a typical configuration, a TURN client is connected to a private network [RFC1918] and through one or more NATs to the public Internet. On the public Internet is a TURN server. Elsewhere in the Internet are one or more peers with which the TURN client wishes to communicate. These peers may or may not be behind one or more NATs. The client uses the server as a relay to send packets to these peers and to receive packets from these peers.
在典型配置中，TURN客户端连接到专用网络[RFC1918]，并通过一个或多个NAT连接到公共互联网。在公共互联网上有一个TURN服务器。互联网上的其他地方是TURN客户端希望与之通信的一个或多个对等方。这些对等方可能支持也可能不支持一个或多个NAT。客户端使用服务器作为中继，向这些对等方发送数据包，并从这些对等方接收数据包。
Peer A
Server-Reflexive +---------+
Transport Address | |
192.0.2.150:32102 | |
| /| |
TURN | / ^| Peer A |
Client's Server | / || |
Host Transport Transport | // || |
Address Address | // |+---------+
10.1.1.2:49721 192.0.2.15:3478 |+-+ // Peer A
| | ||N| / Host Transport
| +-+ | ||A|/ Address
| | | | v|T| 192.168.100.2:49582
| | | | /+-+
+---------+| | | |+---------+ / +---------+
| || |N| || | // | |
| TURN |v | | v| TURN |/ | |
| Client |----|A|----------| Server |------------------| Peer B |
| | | |^ | |^ ^| |
| | |T|| | || || |
+---------+ | || +---------+| |+---------+
| || | |
| || | |
+-+| | |
| | |
| | |
Client's | Peer B
Server-Reflexive Relayed Transport
Transport Address Transport Address Address
192.0.2.1:7000 192.0.2.15:50000 192.0.2.210:49191
Peer A
Server-Reflexive +---------+
Transport Address | |
192.0.2.150:32102 | |
| /| |
TURN | / ^| Peer A |
Client's Server | / || |
Host Transport Transport | // || |
Address Address | // |+---------+
10.1.1.2:49721 192.0.2.15:3478 |+-+ // Peer A
| | ||N| / Host Transport
| +-+ | ||A|/ Address
| | | | v|T| 192.168.100.2:49582
| | | | /+-+
+---------+| | | |+---------+ / +---------+
| || |N| || | // | |
| TURN |v | | v| TURN |/ | |
| Client |----|A|----------| Server |------------------| Peer B |
| | | |^ | |^ ^| |
| | |T|| | || || |
+---------+ | || +---------+| |+---------+
| || | |
| || | |
+-+| | |
| | |
| | |
Client's | Peer B
Server-Reflexive Relayed Transport
Transport Address Transport Address Address
192.0.2.1:7000 192.0.2.15:50000 192.0.2.210:49191
Figure 1
图1
Figure 1 shows a typical deployment. In this figure, the TURN client and the TURN server are separated by a NAT, with the client on the private side and the server on the public side of the NAT. This NAT is assumed to be a "bad" NAT; for example, it might have a mapping property of "address-and-port-dependent mapping" (see [RFC4787]).
图1显示了一个典型的部署。在此图中，TURN客户端和TURN服务器由NAT分隔，客户端位于NAT的私有端，服务器位于NAT的公共端。该NAT被假定为“坏”NAT；例如，它可能具有“地址和端口相关映射”的映射属性（请参见[RFC4787]）。
The client talks to the server from a (IP address, port) combination called the client's HOST TRANSPORT ADDRESS. (The combination of an IP address and port is called a TRANSPORT ADDRESS.)
客户端通过称为客户端主机传输地址的（IP地址、端口）组合与服务器通信。（IP地址和端口的组合称为传输地址。）
The client sends TURN messages from its host transport address to a transport address on the TURN server that is known as the TURN SERVER TRANSPORT ADDRESS. The client learns the TURN server transport address through some unspecified means (e.g., configuration), and this address is typically used by many clients simultaneously.
客户端将TURN消息从其主机传输地址发送到TURN服务器上的传输地址，该地址称为TURN服务器传输地址。客户端通过一些未指定的方式（例如，配置）学习TURN服务器传输地址，该地址通常由多个客户端同时使用。
Since the client is behind a NAT, the server sees packets from the client as coming from a transport address on the NAT itself. This address is known as the client's SERVER-REFLEXIVE transport address; packets sent by the server to the client's server-reflexive transport address will be forwarded by the NAT to the client's host transport address.
由于客户端位于NAT后面，服务器会将来自客户端的数据包视为来自NAT本身的传输地址。该地址称为客户端的服务器自反传输地址；服务器发送到客户端服务器自反传输地址的数据包将由NAT转发到客户端的主机传输地址。
The client uses TURN commands to create and manipulate an ALLOCATION on the server. An allocation is a data structure on the server. This data structure contains, amongst other things, the RELAYED TRANSPORT ADDRESS for the allocation. The relayed transport address is the transport address on the server that peers can use to have the server relay data to the client. An allocation is uniquely identified by its relayed transport address.
客户端使用TURN命令在服务器上创建和操作分配。分配是服务器上的数据结构。除其他外，该数据结构包含分配的中继传输地址。中继传输地址是服务器上的传输地址，对等方可以使用该地址将服务器数据中继到客户端。分配由其中继传输地址唯一标识。
Once an allocation is created, the client can send application data to the server along with an indication of to which peer the data is to be sent, and the server will relay this data to the appropriate peer. The client sends the application data to the server inside a TURN message; at the server, the data is extracted from the TURN message and sent to the peer in a UDP datagram. In the reverse direction, a peer can send application data in a UDP datagram to the relayed transport address for the allocation; the server will then encapsulate this data inside a TURN message and send it to the client along with an indication of which peer sent the data. Since the TURN message always contains an indication of which peer the client is communicating with, the client can use a single allocation to communicate with multiple peers.
创建分配后，客户机可以向服务器发送应用程序数据，并指示数据将发送到哪个对等方，服务器将把该数据中继到相应的对等方。客户端在TURN消息中向服务器发送应用程序数据；在服务器上，从TURN消息中提取数据，并以UDP数据报的形式发送给对等方。在相反方向上，对等方可以将UDP数据报中的应用程序数据发送到中继传输地址以进行分配；然后，服务器将把这些数据封装在TURN消息中，并将其与发送数据的对等方的指示一起发送给客户端。由于TURN消息始终包含客户端与哪个对等方通信的指示，因此客户端可以使用单个分配与多个对等方通信。
When the peer is behind a NAT, then the client must identify the peer using its server-reflexive transport address rather than its host transport address. For example, to send application data to Peer A in the example above, the client must specify 192.0.2.150:32102 (Peer A's server-reflexive transport address) rather than 192.168.100.2: 49582 (Peer A's host transport address).
当对等方位于NAT之后时，客户端必须使用其服务器自反传输地址而不是主机传输地址来识别对等方。例如，在上面的示例中，要将应用程序数据发送给对等方A，客户端必须指定192.0.2.150:32102（对等方A的服务器自反传输地址），而不是192.168.100.2:49582（对等方A的主机传输地址）。
Each allocation on the server belongs to a single client and has exactly one relayed transport address that is used only by that allocation. Thus, when a packet arrives at a relayed transport address on the server, the server knows for which client the data is intended.
服务器上的每个分配都属于单个客户端，并且只有一个中继传输地址仅由该分配使用。因此，当数据包到达服务器上的中继传输地址时，服务器知道数据将用于哪个客户端。
The client may have multiple allocations on a server at the same time.
客户端可能同时在服务器上有多个分配。
TURN, as defined in this specification, always uses UDP between the server and the peer. However, this specification allows the use of any one of UDP, TCP, or Transport Layer Security (TLS) over TCP to carry the TURN messages between the client and the server.
按照本规范中的定义，TURN始终在服务器和对等方之间使用UDP。但是，此规范允许通过TCP使用UDP、TCP或传输层安全性（TLS）中的任何一种在客户端和服务器之间传输TURN消息。
+----------------------------+---------------------+
| TURN client to TURN server | TURN server to peer |
+----------------------------+---------------------+
| UDP | UDP |
| TCP | UDP |
| TLS over TCP | UDP |
+----------------------------+---------------------+
+----------------------------+---------------------+
| TURN client to TURN server | TURN server to peer |
+----------------------------+---------------------+
| UDP | UDP |
| TCP | UDP |
| TLS over TCP | UDP |
+----------------------------+---------------------+
If TCP or TLS-over-TCP is used between the client and the server, then the server will convert between these transports and UDP transport when relaying data to/from the peer.
如果在客户机和服务器之间使用TCP或TCP上的TLS，则服务器在向对等机中继数据或从对等机中继数据时，将在这些传输和UDP传输之间进行转换。
Since this version of TURN only supports UDP between the server and the peer, it is expected that most clients will prefer to use UDP between the client and the server as well. That being the case, some readers may wonder: Why also support TCP and TLS-over-TCP?
由于此版本的TURN仅支持服务器和对等方之间的UDP，因此大多数客户端也希望在客户端和服务器之间使用UDP。在这种情况下，一些读者可能会想：为什么还要通过TCP支持TCP和TLS？
TURN supports TCP transport between the client and the server because some firewalls are configured to block UDP entirely. These firewalls block UDP but not TCP, in part because TCP has properties that make the intention of the nodes being protected by the firewall more obvious to the firewall. For example, TCP has a three-way handshake that makes in clearer that the protected node really wishes to have that particular connection established, while for UDP the best the firewall can do is guess which flows are desired by using filtering rules. Also, TCP has explicit connection teardown; while for UDP, the firewall has to use timers to guess when the flow is finished.
TURN支持客户端和服务器之间的TCP传输，因为某些防火墙配置为完全阻止UDP。这些防火墙阻止UDP而不是TCP，部分原因是TCP的属性使受防火墙保护的节点的意图对防火墙更加明显。例如，TCP有一个三方握手，它可以更清楚地表明受保护的节点确实希望建立特定的连接，而对于UDP，防火墙所能做的最好的事情就是使用过滤规则猜测需要哪些流。此外，TCP具有显式连接断开；而对于UDP，防火墙必须使用计时器来猜测流何时完成。
TURN supports TLS-over-TCP transport between the client and the server because TLS provides additional security properties not provided by TURN's default digest authentication; properties that some clients may wish to take advantage of. In particular, TLS provides a way for the client to ascertain that it is talking to the correct server, and provides for confidentiality of TURN control messages. TURN does not require TLS because the overhead of using TLS is higher than that of digest authentication; for example, using TLS likely means that most application data will be doubly encrypted (once by TLS and once to ensure it is still encrypted in the UDP datagram).
TURN支持客户端和服务器之间的TLS over TCP传输，因为TLS提供TURN默认摘要身份验证未提供的其他安全属性；某些客户可能希望利用的属性。特别是，TLS为客户机提供了一种确定它正在与正确的服务器通信的方法，并为转弯控制消息提供了保密性。TURN不需要TLS，因为使用TLS的开销高于摘要身份验证的开销；例如，使用TLS可能意味着大多数应用程序数据将被双重加密（一次由TLS加密，一次确保它仍然在UDP数据报中加密）。
There is a planned extension to TURN to add support for TCP between the server and the peers [TURN-TCP]. For this reason, allocations that use UDP between the server and the peers are known as UDP allocations, while allocations that use TCP between the server and the peers are known as TCP allocations. This specification describes only UDP allocations.
计划中的扩展将转向在服务器和对等方之间添加对TCP的支持[TURN-TCP]。因此，在服务器和对等方之间使用UDP的分配称为UDP分配，而在服务器和对等方之间使用TCP的分配称为TCP分配。本规范仅描述UDP分配。
TURN, as defined in this specification, only supports IPv4. All IP addresses in this specification must be IPv4 addresses. There is a planned extension to TURN to add support for IPv6 and for relaying between IPv4 and IPv6 [TURN-IPv6].
如本规范中所定义，TURN仅支持IPv4。本规范中的所有IP地址都必须是IPv4地址。计划中的扩展将转向添加对IPv6以及IPv4和IPv6之间中继的支持[TURN-IPv6]。
In some applications for TURN, the client may send and receive packets other than TURN packets on the host transport address it uses to communicate with the server. This can happen, for example, when using TURN with ICE. In these cases, the client can distinguish TURN packets from other packets by examining the source address of the arriving packet: those arriving from the TURN server will be TURN packets.
在某些TURN应用程序中，客户机可以在其用于与服务器通信的主机传输地址上发送和接收除TURN数据包以外的数据包。例如，在冰上使用转弯时，可能会发生这种情况。在这些情况下，客户端可以通过检查到达数据包的源地址来区分TURN数据包和其他数据包：从TURN服务器到达的数据包将是TURN数据包。
To create an allocation on the server, the client uses an Allocate transaction. The client sends an Allocate request to the server, and the server replies with an Allocate success response containing the allocated relayed transport address. The client can include attributes in the Allocate request that describe the type of allocation it desires (e.g., the lifetime of the allocation). Since relaying data has security implications, the server requires that the client authenticate itself, typically using STUN's long-term credential mechanism, to show that it is authorized to use the server.
要在服务器上创建分配，客户端使用分配事务。客户端向服务器发送分配请求，服务器用包含分配的中继传输地址的分配成功响应进行响应。客户机可以在分配请求中包含描述其期望的分配类型（例如，分配的生存期）的属性。由于中继数据具有安全含义，服务器要求客户端进行自身身份验证，通常使用STUN的长期凭证机制，以表明其有权使用服务器。
Once a relayed transport address is allocated, a client must keep the allocation alive. To do this, the client periodically sends a Refresh request to the server. TURN deliberately uses a different method (Refresh rather than Allocate) for refreshes to ensure that the client is informed if the allocation vanishes for some reason.
一旦分配了中继传输地址，客户端必须保持分配活动。为此，客户端定期向服务器发送刷新请求。TURN故意使用不同的方法（刷新而不是分配）进行刷新，以确保在分配因某种原因消失时通知客户端。
The frequency of the Refresh transaction is determined by the lifetime of the allocation. The default lifetime of an allocation is 10 minutes -- this value was chosen to be long enough so that refreshing is not typically a burden on the client, while expiring allocations where the client has unexpectedly quit in a timely manner. However, the client can request a longer lifetime in the Allocate request and may modify its request in a Refresh request, and the server always indicates the actual lifetime in the response. The client must issue a new Refresh transaction within "lifetime" seconds
刷新事务的频率由分配的生存期决定。分配的默认生存期为10分钟——选择此值的时间足够长，因此刷新通常不会对客户端造成负担，而在客户端意外及时退出的情况下使分配过期。但是，客户端可以在分配请求中请求更长的生存期，也可以在刷新请求中修改其请求，并且服务器始终在响应中指示实际的生存期。客户端必须在“生存期”秒内发出新的刷新事务
of the previous Allocate or Refresh transaction. Once a client no longer wishes to use an allocation, it should delete the allocation using a Refresh request with a requested lifetime of 0.
上一个分配或刷新事务的。一旦客户端不再希望使用分配，它应该使用请求生存期为0的刷新请求删除分配。
Both the server and client keep track of a value known as the 5-TUPLE. At the client, the 5-tuple consists of the client's host transport address, the server transport address, and the transport protocol used by the client to communicate with the server. At the server, the 5-tuple value is the same except that the client's host transport address is replaced by the client's server-reflexive address, since that is the client's address as seen by the server.
服务器和客户端都跟踪一个称为5元组的值。在客户端，5元组由客户端的主机传输地址、服务器传输地址以及客户端用于与服务器通信的传输协议组成。在服务器上，5元组值相同，只是客户端的主机传输地址被客户端的服务器自反地址替换，因为这是服务器看到的客户端地址。
Both the client and the server remember the 5-tuple used in the Allocate request. Subsequent messages between the client and the server use the same 5-tuple. In this way, the client and server know which allocation is being referred to. If the client wishes to allocate a second relayed transport address, it must create a second allocation using a different 5-tuple (e.g., by using a different client host address or port).
客户机和服务器都记住分配请求中使用的5元组。客户端和服务器之间的后续消息使用相同的5元组。这样，客户机和服务器就知道引用了哪个分配。如果客户端希望分配第二个中继传输地址，则必须使用不同的5元组（例如，通过使用不同的客户端主机地址或端口）创建第二个分配。
NOTE: While the terminology used in this document refers to 5-tuples, the TURN server can store whatever identifier it likes that yields identical results. Specifically, an implementation may use a file-descriptor in place of a 5-tuple to represent a TCP connection.
注意：虽然本文档中使用的术语指的是5元组，但TURN服务器可以存储任何它喜欢的标识符，以产生相同的结果。具体而言，实现可以使用文件描述符代替5元组来表示TCP连接。
TURN TURN Peer Peer
client server A B
|-- Allocate request --------------->| | |
| | | |
|<--------------- Allocate failure --| | |
| (401 Unauthorized) | | |
| | | |
|-- Allocate request --------------->| | |
| | | |
|<---------- Allocate success resp --| | |
| (192.0.2.15:50000) | | |
// // // //
| | | |
|-- Refresh request ---------------->| | |
| | | |
|<----------- Refresh success resp --| | |
| | | |
TURN TURN Peer Peer
client server A B
|-- Allocate request --------------->| | |
| | | |
|<--------------- Allocate failure --| | |
| (401 Unauthorized) | | |
| | | |
|-- Allocate request --------------->| | |
| | | |
|<---------- Allocate success resp --| | |
| (192.0.2.15:50000) | | |
// // // //
| | | |
|-- Refresh request ---------------->| | |
| | | |
|<----------- Refresh success resp --| | |
| | | |
Figure 2
图2
In Figure 2, the client sends an Allocate request to the server without credentials. Since the server requires that all requests be authenticated using STUN's long-term credential mechanism, the server rejects the request with a 401 (Unauthorized) error code. The client then tries again, this time including credentials (not shown). This time, the server accepts the Allocate request and returns an Allocate success response containing (amongst other things) the relayed transport address assigned to the allocation. Sometime later, the client decides to refresh the allocation and thus sends a Refresh request to the server. The refresh is accepted and the server replies with a Refresh success response.
在图2中，客户端向服务器发送一个不带凭据的分配请求。由于服务器要求使用STUN的长期凭证机制对所有请求进行身份验证，因此服务器会以401（未经授权）错误代码拒绝请求。客户端然后重试，这次包括凭据（未显示）。这一次，服务器接受分配请求并返回一个分配成功响应，其中包含分配给分配的中继传输地址。稍后，客户机决定刷新分配，并因此向服务器发送刷新请求。刷新被接受，服务器将以刷新成功响应进行响应。
To ease concerns amongst enterprise IT administrators that TURN could be used to bypass corporate firewall security, TURN includes the notion of permissions. TURN permissions mimic the address-restricted filtering mechanism of NATs that comply with [RFC4787].
为了缓解企业IT管理员对TURN可用于绕过公司防火墙安全性的担忧，TURN包含了权限的概念。TURN权限模拟符合[RFC4787]的NAT的地址限制过滤机制。
An allocation can have zero or more permissions. Each permission consists of an IP address and a lifetime. When the server receives a UDP datagram on the allocation's relayed transport address, it first checks the list of permissions. If the source IP address of the datagram matches a permission, the application data is relayed to the client, otherwise the UDP datagram is silently discarded.
分配可以有零个或多个权限。每个权限由一个IP地址和一个生存期组成。当服务器收到分配的中继传输地址上的UDP数据报时，它首先检查权限列表。如果数据报的源IP地址与权限匹配，则应用程序数据将中继到客户端，否则UDP数据报将自动丢弃。
A permission expires after 5 minutes if it is not refreshed, and there is no way to explicitly delete a permission. This behavior was selected to match the behavior of a NAT that complies with [RFC4787].
如果未刷新权限，则权限将在5分钟后过期，并且无法显式删除权限。选择此行为是为了匹配符合[RFC4787]的NAT行为。
The client can install or refresh a permission using either a CreatePermission request or a ChannelBind request. Using the CreatePermission request, multiple permissions can be installed or refreshed with a single request -- this is important for applications that use ICE. For security reasons, permissions can only be installed or refreshed by transactions that can be authenticated; thus, Send indications and ChannelData messages (which are used to send data to peers) do not install or refresh any permissions.
客户端可以使用CreatePermission请求或ChannelBind请求安装或刷新权限。使用CreatePermission请求，可以通过单个请求安装或刷新多个权限——这对于使用ICE的应用程序很重要。出于安全原因，权限只能由可通过身份验证的事务安装或刷新；因此，发送指示和ChannelData消息（用于向对等方发送数据）不会安装或刷新任何权限。
Note that permissions are within the context of an allocation, so adding or expiring a permission in one allocation does not affect other allocations.
请注意，权限在分配的上下文中，因此在一个分配中添加或过期权限不会影响其他分配。
There are two mechanisms for the client and peers to exchange application data using the TURN server. The first mechanism uses the Send and Data methods, the second way uses channels. Common to both ways is the ability of the client to communicate with multiple peers using a single allocated relayed transport address; thus, both ways include a means for the client to indicate to the server which peer should receive the data, and for the server to indicate to the client which peer sent the data.
客户机和对等机使用TURN服务器交换应用程序数据有两种机制。第一种机制使用发送和数据方法，第二种方式使用通道。这两种方法的共同点是客户端能够使用单个分配的中继传输地址与多个对等方通信；因此，这两种方式都包括客户端向服务器指示哪个对等方应接收数据的方法，以及服务器向客户端指示哪个对等方发送了数据的方法。
The Send mechanism uses Send and Data indications. Send indications are used to send application data from the client to the server, while Data indications are used to send application data from the server to the client.
发送机制使用发送和数据指示。发送指示用于将应用程序数据从客户端发送到服务器，而数据指示用于将应用程序数据从服务器发送到客户端。
When using the Send mechanism, the client sends a Send indication to the TURN server containing (a) an XOR-PEER-ADDRESS attribute specifying the (server-reflexive) transport address of the peer and (b) a DATA attribute holding the application data. When the TURN server receives the Send indication, it extracts the application data from the DATA attribute and sends it in a UDP datagram to the peer, using the allocated relay address as the source address. Note that there is no need to specify the relayed transport address, since it is implied by the 5-tuple used for the Send indication.
当使用发送机制时，客户机向TURN服务器发送一个发送指示，其中包含（a）一个XOR-PEER-ADDRESS属性，该属性指定对等机的（服务器自反）传输地址，以及（b）一个保存应用程序数据的数据属性。当TURN服务器接收到发送指示时，它从数据属性提取应用程序数据，并使用分配的中继地址作为源地址，以UDP数据报的形式将其发送给对等方。注意，不需要指定中继传输地址，因为它由用于发送指示的5元组暗示。
In the reverse direction, UDP datagrams arriving at the relayed transport address on the TURN server are converted into Data indications and sent to the client, with the server-reflexive transport address of the peer included in an XOR-PEER-ADDRESS attribute and the data itself in a DATA attribute. Since the relayed transport address uniquely identified the allocation, the server knows which client should receive the data.
在相反方向上，到达TURN服务器上中继传输地址的UDP数据报被转换为数据指示并发送到客户端，对等方的服务器自反传输地址包含在XOR-peer-address属性中，数据本身包含在数据属性中。由于中继传输地址唯一地标识了分配，服务器知道哪个客户端应该接收数据。
Send and Data indications cannot be authenticated, since the long-term credential mechanism of STUN does not support authenticating indications. This is not as big an issue as it might first appear, since the client-to-server leg is only half of the total path to the peer. Applications that want proper security should encrypt the data sent between the client and a peer.
无法对发送和数据指示进行身份验证，因为STUN的长期凭证机制不支持身份验证指示。这并不像第一次出现的问题那么大，因为客户机到服务器的分支只是到对等机的总路径的一半。需要适当安全性的应用程序应该加密客户端和对等方之间发送的数据。
Because Send indications are not authenticated, it is possible for an attacker to send bogus Send indications to the server, which will then relay these to a peer. To partly mitigate this attack, TURN requires that the client install a permission towards a peer before sending data to it using a Send indication.
由于发送指示未经过身份验证，攻击者有可能向服务器发送虚假的发送指示，然后服务器将这些指示转发给对等方。为了部分缓解此攻击，TURN要求客户端在使用发送指示向对等方发送数据之前向对等方安装权限。
TURN TURN Peer Peer
client server A B
| | | |
|-- CreatePermission req (Peer A) -->| | |
|<-- CreatePermission success resp --| | |
| | | |
|--- Send ind (Peer A)-------------->| | |
| |=== data ===>| |
| | | |
| |<== data ====| |
|<-------------- Data ind (Peer A) --| | |
| | | |
| | | |
|--- Send ind (Peer B)-------------->| | |
| | dropped | |
| | | |
| |<== data ==================|
| dropped | | |
| | | |
TURN TURN Peer Peer
client server A B
| | | |
|-- CreatePermission req (Peer A) -->| | |
|<-- CreatePermission success resp --| | |
| | | |
|--- Send ind (Peer A)-------------->| | |
| |=== data ===>| |
| | | |
| |<== data ====| |
|<-------------- Data ind (Peer A) --| | |
| | | |
| | | |
|--- Send ind (Peer B)-------------->| | |
| | dropped | |
| | | |
| |<== data ==================|
| dropped | | |
| | | |
Figure 3
图3
In Figure 3, the client has already created an allocation and now wishes to send data to its peers. The client first creates a permission by sending the server a CreatePermission request specifying Peer A's (server-reflexive) IP address in the XOR-PEER-ADDRESS attribute; if this was not done, the server would not relay data between the client and the server. The client then sends data to Peer A using a Send indication; at the server, the application data is extracted and forwarded in a UDP datagram to Peer A, using the relayed transport address as the source transport address. When a UDP datagram from Peer A is received at the relayed transport address, the contents are placed into a Data indication and forwarded to the client. Later, the client attempts to exchange data with Peer B; however, no permission has been installed for Peer B, so the Send indication from the client and the UDP datagram from the peer are both dropped by the server.
在图3中，客户机已经创建了一个分配，现在希望向其对等方发送数据。客户端首先通过向服务器发送CreatePermission请求来创建权限，该请求在XOR-Peer-address属性中指定对等方a（服务器自反）的IP地址；如果不这样做，服务器将不会在客户端和服务器之间中继数据。然后，客户端使用发送指示向对等方A发送数据；在服务器上，使用中继传输地址作为源传输地址，提取应用程序数据并在UDP数据报中转发给对等方a。当在中继传输地址接收到来自对等方a的UDP数据报时，内容被放入数据指示中并转发给客户端。之后，客户端尝试与对等方B交换数据；但是，没有为对等方B安装权限，因此服务器会删除来自客户端的发送指示和来自对等方的UDP数据报。
For some applications (e.g., Voice over IP), the 36 bytes of overhead that a Send indication or Data indication adds to the application data can substantially increase the bandwidth required between the client and the server. To remedy this, TURN offers a second way for the client and server to associate data with a specific peer.
对于某些应用程序（例如，IP语音），发送指示或数据指示添加到应用程序数据的36字节开销可以显著增加客户端和服务器之间所需的带宽。为了解决这个问题，TURN为客户机和服务器提供了第二种将数据与特定对等机关联的方法。
This second way uses an alternate packet format known as the ChannelData message. The ChannelData message does not use the STUN
第二种方式使用另一种称为ChannelData消息的数据包格式。ChannelData消息不使用眩晕
header used by other TURN messages, but instead has a 4-byte header that includes a number known as a channel number. Each channel number in use is bound to a specific peer and thus serves as a shorthand for the peer's host transport address.
其他转弯信息使用的报头，但有一个4字节的报头，其中包含一个称为通道号的数字。使用中的每个通道号都绑定到一个特定的对等方，因此用作对等方主机传输地址的简写。
To bind a channel to a peer, the client sends a ChannelBind request to the server, and includes an unbound channel number and the transport address of the peer. Once the channel is bound, the client can use a ChannelData message to send the server data destined for the peer. Similarly, the server can relay data from that peer towards the client using a ChannelData message.
要将通道绑定到对等方，客户端将向服务器发送ChannelBind请求，并包括未绑定的通道号和对等方的传输地址。一旦绑定了通道，客户机就可以使用ChannelData消息发送发送给对等方的服务器数据。类似地，服务器可以使用ChannelData消息将来自该对等方的数据中继到客户端。
Channel bindings last for 10 minutes unless refreshed -- this lifetime was chosen to be longer than the permission lifetime. Channel bindings are refreshed by sending another ChannelBind request rebinding the channel to the peer. Like permissions (but unlike allocations), there is no way to explicitly delete a channel binding; the client must simply wait for it to time out.
除非刷新，否则通道绑定将持续10分钟——此生存期被选择为长于权限生存期。通过发送另一个将通道重新绑定到对等方的ChannelBind请求来刷新通道绑定。与权限类似（但与分配不同），无法显式删除通道绑定；客户端必须等待它超时。
TURN TURN Peer Peer
client server A B
| | | |
|-- ChannelBind req ---------------->| | |
| (Peer A to 0x4001) | | |
| | | |
|<---------- ChannelBind succ resp --| | |
| | | |
|-- [0x4001] data ------------------>| | |
| |=== data ===>| |
| | | |
| |<== data ====| |
|<------------------ [0x4001] data --| | |
| | | |
|--- Send ind (Peer A)-------------->| | |
| |=== data ===>| |
| | | |
| |<== data ====| |
|<------------------ [0x4001] data --| | |
| | | |
TURN TURN Peer Peer
client server A B
| | | |
|-- ChannelBind req ---------------->| | |
| (Peer A to 0x4001) | | |
| | | |
|<---------- ChannelBind succ resp --| | |
| | | |
|-- [0x4001] data ------------------>| | |
| |=== data ===>| |
| | | |
| |<== data ====| |
|<------------------ [0x4001] data --| | |
| | | |
|--- Send ind (Peer A)-------------->| | |
| |=== data ===>| |
| | | |
| |<== data ====| |
|<------------------ [0x4001] data --| | |
| | | |
Figure 4
图4
Figure 4 shows the channel mechanism in use. The client has already created an allocation and now wishes to bind a channel to Peer A. To do this, the client sends a ChannelBind request to the server, specifying the transport address of Peer A and a channel number (0x4001). After that, the client can send application data encapsulated inside ChannelData messages to Peer A: this is shown as
图4显示了正在使用的通道机制。客户端已创建分配，现在希望将通道绑定到对等a。为此，客户端向服务器发送ChannelBind请求，指定对等a的传输地址和通道号（0x4001）。之后，客户端可以将封装在ChannelData消息中的应用程序数据发送给对等方A：如下所示
"[0x4001] data" where 0x4001 is the channel number. When the ChannelData message arrives at the server, the server transfers the data to a UDP datagram and sends it to Peer A (which is the peer bound to channel number 0x4001).
“[0x4001]数据”，其中0x4001是通道号。当ChannelData消息到达服务器时，服务器将数据传输到UDP数据报，并将其发送到对等方a（即绑定到通道号0x4001的对等方）。
In the reverse direction, when Peer A sends a UDP datagram to the relayed transport address, this UDP datagram arrives at the server on the relayed transport address assigned to the allocation. Since the UDP datagram was received from Peer A, which has a channel number assigned to it, the server encapsulates the data into a ChannelData message when sending the data to the client.
在相反的方向上，当对等方A向中继传输地址发送UDP数据报时，该UDP数据报到达分配的中继传输地址上的服务器。由于UDP数据报是从对等方A接收的，该对等方A具有分配给它的通道号，因此服务器在将数据发送到客户端时将数据封装到ChannelData消息中。
Once a channel has been bound, the client is free to intermix ChannelData messages and Send indications. In the figure, the client later decides to use a Send indication rather than a ChannelData message to send additional data to Peer A. The client might decide to do this, for example, so it can use the DONT-FRAGMENT attribute (see the next section). However, once a channel is bound, the server will always use a ChannelData message, as shown in the call flow.
绑定通道后，客户端可以自由混合通道数据消息并发送指示。在图中，客户机随后决定使用发送指示而不是ChannelData消息向对等方a发送额外数据。例如，客户机可能决定这样做，以便使用DONT-FRAGMENT属性（请参阅下一节）。但是，一旦绑定了通道，服务器将始终使用ChannelData消息，如调用流中所示。
Note that ChannelData messages can only be used for peers to which the client has bound a channel. In the example above, Peer A has been bound to a channel, but Peer B has not, so application data to and from Peer B would use the Send mechanism.
请注意，ChannelData消息只能用于客户端已绑定通道的对等方。在上面的示例中，对等点A已绑定到通道，但对等点B未绑定到通道，因此进出对等点B的应用程序数据将使用发送机制。
This version of TURN is designed so that the server can be implemented as an application that runs in user space under commonly available operating systems without requiring special privileges. This design decision was made to make it easy to deploy a TURN server: for example, to allow a TURN server to be integrated into a peer-to-peer application so that one peer can offer NAT traversal services to another peer.
TURN的此版本的设计目的是将服务器实现为一个应用程序，该应用程序在常用操作系统下的用户空间中运行，而无需特殊权限。做出此设计决策是为了便于部署TURN服务器：例如，允许将TURN服务器集成到对等应用程序中，以便一个对等方可以向另一个对等方提供NAT遍历服务。
This design decision has the following implications for data relayed by a TURN server:
该设计决策对TURN服务器转发的数据具有以下影响：
o The value of the Diffserv field may not be preserved across the server;
o Diffserv字段的值可能不会在整个服务器上保留；
o The Time to Live (TTL) field may be reset, rather than decremented, across the server;
o 生存时间（TTL）字段可以在服务器上重置，而不是递减；
o The Explicit Congestion Notification (ECN) field may be reset by the server;
o 服务器可以重置显式拥塞通知（ECN）字段；
o ICMP messages are not relayed by the server;
o 服务器不转发ICMP消息；
o There is no end-to-end fragmentation, since the packet is re-assembled at the server.
o 没有端到端的碎片，因为数据包是在服务器上重新组装的。
Future work may specify alternate TURN semantics that address these limitations.
未来的工作可能会指定替代转弯语义来解决这些限制。
For reasons described in [Frag-Harmful], applications, especially those sending large volumes of data, should try hard to avoid having their packets fragmented. Applications using TCP can more or less ignore this issue because fragmentation avoidance is now a standard part of TCP, but applications using UDP (and thus any application using this version of TURN) must handle fragmentation avoidance themselves.
出于[Frag有害]中所述的原因，应用程序，尤其是那些发送大量数据的应用程序，应该努力避免数据包被碎片化。使用TCP的应用程序或多或少可以忽略这个问题，因为碎片避免现在是TCP的标准部分，但是使用UDP的应用程序（以及使用此版本TURN的任何应用程序）必须自己处理碎片避免。
The application running on the client and the peer can take one of two approaches to avoid IP fragmentation.
在客户机和对等机上运行的应用程序可以采取两种方法之一来避免IP碎片。
The first approach is to avoid sending large amounts of application data in the TURN messages/UDP datagrams exchanged between the client and the peer. This is the approach taken by most VoIP (Voice-over-IP) applications. In this approach, the application exploits the fact that the IP specification [RFC0791] specifies that IP packets up to 576 bytes should never need to be fragmented.
第一种方法是避免在客户机和对等机之间交换的消息/UDP数据报中发送大量应用程序数据。这是大多数VoIP（IP语音）应用程序所采用的方法。在这种方法中，应用程序利用了一个事实，即IP规范[RFC0791]规定不需要对多达576字节的IP数据包进行分段。
The exact amount of application data that can be included while avoiding fragmentation depends on the details of the TURN session between the client and the server: whether UDP, TCP, or TLS transport is used, whether ChannelData messages or Send/Data indications are used, and whether any additional attributes (such as the DONT-FRAGMENT attribute) are included. Another factor, which is hard to determine, is whether the MTU is reduced somewhere along the path for other reasons, such as the use of IP-in-IP tunneling.
避免碎片化时可以包含的应用程序数据的确切数量取决于客户端和服务器之间TURN会话的详细信息：是否使用UDP、TCP或TLS传输，是否使用ChannelData消息或发送/数据指示，以及是否有任何附加属性（如DONT-FRAGMENT属性）包括在内。另一个很难确定的因素是，MTU是否由于其他原因（例如在IP隧道中使用IP）在路径的某个位置减少。
As a guideline, sending a maximum of 500 bytes of application data in a single TURN message (by the client on the client-to-server leg) or a UDP datagram (by the peer on the peer-to-server leg) will generally avoid IP fragmentation. To further reduce the chance of fragmentation, it is recommended that the client use ChannelData messages when transferring significant volumes of data, since the overhead of the ChannelData message is less than Send and Data indications.
作为一项指导原则，在单个TURN消息（由客户端到服务器分支上的客户端）或UDP数据报（由对等服务器分支上的对等方）中发送最多500字节的应用程序数据通常可以避免IP碎片。为了进一步减少碎片化的机会，建议客户端在传输大量数据时使用ChannelData消息，因为ChannelData消息的开销小于发送和数据指示。
The second approach the client and peer can take to avoid fragmentation is to use a path MTU discovery algorithm to determine the maximum amount of application data that can be sent without fragmentation.
客户端和对等方可以采取的避免碎片的第二种方法是使用路径MTU发现算法来确定在没有碎片的情况下可以发送的最大应用程序数据量。
Unfortunately, because servers implementing this version of TURN do not relay ICMP messages, the classic path MTU discovery algorithm defined in [RFC1191] is not able to discover the MTU of the transmission path between the client and the peer. (Even if they did relay ICMP messages, the algorithm would not always work since ICMP messages are often filtered out by combined NAT/firewall devices).
不幸的是，由于实现此版本TURN的服务器不中继ICMP消息，[RFC1191]中定义的经典路径MTU发现算法无法发现客户端和对等方之间传输路径的MTU。（即使它们确实中继ICMP消息，该算法也不会始终有效，因为ICMP消息通常会被组合的NAT/防火墙设备过滤掉）。
So the client and server need to use a path MTU discovery algorithm that does not require ICMP messages. The Packetized Path MTU Discovery algorithm defined in [RFC4821] is one such algorithm.
因此，客户端和服务器需要使用不需要ICMP消息的路径MTU发现算法。[RFC4821]中定义的分组化路径MTU发现算法就是这样一种算法。
The details of how to use the algorithm of [RFC4821] with TURN are still under investigation. However, as a step towards this goal, this version of TURN supports a DONT-FRAGMENT attribute. When the client includes this attribute in a Send indication, this tells the server to set the DF bit in the resulting UDP datagram that it sends to the peer. Since some servers may be unable to set the DF bit, the client should also include this attribute in the Allocate request -- any server that does not support the DONT-FRAGMENT attribute will indicate this by rejecting the Allocate request.
如何将[RFC4821]算法与TURN结合使用的细节仍在研究中。但是，作为实现此目标的一步，此版本的TURN支持DONT-FRAGMENT属性。当客户端在发送指示中包含此属性时，这会告诉服务器在其发送给对等方的结果UDP数据报中设置DF位。由于某些服务器可能无法设置DF位，因此客户端还应该在分配请求中包含此属性——任何不支持DONT-FRAGMENT属性的服务器都会通过拒绝分配请求来指示这一点。
One of the envisioned uses of TURN is as a relay for clients and peers wishing to exchange real-time data (e.g., voice or video) using RTP. To facilitate the use of TURN for this purpose, TURN includes some special support for older versions of RTP.
TURN的预期用途之一是作为希望使用RTP交换实时数据（如语音或视频）的客户和对等方的中继。为了便于使用TURN实现这一目的，TURN包括对旧版本RTP的一些特殊支持。
Old versions of RTP [RFC3550] required that the RTP stream be on an even port number and the associated RTP Control Protocol (RTCP) stream, if present, be on the next highest port. To allow clients to work with peers that still require this, TURN allows the client to request that the server allocate a relayed transport address with an even port number, and to optionally request the server reserve the next-highest port number for a subsequent allocation.
旧版本的RTP[RFC3550]要求RTP流位于偶数端口号上，并且相关的RTP控制协议（RTCP）流（如果存在）位于下一个最高端口上。为了允许客户机与仍然需要此功能的对等机一起工作，TURN允许客户机请求服务器分配一个偶数端口号的中继传输地址，并可以选择请求服务器为后续分配保留下一个最高的端口号。
This version of TURN has been designed to permit the future specification of a method of doing anycast discovery of a TURN server over UDP.
TURN的此版本旨在允许将来指定通过UDP对TURN服务器进行选播发现的方法。
Specifically, a TURN server can reject an Allocate request with the suggestion that the client try an alternate server. To avoid certain types of attacks, the client must use the same credentials with the alternate server as it would have with the initial server.
具体来说，TURN服务器可以拒绝分配请求，并建议客户端尝试备用服务器。为了避免某些类型的攻击，客户端必须对备用服务器使用与初始服务器相同的凭据。
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]中所述进行解释。
Readers are expected to be familiar with [RFC5389] and the terms defined there.
读者应熟悉[RFC5389]及其定义的术语。
The following terms are used in this document:
本文件中使用了以下术语：
TURN: The protocol spoken between a TURN client and a TURN server. It is an extension to the STUN protocol [RFC5389]. The protocol allows a client to allocate and use a relayed transport address.
TURN：TURN客户端和TURN服务器之间的协议。它是STUN协议[RFC5389]的扩展。该协议允许客户端分配和使用中继传输地址。
TURN client: A STUN client that implements this specification.
TURN客户端：实现此规范的STUN客户端。
TURN server: A STUN server that implements this specification. It relays data between a TURN client and its peer(s).
TURN服务器：实现此规范的STUN服务器。它在TURN客户端和对等客户端之间中继数据。
Peer: A host with which the TURN client wishes to communicate. The TURN server relays traffic between the TURN client and its peer(s). The peer does not interact with the TURN server using the protocol defined in this document; rather, the peer receives data sent by the TURN server and the peer sends data towards the TURN server.
对等机：TURN客户端希望与之通信的主机。TURN服务器在TURN客户端与其对等方之间中继通信量。对等方不使用本文件中定义的协议与TURN服务器交互；相反，对等方接收TURN服务器发送的数据，对等方向TURN服务器发送数据。
Transport Address: The combination of an IP address and a port.
传输地址：IP地址和端口的组合。
Host Transport Address: A transport address on a client or a peer.
主机传输地址：客户机或对等机上的传输地址。
Server-Reflexive Transport Address: A transport address on the "public side" of a NAT. This address is allocated by the NAT to correspond to a specific host transport address.
服务器自反传输地址：NAT“公共端”的传输地址。该地址由NAT分配，以对应于特定的主机传输地址。
Relayed Transport Address: A transport address on the TURN server that is used for relaying packets between the client and a peer. A peer sends to this address on the TURN server, and the packet is then relayed to the client.
中继传输地址：TURN服务器上的传输地址，用于在客户端和对等端之间中继数据包。对等方在TURN服务器上发送到此地址，然后将数据包中继到客户端。
TURN Server Transport Address: A transport address on the TURN server that is used for sending TURN messages to the server. This is the transport address that the client uses to communicate with the server.
转向服务器传输地址：转向服务器上用于向服务器发送转向消息的传输地址。这是客户端用于与服务器通信的传输地址。
Peer Transport Address: The transport address of the peer as seen by the server. When the peer is behind a NAT, this is the peer's server-reflexive transport address.
对等传输地址：服务器看到的对等传输地址。当对等方位于NAT后面时，这是对等方的服务器自反传输地址。
Allocation: The relayed transport address granted to a client through an Allocate request, along with related state, such as permissions and expiration timers.
分配：通过分配请求授予客户端的中继传输地址，以及相关状态，如权限和过期计时器。
5-tuple: The combination (client IP address and port, server IP address and port, and transport protocol (currently one of UDP, TCP, or TLS)) used to communicate between the client and the server. The 5-tuple uniquely identifies this communication stream. The 5-tuple also uniquely identifies the Allocation on the server.
5元组：用于在客户端和服务器之间进行通信的组合（客户端IP地址和端口、服务器IP地址和端口，以及传输协议（当前为UDP、TCP或TLS之一））。5元组唯一标识此通信流。5元组还唯一标识服务器上的分配。
Channel: A channel number and associated peer transport address. Once a channel number is bound to a peer's transport address, the client and server can use the more bandwidth-efficient ChannelData message to exchange data.
通道：通道号和相关的对等传输地址。一旦通道号绑定到对等方的传输地址，客户端和服务器就可以使用带宽效率更高的ChannelData消息来交换数据。
Permission: The IP address and transport protocol (but not the port) of a peer that is permitted to send traffic to the TURN server and have that traffic relayed to the TURN client. The TURN server will only forward traffic to its client from peers that match an existing permission.
权限：允许向TURN服务器发送流量并将该流量中继到TURN客户端的对等方的IP地址和传输协议（但不是端口）。TURN服务器将只从与现有权限匹配的对等方将流量转发到其客户端。
Realm: A string used to describe the server or a context within the server. The realm tells the client which username and password combination to use to authenticate requests.
领域：用于描述服务器或服务器内上下文的字符串。域告诉客户端使用哪个用户名和密码组合来验证请求。
Nonce: A string chosen at random by the server and included in the message-digest. To prevent reply attacks, the server should change the nonce regularly.
Nonce：服务器随机选择并包含在消息摘要中的字符串。为了防止应答攻击，服务器应该定期更改nonce。
This section contains general TURN processing rules that apply to all TURN messages.
本节包含适用于所有转弯信息的常规转弯处理规则。
TURN is an extension to STUN. All TURN messages, with the exception of the ChannelData message, are STUN-formatted messages. All the base processing rules described in [RFC5389] apply to STUN-formatted messages. This means that all the message-forming and message-processing descriptions in this document are implicitly prefixed with the rules of [RFC5389].
转身是晕眩的延伸。除ChannelData消息外，所有转弯消息均为STUN格式消息。[RFC5389]中描述的所有基本处理规则适用于STUN格式的消息。这意味着本文档中的所有消息形成和消息处理描述都隐含地以[RFC5389]的规则作为前缀。
[RFC5389] specifies an authentication mechanism called the long-term credential mechanism. TURN servers and clients MUST implement this mechanism. The server MUST demand that all requests from the client be authenticated using this mechanism, or that a equally strong or stronger mechanism for client authentication is used.
[RFC5389]指定一种称为长期凭证机制的身份验证机制。TURN服务器和客户端必须实现此机制。服务器必须要求使用此机制对来自客户端的所有请求进行身份验证，或者使用同样强或更强的客户端身份验证机制。
Note that the long-term credential mechanism applies only to requests and cannot be used to authenticate indications; thus, indications in TURN are never authenticated. If the server requires requests to be authenticated, then the server's administrator MUST choose a realm value that will uniquely identify the username and password combination that the client must use, even if the client uses multiple servers under different administrations. The server's administrator MAY choose to allocate a unique username to each client, or MAY choose to allocate the same username to more than one client (for example, to all clients from the same department or company). For each allocation, the server SHOULD generate a new random nonce when the allocation is first attempted following the randomness recommendations in [RFC4086] and SHOULD expire the nonce at least once every hour during the lifetime of the allocation.
请注意，长期凭证机制仅适用于请求，不能用于验证指示；因此，指示也不会得到验证。如果服务器要求对请求进行身份验证，则服务器管理员必须选择一个域值，该域值将唯一标识客户端必须使用的用户名和密码组合，即使客户端在不同的管理下使用多个服务器。服务器管理员可以选择为每个客户端分配唯一的用户名，也可以选择为多个客户端（例如，来自同一部门或公司的所有客户端）分配相同的用户名。对于每个分配，当按照[RFC4086]中的随机性建议首次尝试分配时，服务器应生成一个新的随机nonce，并应在分配生命周期内至少每小时使该nonce过期一次。
All requests after the initial Allocate must use the same username as that used to create the allocation, to prevent attackers from hijacking the client's allocation. Specifically, if the server requires the use of the long-term credential mechanism, and if a non-Allocate request passes authentication under this mechanism, and if the 5-tuple identifies an existing allocation, but the request does not use the same username as used to create the allocation, then the request MUST be rejected with a 441 (Wrong Credentials) error.
初始分配后的所有请求必须使用与创建分配时使用的用户名相同的用户名，以防止攻击者劫持客户端的分配。具体地说，如果服务器需要使用长期凭据机制，并且如果非分配请求通过了该机制下的身份验证，并且如果5元组标识了现有分配，但是请求使用的用户名与创建分配时使用的用户名不同，则必须使用441拒绝该请求（错误的凭据）错误。
When a TURN message arrives at the server from the client, the server uses the 5-tuple in the message to identify the associated allocation. For all TURN messages (including ChannelData) EXCEPT an Allocate request, if the 5-tuple does not identify an existing allocation, then the message MUST either be rejected with a 437 Allocation Mismatch error (if it is a request) or silently ignored (if it is an indication or a ChannelData message). A client receiving a 437 error response to a request other than Allocate MUST assume the allocation no longer exists.
当TURN消息从客户端到达服务器时，服务器使用消息中的5元组来标识关联的分配。对于除分配请求外的所有TURN消息（包括ChannelData），如果5元组未识别现有分配，则必须以437分配不匹配错误拒绝该消息（如果是请求）或静默忽略该消息（如果是指示或ChannelData消息）。接收到437错误响应而不是分配请求的客户端必须假定分配不再存在。
[RFC5389] defines a number of attributes, including the SOFTWARE and FINGERPRINT attributes. The client SHOULD include the SOFTWARE attribute in all Allocate and Refresh requests and MAY include it in any other requests or indications. The server SHOULD include the SOFTWARE attribute in all Allocate and Refresh responses (either success or failure) and MAY include it in other responses or indications. The client and the server MAY include the FINGERPRINT attribute in any STUN-formatted messages defined in this document.
[RFC5389]定义了许多属性，包括软件和指纹属性。客户端应在所有分配和刷新请求中包含软件属性，并可在任何其他请求或指示中包含该属性。服务器应在所有分配和刷新响应（成功或失败）中包含软件属性，并可在其他响应或指示中包含该属性。客户端和服务器可以在本文档中定义的任何STUN格式的消息中包含指纹属性。
TURN does not use the backwards-compatibility mechanism described in [RFC5389].
TURN不使用[RFC5389]中所述的向后兼容机制。
TURN, as defined in this specification, only supports IPv4. The client's IP address, the server's IP address, and all IP addresses appearing in a relayed transport address MUST be IPv4 addresses.
如本规范中所定义，TURN仅支持IPv4。客户端的IP地址、服务器的IP地址以及中继传输地址中出现的所有IP地址必须是IPv4地址。
By default, TURN runs on the same ports as STUN: 3478 for TURN over UDP and TCP, and 5349 for TURN over TLS. However, TURN has its own set of Service Record (SRV) names: "turn" for UDP and TCP, and "turns" for TLS. Either the SRV procedures or the ALTERNATE-SERVER procedures, both described in Section 6, can be used to run TURN on a different port.
默认情况下，TURN与STUN在相同的端口上运行：3478用于转接UDP和TCP，5349用于转接TLS。但是，TURN有自己的一组服务记录（SRV）名称：“TURN”表示UDP和TCP，而“turns”表示TLS。第6节中描述的SRV过程或备用服务器过程均可用于在不同端口上运行TURN。
To ensure interoperability, a TURN server MUST support the use of UDP transport between the client and the server, and SHOULD support the use of TCP and TLS transport.
为了确保互操作性，TURN服务器必须支持在客户端和服务器之间使用UDP传输，并且应该支持使用TCP和TLS传输。
When UDP transport is used between the client and the server, the client will retransmit a request if it does not receive a response within a certain timeout period. Because of this, the server may receive two (or more) requests with the same 5-tuple and same transaction id. STUN requires that the server recognize this case and treat the request as idempotent (see [RFC5389]). Some implementations may choose to meet this requirement by remembering all received requests and the corresponding responses for 40 seconds. Other implementations may choose to reprocess the request and arrange that such reprocessing returns essentially the same response. To aid implementors who choose the latter approach (the so-called "stateless stack approach"), this specification includes some implementation notes on how this might be done. Implementations are free to choose either approach or choose some other approach that gives the same results.
在客户端和服务器之间使用UDP传输时，如果客户端在特定超时时间内未收到响应，则会重新传输请求。因此，服务器可能会收到两个（或更多）具有相同5元组和相同事务id的请求。STUN要求服务器识别这种情况，并将请求视为幂等（请参见[RFC5389]）。一些实现可能会选择通过记住所有接收到的请求和相应的响应40秒来满足此要求。其他实现可以选择重新处理请求，并安排这种重新处理返回基本相同的响应。为了帮助选择后一种方法（所谓的“无状态堆栈方法”）的实现者，本规范包含一些关于如何实现的实现说明。实现可以自由选择任何一种方法，也可以选择提供相同结果的其他方法。
When TCP transport is used between the client and the server, it is possible that a bit error will cause a length field in a TURN packet to become corrupted, causing the receiver to lose synchronization with the incoming stream of TURN messages. A client or server that detects a long sequence of invalid TURN messages over TCP transport SHOULD close the corresponding TCP connection to help the other end detect this situation more rapidly.
在客户端和服务器之间使用TCP传输时，可能会出现位错误，导致TURN数据包中的长度字段损坏，从而导致接收器与传入TURN消息流失去同步。通过TCP传输检测到一长串无效翻转消息的客户端或服务器应关闭相应的TCP连接，以帮助另一端更快地检测到这种情况。
To mitigate either intentional or unintentional denial-of-service attacks against the server by clients with valid usernames and passwords, it is RECOMMENDED that the server impose limits on both the number of allocations active at one time for a given username and on the amount of bandwidth those allocations can use. The server should reject new allocations that would exceed the limit on the allowed number of allocations active at one time with a 486 (Allocation Quota Exceeded) (see Section 6.2), and should discard application data traffic that exceeds the bandwidth quota.
为了减轻具有有效用户名和密码的客户端对服务器的有意或无意拒绝服务攻击，建议服务器对给定用户名一次活动的分配数量以及这些分配可以使用的带宽量施加限制。服务器应拒绝一次超过允许的有效分配数量限制的新分配，分配数量为486（超过分配配额）（请参阅第6.2节），并应丢弃超过带宽配额的应用程序数据流量。
All TURN operations revolve around allocations, and all TURN messages are associated with an allocation. An allocation conceptually consists of the following state data:
所有回合操作都围绕分配进行，所有回合消息都与分配关联。分配概念上由以下状态数据组成：
o the relayed transport address;
o 中继传输地址；
o the 5-tuple: (client's IP address, client's port, server IP address, server port, transport protocol);
o 5元组：（客户端IP地址、客户端端口、服务器IP地址、服务器端口、传输协议）；
o the authentication information;
o 认证信息；
o the time-to-expiry;
o 到期时间；
o a list of permissions;
o 权限列表；
o a list of channel to peer bindings.
o 通道到对等绑定的列表。
The relayed transport address is the transport address allocated by the server for communicating with peers, while the 5-tuple describes the communication path between the client and the server. On the client, the 5-tuple uses the client's host transport address; on the server, the 5-tuple uses the client's server-reflexive transport address.
中继传输地址是服务器为与对等方通信而分配的传输地址，而5元组描述客户端和服务器之间的通信路径。在客户机上，5元组使用客户机的主机传输地址；在服务器上，5元组使用客户端的服务器自反传输地址。
Both the relayed transport address and the 5-tuple MUST be unique across all allocations, so either one can be used to uniquely identify the allocation.
中继传输地址和5元组在所有分配中都必须是唯一的，因此任何一个都可以用于唯一标识分配。
The authentication information (e.g., username, password, realm, and nonce) is used to both verify subsequent requests and to compute the message integrity of responses. The username, realm, and nonce values are initially those used in the authenticated Allocate request that creates the allocation, though the server can change the nonce value during the lifetime of the allocation using a 438 (Stale Nonce) reply. Note that, rather than storing the password explicitly, for security reasons, it may be desirable for the server to store the key value, which is an MD5 hash over the username, realm, and password (see [RFC5389]).
身份验证信息（例如用户名、密码、域和nonce）用于验证后续请求和计算响应的消息完整性。用户名、领域和nonce值最初是在创建分配的已验证分配请求中使用的值，不过服务器可以使用438（过时nonce）应答在分配生命周期内更改nonce值。请注意，出于安全原因，服务器可能需要存储键值，而不是显式存储密码，键值是用户名、域和密码上的MD5散列（请参见[RFC5389]）。
The time-to-expiry is the time in seconds left until the allocation expires. Each Allocate or Refresh transaction sets this timer, which then ticks down towards 0. By default, each Allocate or Refresh transaction resets this timer to the default lifetime value of 600 seconds (10 minutes), but the client can request a different value in the Allocate and Refresh request. Allocations can only be refreshed using the Refresh request; sending data to a peer does not refresh an
到期时间是指分配到期前剩余的时间（以秒为单位）。每个分配或刷新事务都会设置此计时器，然后计时器向下滴答地指向0。默认情况下，每个分配或刷新事务都会将此计时器重置为600秒（10分钟）的默认生存期值，但客户端可以在分配和刷新请求中请求不同的值。只能使用刷新请求刷新分配；向对等方发送数据不会刷新
allocation. When an allocation expires, the state data associated with the allocation can be freed.
分配。分配过期时，可以释放与分配关联的状态数据。
The list of permissions is described in Section 8 and the list of channels is described in Section 11.
权限列表见第8节，频道列表见第11节。
An allocation on the server is created using an Allocate transaction.
服务器上的分配是使用分配事务创建的。
The client forms an Allocate request as follows.
客户端形成一个分配请求，如下所示。
The client first picks a host transport address. It is RECOMMENDED that the client pick a currently unused transport address, typically by allowing the underlying OS to pick a currently unused port for a new socket.
客户端首先选择一个主机传输地址。建议客户端选择当前未使用的传输地址，通常是通过允许底层操作系统为新套接字选择当前未使用的端口。
The client then picks a transport protocol to use between the client and the server. The transport protocol MUST be one of UDP, TCP, or TLS-over-TCP. Since this specification only allows UDP between the server and the peers, it is RECOMMENDED that the client pick UDP unless it has a reason to use a different transport. One reason to pick a different transport would be that the client believes, either through configuration or by experiment, that it is unable to contact any TURN server using UDP. See Section 2.1 for more discussion.
然后，客户机选择在客户机和服务器之间使用的传输协议。传输协议必须是UDP、TCP或TCP上的TLS之一。由于此规范仅允许服务器和对等方之间使用UDP，因此建议客户端选择UDP，除非它有理由使用其他传输。选择不同传输的一个原因是，通过配置或实验，客户端认为它无法使用UDP联系任何TURN服务器。更多讨论见第2.1节。
The client also picks a server transport address, which SHOULD be done as follows. The client receives (perhaps through configuration) a domain name for a TURN server. The client then uses the DNS procedures described in [RFC5389], but using an SRV service name of "turn" (or "turns" for TURN over TLS) instead of "stun" (or "stuns"). For example, to find servers in the example.com domain, the client performs a lookup for '_turn._udp.example.com', '_turn._tcp.example.com', and '_turns._tcp.example.com' if the client wants to communicate with the server using UDP, TCP, or TLS-over-TCP, respectively.
客户机还选择一个服务器传输地址，该地址应按如下操作。客户端接收（可能通过配置）TURN服务器的域名。然后，客户机使用[RFC5389]中描述的DNS过程，但使用SRV服务名称“turn”（或“turns”表示移交TLS）而不是“stun”（或“stuns”）。例如，要查找example.com域中的服务器，如果客户端希望分别通过tcp使用udp、tcp或TLS与服务器通信，则客户端将执行对“_turn._udp.example.com”、“_turn._tcp.example.com”和“_turn._tcp.example.com”的查找。
The client MUST include a REQUESTED-TRANSPORT attribute in the request. This attribute specifies the transport protocol between the server and the peers (note that this is NOT the transport protocol that appears in the 5-tuple). In this specification, the REQUESTED-TRANSPORT type is always UDP. This attribute is included to allow future extensions to specify other protocols.
客户端必须在请求中包含请求的传输属性。此属性指定服务器和对等方之间的传输协议（请注意，这不是出现在5元组中的传输协议）。在本规范中，请求的传输类型始终为UDP。包含此属性是为了允许将来的扩展指定其他协议。
If the client wishes the server to initialize the time-to-expiry field of the allocation to some value other than the default
如果客户端希望服务器将分配的“到期时间”字段初始化为默认值以外的某个值
lifetime, then it MAY include a LIFETIME attribute specifying its desired value. This is just a request, and the server may elect to use a different value. Note that the server will ignore requests to initialize the field to less than the default value.
lifetime，则它可能包括指定其所需值的lifetime属性。这只是一个请求，服务器可以选择使用不同的值。请注意，服务器将忽略将字段初始化为小于默认值的请求。
If the client wishes to later use the DONT-FRAGMENT attribute in one or more Send indications on this allocation, then the client SHOULD include the DONT-FRAGMENT attribute in the Allocate request. This allows the client to test whether this attribute is supported by the server.
如果客户端希望以后在此分配的一个或多个发送指示中使用DONT-FRAGMENT属性，则客户端应在分配请求中包含DONT-FRAGMENT属性。这允许客户端测试服务器是否支持此属性。
If the client requires the port number of the relayed transport address be even, the client includes the EVEN-PORT attribute. If this attribute is not included, then the port can be even or odd. By setting the R bit in the EVEN-PORT attribute to 1, the client can request that the server reserve the next highest port number (on the same IP address) for a subsequent allocation. If the R bit is 0, no such request is made.
如果客户端要求中继传输地址的端口号为偶数，则客户端包含偶数端口属性。如果不包括此属性，则端口可以是偶数或奇数。通过将偶数端口属性中的R位设置为1，客户机可以请求服务器保留下一个最高的端口号（在同一IP地址上），以便进行后续分配。如果R位为0，则不会发出此类请求。
The client MAY also include a RESERVATION-TOKEN attribute in the request to ask the server to use a previously reserved port for the allocation. If the RESERVATION-TOKEN attribute is included, then the client MUST omit the EVEN-PORT attribute.
客户端还可以在请求中包括RESERVATION-TOKEN属性，以请求服务器使用先前保留的端口进行分配。如果包含RESERVATION-TOKEN属性，则客户端必须省略偶数端口属性。
Once constructed, the client sends the Allocate request on the 5-tuple.
构建完成后，客户机将在5元组上发送分配请求。
When the server receives an Allocate request, it performs the following checks:
服务器收到分配请求时，将执行以下检查：
1. The server MUST require that the request be authenticated. This authentication MUST be done using the long-term credential mechanism of [RFC5389] unless the client and server agree to use another mechanism through some procedure outside the scope of this document.
1. 服务器必须要求对请求进行身份验证。必须使用[RFC5389]的长期凭证机制进行身份验证，除非客户机和服务器同意通过本文档范围之外的某些程序使用另一种机制。
2. The server checks if the 5-tuple is currently in use by an existing allocation. If yes, the server rejects the request with a 437 (Allocation Mismatch) error.
2. 服务器检查现有分配是否正在使用5元组。如果是，服务器将拒绝请求，并出现437（分配不匹配）错误。
3. The server checks if the request contains a REQUESTED-TRANSPORT attribute. If the REQUESTED-TRANSPORT attribute is not included or is malformed, the server rejects the request with a 400 (Bad Request) error. Otherwise, if the attribute is included but specifies a protocol other that UDP, the server rejects the request with a 442 (Unsupported Transport Protocol) error.
3. 服务器检查请求是否包含请求的传输属性。如果请求的传输属性未包含或格式不正确，服务器将拒绝该请求，并出现400（错误请求）错误。否则，如果包含该属性，但指定了UDP以外的协议，则服务器将拒绝该请求，并出现442（不支持的传输协议）错误。
4. The request may contain a DONT-FRAGMENT attribute. If it does, but the server does not support sending UDP datagrams with the DF bit set to 1 (see Section 12), then the server treats the DONT-FRAGMENT attribute in the Allocate request as an unknown comprehension-required attribute.
4. 请求可能包含DONT-FRAGMENT属性。如果确实如此，但服务器不支持发送DF位设置为1的UDP数据报（请参阅第12节），则服务器会将分配请求中的DONT-FRAGMENT属性视为未知的必需属性。
5. The server checks if the request contains a RESERVATION-TOKEN attribute. If yes, and the request also contains an EVEN-PORT attribute, then the server rejects the request with a 400 (Bad Request) error. Otherwise, it checks to see if the token is valid (i.e., the token is in range and has not expired and the corresponding relayed transport address is still available). If the token is not valid for some reason, the server rejects the request with a 508 (Insufficient Capacity) error.
5. 服务器检查请求是否包含保留令牌属性。如果是，并且请求还包含偶数端口属性，则服务器拒绝请求，并出现400（错误请求）错误。否则，它将检查令牌是否有效（即，令牌在范围内且未过期，且相应的中继传输地址仍然可用）。如果令牌因某种原因无效，服务器将以508（容量不足）错误拒绝请求。
6. The server checks if the request contains an EVEN-PORT attribute. If yes, then the server checks that it can satisfy the request (i.e., can allocate a relayed transport address as described below). If the server cannot satisfy the request, then the server rejects the request with a 508 (Insufficient Capacity) error.
6. 服务器检查请求是否包含偶数端口属性。如果是，则服务器检查它是否能够满足请求（即，可以分配中继传输地址，如下所述）。如果服务器无法满足该请求，则服务器将拒绝该请求，并出现508（容量不足）错误。
7. At any point, the server MAY choose to reject the request with a 486 (Allocation Quota Reached) error if it feels the client is trying to exceed some locally defined allocation quota. The server is free to define this allocation quota any way it wishes, but SHOULD define it based on the username used to authenticate the request, and not on the client's transport address.
7. 在任何时候，如果服务器感觉客户端试图超过某些本地定义的分配配额，则可能会选择以486（已达到分配配额）错误拒绝请求。服务器可以任意定义此分配配额，但应根据用于验证请求的用户名而不是客户端的传输地址来定义。
8. Also at any point, the server MAY choose to reject the request with a 300 (Try Alternate) error if it wishes to redirect the client to a different server. The use of this error code and attribute follow the specification in [RFC5389].
8. 此外，在任何时候，如果服务器希望将客户端重定向到其他服务器，则可能会选择以300（Try Alternate）错误拒绝请求。此错误代码和属性的使用遵循[RFC5389]中的规范。
If all the checks pass, the server creates the allocation. The 5-tuple is set to the 5-tuple from the Allocate request, while the list of permissions and the list of channels are initially empty.
如果所有检查都通过，服务器将创建分配。5元组从分配请求设置为5元组，而权限列表和通道列表最初为空。
The server chooses a relayed transport address for the allocation as follows:
服务器为分配选择中继传输地址，如下所示：
o If the request contains a RESERVATION-TOKEN, the server uses the previously reserved transport address corresponding to the included token (if it is still available). Note that the reservation is a server-wide reservation and is not specific to a particular allocation, since the Allocate request containing the RESERVATION-TOKEN uses a different 5-tuple than the Allocate request that made the reservation. The 5-tuple for the Allocate
o 如果请求包含保留令牌，服务器将使用与包含的令牌相对应的先前保留的传输地址（如果它仍然可用）。请注意，保留是服务器范围的保留，并不特定于特定的分配，因为包含保留令牌的分配请求使用的5元组与进行保留的分配请求不同。用于分配的5元组
request containing the RESERVATION-TOKEN attribute can be any allowed 5-tuple; it can use a different client IP address and port, a different transport protocol, and even different server IP address and port (provided, of course, that the server IP address and port are ones on which the server is listening for TURN requests).
包含RESERVATION-TOKEN属性的请求可以是任何允许的5元组；它可以使用不同的客户端IP地址和端口、不同的传输协议，甚至不同的服务器IP地址和端口（当然，前提是服务器IP地址和端口是服务器侦听TURN请求的IP地址和端口）。
o If the request contains an EVEN-PORT attribute with the R bit set to 0, then the server allocates a relayed transport address with an even port number.
o 如果请求包含R位设置为0的偶数端口属性，则服务器将分配偶数端口号的中继传输地址。
o If the request contains an EVEN-PORT attribute with the R bit set to 1, then the server looks for a pair of port numbers N and N+1 on the same IP address, where N is even. Port N is used in the current allocation, while the relayed transport address with port N+1 is assigned a token and reserved for a future allocation. The server MUST hold this reservation for at least 30 seconds, and MAY choose to hold longer (e.g., until the allocation with port N expires). The server then includes the token in a RESERVATION-TOKEN attribute in the success response.
o 如果请求包含一个偶数端口属性，且R位设置为1，则服务器会在同一IP地址上查找一对端口号N和N+1，其中N为偶数。端口N用于当前分配，而端口N+1的中继传输地址被分配一个令牌，并保留用于将来的分配。服务器必须保持此保留至少30秒，并且可以选择保持更长时间（例如，直到端口N的分配过期）。然后，服务器在成功响应的RESERVATION-token属性中包含令牌。
o Otherwise, the server allocates any available relayed transport address.
o 否则，服务器将分配任何可用的中继传输地址。
In all cases, the server SHOULD only allocate ports from the range 49152 - 65535 (the Dynamic and/or Private Port range [Port-Numbers]), unless the TURN server application knows, through some means not specified here, that other applications running on the same host as the TURN server application will not be impacted by allocating ports outside this range. This condition can often be satisfied by running the TURN server application on a dedicated machine and/or by arranging that any other applications on the machine allocate ports before the TURN server application starts. In any case, the TURN server SHOULD NOT allocate ports in the range 0 - 1023 (the Well-Known Port range) to discourage clients from using TURN to run standard services.
在所有情况下，服务器应仅分配范围为49152-65535（动态和/或专用端口范围[端口号]）的端口，除非TURN服务器应用程序通过此处未指定的某种方式知道，与TURN server应用程序在同一主机上运行的其他应用程序不会因分配此范围之外的端口而受到影响。通过在专用机器上运行TURN server应用程序和/或安排机器上的任何其他应用程序在TURN server应用程序启动之前分配端口，通常可以满足此条件。在任何情况下，TURN服务器都不应分配范围为0-1023（众所周知的端口范围）的端口，以阻止客户端使用TURN来运行标准服务。
NOTE: The IETF is currently investigating the topic of randomized port assignments to avoid certain types of attacks (see [TSVWG-PORT]). It is strongly recommended that a TURN implementor keep abreast of this topic and, if appropriate, implement a randomized port assignment algorithm. This is especially applicable to servers that choose to pre-allocate a number of ports from the underlying OS and then later assign them to allocations; for example, a server may choose this technique to implement the EVEN-PORT attribute.
注：IETF目前正在研究随机端口分配的主题，以避免某些类型的攻击（参见[TSVWG-port]）。强烈建议TURN实施者了解此主题，并在适当的情况下实施随机端口分配算法。这尤其适用于选择从底层操作系统预分配多个端口，然后再将它们分配给分配的服务器；例如，服务器可以选择此技术来实现偶数端口属性。
The server determines the initial value of the time-to-expiry field as follows. If the request contains a LIFETIME attribute, then the server computes the minimum of the client's proposed lifetime and the server's maximum allowed lifetime. If this computed value is greater than the default lifetime, then the server uses the computed lifetime as the initial value of the time-to-expiry field. Otherwise, the server uses the default lifetime. It is RECOMMENDED that the server use a maximum allowed lifetime value of no more than 3600 seconds (1 hour). Servers that implement allocation quotas or charge users for allocations in some way may wish to use a smaller maximum allowed lifetime (perhaps as small as the default lifetime) to more quickly remove orphaned allocations (that is, allocations where the corresponding client has crashed or terminated or the client connection has been lost for some reason). Also, note that the time-to-expiry is recomputed with each successful Refresh request, and thus the value computed here applies only until the first refresh.
服务器确定到期时间字段的初始值，如下所示。如果请求包含生存期属性，则服务器将计算客户端建议的最小生存期和服务器允许的最大生存期。如果此计算值大于默认生存期，则服务器使用计算的生存期作为到期时间字段的初始值。否则，服务器将使用默认生存期。建议服务器使用的最大允许生存期值不超过3600秒（1小时）。实施分配配额或以某种方式向用户收取分配费用的服务器可能希望使用较小的最大允许生存期（可能与默认生存期一样小）来更快地删除孤立的分配（也就是说，在相应的客户端崩溃或终止或客户端连接因某种原因丢失的情况下进行分配）。此外，请注意，每次成功的刷新请求都会重新计算到期时间，因此此处计算的值仅适用于第一次刷新。
Once the allocation is created, the server replies with a success response. The success response contains:
创建分配后，服务器将以成功响应进行响应。成功响应包括：
o An XOR-RELAYED-ADDRESS attribute containing the relayed transport address.
o 包含中继传输地址的XOR中继地址属性。
o A LIFETIME attribute containing the current value of the time-to-expiry timer.
o 包含到期时间计时器当前值的生存期属性。
o A RESERVATION-TOKEN attribute (if a second relayed transport address was reserved).
o 保留令牌属性（如果保留了第二个中继传输地址）。
o An XOR-MAPPED-ADDRESS attribute containing the client's IP address and port (from the 5-tuple).
o 包含客户端IP地址和端口（来自5元组）的XOR映射地址属性。
NOTE: The XOR-MAPPED-ADDRESS attribute is included in the response as a convenience to the client. TURN itself does not make use of this value, but clients running ICE can often need this value and can thus avoid having to do an extra Binding transaction with some STUN server to learn it.
注意：响应中包含XOR-MAPPED-ADDRESS属性是为了方便客户端。TURN本身不使用该值，但运行ICE的客户端通常需要该值，因此可以避免与某些STUN服务器进行额外的绑定事务来学习该值。
The response (either success or error) is sent back to the client on the 5-tuple.
响应（成功或错误）通过5元组发送回客户端。
NOTE: When the Allocate request is sent over UDP, section 7.3.1 of [RFC5389] requires that the server handle the possible retransmissions of the request so that retransmissions do not cause multiple allocations to be created. Implementations may achieve this using the so-called "stateless stack approach" as follows. To detect retransmissions when the original request was successful in creating an allocation, the server can store the
注意：当通过UDP发送分配请求时，[RFC5389]的第7.3.1节要求服务器处理可能的请求重传，以便重传不会导致创建多个分配。实现可以使用所谓的“无状态堆栈方法”实现这一点，如下所示。要在原始请求成功创建分配时检测重传，服务器可以存储
transaction id that created the request with the allocation data and compare it with incoming Allocate requests on the same 5-tuple. Once such a request is detected, the server can stop parsing the request and immediately generate a success response. When building this response, the value of the LIFETIME attribute can be taken from the time-to-expiry field in the allocate state data, even though this value may differ slightly from the LIFETIME value originally returned. In addition, the server may need to store an indication of any reservation token returned in the original response, so that this may be returned in any retransmitted responses.
使用分配数据创建请求并将其与相同5元组上的传入分配请求进行比较的事务id。一旦检测到这样的请求，服务器就可以停止解析请求并立即生成成功响应。构建此响应时，可以从分配状态数据中的“到期时间”字段中获取LIFETIME属性的值，即使该值可能与最初返回的LIFETIME值略有不同。此外，服务器可能需要存储原始响应中返回的任何保留令牌的指示，以便可以在任何重新传输的响应中返回该标记。
For the case where the original request was unsuccessful in creating an allocation, the server may choose to do nothing special. Note, however, that there is a rare case where the server rejects the original request but accepts the retransmitted request (because conditions have changed in the brief intervening time period). If the client receives the first failure response, it will ignore the second (success) response and believe that an allocation was not created. An allocation created in this matter will eventually timeout, since the client will not refresh it. Furthermore, if the client later retries with the same 5-tuple but different transaction id, it will receive a 437 (Allocation Mismatch), which will cause it to retry with a different 5-tuple. The server may use a smaller maximum lifetime value to minimize the lifetime of allocations "orphaned" in this manner.
对于原始请求在创建分配时失败的情况，服务器可以选择不执行任何特殊操作。但是，请注意，服务器拒绝原始请求但接受重新传输的请求的情况很少（因为在短暂的中间时间段内条件发生了变化）。如果客户端收到第一个失败响应，它将忽略第二个（成功）响应，并认为未创建分配。在此事件中创建的分配最终将超时，因为客户端不会刷新它。此外，如果客户端稍后使用相同的5元组但不同的事务id重试，它将收到437（分配不匹配），这将导致它使用不同的5元组重试。服务器可以使用较小的最大生存期值来以这种方式最小化“孤立”分配的生存期。
If the client receives an Allocate success response, then it MUST check that the mapped address and the relayed transport address are in an address family that the client understands and is prepared to handle. This specification only covers the case where these two addresses are IPv4 addresses. If these two addresses are not in an address family which the client is prepared to handle, then the client MUST delete the allocation (Section 7) and MUST NOT attempt to create another allocation on that server until it believes the mismatch has been fixed.
如果客户端收到分配成功响应，则必须检查映射地址和中继传输地址是否位于客户端理解并准备处理的地址族中。本规范仅涵盖这两个地址为IPv4地址的情况。如果这两个地址不在客户机准备处理的地址族中，则客户机必须删除分配（第7节），并且在认为不匹配已修复之前，不得尝试在该服务器上创建另一个分配。
The IETF is currently considering mechanisms for transitioning between IPv4 and IPv6 that could result in a client originating an Allocate request over IPv6, but the request would arrive at the server over IPv4, or vice versa.
IETF目前正在考虑在IPv4和IPv6之间转换的机制，这可能导致客户端通过IPv6发起分配请求，但请求将通过IPv4到达服务器，反之亦然。
Otherwise, the client creates its own copy of the allocation data structure to track what is happening on the server. In particular, the client needs to remember the actual lifetime received back from the server, rather than the value sent to the server in the request.
否则，客户端将创建自己的分配数据结构副本，以跟踪服务器上发生的情况。特别是，客户机需要记住从服务器返回的实际生存期，而不是请求中发送给服务器的值。
The client must also remember the 5-tuple used for the request and the username and password it used to authenticate the request to ensure that it reuses them for subsequent messages. The client also needs to track the channels and permissions it establishes on the server.
客户端还必须记住用于请求的5元组以及用于验证请求的用户名和密码，以确保在后续消息中重用它们。客户端还需要跟踪它在服务器上建立的通道和权限。
The client will probably wish to send the relayed transport address to peers (using some method not specified here) so the peers can communicate with it. The client may also wish to use the server-reflexive address it receives in the XOR-MAPPED-ADDRESS attribute in its ICE processing.
客户端可能希望将中继传输地址发送给对等方（使用此处未指定的某种方法），以便对等方可以与其通信。客户机还可能希望在其ICE处理中使用其在XOR-MAPPED-address属性中接收的服务器自反地址。
If the client receives an Allocate error response, then the processing depends on the actual error code returned:
如果客户端收到分配错误响应，则处理取决于返回的实际错误代码：
o (Request timed out): There is either a problem with the server, or a problem reaching the server with the chosen transport. The client considers the current transaction as having failed but MAY choose to retry the Allocate request using a different transport (e.g., TCP instead of UDP).
o （请求超时）：服务器出现问题，或者使用所选传输到达服务器时出现问题。客户端认为当前事务失败，但可以选择使用其他传输（例如TCP而不是UDP）重试分配请求。
o 300 (Try Alternate): The server would like the client to use the server specified in the ALTERNATE-SERVER attribute instead. The client considers the current transaction as having failed, but SHOULD try the Allocate request with the alternate server before trying any other servers (e.g., other servers discovered using the SRV procedures). When trying the Allocate request with the alternate server, the client follows the ALTERNATE-SERVER procedures specified in [RFC5389].
o 300（Try Alternate）：服务器希望客户端改用Alternate-server属性中指定的服务器。客户端认为当前事务已失败，但在尝试任何其他服务器（例如，使用SRV过程发现的其他服务器）之前，应先尝试使用备用服务器分配请求。在使用备用服务器尝试分配请求时，客户端遵循[RFC5389]中指定的备用服务器过程。
o 400 (Bad Request): The server believes the client's request is malformed for some reason. The client considers the current transaction as having failed. The client MAY notify the user or operator and SHOULD NOT retry the request with this server until it believes the problem has been fixed.
o 400（错误请求）：服务器认为客户端的请求由于某种原因存在格式错误。客户端认为当前事务已失败。客户端可能会通知用户或操作员，并且在认为问题已解决之前，不应使用此服务器重试请求。
o 401 (Unauthorized): If the client has followed the procedures of the long-term credential mechanism and still gets this error, then the server is not accepting the client's credentials. In this case, the client considers the current transaction as having failed and SHOULD notify the user or operator. The client SHOULD NOT send any further requests to this server until it believes the problem has been fixed.
o 401（Unauthorized）：如果客户端遵循了长期凭据机制的过程，但仍然出现此错误，则服务器不接受客户端的凭据。在这种情况下，客户端认为当前事务失败，应通知用户或操作员。在客户端认为问题已解决之前，不应向该服务器发送任何进一步的请求。
o 403 (Forbidden): The request is valid, but the server is refusing to perform it, likely due to administrative restrictions. The client considers the current transaction as having failed. The client MAY notify the user or operator and SHOULD NOT retry the same request with this server until it believes the problem has been fixed.
o 403（禁止）：请求有效，但服务器拒绝执行该请求，可能是由于管理限制。客户端认为当前事务已失败。客户端可能会通知用户或操作员，并且在认为问题已解决之前，不应在此服务器上重试相同的请求。
o 420 (Unknown Attribute): If the client included a DONT-FRAGMENT attribute in the request and the server rejected the request with a 420 error code and listed the DONT-FRAGMENT attribute in the UNKNOWN-ATTRIBUTES attribute in the error response, then the client now knows that the server does not support the DONT-FRAGMENT attribute. The client considers the current transaction as having failed but MAY choose to retry the Allocate request without the DONT-FRAGMENT attribute.
o 420（未知属性）：如果客户端在请求中包含一个DONT-FRAGMENT属性，而服务器以420错误代码拒绝了请求，并在错误响应中的Unknown-ATTRIBUTES属性中列出了DONT-FRAGMENT属性，则客户端现在知道服务器不支持don-FRAGMENT属性。客户端认为当前事务失败，但可以选择在不使用DONT-FRAGMENT属性的情况下重试分配请求。
o 437 (Allocation Mismatch): This indicates that the client has picked a 5-tuple that the server sees as already in use. One way this could happen is if an intervening NAT assigned a mapped transport address that was used by another client that recently crashed. The client considers the current transaction as having failed. The client SHOULD pick another client transport address and retry the Allocate request (using a different transaction id). The client SHOULD try three different client transport addresses before giving up on this server. Once the client gives up on the server, it SHOULD NOT try to create another allocation on the server for 2 minutes.
o 437（分配不匹配）：这表示客户机选择了一个5元组，服务器认为该5元组已经在使用中。一种可能发生这种情况的方法是，如果介入NAT分配了一个映射的传输地址，该地址由最近崩溃的另一个客户端使用。客户端认为当前事务已失败。客户端应选择另一个客户端传输地址，然后重试分配请求（使用不同的事务id）。在放弃此服务器之前，客户端应尝试三个不同的客户端传输地址。一旦客户机放弃在服务器上的分配，2分钟内不应尝试在服务器上创建另一个分配。
o 438 (Stale Nonce): See the procedures for the long-term credential mechanism [RFC5389].
o 438（失效当前）：请参阅长期凭证机制的过程[RFC5389]。
o 441 (Wrong Credentials): The client should not receive this error in response to a Allocate request. The client MAY notify the user or operator and SHOULD NOT retry the same request with this server until it believes the problem has been fixed.
o 441（错误凭据）：客户端不应在响应分配请求时收到此错误。客户端可能会通知用户或操作员，并且在认为问题已解决之前，不应在此服务器上重试相同的请求。
o 442 (Unsupported Transport Address): The client should not receive this error in response to a request for a UDP allocation. The client MAY notify the user or operator and SHOULD NOT reattempt the request with this server until it believes the problem has been fixed.
o 442（不支持的传输地址）：客户端不应在响应UDP分配请求时收到此错误。客户端可能会通知用户或操作员，并且在认为问题已解决之前，不应使用此服务器重新尝试请求。
o 486 (Allocation Quota Reached): The server is currently unable to create any more allocations with this username. The client considers the current transaction as having failed. The client SHOULD wait at least 1 minute before trying to create any more allocations on the server.
o 486（已达到分配配额）：服务器当前无法使用此用户名创建更多分配。客户端认为当前事务已失败。在尝试在服务器上创建更多分配之前，客户端应至少等待1分钟。
o 508 (Insufficient Capacity): The server has no more relayed transport addresses available, or has none with the requested properties, or the one that was reserved is no longer available. The client considers the current operation as having failed. If the client is using either the EVEN-PORT or the RESERVATION-TOKEN attribute, then the client MAY choose to remove or modify this attribute and try again immediately. Otherwise, the client SHOULD wait at least 1 minute before trying to create any more allocations on this server.
o 508（容量不足）：服务器没有更多可用的中继传输地址，或者没有具有请求属性的中继传输地址，或者保留的传输地址不再可用。客户端认为当前操作已失败。如果客户端正在使用偶数端口或保留令牌属性，则客户端可以选择删除或修改此属性，然后立即重试。否则，客户端应至少等待1分钟，然后再尝试在此服务器上创建任何其他分配。
An unknown error response MUST be handled as described in [RFC5389].
必须按照[RFC5389]中的说明处理未知错误响应。
A Refresh transaction can be used to either (a) refresh an existing allocation and update its time-to-expiry or (b) delete an existing allocation.
刷新事务可用于（A）刷新现有分配并更新其到期时间，或（b）删除现有分配。
If a client wishes to continue using an allocation, then the client MUST refresh it before it expires. It is suggested that the client refresh the allocation roughly 1 minute before it expires. If a client no longer wishes to use an allocation, then it SHOULD explicitly delete the allocation. A client MAY refresh an allocation at any time for other reasons.
如果客户端希望继续使用分配，则客户端必须在分配过期之前刷新分配。建议客户端在分配到期前大约1分钟刷新分配。如果客户端不再希望使用分配，则应明确删除该分配。客户端可能会因为其他原因随时刷新分配。
If the client wishes to immediately delete an existing allocation, it includes a LIFETIME attribute with a value of 0. All other forms of the request refresh the allocation.
如果客户端希望立即删除现有分配，它将包含一个值为0的生存期属性。所有其他形式的请求刷新分配。
The Refresh transaction updates the time-to-expiry timer of an allocation. If the client wishes the server to set the time-to-expiry timer to something other than the default lifetime, it includes a LIFETIME attribute with the requested value. The server then computes a new time-to-expiry value in the same way as it does for an Allocate transaction, with the exception that a requested lifetime of 0 causes the server to immediately delete the allocation.
刷新事务更新分配的到期时间计时器。如果客户机希望服务器将到期时间计时器设置为默认生存期以外的值，则它将包含一个具有请求值的生存期属性。然后，服务器以与分配事务相同的方式计算新的到期时间值，但请求的生存期为0会导致服务器立即删除分配。
When the server receives a Refresh request, it processes as per Section 4 plus the specific rules mentioned here.
当服务器收到刷新请求时，它将按照第4节以及此处提到的特定规则进行处理。
The server computes a value called the "desired lifetime" as follows: if the request contains a LIFETIME attribute and the attribute value is 0, then the "desired lifetime" is 0. Otherwise, if the request contains a LIFETIME attribute, then the server computes the minimum
服务器计算一个名为“期望生存期”的值，如下所示：如果请求包含生存期属性且属性值为0，则“期望生存期”为0。否则，如果请求包含生存期属性，则服务器将计算最小值
of the client's requested lifetime and the server's maximum allowed lifetime. If this computed value is greater than the default lifetime, then the "desired lifetime" is the computed value. Otherwise, the "desired lifetime" is the default lifetime.
客户端请求的生存期和服务器允许的最大生存期。如果此计算值大于默认寿命，则“期望寿命”为计算值。否则，“期望寿命”是默认寿命。
Subsequent processing depends on the "desired lifetime" value:
后续处理取决于“期望寿命”值：
o If the "desired lifetime" is 0, then the request succeeds and the allocation is deleted.
o 如果“期望寿命”为0，则请求成功，分配被删除。
o If the "desired lifetime" is non-zero, then the request succeeds and the allocation's time-to-expiry is set to the "desired lifetime".
o 如果“期望寿命”非零，则请求成功，分配的到期时间设置为“期望寿命”。
If the request succeeds, then the server sends a success response containing:
如果请求成功，则服务器将发送一个成功响应，其中包含：
o A LIFETIME attribute containing the current value of the time-to-expiry timer.
o 包含到期时间计时器当前值的生存期属性。
NOTE: A server need not do anything special to implement idempotency of Refresh requests over UDP using the "stateless stack approach". Retransmitted Refresh requests with a non-zero "desired lifetime" will simply refresh the allocation. A retransmitted Refresh request with a zero "desired lifetime" will cause a 437 (Allocation Mismatch) response if the allocation has already been deleted, but the client will treat this as equivalent to a success response (see below).
注意：使用“无状态堆栈方法”，服务器无需执行任何特殊操作即可通过UDP实现刷新请求的幂等性。具有非零“期望生存期”的重传刷新请求将只是刷新分配。如果分配已被删除，则“期望生存期”为零的重新传输刷新请求将导致437（分配不匹配）响应，但客户端将将其视为成功响应（见下文）。
If the client receives a success response to its Refresh request with a non-zero lifetime, it updates its copy of the allocation data structure with the time-to-expiry value contained in the response.
如果客户端接收到对其刷新请求的非零生存期的成功响应，它将使用响应中包含的到期时间值更新其分配数据结构副本。
If the client receives a 437 (Allocation Mismatch) error response to a request to delete the allocation, then the allocation no longer exists and it should consider its request as having effectively succeeded.
如果客户端接收到对删除分配请求的437（分配不匹配）错误响应，则分配不再存在，并且应该考虑其请求作为有效的成功。
For each allocation, the server keeps a list of zero or more permissions. Each permission consists of an IP address and an associated time-to-expiry. While a permission exists, all peers using the IP address in the permission are allowed to send data to
对于每个分配，服务器都会保留一个包含零个或多个权限的列表。每个权限由一个IP地址和相关的到期时间组成。当权限存在时，所有使用该权限中的IP地址的对等方都可以向发送数据
the client. The time-to-expiry is the number of seconds until the permission expires. Within the context of an allocation, a permission is uniquely identified by its associated IP address.
客户。到期时间是权限到期前的秒数。在分配上下文中，权限由其关联的IP地址唯一标识。
By sending either CreatePermission requests or ChannelBind requests, the client can cause the server to install or refresh a permission for a given IP address. This causes one of two things to happen:
通过发送CreatePermission请求或ChannelBind请求，客户端可以使服务器安装或刷新给定IP地址的权限。这会导致以下两种情况之一：
o If no permission for that IP address exists, then a permission is created with the given IP address and a time-to-expiry equal to Permission Lifetime.
o 如果不存在该IP地址的权限，则将使用给定的IP地址创建权限，其过期时间等于权限生存期。
o If a permission for that IP address already exists, then the time-to-expiry for that permission is reset to Permission Lifetime.
o 如果该IP地址的权限已存在，则该权限的过期时间将重置为权限生存期。
The Permission Lifetime MUST be 300 seconds (= 5 minutes).
权限生存期必须为300秒（=5分钟）。
Each permission's time-to-expiry decreases down once per second until it reaches 0; at which point, the permission expires and is deleted.
每个权限的到期时间每秒减少一次，直到达到0；此时，权限过期并被删除。
CreatePermission and ChannelBind requests may be freely intermixed on a permission. A given permission may be initially installed and/or refreshed with a CreatePermission request, and then later refreshed with a ChannelBind request, or vice versa.
CreatePermission和ChannelBind请求可以在权限上自由混合。给定的权限最初可以通过CreatePermission请求安装和/或刷新，然后通过ChannelBind请求刷新，反之亦然。
When a UDP datagram arrives at the relayed transport address for the allocation, the server extracts the source IP address from the IP header. The server then compares this address with the IP address associated with each permission in the list of permissions for the allocation. If no match is found, relaying is not permitted, and the server silently discards the UDP datagram. If an exact match is found, then the permission check is considered to have succeeded and the server continues to process the UDP datagram as specified elsewhere (Section 10.3). Note that only addresses are compared and port numbers are not considered.
当UDP数据报到达分配的中继传输地址时，服务器从IP报头提取源IP地址。然后，服务器将此地址与分配权限列表中与每个权限关联的IP地址进行比较。如果未找到匹配项，则不允许中继，并且服务器会自动丢弃UDP数据报。如果发现完全匹配，则认为权限检查已成功，服务器将继续处理其他地方指定的UDP数据报（第10.3节）。请注意，只比较地址，不考虑端口号。
The permissions for one allocation are totally unrelated to the permissions for a different allocation. If an allocation expires, all its permissions expire with it.
一个分配的权限与另一个分配的权限完全无关。如果分配过期，则其所有权限也随之过期。
NOTE: Though TURN permissions expire after 5 minutes, many NATs deployed at the time of publication expire their UDP bindings considerably faster. Thus, an application using TURN will probably wish to send some sort of keep-alive traffic at a much faster rate. Applications using ICE should follow the keep-alive guidelines of ICE [RFC5245], and applications not using ICE are advised to do something similar.
注意：尽管TURN权限在5分钟后过期，但发布时部署的许多NAT的UDP绑定过期速度要快得多。因此，使用TURN的应用程序可能希望以更快的速度发送某种保持活动的流量。使用ICE的应用程序应遵循ICE[RFC5245]的保持活动指南，不使用ICE的应用程序建议执行类似操作。
TURN supports two ways for the client to install or refresh permissions on the server. This section describes one way: the CreatePermission request.
TURN支持客户端在服务器上安装或刷新权限的两种方式。本节介绍一种方法：CreatePermission请求。
A CreatePermission request may be used in conjunction with either the Send mechanism in Section 10 or the Channel mechanism in Section 11.
CreatePermission请求可与第10节中的发送机制或第11节中的通道机制结合使用。
The client who wishes to install or refresh one or more permissions can send a CreatePermission request to the server.
希望安装或刷新一个或多个权限的客户端可以向服务器发送CreatePermission请求。
When forming a CreatePermission request, the client MUST include at least one XOR-PEER-ADDRESS attribute, and MAY include more than one such attribute. The IP address portion of each XOR-PEER-ADDRESS attribute contains the IP address for which a permission should be installed or refreshed. The port portion of each XOR-PEER-ADDRESS attribute will be ignored and can be any arbitrary value. The various XOR-PEER-ADDRESS attributes can appear in any order.
当形成CreatePermission请求时，客户端必须包括至少一个XOR-PEER-ADDRESS属性，并且可以包括多个这样的属性。每个XOR-PEER-address属性的IP地址部分包含应该为其安装或刷新权限的IP地址。每个XOR-PEER-ADDRESS属性的端口部分将被忽略，可以是任意值。各种XOR-PEER-ADDRESS属性可以以任何顺序出现。
When the server receives the CreatePermission request, it processes as per Section 4 plus the specific rules mentioned here.
当服务器收到CreatePermission请求时，它将按照第4节以及此处提到的特定规则进行处理。
The message is checked for validity. The CreatePermission request MUST contain at least one XOR-PEER-ADDRESS attribute and MAY contain multiple such attributes. If no such attribute exists, or if any of these attributes are invalid, then a 400 (Bad Request) error is returned. If the request is valid, but the server is unable to satisfy the request due to some capacity limit or similar, then a 508 (Insufficient Capacity) error is returned.
检查消息的有效性。CreatePermission请求必须至少包含一个XOR-PEER-ADDRESS属性，并且可以包含多个此类属性。如果不存在此类属性，或者这些属性中的任何一个无效，则返回400（错误请求）错误。如果请求有效，但服务器由于某些容量限制或类似原因无法满足请求，则返回508（容量不足）错误。
The server MAY impose restrictions on the IP address allowed in the XOR-PEER-ADDRESS attribute -- if a value is not allowed, the server rejects the request with a 403 (Forbidden) error.
服务器可能会对XOR-PEER-address属性中允许的IP地址施加限制——如果不允许某个值，则服务器会以403（禁止）错误拒绝请求。
If the message is valid and the server is capable of carrying out the request, then the server installs or refreshes a permission for the IP address contained in each XOR-PEER-ADDRESS attribute as described in Section 8. The port portion of each attribute is ignored and may be any arbitrary value.
如果消息有效且服务器能够执行请求，则服务器会安装或刷新每个XOR-PEER-address属性中包含的IP地址权限，如第8节所述。每个属性的端口部分都会被忽略，可以是任意值。
The server then responds with a CreatePermission success response. There are no mandatory attributes in the success response.
然后，服务器以CreatePermission成功响应进行响应。成功响应中没有强制属性。
NOTE: A server need not do anything special to implement idempotency of CreatePermission requests over UDP using the "stateless stack approach". Retransmitted CreatePermission requests will simply refresh the permissions.
注意：使用“无状态堆栈方法”，服务器无需执行任何特殊操作即可通过UDP实现CreatePermission请求的幂等性。重新传输的CreatePermission请求只会刷新权限。
If the client receives a valid CreatePermission success response, then the client updates its data structures to indicate that the permissions have been installed or refreshed.
如果客户端收到有效的CreatePermission成功响应，则客户端将更新其数据结构，以指示权限已安装或刷新。
TURN supports two mechanisms for sending and receiving data from peers. This section describes the use of the Send and Data mechanisms, while Section 11 describes the use of the Channel mechanism.
TURN支持两种从对等方发送和接收数据的机制。本节介绍发送和数据机制的使用，而第11节介绍通道机制的使用。
The client can use a Send indication to pass data to the server for relaying to a peer. A client may use a Send indication even if a channel is bound to that peer. However, the client MUST ensure that there is a permission installed for the IP address of the peer to which the Send indication is being sent; this prevents a third party from using a TURN server to send data to arbitrary destinations.
客户端可以使用发送指示将数据传递到服务器，以便中继到对等方。即使信道绑定到对等方，客户端也可以使用发送指示。但是，客户端必须确保为发送指示的对等方的IP地址安装了权限；这可防止第三方使用TURN服务器向任意目的地发送数据。
When forming a Send indication, the client MUST include an XOR-PEER-ADDRESS attribute and a DATA attribute. The XOR-PEER-ADDRESS attribute contains the transport address of the peer to which the data is to be sent, and the DATA attribute contains the actual application data to be sent to the peer.
形成发送指示时，客户端必须包括XOR-PEER-ADDRESS属性和数据属性。XOR-PEER-ADDRESS属性包含将数据发送到的对等方的传输地址，data属性包含将发送到对等方的实际应用程序数据。
The client MAY include a DONT-FRAGMENT attribute in the Send indication if it wishes the server to set the DF bit on the UDP datagram sent to the peer.
如果客户端希望服务器在发送给对等方的UDP数据报上设置DF位，则可以在发送指示中包含DONT-FRAGMENT属性。
When the server receives a Send indication, it processes as per Section 4 plus the specific rules mentioned here.
当服务器收到发送指示时，它将按照第4节以及此处提到的特定规则进行处理。
The message is first checked for validity. The Send indication MUST contain both an XOR-PEER-ADDRESS attribute and a DATA attribute. If one of these attributes is missing or invalid, then the message is discarded. Note that the DATA attribute is allowed to contain zero bytes of data.
首先检查消息的有效性。发送指示必须同时包含XOR-PEER-ADDRESS属性和数据属性。如果其中一个属性丢失或无效，则丢弃该消息。请注意，DATA属性允许包含零字节的数据。
The Send indication may also contain the DONT-FRAGMENT attribute. If the server is unable to set the DF bit on outgoing UDP datagrams when this attribute is present, then the server acts as if the DONT-FRAGMENT attribute is an unknown comprehension-required attribute (and thus the Send indication is discarded).
发送指示也可能包含DONT-FRAGMENT属性。如果存在此属性时，服务器无法在传出UDP数据报上设置DF位，则服务器的行为就好像DONT-FRAGMENT属性是未知的理解必需属性一样（因此，发送指示被丢弃）。
The server also checks that there is a permission installed for the IP address contained in the XOR-PEER-ADDRESS attribute. If no such permission exists, the message is discarded. Note that a Send indication never causes the server to refresh the permission.
服务器还检查是否为XOR-PEER-address属性中包含的IP地址安装了权限。如果不存在此类权限，则丢弃该消息。请注意，发送指示不会导致服务器刷新权限。
The server MAY impose restrictions on the IP address and port values allowed in the XOR-PEER-ADDRESS attribute -- if a value is not allowed, the server silently discards the Send indication.
服务器可能会对XOR-PEER-address属性中允许的IP地址和端口值施加限制——如果不允许某个值，服务器会自动放弃发送指示。
If everything is OK, then the server forms a UDP datagram as follows:
如果一切正常，则服务器将形成一个UDP数据报，如下所示：
o the source transport address is the relayed transport address of the allocation, where the allocation is determined by the 5-tuple on which the Send indication arrived;
o 源传输地址是分配的中继传输地址，其中分配由发送指示到达的5元组确定；
o the destination transport address is taken from the XOR-PEER-ADDRESS attribute;
o 目标传输地址取自XOR-PEER-address属性；
o the data following the UDP header is the contents of the value field of the DATA attribute.
o UDP标头后面的数据是数据属性的值字段的内容。
The handling of the DONT-FRAGMENT attribute (if present), is described in Section 12.
DONT-FRAGMENT属性（如果存在）的处理在第12节中描述。
The resulting UDP datagram is then sent to the peer.
然后将生成的UDP数据报发送给对等方。
When the server receives a UDP datagram at a currently allocated relayed transport address, the server looks up the allocation associated with the relayed transport address. The server then checks to see whether the set of permissions for the allocation allow the relaying of the UDP datagram as described in Section 8.
当服务器在当前分配的中继传输地址接收到UDP数据报时，服务器将查找与中继传输地址关联的分配。然后，服务器检查分配权限集是否允许如第8节所述中继UDP数据报。
If relaying is permitted, then the server checks if there is a channel bound to the peer that sent the UDP datagram (see Section 11). If a channel is bound, then processing proceeds as described in Section 11.7.
如果允许中继，则服务器将检查是否存在绑定到发送UDP数据报的对等方的通道（请参阅第11节）。如果通道被绑定，则处理将按照第11.7节所述进行。
If relaying is permitted but no channel is bound to the peer, then the server forms and sends a Data indication. The Data indication MUST contain both an XOR-PEER-ADDRESS and a DATA attribute. The DATA
如果允许中继，但没有通道绑定到对等方，则服务器形成并发送数据指示。数据指示必须同时包含XOR对等地址和数据属性。数据
attribute is set to the value of the 'data octets' field from the datagram, and the XOR-PEER-ADDRESS attribute is set to the source transport address of the received UDP datagram. The Data indication is then sent on the 5-tuple associated with the allocation.
属性设置为数据报中“数据八位字节”字段的值，XOR-PEER-ADDRESS属性设置为接收到的UDP数据报的源传输地址。然后在与分配相关联的5元组上发送数据指示。
When the client receives a Data indication, it checks that the Data indication contains both an XOR-PEER-ADDRESS and a DATA attribute, and discards the indication if it does not. The client SHOULD also check that the XOR-PEER-ADDRESS attribute value contains an IP address with which the client believes there is an active permission, and discard the Data indication otherwise. Note that the DATA attribute is allowed to contain zero bytes of data.
当客户端接收到数据指示时，它会检查该数据指示是否同时包含XOR-PEER地址和数据属性，如果不包含，则丢弃该指示。客户端还应检查XOR-PEER-ADDRESS属性值是否包含客户端认为存在活动权限的IP地址，否则将放弃数据指示。请注意，DATA属性允许包含零字节的数据。
NOTE: The latter check protects the client against an attacker who somehow manages to trick the server into installing permissions not desired by the client.
注意：后一项检查保护客户端免受攻击者的攻击，攻击者以某种方式设法诱使服务器安装客户端不需要的权限。
If the Data indication passes the above checks, the client delivers the data octets inside the DATA attribute to the application, along with an indication that they were received from the peer whose transport address is given by the XOR-PEER-ADDRESS attribute.
如果数据指示通过了上述检查，则客户机将数据属性中的数据八位字节传递给应用程序，并指示它们是从传输地址由XOR-peer-address属性给定的对等方接收的。
Channels provide a way for the client and server to send application data using ChannelData messages, which have less overhead than Send and Data indications.
通道为客户端和服务器提供了一种使用ChannelData消息发送应用程序数据的方法，该消息的开销比发送和数据指示要小。
The ChannelData message (see Section 11.4) starts with a two-byte field that carries the channel number. The values of this field are allocated as follows:
ChannelData消息（见第11.4节）以一个双字节字段开始，该字段携带通道号。该字段的值分配如下：
0x0000 through 0x3FFF: These values can never be used for channel numbers.
0x0000到0x3FFF：这些值永远不能用于通道号。
0x4000 through 0x7FFF: These values are the allowed channel numbers (16,383 possible values).
0x4000到0x7FFF：这些值是允许的通道号（16383个可能值）。
0x8000 through 0xFFFF: These values are reserved for future use.
0x8000到0xFFFF：这些值保留供将来使用。
Because of this division, ChannelData messages can be distinguished from STUN-formatted messages (e.g., Allocate request, Send indication, etc.) by examining the first two bits of the message:
由于这种划分，通过检查消息的前两位，可以将ChannelData消息与STUN格式的消息（例如，分配请求、发送指示等）区分开来：
0b00: STUN-formatted message (since the first two bits of a STUN-formatted message are always zero).
0b00:STUN格式消息（因为STUN格式消息的前两位始终为零）。
0b01: ChannelData message (since the channel number is the first field in the ChannelData message and channel numbers fall in the range 0x4000 - 0x7FFF).
0b01:ChannelData消息（因为通道号是ChannelData消息中的第一个字段，通道号在0x4000-0x7FFF范围内）。
0b10: Reserved
0b10:保留
0b11: Reserved
0b11:保留
The reserved values may be used in the future to extend the range of channel numbers. Thus, an implementation MUST NOT assume that a TURN message always starts with a 0 bit.
保留值将来可用于扩展信道号的范围。因此，一个实现不能假设一个转向消息总是以0位开始。
Channel bindings are always initiated by the client. The client can bind a channel to a peer at any time during the lifetime of the allocation. The client may bind a channel to a peer before exchanging data with it, or after exchanging data with it (using Send and Data indications) for some time, or may choose never to bind a channel to it. The client can also bind channels to some peers while not binding channels to other peers.
通道绑定始终由客户端启动。客户端可以在分配生命周期内的任何时间将通道绑定到对等方。客户端可以在与对等方交换数据之前或在与对等方交换数据（使用发送和数据指示）一段时间之后将通道绑定到对等方，也可以选择从不将通道绑定到对等方。客户端还可以将通道绑定到某些对等方，而不将通道绑定到其他对等方。
Channel bindings are specific to an allocation, so that the use of a channel number or peer transport address in a channel binding in one allocation has no impact on their use in a different allocation. If an allocation expires, all its channel bindings expire with it.
通道绑定特定于分配，因此在一个分配中的通道绑定中使用通道号或对等传输地址不会影响它们在不同分配中的使用。如果分配过期，则其所有通道绑定也随之过期。
A channel binding consists of:
通道绑定包括：
o a channel number;
o 频道号；
o a transport address (of the peer); and
o （对等方的）传输地址；和
o A time-to-expiry timer.
o 到期时间计时器。
Within the context of an allocation, a channel binding is uniquely identified either by the channel number or by the peer's transport address. Thus, the same channel cannot be bound to two different transport addresses, nor can the same transport address be bound to two different channels.
在分配上下文中，通道绑定由通道号或对等方的传输地址唯一标识。因此，同一信道不能绑定到两个不同的传输地址，同一传输地址也不能绑定到两个不同的信道。
A channel binding lasts for 10 minutes unless refreshed. Refreshing the binding (by the server receiving a ChannelBind request rebinding the channel to the same peer) resets the time-to-expiry timer back to 10 minutes.
除非刷新，否则通道绑定将持续10分钟。刷新绑定（通过服务器接收到将通道重新绑定到同一对等方的ChannelBind请求）将到期时间计时器重置回10分钟。
When the channel binding expires, the channel becomes unbound. Once unbound, the channel number can be bound to a different transport address, and the transport address can be bound to a different channel number. To prevent race conditions, the client MUST wait 5
当通道绑定到期时，通道将解除绑定。一旦解除绑定，通道号可以绑定到不同的传输地址，并且传输地址可以绑定到不同的通道号。要防止竞争条件，客户端必须等待5分钟
minutes after the channel binding expires before attempting to bind the channel number to a different transport address or the transport address to a different channel number.
在尝试将通道号绑定到其他传输地址或将传输地址绑定到其他通道号之前，通道绑定过期后的分钟数。
When binding a channel to a peer, the client SHOULD be prepared to receive ChannelData messages on the channel from the server as soon as it has sent the ChannelBind request. Over UDP, it is possible for the client to receive ChannelData messages from the server before it receives a ChannelBind success response.
将通道绑定到对等方时，客户机应准备好在发送ChannelBind请求后立即从服务器接收通道上的ChannelData消息。通过UDP，客户端可以在收到ChannelBind成功响应之前从服务器接收ChannelData消息。
In the other direction, the client MAY elect to send ChannelData messages before receiving the ChannelBind success response. Doing so, however, runs the risk of having the ChannelData messages dropped by the server if the ChannelBind request does not succeed for some reason (e.g., packet lost if the request is sent over UDP, or the server being unable to fulfill the request). A client that wishes to be safe should either queue the data or use Send indications until the channel binding is confirmed.
在另一个方向上，客户端可以选择在接收ChannelBind成功响应之前发送ChannelData消息。但是，如果ChannelBind请求因某种原因未成功（例如，如果请求通过UDP发送，则数据包丢失，或者服务器无法完成请求），则这样做可能会导致服务器丢弃ChannelData消息。希望安全的客户端应将数据排队或使用发送指示，直到通道绑定得到确认。
A channel binding is created or refreshed using a ChannelBind transaction. A ChannelBind transaction also creates or refreshes a permission towards the peer (see Section 8).
使用ChannelBind事务创建或刷新通道绑定。ChannelBind事务还创建或刷新对对等方的权限（请参阅第8节）。
To initiate the ChannelBind transaction, the client forms a ChannelBind request. The channel to be bound is specified in a CHANNEL-NUMBER attribute, and the peer's transport address is specified in an XOR-PEER-ADDRESS attribute. Section 11.2 describes the restrictions on these attributes.
要启动ChannelBind事务，客户端将形成ChannelBind请求。要绑定的通道在channel-NUMBER属性中指定，对等方的传输地址在XOR-peer-address属性中指定。第11.2节描述了对这些属性的限制。
Rebinding a channel to the same transport address that it is already bound to provides a way to refresh a channel binding and the corresponding permission without sending data to the peer. Note however, that permissions need to be refreshed more frequently than channels.
将通道重新绑定到其已绑定到的相同传输地址提供了一种刷新通道绑定和相应权限的方法，而无需向对等方发送数据。但是请注意，权限需要比通道更频繁地刷新。
When the server receives a ChannelBind request, it processes as per Section 4 plus the specific rules mentioned here.
当服务器收到ChannelBind请求时，它将按照第4节以及此处提到的特定规则进行处理。
The server checks the following:
服务器将检查以下各项：
o The request contains both a CHANNEL-NUMBER and an XOR-PEER-ADDRESS attribute;
o 请求同时包含通道号和XOR对等地址属性；
o The channel number is in the range 0x4000 through 0x7FFE (inclusive);
o 通道号在0x4000至0x7FFE（含）范围内；
o The channel number is not currently bound to a different transport address (same transport address is OK);
o 通道号当前未绑定到不同的传输地址（相同的传输地址可以）；
o The transport address is not currently bound to a different channel number.
o 传输地址当前未绑定到其他通道号。
If any of these tests fail, the server replies with a 400 (Bad Request) error.
如果这些测试中的任何一个失败，服务器将返回400（错误请求）错误。
The server MAY impose restrictions on the IP address and port values allowed in the XOR-PEER-ADDRESS attribute -- if a value is not allowed, the server rejects the request with a 403 (Forbidden) error.
服务器可能会对XOR-PEER-address属性中允许的IP地址和端口值施加限制——如果不允许某个值，服务器将以403（禁止）错误拒绝请求。
If the request is valid, but the server is unable to fulfill the request due to some capacity limit or similar, the server replies with a 508 (Insufficient Capacity) error.
如果请求有效，但由于某些容量限制或类似原因，服务器无法完成请求，则服务器将返回508（容量不足）错误。
Otherwise, the server replies with a ChannelBind success response. There are no required attributes in a successful ChannelBind response.
否则，服务器将以ChannelBind成功响应进行响应。成功的ChannelBind响应中没有必需的属性。
If the server can satisfy the request, then the server creates or refreshes the channel binding using the channel number in the CHANNEL-NUMBER attribute and the transport address in the XOR-PEER-ADDRESS attribute. The server also installs or refreshes a permission for the IP address in the XOR-PEER-ADDRESS attribute as described in Section 8.
如果服务器可以满足请求，则服务器将使用channel-number属性中的channel number和XOR-PEER-address属性中的transport address创建或刷新通道绑定。服务器还安装或刷新XOR-PEER-address属性中的IP地址权限，如第8节所述。
NOTE: A server need not do anything special to implement idempotency of ChannelBind requests over UDP using the "stateless stack approach". Retransmitted ChannelBind requests will simply refresh the channel binding and the corresponding permission. Furthermore, the client must wait 5 minutes before binding a previously bound channel number or peer address to a different channel, eliminating the possibility that the transaction would initially fail but succeed on a retransmission.
注意：使用“无状态堆栈方法”，服务器无需执行任何特殊操作即可通过UDP实现ChannelBind请求的幂等性。重新传输的ChannelBind请求将只刷新通道绑定和相应的权限。此外，客户端必须等待5分钟才能将先前绑定的通道号或对等地址绑定到不同的通道，从而消除了事务最初失败但重新传输成功的可能性。
When the client receives a ChannelBind success response, it updates its data structures to record that the channel binding is now active. It also updates its data structures to record that the corresponding permission has been installed or refreshed.
当客户端收到ChannelBind成功响应时，它将更新其数据结构，以记录通道绑定现在处于活动状态。它还更新其数据结构，以记录相应的权限已安装或刷新。
If the client receives a ChannelBind failure response that indicates that the channel information is out-of-sync between the client and the server (e.g., an unexpected 400 "Bad Request" response), then it is RECOMMENDED that the client immediately delete the allocation and start afresh with a new allocation.
如果客户端接收到一个ChannelBind失败响应，该响应指示客户端和服务器之间的通道信息不同步（例如，意外的400“坏请求”响应），则建议客户端立即删除分配并重新开始新的分配。
The ChannelData message is used to carry application data between the client and the server. It has the following format:
ChannelData消息用于在客户端和服务器之间传输应用程序数据。其格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Application Data /
/ /
| |
| +-------------------------------+
| |
+-------------------------------+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Application Data /
/ /
| |
| +-------------------------------+
| |
+-------------------------------+
The Channel Number field specifies the number of the channel on which the data is traveling, and thus the address of the peer that is sending or is to receive the data.
通道号字段指定数据传输的通道号，从而指定发送或接收数据的对等方的地址。
The Length field specifies the length in bytes of the application data field (i.e., it does not include the size of the ChannelData header). Note that 0 is a valid length.
长度字段指定应用程序数据字段的字节长度（即，它不包括ChannelData标头的大小）。请注意，0是一个有效长度。
The Application Data field carries the data the client is trying to send to the peer, or that the peer is sending to the client.
应用程序数据字段包含客户端试图发送给对等方的数据，或者对等方正在发送给客户端的数据。
Once a client has bound a channel to a peer, then when the client has data to send to that peer it may use either a ChannelData message or a Send indication; that is, the client is not obligated to use the channel when it exists and may freely intermix the two message types when sending data to the peer. The server, on the other hand, MUST use the ChannelData message if a channel has been bound to the peer.
一旦客户机将信道绑定到对等机，那么当客户机有数据要发送到该对等机时，它可以使用信道数据消息或发送指示；也就是说，当通道存在时，客户机没有义务使用通道，并且在向对等方发送数据时，可以自由混合这两种消息类型。另一方面，如果通道已绑定到对等方，则服务器必须使用ChannelData消息。
The fields of the ChannelData message are filled in as described in Section 11.4.
按照第11.4节所述填写ChannelData消息的字段。
Over TCP and TLS-over-TCP, the ChannelData message MUST be padded to a multiple of four bytes in order to ensure the alignment of subsequent messages. The padding is not reflected in the length field of the ChannelData message, so the actual size of a ChannelData message (including padding) is (4 + Length) rounded up to the nearest multiple of 4. Over UDP, the padding is not required but MAY be included.
在TCP和TLS上，ChannelData消息必须填充为四个字节的倍数，以确保后续消息的对齐。填充不会反映在ChannelData消息的长度字段中，因此ChannelData消息（包括填充）的实际大小是（4+长度）四舍五入到4的最近倍数。在UDP上，不需要填充，但可以包含填充。
The ChannelData message is then sent on the 5-tuple associated with the allocation.
然后在与分配相关联的5元组上发送ChannelData消息。
The receiver of the ChannelData message uses the first two bits to distinguish it from STUN-formatted messages, as described above. If the message uses a value in the reserved range (0x8000 through 0xFFFF), then the message is silently discarded.
如上所述，ChannelData消息的接收器使用前两位将其与STUN格式的消息区分开来。如果消息使用保留范围（0x8000到0xFFFF）中的值，则消息将被自动丢弃。
If the ChannelData message is received in a UDP datagram, and if the UDP datagram is too short to contain the claimed length of the ChannelData message (i.e., the UDP header length field value is less than the ChannelData header length field value + 4 + 8), then the message is silently discarded.
如果在UDP数据报中接收到ChannelData消息，并且如果UDP数据报太短，无法包含ChannelData消息的声明长度（即，UDP报头长度字段值小于ChannelData报头长度字段值+4+8），则消息将被静默丢弃。
If the ChannelData message is received over TCP or over TLS-over-TCP, then the actual length of the ChannelData message is as described in Section 11.5.
如果通过TCP或通过TLS通过TCP接收ChannelData消息，则ChannelData消息的实际长度如第11.5节所述。
If the ChannelData message is received on a channel that is not bound to any peer, then the message is silently discarded.
如果在未绑定到任何对等方的通道上接收ChannelData消息，则该消息将被静默丢弃。
On the client, it is RECOMMENDED that the client discard the ChannelData message if the client believes there is no active permission towards the peer. On the server, the receipt of a ChannelData message MUST NOT refresh either the channel binding or the permission towards the peer.
在客户端上，如果客户端认为没有对对等方的活动权限，建议客户端丢弃ChannelData消息。在服务器上，ChannelData消息的接收不得刷新通道绑定或对对等方的权限。
On the server, if no errors are detected, the server relays the application data to the peer by forming a UDP datagram as follows:
在服务器上，如果未检测到任何错误，则服务器通过形成UDP数据报将应用程序数据中继到对等方，如下所示：
o the source transport address is the relayed transport address of the allocation, where the allocation is determined by the 5-tuple on which the ChannelData message arrived;
o 源传输地址是分配的中继传输地址，其中分配由ChannelData消息到达的5元组确定；
o the destination transport address is the transport address to which the channel is bound;
o 目的地传输地址是信道绑定到的传输地址；
o the data following the UDP header is the contents of the data field of the ChannelData message.
o UDP标头后面的数据是ChannelData消息的数据字段的内容。
The resulting UDP datagram is then sent to the peer. Note that if the Length field in the ChannelData message is 0, then there will be no data in the UDP datagram, but the UDP datagram is still formed and sent.
然后将生成的UDP数据报发送给对等方。请注意，如果ChannelData消息中的长度字段为0，则UDP数据报中将没有数据，但UDP数据报仍会形成并发送。
When the server receives a UDP datagram on the relayed transport address associated with an allocation, the server processes it as described in Section 10.3. If that section indicates that a ChannelData message should be sent (because there is a channel bound to the peer that sent to the UDP datagram), then the server forms and sends a ChannelData message as described in Section 11.5.
当服务器在与分配相关联的中继传输地址上接收到UDP数据报时，服务器将按照第10.3节所述进行处理。如果该节指示应发送ChannelData消息（因为有一个通道绑定到发送到UDP数据报的对等方），则服务器将形成并发送ChannelData消息，如第11.5节所述。
This section describes how the server sets various fields in the IP header when relaying between the client and the peer or vice versa. The descriptions in this section apply: (a) when the server sends a UDP datagram to the peer, or (b) when the server sends a Data indication or ChannelData message to the client over UDP transport. The descriptions in this section do not apply to TURN messages sent over TCP or TLS transport from the server to the client.
本节描述了在客户端和对等端之间进行中继时，服务器如何在IP报头中设置各种字段，反之亦然。本节中的描述适用于：（a）当服务器向对等方发送UDP数据报时，或（b）当服务器通过UDP传输向客户端发送数据指示或信道数据消息时。本节中的描述不适用于将通过TCP或TLS传输发送的消息从服务器转到客户端。
The descriptions below have two parts: a preferred behavior and an alternate behavior. The server SHOULD implement the preferred behavior, but if that is not possible for a particular field, then it SHOULD implement the alternative behavior.
下面的描述分为两部分：首选行为和备用行为。服务器应该实现首选行为，但如果特定字段不可能实现，则应该实现替代行为。
Time to Live (TTL) field
生存时间（TTL）字段
Preferred Behavior: If the incoming value is 0, then the drop the incoming packet. Otherwise, set the outgoing Time to Live/Hop Count to one less than the incoming value.
首选行为：如果传入值为0，则丢弃传入数据包。否则，将传出生存时间/跃点计数设置为比传入值小一个。
Alternate Behavior: Set the outgoing value to the default for outgoing packets.
备用行为：将传出数据包的传出值设置为默认值。
Differentiated Services Code Point (DSCP) field [RFC2474]
区分服务代码点（DSCP）字段[RFC2474]
Preferred Behavior: Set the outgoing value to the incoming value, unless the server includes a differentiated services classifier and marker [RFC2474].
首选行为：将传出值设置为传入值，除非服务器包含区分服务分类器和标记[RFC2474]。
Alternate Behavior: Set the outgoing value to a fixed value, which by default is Best Effort unless configured otherwise.
替代行为：将传出值设置为固定值，默认情况下，除非另有配置，否则该值为最大努力。
In both cases, if the server is immediately adjacent to a differentiated services classifier and marker, then DSCP MAY be set to any arbitrary value in the direction towards the classifier.
在这两种情况下，如果服务器紧邻区分服务分类器和标记，则DSCP可以设置为朝向分类器的方向上的任意值。
Explicit Congestion Notification (ECN) field [RFC3168]
显式拥塞通知（ECN）字段[RFC3168]
Preferred Behavior: Set the outgoing value to the incoming value, UNLESS the server is doing Active Queue Management, the incoming ECN field is ECT(1) (=0b01) or ECT(0) (=0b10), and the server wishes to indicate that congestion has been experienced, in which case set the outgoing value to CE (=0b11).
首选行为：将传出值设置为传入值，除非服务器正在执行活动队列管理，否则传入ECN字段为ECT（1）（=0b01）或ECT（0）（=0b10），并且服务器希望指示发生了拥塞，在这种情况下，将传出值设置为CE（=0b11）。
Alternate Behavior: Set the outgoing value to Not-ECT (=0b00).
替代行为：将传出值设置为Not ECT（=0b00）。
IPv4 Fragmentation fields
IPv4碎片字段
Preferred Behavior: When the server sends a packet to a peer in response to a Send indication containing the DONT-FRAGMENT attribute, then set the DF bit in the outgoing IP header to 1. In all other cases when sending an outgoing packet containing application data (e.g., Data indication, ChannelData message, or DONT-FRAGMENT attribute not included in the Send indication), copy the DF bit from the DF bit of the incoming packet that contained the application data.
首选行为：当服务器响应包含DONT-FRAGMENT属性的发送指示向对等方发送数据包时，将传出IP报头中的DF位设置为1。在所有其他情况下，当发送包含应用程序数据的传出数据包时（例如，数据指示、ChannelData消息或发送指示中未包含的DONT-FRAGMENT属性），从包含应用程序数据的传入数据包的DF位复制DF位。
Set the other fragmentation fields (Identification, More Fragments, Fragment Offset) as appropriate for a packet originating from the server.
根据需要为来自服务器的数据包设置其他碎片字段（标识、更多碎片、碎片偏移量）。
Alternate Behavior: As described in the Preferred Behavior, except always assume the incoming DF bit is 0.
替代行为：如首选行为中所述，除非始终假定传入的DF位为0。
In both the Preferred and Alternate Behaviors, the resulting packet may be too large for the outgoing link. If this is the case, then the normal fragmentation rules apply [RFC1122].
在优选和备选行为中，结果分组对于传出链路可能太大。如果是这种情况，则应用正常的分段规则[RFC1122]。
IPv4 Options
IPv4选项
Preferred Behavior: The outgoing packet is sent without any IPv4 options.
首选行为：发送传出数据包时不带任何IPv4选项。
Alternate Behavior: Same as preferred.
替代行为：与首选行为相同。
This section lists the codepoints for the new STUN methods defined in this specification. See elsewhere in this document for the semantics of these new methods.
本节列出了本规范中定义的新STUN方法的代码点。有关这些新方法的语义，请参见本文档的其他部分。
0x003 : Allocate (only request/response semantics defined)
0x004 : Refresh (only request/response semantics defined)
0x006 : Send (only indication semantics defined)
0x007 : Data (only indication semantics defined)
0x008 : CreatePermission (only request/response semantics defined
0x009 : ChannelBind (only request/response semantics defined)
0x003 : Allocate (only request/response semantics defined)
0x004 : Refresh (only request/response semantics defined)
0x006 : Send (only indication semantics defined)
0x007 : Data (only indication semantics defined)
0x008 : CreatePermission (only request/response semantics defined
0x009 : ChannelBind (only request/response semantics defined)
This STUN extension defines the following new attributes:
此眩晕扩展定义了以下新属性：
0x000C: CHANNEL-NUMBER 0x000D: LIFETIME 0x0010: Reserved (was BANDWIDTH) 0x0012: XOR-PEER-ADDRESS 0x0013: DATA 0x0016: XOR-RELAYED-ADDRESS 0x0018: EVEN-PORT 0x0019: REQUESTED-TRANSPORT 0x001A: DONT-FRAGMENT 0x0021: Reserved (was TIMER-VAL) 0x0022: RESERVATION-TOKEN
0x000C:通道号0x000D:生存期0x0010:保留（was带宽）0x0012:异或对等地址0x0013:数据0x0016:异或中继地址0x0018:偶数端口0x0019:请求的传输0x001A:不片段0x0021:保留（was定时器-VAL）0x0022:保留令牌
Some of these attributes have lengths that are not multiples of 4. By the rules of STUN, any attribute whose length is not a multiple of 4 bytes MUST be immediately followed by 1 to 3 padding bytes to ensure the next attribute (if any) would start on a 4-byte boundary (see [RFC5389]).
其中一些属性的长度不是4的倍数。根据STUN的规则，长度不是4字节倍数的任何属性后面必须紧跟1到3个填充字节，以确保下一个属性（如果有）将从4字节边界开始（请参见[RFC5389]）。
The CHANNEL-NUMBER attribute contains the number of the channel. The value portion of this attribute is 4 bytes long and consists of a 16- bit unsigned integer, followed by a two-octet RFFU (Reserved For Future Use) field, which MUST be set to 0 on transmission and MUST be ignored on reception.
CHANNEL-NUMBER属性包含通道的编号。该属性的值部分长度为4字节，由一个16位无符号整数组成，后跟一个两个八位RFFU（保留供将来使用）字段，该字段在传输时必须设置为0，在接收时必须忽略。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Number | RFFU = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Number | RFFU = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LIFETIME attribute represents the duration for which the server will maintain an allocation in the absence of a refresh. The value portion of this attribute is 4-bytes long and consists of a 32-bit unsigned integral value representing the number of seconds remaining until expiration.
LIFETIME属性表示在没有刷新的情况下服务器将维持分配的持续时间。此属性的值部分长度为4字节，由一个32位无符号整数值组成，该值表示过期前剩余的秒数。
The XOR-PEER-ADDRESS specifies the address and port of the peer as seen from the TURN server. (For example, the peer's server-reflexive transport address if the peer is behind a NAT.) It is encoded in the same way as XOR-MAPPED-ADDRESS [RFC5389].
XOR-PEER-ADDRESS指定从TURN服务器看到的对等机的地址和端口。（例如，如果对等方位于NAT后面，则为对等方的服务器自反传输地址。）其编码方式与XOR映射地址[RFC5389]相同。
The DATA attribute is present in all Send and Data indications. The value portion of this attribute is variable length and consists of the application data (that is, the data that would immediately follow the UDP header if the data was been sent directly between the client and the peer). If the length of this attribute is not a multiple of 4, then padding must be added after this attribute.
数据属性出现在所有发送和数据指示中。此属性的值部分是可变长度的，由应用程序数据组成（即，如果数据直接在客户端和对等方之间发送，则紧跟在UDP头之后的数据）。如果此属性的长度不是4的倍数，则必须在此属性后添加填充。
The XOR-RELAYED-ADDRESS is present in Allocate responses. It specifies the address and port that the server allocated to the client. It is encoded in the same way as XOR-MAPPED-ADDRESS [RFC5389].
XOR中继地址出现在分配响应中。它指定服务器分配给客户端的地址和端口。它的编码方式与XOR映射地址[RFC5389]相同。
This attribute allows the client to request that the port in the relayed transport address be even, and (optionally) that the server reserve the next-higher port number. The value portion of this attribute is 1 byte long. Its format is:
此属性允许客户端请求中继传输地址中的端口为偶数，并且（可选）服务器保留下一个更高的端口号。此属性的值部分的长度为1字节。其格式为：
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R| RFFU |
+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R| RFFU |
+-+-+-+-+-+-+-+-+
The value contains a single 1-bit flag:
该值包含一个1位标志：
R: If 1, the server is requested to reserve the next-higher port number (on the same IP address) for a subsequent allocation. If 0, no such reservation is requested.
R：如果为1，则请求服务器保留下一个更高的端口号（在同一IP地址上），以供后续分配。如果为0，则不请求此类预订。
The other 7 bits of the attribute's value must be set to zero on transmission and ignored on reception.
属性值的其他7位必须在传输时设置为零，在接收时忽略。
Since the length of this attribute is not a multiple of 4, padding must immediately follow this attribute.
由于该属性的长度不是4的倍数，因此填充必须紧跟在该属性之后。
This attribute is used by the client to request a specific transport
protocol for the allocated transport address. The value of this
attribute is 4 bytes with the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | RFFU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This attribute is used by the client to request a specific transport
protocol for the allocated transport address. The value of this
attribute is 4 bytes with the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | RFFU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Protocol field specifies the desired protocol. The codepoints used in this field are taken from those allowed in the Protocol field in the IPv4 header and the NextHeader field in the IPv6 header [Protocol-Numbers]. This specification only allows the use of codepoint 17 (User Datagram Protocol).
协议字段指定所需的协议。此字段中使用的代码点取自IPv4标头中的协议字段和IPv6标头[协议编号]中的下一个标头字段中允许的代码点。本规范仅允许使用代码点17（用户数据报协议）。
The RFFU field MUST be set to zero on transmission and MUST be ignored on reception. It is reserved for future uses.
RFFU字段在传输时必须设置为零，在接收时必须忽略。这是留作将来使用的。
This attribute is used by the client to request that the server set the DF (Don't Fragment) bit in the IP header when relaying the application data onward to the peer. This attribute has no value part and thus the attribute length field is 0.
客户端使用此属性请求服务器在将应用程序数据转发给对等方时在IP头中设置DF（不分段）位。此属性没有值部分，因此属性长度字段为0。
The RESERVATION-TOKEN attribute contains a token that uniquely identifies a relayed transport address being held in reserve by the server. The server includes this attribute in a success response to tell the client about the token, and the client includes this attribute in a subsequent Allocate request to request the server use that relayed transport address for the allocation.
RESERVATION-TOKEN属性包含一个令牌，该令牌唯一标识服务器保留的中继传输地址。服务器在成功响应中包含此属性以告知客户端令牌，客户端在后续分配请求中包含此属性以请求服务器使用该中继传输地址进行分配。
The attribute value is 8 bytes and contains the token value.
属性值为8字节，包含令牌值。
This document defines the following new error response codes:
本文件定义了以下新的错误响应代码：
403 (Forbidden): The request was valid but cannot be performed due to administrative or similar restrictions.
403（禁止）：请求有效，但由于管理或类似限制而无法执行。
437 (Allocation Mismatch): A request was received by the server that requires an allocation to be in place, but no allocation exists, or a request was received that requires no allocation, but an allocation exists.
437（分配不匹配）：服务器收到的请求要求分配到位，但不存在分配，或者收到的请求不要求分配，但存在分配。
441 (Wrong Credentials): The credentials in the (non-Allocate) request do not match those used to create the allocation.
441（错误凭据）：（非分配）请求中的凭据与用于创建分配的凭据不匹配。
442 (Unsupported Transport Protocol): The Allocate request asked the server to use a transport protocol between the server and the peer that the server does not support. NOTE: This does NOT refer to the transport protocol used in the 5-tuple.
442（不受支持的传输协议）：分配请求要求服务器在服务器和对等方之间使用服务器不支持的传输协议。注意：这不是指5元组中使用的传输协议。
486 (Allocation Quota Reached): No more allocations using this username can be created at the present time.
486（已达到分配配额）：目前无法使用此用户名创建更多分配。
508 (Insufficient Capacity): The server is unable to carry out the request due to some capacity limit being reached. In an Allocate response, this could be due to the server having no more relayed transport addresses available at that time, having none with the requested properties, or the one that corresponds to the specified reservation token is not available.
508（容量不足）：由于达到某些容量限制，服务器无法执行请求。在分配响应中，这可能是因为服务器当时没有更多可用的中继传输地址，没有具有请求属性的中继传输地址，或者与指定的保留令牌对应的中继传输地址不可用。
This section gives an example of the use of TURN, showing in detail the contents of the messages exchanged. The example uses the network diagram shown in the Overview (Figure 1).
本节给出了TURN的使用示例，详细显示了交换的消息的内容。该示例使用概述中所示的网络图（图1）。
For each message, the attributes included in the message and their values are shown. For convenience, values are shown in a human-readable format rather than showing the actual octets; for example, "XOR-RELAYED-ADDRESS=192.0.2.15:9000" shows that the XOR-RELAYED-ADDRESS attribute is included with an address of 192.0.2.15 and a port of 9000, here the address and port are shown before the xor-ing is done. For attributes with string-like values (e.g., SOFTWARE="Example client, version 1.03" and NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm"), the value of the attribute is shown in quotes for readability, but these quotes do not appear in the actual value.
对于每条消息，将显示消息中包含的属性及其值。为方便起见，值以人类可读的格式显示，而不是显示实际的八位字节；例如，“XOR-RELAYED-ADDRESS=192.0.2.15:9000”表示XOR-RELAYED-ADDRESS属性包含在地址192.0.2.15和端口9000中，这里在XOR操作完成之前显示地址和端口。对于具有类似字符串的值的属性（例如，SOFTWARE=“Example client，version 1.03”和NONCE=“adl7W7PeDU4hKE72jdaQvbAMcr6h39sm”），为便于阅读，属性值以引号显示，但这些引号不会出现在实际值中。
TURN TURN Peer Peer
client server A B
| | | |
|--- Allocate request -------------->| | |
| Transaction-Id=0xA56250D3F17ABE679422DE85 | |
| SOFTWARE="Example client, version 1.03" | |
| LIFETIME=3600 (1 hour) | | |
| REQUESTED-TRANSPORT=17 (UDP) | | |
| DONT-FRAGMENT | | |
| | | |
|<-- Allocate error response --------| | |
| Transaction-Id=0xA56250D3F17ABE679422DE85 | |
| SOFTWARE="Example server, version 1.17" | |
| ERROR-CODE=401 (Unauthorized) | | |
| REALM="example.com" | | |
| NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | |
| | | |
|--- Allocate request -------------->| | |
| Transaction-Id=0xC271E932AD7446A32C234492 | |
| SOFTWARE="Example client 1.03" | | |
| LIFETIME=3600 (1 hour) | | |
| REQUESTED-TRANSPORT=17 (UDP) | | |
| DONT-FRAGMENT | | |
| USERNAME="George" | | |
| REALM="example.com" | | |
| NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | |
| MESSAGE-INTEGRITY=... | | |
| | | |
|<-- Allocate success response ------| | |
| Transaction-Id=0xC271E932AD7446A32C234492 | |
| SOFTWARE="Example server, version 1.17" | |
| LIFETIME=1200 (20 minutes) | | |
| XOR-RELAYED-ADDRESS=192.0.2.15:50000 | |
| XOR-MAPPED-ADDRESS=192.0.2.1:7000 | |
| MESSAGE-INTEGRITY=... | | |
TURN TURN Peer Peer
client server A B
| | | |
|--- Allocate request -------------->| | |
| Transaction-Id=0xA56250D3F17ABE679422DE85 | |
| SOFTWARE="Example client, version 1.03" | |
| LIFETIME=3600 (1 hour) | | |
| REQUESTED-TRANSPORT=17 (UDP) | | |
| DONT-FRAGMENT | | |
| | | |
|<-- Allocate error response --------| | |
| Transaction-Id=0xA56250D3F17ABE679422DE85 | |
| SOFTWARE="Example server, version 1.17" | |
| ERROR-CODE=401 (Unauthorized) | | |
| REALM="example.com" | | |
| NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | |
| | | |
|--- Allocate request -------------->| | |
| Transaction-Id=0xC271E932AD7446A32C234492 | |
| SOFTWARE="Example client 1.03" | | |
| LIFETIME=3600 (1 hour) | | |
| REQUESTED-TRANSPORT=17 (UDP) | | |
| DONT-FRAGMENT | | |
| USERNAME="George" | | |
| REALM="example.com" | | |
| NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | |
| MESSAGE-INTEGRITY=... | | |
| | | |
|<-- Allocate success response ------| | |
| Transaction-Id=0xC271E932AD7446A32C234492 | |
| SOFTWARE="Example server, version 1.17" | |
| LIFETIME=1200 (20 minutes) | | |
| XOR-RELAYED-ADDRESS=192.0.2.15:50000 | |
| XOR-MAPPED-ADDRESS=192.0.2.1:7000 | |
| MESSAGE-INTEGRITY=... | | |
The client begins by selecting a host transport address to use for the TURN session; in this example, the client has selected 10.1.1.2: 49721 as shown in Figure 1. The client then sends an Allocate request to the server at the server transport address. The client randomly selects a 96-bit transaction id of 0xA56250D3F17ABE679422DE85 for this transaction; this is encoded in the transaction id field in the fixed header. The client includes a SOFTWARE attribute that gives information about the client's software; here the value is "Example client, version 1.03" to indicate that this is version 1.03 of something called the Example client. The client includes the LIFETIME attribute because it wishes the allocation to have a longer lifetime than the default of 10 minutes; the value of this attribute is 3600 seconds, which corresponds to 1 hour. The client must always include a REQUESTED-TRANSPORT attribute in an Allocate request and the only value allowed by this specification is 17, which indicates UDP transport between the server and the peers. The client also includes the DONT-FRAGMENT attribute because it wishes to use the DONT-FRAGMENT attribute later in Send indications; this attribute consists of only an attribute header, there is no value part. We assume the client has not recently interacted with the server, thus the client does not include USERNAME, REALM, NONCE, or MESSAGE-INTEGRITY attribute. Finally, note that the order of attributes in a message is arbitrary (except for the MESSAGE-INTEGRITY and FINGERPRINT attributes) and the client could have used a different order.
客户端首先选择用于TURN会话的主机传输地址；在本例中，客户机选择了10.1.1.2:49721，如图1所示。然后，客户端在服务器传输地址向服务器发送分配请求。客户机为此事务随机选择一个96位事务id 0xA56250D3F17ABE679422DE85；这在固定标头的事务id字段中进行编码。客户机包括提供关于客户机软件的信息的软件属性；这里的值是“示例客户端，版本1.03”，表示这是示例客户端的版本1.03。客户端包括LIFETIME属性，因为它希望分配的生存期比默认的10分钟更长；此属性的值为3600秒，相当于1小时。客户端必须始终在分配请求中包含request-TRANSPORT属性，此规范允许的唯一值为17，表示服务器和对等方之间的UDP传输。客户端还包括DONT-FRAGMENT属性，因为它希望稍后在发送指示中使用DONT-FRAGMENT属性；此属性仅包含一个属性头，没有值部分。我们假设客户端最近没有与服务器交互，因此客户端不包括用户名、领域、NONCE或消息完整性属性。最后，请注意，消息中属性的顺序是任意的（消息完整性和指纹属性除外），客户端可以使用不同的顺序。
Servers require any request to be authenticated. Thus, when the server receives the initial Allocate request, it rejects the request because the request does not contain the authentication attributes. Following the procedures of the long-term credential mechanism of STUN [RFC5389], the server includes an ERROR-CODE attribute with a value of 401 (Unauthorized), a REALM attribute that specifies the authentication realm used by the server (in this case, the server's domain "example.com"), and a nonce value in a NONCE attribute. The server also includes a SOFTWARE attribute that gives information about the server's software.
服务器要求对任何请求进行身份验证。因此，当服务器收到初始分配请求时，它会拒绝该请求，因为该请求不包含身份验证属性。按照STUN[RFC5389]的长期凭证机制的过程，服务器包括一个值为401（未经授权）的错误代码属性、一个指定服务器使用的身份验证领域的领域属性（在本例中，服务器的域“example.com”）和一个nonce属性中的nonce值。服务器还包括一个软件属性，该属性提供有关服务器软件的信息。
The client, upon receipt of the 401 error, re-attempts the Allocate request, this time including the authentication attributes. The client selects a new transaction id, and then populates the new Allocate request with the same attributes as before. The client includes a USERNAME attribute and uses the realm value received from the server to help it determine which value to use; here the client is configured to use the username "George" for the realm "example.com". The client also includes the REALM and NONCE attributes, which are just copied from the 401 error response. Finally, the client includes a MESSAGE-INTEGRITY attribute as the last attribute in the message, whose value is a Hashed Message
客户端在收到401错误后，重新尝试分配请求，这次包括身份验证属性。客户端选择一个新的事务id，然后使用与以前相同的属性填充新的分配请求。客户端包括一个USERNAME属性，并使用从服务器接收的领域值来帮助它确定要使用的值；在这里，客户机被配置为使用领域“example.com”的用户名“George”。客户端还包括REALM和NONCE属性，它们只是从401错误响应中复制的。最后，客户机包括一个MESSAGE-INTEGRITY属性作为消息中的最后一个属性，其值是散列消息
Authentication Code - Secure Hash Algorithm 1 (HMAC-SHA1) hash over the contents of the message (shown as just "..." above); this HMAC-SHA1 computation includes a password value. Thus, an attacker cannot compute the message integrity value without somehow knowing the secret password.
身份验证代码-安全哈希算法1（HMAC-SHA1）对消息内容进行哈希（如上所示“…”）；此HMAC-SHA1计算包括密码值。因此，攻击者无法在不知道密码的情况下计算消息完整性值。
The server, upon receipt of the authenticated Allocate request, checks that everything is OK, then creates an allocation. The server replies with an Allocate success response. The server includes a LIFETIME attribute giving the lifetime of the allocation; here, the server has reduced the client's requested 1-hour lifetime to just 20 minutes, because this particular server doesn't allow lifetimes longer than 20 minutes. The server includes an XOR-RELAYED-ADDRESS attribute whose value is the relayed transport address of the allocation. The server includes an XOR-MAPPED-ADDRESS attribute whose value is the server-reflexive address of the client; this value is not used otherwise in TURN but is returned as a convenience to the client. The server includes a MESSAGE-INTEGRITY attribute to authenticate the response and to ensure its integrity; note that the response does not contain the USERNAME, REALM, and NONCE attributes. The server also includes a SOFTWARE attribute.
服务器在收到经过身份验证的分配请求后，检查一切是否正常，然后创建分配。服务器以分配成功响应进行响应。服务器包括给出分配的生存期的生存期属性；在这里，服务器已将客户端请求的1小时生存期缩短为20分钟，因为此特定服务器不允许生存期超过20分钟。服务器包括一个XOR-RELAYED-ADDRESS属性，其值是分配的中继传输地址。服务器包括XOR映射地址属性，其值是客户端的服务器自反地址；此值不在其他情况下使用，而是作为一种方便返回给客户端。服务器包括消息完整性属性，用于认证响应并确保其完整性；请注意，响应不包含USERNAME、REALM和NONCE属性。服务器还包括一个软件属性。
TURN TURN Peer Peer
client server A B
|--- CreatePermission request ------>| | |
| Transaction-Id=0xE5913A8F460956CA277D3319 | |
| XOR-PEER-ADDRESS=192.0.2.150:0 | | |
| USERNAME="George" | | |
| REALM="example.com" | | |
| NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | |
| MESSAGE-INTEGRITY=... | | |
| | | |
|<-- CreatePermission success resp.--| | |
| Transaction-Id=0xE5913A8F460956CA277D3319 | |
| MESSAGE-INTEGRITY=... | | |
TURN TURN Peer Peer
client server A B
|--- CreatePermission request ------>| | |
| Transaction-Id=0xE5913A8F460956CA277D3319 | |
| XOR-PEER-ADDRESS=192.0.2.150:0 | | |
| USERNAME="George" | | |
| REALM="example.com" | | |
| NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | |
| MESSAGE-INTEGRITY=... | | |
| | | |
|<-- CreatePermission success resp.--| | |
| Transaction-Id=0xE5913A8F460956CA277D3319 | |
| MESSAGE-INTEGRITY=... | | |
The client then creates a permission towards Peer A in preparation for sending it some application data. This is done through a CreatePermission request. The XOR-PEER-ADDRESS attribute contains the IP address for which a permission is established (the IP address of peer A); note that the port number in the attribute is ignored when used in a CreatePermission request, and here it has been set to 0; also, note how the client uses Peer A's server-reflexive IP address and not its (private) host address. The client uses the same username, realm, and nonce values as in the previous request on the allocation. Though it is allowed to do so, the client has chosen not to include a SOFTWARE attribute in this request.
然后，客户端向对等方a创建一个权限，以准备向其发送一些应用程序数据。这是通过CreatePermission请求完成的。XOR-PEER-ADDRESS属性包含为其建立权限的IP地址（对等a的IP地址）；请注意，当在CreatePermission请求中使用时，该属性中的端口号将被忽略，这里它已设置为0；另外，请注意客户端如何使用对等方A的服务器自反IP地址而不是其（专用）主机地址。客户端使用的用户名、领域和nonce值与上一个分配请求中相同。虽然允许这样做，但客户机已选择不在此请求中包含软件属性。
The server receives the CreatePermission request, creates the corresponding permission, and then replies with a CreatePermission success response. Like the client, the server chooses not to include the SOFTWARE attribute in its reply. Again, note how success responses contain a MESSAGE-INTEGRITY attribute (assuming the server uses the long-term credential mechanism), but no USERNAME, REALM, and NONCE attributes.
服务器接收CreatePermission请求，创建相应的权限，然后使用CreatePermission成功响应进行响应。与客户端一样，服务器选择不在其回复中包含软件属性。同样，请注意成功响应如何包含消息完整性属性（假设服务器使用长期凭据机制），但不包含用户名、领域和NONCE属性。
TURN TURN Peer Peer
client server A B
|--- Send indication --------------->| | |
| Transaction-Id=0x1278E9ACA2711637EF7D3328 | |
| XOR-PEER-ADDRESS=192.0.2.150:32102 | |
| DONT-FRAGMENT | | |
| DATA=... | | |
| |-- UDP dgm ->| |
| | data=... | |
| | | |
| |<- UDP dgm --| |
| | data=... | |
|<-- Data indication ----------------| | |
| Transaction-Id=0x8231AE8F9242DA9FF287FEFF | |
| XOR-PEER-ADDRESS=192.0.2.150:32102 | |
| DATA=... | | |
TURN TURN Peer Peer
client server A B
|--- Send indication --------------->| | |
| Transaction-Id=0x1278E9ACA2711637EF7D3328 | |
| XOR-PEER-ADDRESS=192.0.2.150:32102 | |
| DONT-FRAGMENT | | |
| DATA=... | | |
| |-- UDP dgm ->| |
| | data=... | |
| | | |
| |<- UDP dgm --| |
| | data=... | |
|<-- Data indication ----------------| | |
| Transaction-Id=0x8231AE8F9242DA9FF287FEFF | |
| XOR-PEER-ADDRESS=192.0.2.150:32102 | |
| DATA=... | | |
The client now sends application data to Peer A using a Send indication. Peer A's server-reflexive transport address is specified in the XOR-PEER-ADDRESS attribute, and the application data (shown here as just "...") is specified in the DATA attribute. The client is doing a form of path MTU discovery at the application layer and thus specifies (by including the DONT-FRAGMENT attribute) that the server should set the DF bit in the UDP datagram to send to the peer. Indications cannot be authenticated using the long-term credential mechanism of STUN, so no MESSAGE-INTEGRITY attribute is included in the message. An application wishing to ensure that its data is not altered or forged must integrity-protect its data at the application level.
客户端现在使用发送指示将应用程序数据发送给对等方A。对等A的服务器自反传输地址在XOR-Peer-address属性中指定，应用程序数据（此处显示为“…”）在数据属性中指定。客户端在应用层执行一种形式的路径MTU发现，因此指定（通过包括DONT-FRAGMENT属性）服务器应在UDP数据报中设置DF位以发送给对等方。无法使用STUN的长期凭证机制对指示进行身份验证，因此消息中不包含消息完整性属性。希望确保其数据不被更改或伪造的应用程序必须在应用程序级别保护其数据的完整性。
Upon receipt of the Send indication, the server extracts the application data and sends it in a UDP datagram to Peer A, with the relayed transport address as the source transport address of the datagram, and with the DF bit set as requested. Note that, had the client not previously established a permission for Peer A's server-reflexive IP address, then the server would have silently discarded the Send indication instead.
在收到发送指示后，服务器提取应用程序数据并以UDP数据报的形式将其发送给对等方a，中继传输地址作为数据报的源传输地址，DF位根据请求设置。请注意，如果客户端以前没有为对等方a的服务器自反IP地址建立权限，那么服务器将自动放弃发送指示。
Peer A then replies with its own UDP datagram containing application data. The datagram is sent to the relayed transport address on the server. When this arrives, the server creates a Data indication containing the source of the UDP datagram in the XOR-PEER-ADDRESS attribute, and the data from the UDP datagram in the DATA attribute. The resulting Data indication is then sent to the client.
然后，对等方A使用自己的包含应用程序数据的UDP数据报进行回复。数据报被发送到服务器上的中继传输地址。当到达时，服务器将创建一个数据指示，其中包含XOR-PEER-ADDRESS属性中UDP数据报的源，以及数据属性中UDP数据报的数据。然后将结果数据指示发送到客户端。
TURN TURN Peer Peer
client server A B
|--- ChannelBind request ----------->| | |
| Transaction-Id=0x6490D3BC175AFF3D84513212 | |
| CHANNEL-NUMBER=0x4000 | | |
| XOR-PEER-ADDRESS=192.0.2.210:49191 | |
| USERNAME="George" | | |
| REALM="example.com" | | |
| NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | |
| MESSAGE-INTEGRITY=... | | |
| | | |
|<-- ChannelBind success response ---| | |
| Transaction-Id=0x6490D3BC175AFF3D84513212 | |
| MESSAGE-INTEGRITY=... | | |
TURN TURN Peer Peer
client server A B
|--- ChannelBind request ----------->| | |
| Transaction-Id=0x6490D3BC175AFF3D84513212 | |
| CHANNEL-NUMBER=0x4000 | | |
| XOR-PEER-ADDRESS=192.0.2.210:49191 | |
| USERNAME="George" | | |
| REALM="example.com" | | |
| NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | |
| MESSAGE-INTEGRITY=... | | |
| | | |
|<-- ChannelBind success response ---| | |
| Transaction-Id=0x6490D3BC175AFF3D84513212 | |
| MESSAGE-INTEGRITY=... | | |
The client now binds a channel to Peer B, specifying a free channel number (0x4000) in the CHANNEL-NUMBER attribute, and Peer B's transport address in the XOR-PEER-ADDRESS attribute. As before, the client re-uses the username, realm, and nonce from its last request in the message.
客户机现在将通道绑定到对等B，在channel-number属性中指定空闲通道号（0x4000），并在XOR-Peer-address属性中指定对等B的传输地址。与前面一样，客户端重新使用消息中最后一个请求中的用户名、领域和nonce。
Upon receipt of the request, the server binds the channel number to the peer, installs a permission for Peer B's IP address, and then replies with ChannelBind success response.
收到请求后，服务器将通道号绑定到对等方，为对等方B的IP地址安装权限，然后使用ChannelBind success响应进行响应。
TURN TURN Peer Peer
client server A B
|--- ChannelData ------------------->| | |
| Channel-number=0x4000 |--- UDP datagram --------->|
| Data=... | Data=... |
| | | |
| |<-- UDP datagram ----------|
| | Data=... | |
|<-- ChannelData --------------------| | |
| Channel-number=0x4000 | | |
| Data=... | | |
TURN TURN Peer Peer
client server A B
|--- ChannelData ------------------->| | |
| Channel-number=0x4000 |--- UDP datagram --------->|
| Data=... | Data=... |
| | | |
| |<-- UDP datagram ----------|
| | Data=... | |
|<-- ChannelData --------------------| | |
| Channel-number=0x4000 | | |
| Data=... | | |
The client now sends a ChannelData message to the server with data destined for Peer B. The ChannelData message is not a STUN message, and thus has no transaction id. Instead, it has only three fields: a channel number, data, and data length; here the channel number field
客户端现在向服务器发送一条ChannelData消息，其中包含发送给对等方B的数据。ChannelData消息不是STUN消息，因此没有事务id。相反，它只有三个字段：通道号、数据和数据长度；这里是频道号字段
is 0x4000 (the channel the client just bound to Peer B). When the server receives the ChannelData message, it checks that the channel is currently bound (which it is) and then sends the data onward to Peer B in a UDP datagram, using the relayed transport address as the source transport address and 192.0.2.210:49191 (the value of the XOR-PEER-ADDRESS attribute in the ChannelBind request) as the destination transport address.
是0x4000（客户端刚刚绑定到对等B的通道）。当服务器接收到ChannelData消息时，它会检查通道当前是否已绑定（即已绑定），然后使用中继传输地址作为源传输地址和192.0.2.210:49191（ChannelBind请求中XOR-Peer-address属性的值），将数据向前发送到UDP数据报中的对等方B作为目标传输地址。
Later, Peer B sends a UDP datagram back to the relayed transport address. This causes the server to send a ChannelData message to the client containing the data from the UDP datagram. The server knows to which client to send the ChannelData message because of the relayed transport address at which the UDP datagram arrived, and knows to use channel 0x4000 because this is the channel bound to 192.0.2.210:49191. Note that if there had not been any channel number bound to that address, the server would have used a Data indication instead.
稍后，对等方B将UDP数据报发送回中继传输地址。这会导致服务器向客户端发送包含UDP数据报数据的ChannelData消息。由于UDP数据报到达的中继传输地址，服务器知道向哪个客户端发送ChannelData消息，并且知道使用通道0x4000，因为这是绑定到192.0.2.210:49191的通道。请注意，如果没有任何通道号绑定到该地址，服务器将使用数据指示。
TURN TURN Peer Peer
client server A B
|--- Refresh request --------------->| | |
| Transaction-Id=0x0864B3C27ADE9354B4312414 | |
| SOFTWARE="Example client 1.03" | | |
| USERNAME="George" | | |
| REALM="example.com" | | |
| NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | |
| MESSAGE-INTEGRITY=... | | |
| | | |
|<-- Refresh error response ---------| | |
| Transaction-Id=0x0864B3C27ADE9354B4312414 | |
| SOFTWARE="Example server, version 1.17" | |
| ERROR-CODE=438 (Stale Nonce) | | |
| REALM="example.com" | | |
| NONCE="npSw1Xw239bBwGYhjNWgz2yH47sxB2j" | |
| | | |
|--- Refresh request --------------->| | |
| Transaction-Id=0x427BD3E625A85FC731DC4191 | |
| SOFTWARE="Example client 1.03" | | |
| USERNAME="George" | | |
| REALM="example.com" | | |
| NONCE="npSw1Xw239bBwGYhjNWgz2yH47sxB2j" | |
| MESSAGE-INTEGRITY=... | | |
| | | |
|<-- Refresh success response -------| | |
| Transaction-Id=0x427BD3E625A85FC731DC4191 | |
| SOFTWARE="Example server, version 1.17" | |
| LIFETIME=600 (10 minutes) | | |
TURN TURN Peer Peer
client server A B
|--- Refresh request --------------->| | |
| Transaction-Id=0x0864B3C27ADE9354B4312414 | |
| SOFTWARE="Example client 1.03" | | |
| USERNAME="George" | | |
| REALM="example.com" | | |
| NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | |
| MESSAGE-INTEGRITY=... | | |
| | | |
|<-- Refresh error response ---------| | |
| Transaction-Id=0x0864B3C27ADE9354B4312414 | |
| SOFTWARE="Example server, version 1.17" | |
| ERROR-CODE=438 (Stale Nonce) | | |
| REALM="example.com" | | |
| NONCE="npSw1Xw239bBwGYhjNWgz2yH47sxB2j" | |
| | | |
|--- Refresh request --------------->| | |
| Transaction-Id=0x427BD3E625A85FC731DC4191 | |
| SOFTWARE="Example client 1.03" | | |
| USERNAME="George" | | |
| REALM="example.com" | | |
| NONCE="npSw1Xw239bBwGYhjNWgz2yH47sxB2j" | |
| MESSAGE-INTEGRITY=... | | |
| | | |
|<-- Refresh success response -------| | |
| Transaction-Id=0x427BD3E625A85FC731DC4191 | |
| SOFTWARE="Example server, version 1.17" | |
| LIFETIME=600 (10 minutes) | | |
Sometime before the 20 minute lifetime is up, the client refreshes the allocation. This is done using a Refresh request. As before, the client includes the latest username, realm, and nonce values in the request. The client also includes the SOFTWARE attribute, following the recommended practice of always including this attribute in Allocate and Refresh messages. When the server receives the Refresh request, it notices that the nonce value has expired, and so replies with 438 (Stale Nonce) error given a new nonce value. The client then reattempts the request, this time with the new nonce value. This second attempt is accepted, and the server replies with a success response. Note that the client did not include a LIFETIME attribute in the request, so the server refreshes the allocation for the default lifetime of 10 minutes (as can be seen by the LIFETIME attribute in the success response).
在20分钟生存期结束之前，客户端刷新分配。这是使用刷新请求完成的。与前面一样，客户端在请求中包含最新的用户名、领域和nonce值。客户机还包括软件属性，遵循在分配和刷新消息中始终包含此属性的推荐做法。当服务器接收到刷新请求时，它会注意到nonce值已过期，因此在给定新的nonce值的情况下，会返回438（Stale nonce）错误。然后，客户端重新尝试该请求，这次使用新的nonce值。第二次尝试被接受，服务器将以成功响应进行响应。请注意，客户端在请求中没有包含生存期属性，因此服务器将刷新分配，默认生存期为10分钟（如成功响应中的生存期属性所示）。
This section considers attacks that are possible in a TURN deployment, and discusses how they are mitigated by mechanisms in the protocol or recommended practices in the implementation.
本节考虑轮流部署中可能发生的攻击，并讨论如何通过协议中的机制或实现中的推荐做法来缓解这些攻击。
Most of the attacks on TURN are mitigated by the server requiring requests be authenticated. Thus, this specification requires the use of authentication. The mandatory-to-implement mechanism is the long-term credential mechanism of STUN. Other authentication mechanisms of equal or stronger security properties may be used. However, it is important to ensure that they can be invoked in an inter-operable way.
服务器要求对请求进行身份验证，从而减轻了大多数攻击。因此，本规范要求使用身份验证。必须实施的机制是STUN的长期凭证机制。可以使用具有相同或更强安全属性的其他认证机制。但是，重要的是确保可以以互操作的方式调用它们。
Outsider attacks are ones where the attacker has no credentials in the system, and is attempting to disrupt the service seen by the client or the server.
外部攻击是指攻击者在系统中没有凭据，并试图中断客户端或服务器看到的服务的攻击。
An attacker might wish to obtain allocations on a TURN server for any number of nefarious purposes. A TURN server provides a mechanism for sending and receiving packets while cloaking the actual IP address of the client. This makes TURN servers an attractive target for attackers who wish to use it to mask their true identity.
攻击者可能希望在TURN服务器上获得分配，以达到任何邪恶目的。TURN服务器提供发送和接收数据包的机制，同时隐藏客户端的实际IP地址。这使得TURN服务器成为希望使用它来掩盖其真实身份的攻击者的诱人目标。
An attacker might also wish to simply utilize the services of a TURN server without paying for them. Since TURN services require resources from the provider, it is anticipated that their usage will come with a cost.
攻击者还可能希望只利用TURN服务器的服务而不付费。由于TURN服务需要供应商提供资源，因此预计其使用将产生成本。
These attacks are prevented using the long-term credential mechanism, which allows the TURN server to determine the identity of the requestor and whether the requestor is allowed to obtain the allocation.
使用长期凭证机制可以防止这些攻击，该机制允许TURN服务器确定请求者的身份以及是否允许请求者获得分配。
The long-term credential mechanism used by TURN is subject to offline dictionary attacks. An attacker that is capable of eavesdropping on a message exchange between a client and server can determine the password by trying a number of candidate passwords and seeing if one of them is correct. This attack works when the passwords are low entropy, such as a word from the dictionary. This attack can be mitigated by using strong passwords with large entropy. In situations where even stronger mitigation is required, TLS transport between the client and the server can be used.
TURN使用的长期凭证机制会受到脱机字典攻击。能够窃听客户端和服务器之间的消息交换的攻击者可以通过尝试多个候选密码并查看其中一个是否正确来确定密码。当密码为低熵时（例如字典中的一个单词），此攻击有效。这种攻击可以通过使用具有大熵的强密码来缓解。在需要更强缓解的情况下，可以使用客户端和服务器之间的TLS传输。
An attacker might wish to attack an active allocation by sending it a Refresh request with an immediate expiration, in order to delete it and disrupt service to the client. This is prevented by authentication of refreshes. Similarly, an attacker wishing to send CreatePermission requests to create permissions to undesirable destinations is prevented from doing so through authentication. The motivations for such an attack are described in Section 17.2.
攻击者可能希望通过向活动分配发送一个立即过期的刷新请求来攻击该分配，以便将其删除并中断对客户端的服务。这是通过对刷新进行身份验证来防止的。类似地，通过身份验证可以防止攻击者发送CreatePermission请求以向不需要的目标创建权限。第17.2节描述了此类攻击的动机。
An attacker might wish to send data to the client or the peer, as if they came from the peer or client, respectively. To do that, the attacker can send the client a faked Data Indication or ChannelData message, or send the TURN server a faked Send Indication or ChannelData message.
攻击者可能希望向客户端或对等方发送数据，就好像它们分别来自对等方或客户端一样。为此，攻击者可以向客户端发送伪造的数据指示或ChannelData消息，或向TURN服务器发送伪造的发送指示或ChannelData消息。
Since indications and ChannelData messages are not authenticated, this attack is not prevented by TURN. However, this attack is generally present in IP-based communications and is not substantially worsened by TURN. Consider a normal, non-TURN IP session between hosts A and B. An attacker can send packets to B as if they came from A by sending packets towards A with a spoofed IP address of B. This attack requires the attacker to know the IP addresses of A and B. With TURN, an attacker wishing to send packets towards a client using a Data indication needs to know its IP address (and port), the IP address and port of the TURN server, and the IP address and port of the peer (for inclusion in the XOR-PEER-ADDRESS attribute). To send a fake ChannelData message to a client, an attacker needs to know the IP address and port of the client, the IP address and port
由于指示和通道数据消息未通过身份验证，因此无法通过轮次阻止此攻击。然而，这种攻击通常存在于基于IP的通信中，并且不会反过来严重恶化。考虑主机A之间的正常、非转接IP会话，而B. An攻击者可以将分组发送到B，好像它们是通过向A发送带有B的欺骗IP地址的数据包而来的。这种攻击要求攻击者知道A和B的IP地址。希望使用数据指示向客户端发送数据包的攻击者需要知道其IP地址（和端口）、TURN服务器的IP地址和端口以及对等方的IP地址和端口（包含在XOR-peer-address属性中）。要向客户端发送假ChannelData消息，攻击者需要知道客户端的IP地址和端口、IP地址和端口
of the TURN server, and the channel number. This particular combination is mildly more guessable than in the non-TURN case.
以及频道号。这种特殊的组合比不转弯的情况更容易猜测。
These attacks are more properly mitigated by application-layer authentication techniques. In the case of real-time traffic, usage of SRTP [RFC3711] prevents these attacks.
应用层身份验证技术可以更有效地缓解这些攻击。在实时流量的情况下，使用SRTP[RFC3711]可以防止这些攻击。
In some situations, the TURN server may be situated in the network such that it is able to send to hosts to which the client cannot directly send. This can happen, for example, if the server is located behind a firewall that allows packets from outside the firewall to be delivered to the server, but not to other hosts behind the firewall. In these situations, an attacker could send the server a Send indication with an XOR-PEER-ADDRESS attribute containing the transport address of one of the other hosts behind the firewall. If the server was to allow relaying of traffic to arbitrary peers, then this would provide a way for the attacker to attack arbitrary hosts behind the firewall.
在某些情况下，TURN服务器可能位于网络中，以便能够发送到客户端无法直接发送到的主机。例如，如果服务器位于防火墙后面，允许将来自防火墙之外的数据包传送到服务器，但不传送到防火墙后面的其他主机，则可能发生这种情况。在这些情况下，攻击者可以向服务器发送带有XOR-PEER-ADDRESS属性的发送指示，该属性包含防火墙后面其他主机之一的传输地址。如果服务器允许将流量中继到任意对等方，那么这将为攻击者攻击防火墙后面的任意主机提供一种方法。
To mitigate this attack, TURN requires that the client establish a permission to a host before sending it data. Thus, an attacker can only attack hosts with which the client is already communicating, unless the attacker is able to create authenticated requests. Furthermore, the server administrator may configure the server to restrict the range of IP addresses and ports to which it will relay data. To provide even greater security, the server administrator can require that the client use TLS for all communication between the client and the server.
为了减轻此攻击，TURN要求客户端在向主机发送数据之前建立对主机的权限。因此，除非攻击者能够创建经过身份验证的请求，否则攻击者只能攻击客户端已经与之通信的主机。此外，服务器管理员可以配置服务器以限制其将数据中继到的IP地址和端口的范围。为了提供更高的安全性，服务器管理员可以要求客户端使用TLS进行客户端和服务器之间的所有通信。
When a client learns a relayed address from a TURN server, it uses that relayed address in application protocols to receive traffic. Therefore, an attacker wishing to intercept or redirect that traffic might try to impersonate a TURN server and provide the client with a faked relayed address.
当客户机从TURN服务器学习到中继地址时，它会在应用程序协议中使用该中继地址来接收流量。因此，希望拦截或重定向该流量的攻击者可能会尝试模拟TURN服务器并向客户端提供伪造的中继地址。
This attack is prevented through the long-term credential mechanism, which provides message integrity for responses in addition to verifying that they came from the server. Furthermore, an attacker cannot replay old server responses as the transaction id in the STUN header prevents this. Replay attacks are further thwarted through frequent changes to the nonce value.
通过长期凭据机制可以防止此攻击，该机制除了验证响应是否来自服务器之外，还为响应提供消息完整性。此外，攻击者无法重播旧服务器响应，因为STUN头中的事务id阻止了这一点。通过频繁更改nonce值，可以进一步阻止重播攻击。
TURN concerns itself primarily with authentication and message integrity. Confidentiality is only a secondary concern, as TURN control messages do not include information that is particularly sensitive. The primary protocol content of the messages is the IP address of the peer. If it is important to prevent an eavesdropper on a TURN connection from learning this, TURN can be run over TLS.
TURN主要关注身份验证和消息完整性。保密性只是次要问题，因为转弯控制信息不包括特别敏感的信息。消息的主要协议内容是对等方的IP地址。如果防止转弯连接上的窃听者知道这一点很重要，转弯可以通过TLS运行。
Confidentiality for the application data relayed by TURN is best provided by the application protocol itself, since running TURN over TLS does not protect application data between the server and the peer. If confidentiality of application data is important, then the application should encrypt or otherwise protect its data. For example, for real-time media, confidentiality can be provided by using SRTP.
TURN中继的应用程序数据的机密性最好由应用程序协议本身提供，因为运行TURN over TLS不会保护服务器和对等方之间的应用程序数据。如果应用程序数据的机密性很重要，则应用程序应加密或以其他方式保护其数据。例如，对于实时媒体，可以通过使用SRTP来提供机密性。
An attacker might attempt to cause data packets to loop indefinitely between two TURN servers. The attack goes as follows. First, the attacker sends an Allocate request to server A, using the source address of server B. Server A will send its response to server B, and for the attack to succeed, the attacker must have the ability to either view or guess the contents of this response, so that the attacker can learn the allocated relayed transport address. The attacker then sends an Allocate request to server B, using the source address of server A. Again, the attacker must be able to view or guess the contents of the response, so it can send learn the allocated relayed transport address. Using the same spoofed source address technique, the attacker then binds a channel number on server A to the relayed transport address on server B, and similarly binds the same channel number on server B to the relayed transport address on server A. Finally, the attacker sends a ChannelData message to server A.
攻击者可能试图使数据包在两台TURN服务器之间无限循环。攻击如下。首先，攻击者使用服务器B的源地址向服务器A发送分配请求。服务器A将向服务器B发送其响应，为了使攻击成功，攻击者必须能够查看或猜测此响应的内容，以便攻击者能够了解分配的中继传输地址。然后，攻击者使用服务器A的源地址向服务器B发送分配请求。同样，攻击者必须能够查看或猜测响应的内容，以便发送并了解分配的中继传输地址。使用相同的伪造源地址技术，攻击者然后将服务器a上的通道号绑定到服务器B上的中继传输地址，并将服务器B上的相同通道号绑定到服务器a上的中继传输地址。最后，攻击者向服务器a发送ChannelData消息。
The result is a data packet that loops from the relayed transport address on server A to the relayed transport address on server B, then from server B's transport address to server A's transport address, and then around the loop again.
结果是数据包从服务器a上的中继传输地址循环到服务器B上的中继传输地址，然后从服务器B的传输地址循环到服务器a的传输地址，然后再次循环。
This attack is mitigated as follows. By requiring all requests to be authenticated and/or by randomizing the port number allocated for the relayed transport address, the server forces the attacker to either intercept or view responses sent to a third party (in this case, the other server) so that the attacker can authenticate the requests and learn the relayed transport address. Without one of these two measures, an attacker can guess the contents of the responses without
此攻击的缓解措施如下。通过要求对所有请求进行身份验证和/或随机分配给中继传输地址的端口号，服务器迫使攻击者拦截或查看发送给第三方（在本例中为另一台服务器）的响应，以便攻击者能够对请求进行身份验证并了解中继传输地址。如果没有这两种措施中的一种，攻击者就可以猜测响应的内容，而不必担心
needing to see them, which makes the attack much easier to perform. Furthermore, by requiring authenticated requests, the server forces the attacker to have credentials acceptable to the server, which turns this from an outsider attack into an insider attack and allows the attack to be traced back to the client initiating it.
需要看到他们，这使得攻击更容易执行。此外，通过要求经过身份验证的请求，服务器迫使攻击者拥有服务器可接受的凭据，从而将外部攻击转化为内部攻击，并允许将攻击追溯到发起攻击的客户端。
The attack can be further mitigated by imposing a per-username limit on the bandwidth used to relay data by allocations owned by that username, to limit the impact of this attack on other allocations. More mitigation can be achieved by decrementing the TTL when relaying data packets (if the underlying OS allows this).
通过对该用户名拥有的分配用于中继数据的带宽施加每个用户名的限制，以限制此攻击对其他分配的影响，可以进一步减轻攻击。在中继数据包时（如果底层操作系统允许的话），通过减少TTL可以实现更多的缓解。
A key security consideration of TURN is that TURN should not weaken the protections afforded by firewalls deployed between a client and a TURN server. It is anticipated that TURN servers will often be present on the public Internet, and clients may often be inside enterprise networks with corporate firewalls. If TURN servers provide a 'backdoor' for reaching into the enterprise, TURN will be blocked by these firewalls.
TURN的一个关键安全考虑因素是TURN不应削弱客户端和TURN服务器之间部署的防火墙提供的保护。预计TURN服务器通常会出现在公共互联网上，客户机可能经常位于企业网络内，并带有企业防火墙。如果TURN服务器提供进入企业的“后门”，TURN将被这些防火墙阻止。
TURN servers therefore emulate the behavior of NAT devices that implement address-dependent filtering [RFC4787], a property common in many firewalls as well. When a NAT or firewall implements this behavior, packets from an outside IP address are only allowed to be sent to an internal IP address and port if the internal IP address and port had recently sent a packet to that outside IP address. TURN servers introduce the concept of permissions, which provide exactly this same behavior on the TURN server. An attacker cannot send a packet to a TURN server and expect it to be relayed towards the client, unless the client has tried to contact the attacker first.
因此，TURN服务器模拟NAT设备的行为，这些设备实现了地址相关过滤[RFC4787]，这也是许多防火墙中常见的特性。当NAT或防火墙实现此行为时，仅当内部IP地址和端口最近向该外部IP地址发送了数据包时，才允许将来自外部IP地址的数据包发送到该内部IP地址和端口。TURN服务器引入了权限的概念，它在TURN服务器上提供了完全相同的行为。攻击者无法将数据包发送到TURN服务器并期望它被转发到客户端，除非客户端尝试先与攻击者联系。
It is important to note that some firewalls have policies that are even more restrictive than address-dependent filtering. Firewalls can also be configured with address- and port-dependent filtering, or can be configured to disallow inbound traffic entirely. In these cases, if a client is allowed to connect the TURN server, communications to the client will be less restrictive than what the firewall would normally allow.
需要注意的是，某些防火墙的策略甚至比地址相关过滤更具限制性。防火墙还可以配置地址和端口相关过滤，或者配置为完全不允许入站流量。在这些情况下，如果允许客户端连接TURN服务器，则与客户端的通信限制将小于防火墙通常允许的限制。
In firewalls and NAT devices, permissions are granted implicitly through the traversal of a packet from the inside of the network towards the outside peer. Thus, a permission cannot, by definition, be created by any entity except one inside the firewall or NAT. With TURN, this restriction no longer holds. Since the TURN server sits
在防火墙和NAT设备中，通过从网络内部向外部对等方遍历数据包来隐式授予权限。因此，根据定义，权限不能由防火墙或NAT内的实体之外的任何实体创建。轮换时，此限制不再有效。因为TURN服务器位于
outside the firewall, at attacker outside the firewall can now send a message to the TURN server and try to create a permission for itself.
在防火墙之外，位于防火墙之外的at攻击者现在可以向TURN服务器发送消息，并尝试为自己创建权限。
This attack is prevented because all messages that create permissions (i.e., ChannelBind and CreatePermission) are authenticated.
由于创建权限（即ChannelBind和CreatePermission）的所有消息都经过身份验证，因此阻止了此攻击。
Many firewalls can be configured with blacklists that prevent a client behind the firewall from sending packets to, or receiving packets from, ranges of blacklisted IP addresses. This is accomplished by inspecting the source and destination addresses of packets entering and exiting the firewall, respectively.
许多防火墙可以配置黑名单，以防止防火墙后面的客户端向黑名单IP地址范围发送数据包或从中接收数据包。这是通过分别检查进出防火墙的数据包的源地址和目标地址来实现的。
This feature is also present in TURN, since TURN servers are allowed to arbitrarily restrict the range of addresses of peers that they will relay to.
由于TURN服务器被允许任意限制它们将中继到的对等方的地址范围，因此该功能也会依次出现。
A malicious client behind a firewall might try to connect to a TURN server and obtain an allocation which it then uses to run a server. For example, a client might try to run a DNS server or FTP server.
防火墙后面的恶意客户端可能试图连接到TURN服务器并获得分配，然后使用该分配运行服务器。例如，客户端可能尝试运行DNS服务器或FTP服务器。
This is not possible in TURN. A TURN server will never accept traffic from a peer for which the client has not installed a permission. Thus, peers cannot just connect to the allocated port in order to obtain the service.
反过来，这是不可能的。TURN服务器永远不会接受来自客户端未安装权限的对等方的流量。因此，对等方不能仅仅连接到分配的端口以获得服务。
In insider attacks, a client has legitimate credentials but defies the trust relationship that goes with those credentials. These attacks cannot be prevented by cryptographic means but need to be considered in the design of the protocol.
在内幕攻击中，客户机拥有合法的凭据，但违反了与这些凭据相关的信任关系。这些攻击无法通过加密手段防止，但需要在协议设计中加以考虑。
A client wishing to disrupt service to other clients might obtain an allocation and then flood it with traffic, in an attempt to swamp the server and prevent it from servicing other legitimate clients. This is mitigated by the recommendation that the server limit the amount of bandwidth it will relay for a given username. This won't prevent a client from sending a large amount of traffic, but it allows the server to immediately discard traffic in excess.
希望中断对其他客户机的服务的客户机可能会获得一个分配，然后向其发送大量流量，试图淹没服务器并阻止它为其他合法客户机提供服务。通过建议服务器限制它将为给定用户名中继的带宽量，可以缓解这一问题。这不会阻止客户端发送大量流量，但它允许服务器立即丢弃多余的流量。
Since each allocation uses a port number on the IP address of the TURN server, the number of allocations on a server is finite. An
由于每次分配都使用TURN服务器IP地址上的端口号，因此服务器上的分配数量是有限的。一
attacker might attempt to consume all of them by requesting a large number of allocations. This is prevented by the recommendation that the server impose a limit of the number of allocations active at a time for a given username.
攻击者可能试图通过请求大量分配来消耗所有这些资源。这是由于建议服务器对给定用户名一次活动的分配数量施加限制而无法实现的。
TURN servers provide a degree of anonymization. A client can send data to peers without revealing its own IP address. TURN servers may therefore become attractive vehicles for attackers to launch attacks against targets without fear of detection. Indeed, it is possible for a client to chain together multiple TURN servers, such that any number of relays can be used before a target receives a packet.
TURN服务器提供一定程度的匿名化。客户端可以向对等方发送数据，而无需透露自己的IP地址。因此，TURN服务器可能成为攻击者对目标发起攻击而不必担心被发现的有吸引力的工具。实际上，客户机可以将多个TURN服务器链接在一起，以便在目标接收数据包之前可以使用任意数量的中继。
Administrators who are worried about this attack can maintain logs that capture the actual source IP and port of the client, and perhaps even every permission that client installs. This will allow for forensic tracing to determine the original source, should it be discovered that an attack is being relayed through a TURN server.
担心此攻击的管理员可以维护日志，以捕获客户端的实际源IP和端口，甚至客户端安装的每个权限。这将允许法医追踪，以确定原始来源，如果发现攻击正通过TURN服务器中继。
An attacker might attempt to disrupt service to other users of the TURN server by sending Refresh requests or CreatePermission requests that (through source address spoofing) appear to be coming from another user of the TURN server. TURN prevents this by requiring that the credentials used in CreatePermission, Refresh, and ChannelBind messages match those used to create the initial allocation. Thus, the fake requests from the attacker will be rejected.
攻击者可能试图通过发送刷新请求或CreatePermission请求（通过源地址欺骗）来中断对TURN服务器其他用户的服务，这些请求似乎来自TURN服务器的其他用户。TURN通过要求CreatePermission、Refresh和ChannelBind消息中使用的凭据与用于创建初始分配的凭据匹配来防止这种情况。因此，攻击者的假请求将被拒绝。
Any relay addresses learned through an Allocate request will not operate properly with IPsec Authentication Header (AH) [RFC4302] in transport or tunnel mode. However, tunnel-mode IPsec Encapsulating Security Payload (ESP) [RFC4303] should still operate.
在传输或隧道模式下，通过分配请求学习的任何中继地址在IPsec身份验证标头（AH）[RFC4302]下都无法正常工作。但是，隧道模式IPsec封装安全有效负载（ESP）[RFC4303]仍应运行。
Since TURN is an extension to STUN [RFC5389], the methods, attributes, and error codes defined in this specification are new methods, attributes, and error codes for STUN. IANA has added these new protocol elements to the IANA registry of STUN protocol elements.
由于TURN是STUN[RFC5389]的扩展，因此本规范中定义的方法、属性和错误代码是STUN的新方法、属性和错误代码。IANA已将这些新的协议元素添加到IANA STUN协议元素注册表中。
The codepoints for the new STUN methods defined in this specification are listed in Section 13.
第13节列出了本规范中定义的新STUN方法的代码点。
The codepoints for the new STUN attributes defined in this specification are listed in Section 14.
第14节列出了本规范中定义的新STUN属性的代码点。
The codepoints for the new STUN error codes defined in this specification are listed in Section 15.
第15节列出了本规范中定义的新STUN错误代码的代码点。
IANA has allocated the SRV service name of "turn" for TURN over UDP or TCP, and the service name of "turns" for TURN over TLS.
IANA已将SRV服务名称“turn”分配给翻转UDP或TCP，并将服务名称“turns”分配给翻转TLS。
IANA has created a registry for TURN channel numbers, initially populated as follows:
IANA已为转弯通道编号创建了一个注册表，初始填充如下：
0x0000 through 0x3FFF: Reserved and not available for use, since they conflict with the STUN header.
0x0000到0x3FFF：保留，不可使用，因为它们与STUN头冲突。
0x4000 through 0x7FFF: A TURN implementation is free to use channel numbers in this range.
0x4000到0x7FFF：TURN实现可在此范围内自由使用通道号。
0x8000 through 0xFFFF: Unassigned.
0x8000到0xFFFF：未分配。
Any change to this registry must be made through an IETF Standards Action.
必须通过IETF标准行动对此注册表进行任何更改。
The IAB has studied the problem of "Unilateral Self Address Fixing" (UNSAF), which is the general process by which a client attempts to determine its address in another realm on the other side of a NAT through a collaborative protocol-reflection mechanism [RFC3424]. The TURN extension is an example of a protocol that performs this type of function. The IAB has mandated that any protocols developed for this purpose document a specific set of considerations. These considerations and the responses for TURN are documented in this section.
IAB已经研究了“单边自地址固定”（UNSAF）问题，这是一个一般过程，通过该过程，客户端试图通过协作协议反射机制确定NAT另一侧另一领域中的地址[RFC3424]。TURN扩展是执行此类功能的协议的一个示例。IAB已授权为此目的制定的任何协议都应记录一组特定的考虑因素。本节记录了这些注意事项和TURN的响应。
Consideration 1: Precise definition of a specific, limited-scope problem that is to be solved with the UNSAF proposal. A short-term fix should not be generalized to solve other problems. Such generalizations lead to the prolonged dependence on and usage of the supposed short-term fix -- meaning that it is no longer accurate to call it "short-term".
考虑事项1：精确定义一个具体的、范围有限的问题，该问题将由UNSAF提案解决。短期解决方案不应推广到解决其他问题。这种泛化导致长期依赖和使用所谓的短期修正——这意味着称之为“短期修正”不再准确。
Response: TURN is a protocol for communication between a relay (= TURN server) and its client. The protocol allows a client that is behind a NAT to obtain and use a public IP address on the relay. As a convenience to the client, TURN also allows the client to determine its server-reflexive transport address.
响应：TURN是中继（=TURN服务器）与其客户端之间通信的协议。该协议允许NAT后面的客户端获取并使用中继上的公共IP地址。为了方便客户端，TURN还允许客户端确定其服务器自反传输地址。
Consideration 2: Description of an exit strategy/transition plan. The better short-term fixes are the ones that will naturally see less and less use as the appropriate technology is deployed.
考虑事项2：退出战略/过渡计划的说明。更好的短期修复方法是，随着适当技术的部署，自然会看到越来越少的使用。
Response: TURN will no longer be needed once there are no longer any NATs. Unfortunately, as of the date of publication of this document, it no longer seems very likely that NATs will go away any time soon. However, the need for TURN will also decrease as the number of NATs with the mapping property of Endpoint-Independent Mapping [RFC4787] increases.
回答：一旦不再有任何NAT，将不再需要TURN。不幸的是，自本文件发布之日起，NATs似乎不太可能很快消失。然而，随着具有端点独立映射[RFC4787]映射属性的NAT数量的增加，TURN的需求也将减少。
Consideration 3: Discussion of specific issues that may render systems more "brittle". For example, approaches that involve using data at multiple network layers create more dependencies, increase debugging challenges, and make it harder to transition.
考虑事项3：讨论可能使系统更“脆弱”的具体问题。例如，涉及在多个网络层使用数据的方法会产生更多的依赖性，增加调试挑战，并使转换更加困难。
Response: TURN is "brittle" in that it requires the NAT bindings between the client and the server to be maintained unchanged for the lifetime of the allocation. This is typically done using keep-alives. If this is not done, then the client will lose its allocation and can no longer exchange data with its peers.
响应：TURN是“脆弱的”，因为它要求客户端和服务器之间的NAT绑定在分配的生命周期内保持不变。这通常是使用keep alives完成的。如果不这样做，则客户端将丢失其分配，并且无法再与其对等方交换数据。
Consideration 4: Identify requirements for longer-term, sound technical solutions; contribute to the process of finding the right longer-term solution.
考虑4：确定长期、可靠的技术解决方案的要求；有助于找到正确的长期解决方案。
Response: The need for TURN will be reduced once NATs implement the recommendations for NAT UDP behavior documented in [RFC4787]. Applications are also strongly urged to use ICE [RFC5245] to communicate with peers; though ICE uses TURN, it does so only as a last resort, and uses it in a controlled manner.
响应：一旦NAT实施[RFC4787]中记录的NAT UDP行为建议，TURN的需求将减少。强烈建议应用程序使用ICE[RFC5245]与同行进行通信；尽管ICE使用TURN，但它只是作为最后手段，并以可控的方式使用TURN。
Consideration 5: Discussion of the impact of the noted practical issues with existing deployed NATs and experience reports.
考虑事项5：与现有部署的NAT和经验报告讨论注意到的实际问题的影响。
Response: Some NATs deployed today exhibit a mapping behavior other than Endpoint-Independent mapping. These NATs are difficult to work with, as they make it difficult or impossible for protocols like ICE to use server-reflexive transport addresses on those NATs. A client behind such a NAT is often forced to use a relay protocol like TURN because "UDP hole punching" techniques [RFC5128] do not work.
响应：今天部署的一些NAT表现出与端点无关的映射行为。这些NAT很难使用，因为它们使得像ICE这样的协议很难或不可能在这些NAT上使用服务器自反传输地址。这种NAT背后的客户端通常被迫使用TURN之类的中继协议，因为“UDP打孔”技术[RFC5128]不起作用。
The authors would like to thank the various participants in the BEHAVE working group for their many comments on this document. Marc Petit-Huguenin, Remi Denis-Courmont, Jason Fischl, Derek MacDonald, Scott Godin, Cullen Jennings, Lars Eggert, Magnus Westerlund, Benny
作者感谢BEHAVE工作组的各位与会者对本文件提出的许多意见。马克·佩蒂·胡格宁、雷米·丹尼斯·库尔蒙、杰森·菲舍尔、德里克·麦克唐纳、斯科特·戈丁、卡伦·詹宁斯、拉尔斯·艾格特、马格纳斯·韦斯特隆德、本尼
Prijono, and Eric Rescorla have been particularly helpful, with Eric suggesting the channel allocation mechanism, Cullen suggesting an earlier version of the EVEN-PORT mechanism, and Marc spending many hours implementing the preliminary versions to look for problems. Christian Huitema was an early contributor to this document and was a co-author on the first few versions. Finally, the authors would like to thank Dan Wing for both his contributions to the text and his huge help in restarting progress on this document after work had stalled.
Prijono和Eric Rescorla特别有帮助，Eric提出了通道分配机制，Cullen提出了早期版本的偶数端口机制，Marc花了很多时间实施初步版本以查找问题。Christian Huitema是本文件的早期撰稿人，也是前几个版本的合著者。最后，作者要感谢Dan Wing，感谢他对文本的贡献，感谢他在工作停滞后为重新启动本文件的进展提供的巨大帮助。
[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月。
[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月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[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月。
[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月。
[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月。
[TURN-TCP] Perreault, S. and J. Rosenberg, "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", Work in Progress, March 2010.
[TURN-TCP]Perreault，S.和J.Rosenberg，“围绕TCP分配的NAT（TURN）扩展使用中继进行遍历”，正在进行的工作，2010年3月。
[TURN-IPv6] Perreault, S., Camarillo, G., and O. Novo, "Traversal Using Relays around NAT (TURN) Extension for IPv6", Work in Progress, March 2010.
[TURN-IPv6]Perreault，S.，Camarillo，G.，和O.Novo，“围绕IPv6的NAT（TURN）扩展使用中继进行遍历”，正在进行的工作，2010年3月。
[TSVWG-PORT] Larsen, M. and F. Gont, "Port Randomization", Work in Progress, April 2010.
[TSVWG-PORT]Larsen，M.和F.Gont，“港口随机化”，正在进行的工作，2010年4月。
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)", RFC 5128, March 2008.
[RFC5128]Srisuresh，P.，Ford，B.，和D.Kegel，“跨网络地址转换器（NAT）的对等（P2P）通信状态”，RFC 51282008年3月。
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
[RFC1928]Leech，M.，Ganis，M.，Lee，Y.，Kuris，R.，Koblas，D.，和L.Jones，“SOCKS协议版本5”，RFC 19281996年3月。
[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月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年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月。
[MMUSIC-ICE-NONSIP] Rosenberg, J., "Guidelines for Usage of Interactive Connectivity Establishment (ICE) by non Session Initiation Protocol (SIP) Protocols", Work in Progress, July 2008.
[MMUSIC-ICE-NONSIP]Rosenberg，J.，“非会话启动协议（SIP）使用交互式连接建立（ICE）的指南”，正在进行的工作，2008年7月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[Frag-Harmful] Kent and Mogul, "Fragmentation Considered Harmful". Proc. SIGCOMM '87, vol. 17, No. 5, October 1987
[Frag有害]Kent和Mogul，“碎片化被认为是有害的”。过程。SIGCOMM'87，第17卷，第5期，1987年10月
[Port-Numbers] "IANA Port Numbers Registry", <http://www.iana.org>.
[端口号]“IANA端口号注册表”<http://www.iana.org>.
[Protocol-Numbers] "IANA Protocol Numbers Registry", 2005, <http://www.iana.org>.
[协议编号]“IANA协议编号登记册”，2005年<http://www.iana.org>.
Authors' Addresses
作者地址
Rohan Mahy Unaffiliated
Rohan Mahy非附属公司
EMail: rohan@ekabal.com
EMail: rohan@ekabal.com
Philip Matthews Alcatel-Lucent 600 March Road Ottawa, Ontario Canada
加拿大安大略省渥太华市3月路600号菲利普·马修斯阿尔卡特朗讯公司
EMail: philip_matthews@magma.ca
EMail: philip_matthews@magma.ca
Jonathan Rosenberg jdrosen.net Monmouth, NJ USA
Jonathan Rosenberg jdrosen.net美国新泽西州蒙茅斯
EMail: jdrosen@jdrosen.net
URI: http://www.jdrosen.net
EMail: jdrosen@jdrosen.net
URI: http://www.jdrosen.net