Internet Engineering Task Force (IETF) A. Begen
Request for Comments: 6284 D. Wing
Category: Standards Track Cisco
ISSN: 2070-1721 T. Van Caenegem
Alcatel-Lucent
June 2011
Internet Engineering Task Force (IETF) A. Begen
Request for Comments: 6284 D. Wing
Category: Standards Track Cisco
ISSN: 2070-1721 T. Van Caenegem
Alcatel-Lucent
June 2011
Port Mapping between Unicast and Multicast RTP Sessions
单播和多播RTP会话之间的端口映射
Abstract
摘要
This document presents a port mapping solution that allows RTP receivers to choose their own ports for an auxiliary unicast session in RTP applications using both unicast and multicast services. The solution provides protection against denial-of-service or packet amplification attacks that could be used to cause one or more RTP packets to be sent to a victim client.
本文档介绍了一种端口映射解决方案，该解决方案允许RTP接收器为使用单播和多播服务的RTP应用程序中的辅助单播会话选择自己的端口。该解决方案提供了针对拒绝服务或数据包放大攻击的保护，这些攻击可用于将一个或多个RTP数据包发送到受害客户端。
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/rfc6284.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6284.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Token-Based Port Mapping . . . . . . . . . . . . . . . . . . . 5
3.1. Motivating Scenario . . . . . . . . . . . . . . . . . . . 6
3.2. Normative Behavior and Requirements . . . . . . . . . . . 9
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Port Mapping Request . . . . . . . . . . . . . . . . . . . 12
4.2. Port Mapping Response . . . . . . . . . . . . . . . . . . 13
4.3. Token Verification Request . . . . . . . . . . . . . . . . 15
4.3.1. Where to Include Token . . . . . . . . . . . . . . . . 16
4.4. Token Verification Failure . . . . . . . . . . . . . . . . 17
5. Procedures for Token Construction . . . . . . . . . . . . . . 18
6. Validating Tokens . . . . . . . . . . . . . . . . . . . . . . 20
7. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. The 'portmapping-req' Attribute . . . . . . . . . . . . . 21
7.1.1. ABNF Definition of 'portmapping-req' . . . . . . . . . 21
7.1.2. Offer/Answer Model Considerations . . . . . . . . . . 22
7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 22
7.3. Example and Discussion . . . . . . . . . . . . . . . . . . 23
8. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.2. The 'portmapping-req' Attribute . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10.1. Registration of SDP Attributes . . . . . . . . . . . . . . 26
10.2. Registration of RTCP Control Packet Types . . . . . . . . 27
10.3. SMT Values for TOKEN Packet Type Registry . . . . . . . . 27
10.4. RAMS Response Code Space Registry . . . . . . . . . . . . 27
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . . 29
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Token-Based Port Mapping . . . . . . . . . . . . . . . . . . . 5
3.1. Motivating Scenario . . . . . . . . . . . . . . . . . . . 6
3.2. Normative Behavior and Requirements . . . . . . . . . . . 9
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Port Mapping Request . . . . . . . . . . . . . . . . . . . 12
4.2. Port Mapping Response . . . . . . . . . . . . . . . . . . 13
4.3. Token Verification Request . . . . . . . . . . . . . . . . 15
4.3.1. Where to Include Token . . . . . . . . . . . . . . . . 16
4.4. Token Verification Failure . . . . . . . . . . . . . . . . 17
5. Procedures for Token Construction . . . . . . . . . . . . . . 18
6. Validating Tokens . . . . . . . . . . . . . . . . . . . . . . 20
7. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. The 'portmapping-req' Attribute . . . . . . . . . . . . . 21
7.1.1. ABNF Definition of 'portmapping-req' . . . . . . . . . 21
7.1.2. Offer/Answer Model Considerations . . . . . . . . . . 22
7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 22
7.3. Example and Discussion . . . . . . . . . . . . . . . . . . 23
8. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.2. The 'portmapping-req' Attribute . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10.1. Registration of SDP Attributes . . . . . . . . . . . . . . 26
10.2. Registration of RTCP Control Packet Types . . . . . . . . 27
10.3. SMT Values for TOKEN Packet Type Registry . . . . . . . . 27
10.4. RAMS Response Code Space Registry . . . . . . . . . . . . 27
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . . 29
In (any-source or source-specific) multicast RTP applications, destination ports (i.e., the ports on which the multicast receivers receive the RTP and RTP Control Protocol (RTCP) packets) are defined declaratively. In other words, the receivers cannot choose their receive ports, and the sender(s) use the predefined ports.
在（任何源或源特定的）多播RTP应用程序中，目标端口（即多播接收器接收RTP和RTP控制协议（RTCP）数据包的端口）以声明方式定义。换句话说，接收方不能选择其接收端口，而发送方使用预定义的端口。
In unicast RTP applications, the receiving end needs to choose its ports for RTP and RTCP since these ports are local resources and only the receiving end can determine which ports are available to use. In addition, Network Address Port Translation (NAPT, hereafter simply called NAT) devices are commonly deployed in networks; thus, static port assignments cannot be used. The receiving end may convey its request to the sending end through different ways, one of which is the Offer/Answer Model [RFC3264] for the Session Description Protocol (SDP) [RFC4566]. However, the Offer/Answer Model requires offer/ answer exchange(s) between the endpoints, and the resulting delay may not be desirable in delay-sensitive real-time applications. Furthermore, the Offer/Answer Model may be burdensome for the endpoints that are concurrently running a large number of unicast sessions with other endpoints.
在单播RTP应用程序中，接收端需要为RTP和RTCP选择端口，因为这些端口是本地资源，只有接收端可以确定哪些端口可用。此外，网络地址端口转换（NAPT，以下简称NAT）设备通常部署在网络中；因此，不能使用静态端口分配。接收端可以通过不同的方式将其请求传送给发送端，其中之一是会话描述协议（SDP）[RFC4566]的提供/应答模型[rfc326]。然而，提供/应答模型需要端点之间的提供/应答交换，并且在对延迟敏感的实时应用程序中，可能不希望产生延迟。此外，对于与其他端点同时运行大量单播会话的端点，提供/应答模型可能是负担。
In this specification, we consider an RTP application that uses one or more unicast and multicast RTP sessions together. While the declaration and selection of the ports are well defined and work well for multicast and unicast RTP applications, respectively, the usage of the ports introduces complications when a receiving end mixes unicast and multicast RTP sessions within the same RTP application.
在本规范中，我们考虑使用一个或多个单播和多播RTP会话的RTP应用。虽然端口的声明和选择定义良好，并且分别适用于多播和单播RTP应用程序，但当接收端在同一RTP应用程序中混合单播和多播RTP会话时，端口的使用会带来复杂性。
An example scenario is where the RTP packets are distributed through source-specific multicast (SSM) [RFC4607] and a receiver sends unicast RTCP NACK feedback [RFC4585] to a local repair server (also functioning as a unicast RTCP feedback target) [RFC5760] asking for a retransmission of the packets it is missing, and the local repair server sends the retransmission packets over a unicast RTP session [RETRANSMISSION-FOR-SSM].
一个示例场景是，RTP分组通过源特定多播（SSM）[RFC4607]分发，并且接收机向本地修复服务器（也用作单播RTCP反馈目标）[RFC5760]发送单播RTCP NACK反馈[RFC4585]，请求重新传输丢失的分组，并且本地修复服务器通过单播RTP会话[retransmission-FOR-SSM]发送重传分组。
Another scenario is where a receiver wants to rapidly acquire a new primary multicast RTP session and receives one or more RTP burst packets over a unicast session before joining the SSM session; see [RFC6285] regarding Rapid Acquisition of Multicast RTP Sessions (RAMS). Similar scenarios exist in applications where some part of the content is distributed through multicast while the receivers get additional and/or auxiliary content through one or more unicast connections, as illustrated in Figure 1.
另一个场景是，接收机希望快速获取新的主多播RTP会话，并在加入SSM会话之前通过单播会话接收一个或多个RTP突发分组；有关多播RTP会话（RAM）的快速获取，请参阅[RFC6285]。在应用程序中也存在类似的场景，其中部分内容通过多播分发，而接收方通过一个或多个单播连接获得附加和/或辅助内容，如图1所示。
In this document, we discuss this problem and introduce a solution that we refer to as port mapping. This solution allows receivers to choose their desired UDP ports for RTP and RTCP in every unicast session when they are running RTP applications using both unicast and multicast services and offer/answer exchange is not available. The solution includes a Token-based protection mechanism against denial-of-service (DoS) or packet amplification attacks that could be used to cause one or more RTP packets to be sent to a victim client. This solution is not applicable in cases where TCP is used as the transport protocol in the unicast sessions. For such scenarios, refer to [RFC4145].
在本文中，我们将讨论这个问题，并介绍一个称为端口映射的解决方案。此解决方案允许接收器在运行同时使用单播和多播服务的RTP应用程序且提供/应答交换不可用时，在每个单播会话中为RTP和RTCP选择所需的UDP端口。该解决方案包括一种基于令牌的保护机制，用于防止拒绝服务（DoS）或数据包放大攻击，这些攻击可用于将一个或多个RTP数据包发送到受害客户端。此解决方案不适用于在单播会话中将TCP用作传输协议的情况。有关此类场景，请参阅[RFC4145]。
-----------
| Unicast |................
| Source |............. :
| (Server) | : :
----------- : :
v v
----------- ---------- -----------
| Multicast |------->| Router |---------->|Client RTP |
| Source | | |..........>|Application|
----------- ---------- -----------
| :
| : -----------
| :..............>|Client RTP |
+---------------->|Application|
-----------
-----------
| Unicast |................
| Source |............. :
| (Server) | : :
----------- : :
v v
----------- ---------- -----------
| Multicast |------->| Router |---------->|Client RTP |
| Source | | |..........>|Application|
----------- ---------- -----------
| :
| : -----------
| :..............>|Client RTP |
+---------------->|Application|
-----------
-------> Multicast RTP Flow
.......> Unicast RTP Flow
-------> Multicast RTP Flow
.......> Unicast RTP Flow
Figure 1: RTP Applications Simultaneously Using Both Unicast and Multicast Services
图1：同时使用单播和多播服务的RTP应用程序
In the remainder of this document, we refer to the RTP endpoints that serve other RTP endpoints over a unicast session as the Servers. The receiving RTP endpoints are referred to as Clients. This terminology also reflects the fact that when port mapping is used, the RTP packets can only flow in one direction (from the server to the client) in the unicast sessions.
在本文档的其余部分中，我们将通过单播会话为其他RTP端点提供服务的RTP端点称为服务器。接收RTP端点称为客户端。该术语还反映了这样一个事实，即当使用端口映射时，RTP数据包在单播会话中只能朝一个方向（从服务器到客户端）流动。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
Token-based port mapping consists of the server providing the client a Token that can be used to establish a unicast session without the possibility of an attacker redirecting traffic to an unsuspecting third party to create a DoS attack. The Token is essentially an opaque encapsulation that is based on the client's IP address (as seen by the server), a time-to-live value, and a random nonce provided by the client.
基于令牌的端口映射由服务器向客户端提供令牌组成，令牌可用于建立单播会话，而攻击者不可能将通信重定向到不知情的第三方以创建DoS攻击。令牌本质上是一个不透明的封装，它基于客户端的IP地址（如服务器所见）、生存时间值和客户端提供的随机nonce。
Token-based port mapping consists of two steps: (i) Token request and retrieval, and (ii) unicast session establishment.
基于令牌的端口映射包括两个步骤：（i）令牌请求和检索，以及（ii）单播会话建立。
When a Token request is received, the server creates a Token for this particular client and sends it back to the client.
当接收到令牌请求时，服务器将为此特定客户端创建令牌并将其发送回客户端。
Once a Token is retrieved from a particular server, it can be used for all the unicast sessions the client will be running with this particular server until the Token expires. By default, Tokens are server specific. However, the client can use the same Token to communicate with different servers if these servers are provided with the same secret key and algorithm used to generate the Token and are at least loosely clock-synchronized.
一旦从特定服务器检索到令牌，它就可以用于客户端将使用该特定服务器运行的所有单播会话，直到令牌过期。默认情况下，令牌是特定于服务器的。然而，如果为不同的服务器提供用于生成令牌的相同密钥和算法，并且至少是松散的时钟同步，则客户端可以使用相同的令牌与不同的服务器通信。
The Token becomes invalid if the client's IP address (as seen by the server) changes (note that the client cannot necessarily detect this in a timely manner) or if the server expires the Token. In these cases, the client has to request a new Token.
如果客户端的IP地址（由服务器看到）发生更改（注意，客户端不一定能及时检测到），或者如果服务器使令牌过期，则令牌将无效。在这些情况下，客户端必须请求一个新令牌。
As the second step, when the client wants to establish a unicast session, the client includes the Token with its RTCP feedback message. The server validates the Token, making sure that the IP address information matches. This is effective against DoS attacks, e.g., an attacker cannot simply spoof another client's IP address and start a unicast transmission towards random clients. If the validation passes, the unicast session gets established. Otherwise, the server notifies the client that the validation has failed, and in this case, the unicast session will not be established.
作为第二步，当客户机想要建立单播会话时，客户机将令牌包括在其RTCP反馈消息中。服务器验证令牌，确保IP地址信息匹配。这对DoS攻击是有效的，例如，攻击者不能简单地欺骗另一个客户端的IP地址，并开始向随机客户端进行单播传输。如果验证通过，将建立单播会话。否则，服务器将通知客户端验证失败，在这种情况下，将不会建立单播会话。
Upon successful validation and once the unicast session is established, all the RTP and RTCP rules specified in [RFC3550] and other relevant specifications also apply in this session until it is terminated. During the lifetime of a unicast session, a client might need to send RTCP messages that require authorization. Since such messages require a valid Token for authorization, the client needs to include the Token along with such RTCP messages as explained in detail in later sections of this document.
成功验证后，单播会话建立后，[RFC3550]和其他相关规范中规定的所有RTP和RTCP规则也适用于该会话，直到终止。在单播会话的生存期内，客户端可能需要发送需要授权的RTCP消息。由于此类消息需要有效的令牌进行授权，因此客户机需要将令牌与此类RTCP消息一起包含，本文档后面部分将对此进行详细说明。
Below, we first present a motivating scenario for port mapping and then describe the normative behavior and requirements.
下面，我们首先介绍端口映射的激励场景，然后描述规范行为和需求。
Consider an SSM distribution network where a distribution source multicasts RTP packets to a large number of clients, and one or more retransmission servers function as feedback targets to collect unicast RTCP feedback from these clients [RFC5760]. The retransmission servers also join the multicast session to receive the multicast packets and cache them for a certain time period. When a client detects missing packets in the multicast session, it requests a retransmission from one of the retransmission servers by using an RTCP NACK message [RFC4585]. The retransmission server pulls the requested packet(s) out of the cache and retransmits them to the requesting client [RETRANSMISSION-FOR-SSM].
考虑SSM分发网络，其中分发源将RTP分组组播到大量客户端，并且一个或多个重传服务器用作反馈目标，以收集来自这些客户端的单播RTCP反馈[RCFC6060]。重传服务器还加入多播会话以接收多播数据包并将其缓存一定时间段。当客户端在多播会话中检测到丢失的数据包时，它使用RTCP NACK消息[RFC4585]从其中一个重传服务器请求重传。重传服务器将请求的数据包从缓存中取出，并将其重传给请求客户端[retransmission-FOR-SSM]。
The RTP and RTCP flows pertaining to the scenario described above are illustrated in Figure 2. Between the client and server, we assume there exists at least one NAT device [RFC4787]. (If there are no NAT devices between the server and client, the method still works in the same fashion.) The multicast and unicast sessions are clearly identified with their individual RTP and RTCP flows and port numbers.
与上述场景相关的RTP和RTCP流如图2所示。在客户端和服务器之间，我们假设至少存在一个NAT设备[RFC4787]。（如果服务器和客户端之间没有NAT设备，则该方法仍以相同的方式工作。）多播和单播会话用各自的RTP和RTCP流以及端口号清楚地标识。
-------------- --- ----------
| |-------------------------------| |-->|P1 |
| |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |.->|P2 |
| | | | | |
| Distribution | ---------------- | | | |
| Source | | | | | | |
| |---->|P1 | | | | |
| |.-.->|P2 | | | | |
| | | | | | | |
-------------- | P3|<.=.=.=.| |=.=|*c0 |
| P3|<~~~~~~~| |~~~|*c1 |
MULTICAST RTP | | | | | |
SESSION with | | | N | | |
UNICAST FEEDBACK | | | A | | |
| Retransmission | | T | | Client |
- - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|-
| Server | | | | |
| | | | | |
PORT MAPPING | PT|<~~~~~~~| |~~>|*cT |
| | | | | |
- - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|-
| | | | | |
AUXILIARY UNICAST | | | | | |
RTP SESSION | | | | | |
| P3|........| |..>|*c1 |
| P3|=.=.=.=.| |=.>|*c1 |
| P4|<.=.=.=.| |=.=|*c2 |
| | | | | |
---------------- --- ----------
-------------- --- ----------
| |-------------------------------| |-->|P1 |
| |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |.->|P2 |
| | | | | |
| Distribution | ---------------- | | | |
| Source | | | | | | |
| |---->|P1 | | | | |
| |.-.->|P2 | | | | |
| | | | | | | |
-------------- | P3|<.=.=.=.| |=.=|*c0 |
| P3|<~~~~~~~| |~~~|*c1 |
MULTICAST RTP | | | | | |
SESSION with | | | N | | |
UNICAST FEEDBACK | | | A | | |
| Retransmission | | T | | Client |
- - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|-
| Server | | | | |
| | | | | |
PORT MAPPING | PT|<~~~~~~~| |~~>|*cT |
| | | | | |
- - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|-
| | | | | |
AUXILIARY UNICAST | | | | | |
RTP SESSION | | | | | |
| P3|........| |..>|*c1 |
| P3|=.=.=.=.| |=.>|*c1 |
| P4|<.=.=.=.| |=.=|*c2 |
| | | | | |
---------------- --- ----------
-------> Multicast RTP Flow
.-.-.-.> Multicast RTCP Flow
.=.=.=.> Unicast RTCP Reports
~~~~~~~> Unicast RTCP (Feedback) Messages
.......> Unicast RTP Flow
-------> Multicast RTP Flow
.-.-.-.> Multicast RTCP Flow
.=.=.=.> Unicast RTCP Reports
~~~~~~~> Unicast RTCP (Feedback) Messages
.......> Unicast RTP Flow
Figure 2: Example Scenario Showing an SSM Distribution with Support for Retransmissions from a Server
图2：示例场景显示了支持从服务器重新传输的SSM分发
In Figure 2, we have the following multicast and unicast ports:
在图2中，我们有以下多播和单播端口：
o Ports P1 and P2 denote the destination RTP and RTCP ports in the multicast session, respectively. The clients listen to these ports to receive the multicast RTP and RTCP packets. Ports P1 and P2 are defined declaratively.
o 端口P1和P2分别表示多播会话中的目标RTP和RTCP端口。客户端侦听这些端口以接收多播RTP和RTCP数据包。端口P1和P2是以声明方式定义的。
o Port P3 denotes the RTCP port on the feedback target running on the retransmission server to collect any RTCP packet sent by the clients, including feedback messages and RTCP receiver and extended reports. This is also the port that the retransmission server uses to send the RTP packets and RTCP sender reports in the unicast session. Port P3 is defined declaratively.
o 端口P3表示在重传服务器上运行的反馈目标上的RTCP端口，用于收集客户端发送的任何RTCP数据包，包括反馈消息、RTCP接收器和扩展报告。这也是重传服务器用于在单播会话中发送RTP数据包和RTCP发送方报告的端口。端口P3是以声明方式定义的。
o Port P4 denotes the RTCP port on the retransmission server used to collect the RTCP receiver and extended reports for the unicast session. Port P4 is defined declaratively.
o 端口P4表示重传服务器上的RTCP端口，用于收集单播会话的RTCP接收器和扩展报告。端口P4是以声明方式定义的。
o Ports *c0, *c1, and *c2 are chosen by the client. (Note: "*" indicates that the port can be chosen randomly; once chosen, the "*" is no longer used.) *c0 denotes the port on the client used to send the RTCP reports for the multicast session. *c1 denotes the port on the client used to send the unicast RTCP feedback messages in the multicast session and to receive the RTP packets and RTCP sender reports in the unicast session. *c2 denotes the port on the client used to send the RTCP receiver and extended reports in the unicast session. Ports c0, c1, and c2 could be the same port or different ports. There are two advantages of using the same port for both c0 and c1:
o 端口*c0、*c1和*c2由客户端选择。（注意：“*”表示可以随机选择端口；选择后，“*”将不再使用。）*c0表示客户端上用于发送多播会话RTCP报告的端口*c1表示客户端上的端口，用于在多播会话中发送单播RTCP反馈消息，并在单播会话中接收RTP数据包和RTCP发送方报告*c2表示客户端上用于在单播会话中发送RTCP接收器和扩展报告的端口。端口c0、c1和c2可以是相同的端口，也可以是不同的端口。对c0和c1使用同一端口有两个优点：
1. Some NATs only keep bindings active when a packet goes from the inside to the outside of the NAT (see REQ-6 of Section 4.3 of [RFC4787]). When the gap between the packets sent from the client to the server is long, this can exceed the timeout limit. If c0=c1, the occasional (periodic) RTCP receiver reports sent from port c0 (for the multicast session's RTCP port P3) will ensure the NAT does not time out the public port associated with the incoming unicast traffic to port c1.
1. 一些NAT仅在数据包从NAT内部到外部时才保持绑定活动（参见[RFC4787]第4.3节的REQ-6]）。当从客户端发送到服务器的数据包之间的间隔较长时，这可能会超过超时限制。如果c0=c1，则从端口c0（用于多播会话的RTCP端口P3）发送的偶尔（定期）RTCP接收器报告将确保NAT不会超时与端口c1的传入单播通信量相关的公共端口。
2. Having c0=c1 conserves NAT port bindings.
2. c0=c1保留NAT端口绑定。
o Ports PT and *cT denote the ports through which the Token request and retrieval occur at the server and client sides, respectively. Port PT is declared on a per-unicast-session basis, although the same port could be used for two or more unicast sessions sourced by the server. A Token once requested and retrieved by a client from port PT remains valid until its expiration time.
o 端口PT和*cT分别表示在服务器端和客户端进行令牌请求和检索的端口。端口PT是在每个单播会话的基础上声明的，尽管同一端口可用于服务器源的两个或多个单播会话。客户端从端口PT请求和检索的令牌在到期之前保持有效。
We assume that the information declaratively defined is available as part of the session description information and is provided to the clients. The Session Description Protocol (SDP) [RFC4566] and other session description methods can be used for this purpose.
我们假设声明定义的信息作为会话描述信息的一部分可用，并提供给客户端。会话描述协议（SDP）[RFC4566]和其他会话描述方法可用于此目的。
In this section, we describe the normative behavior and requirements. To simplify the presentation, we refer to the port numbers described in the example presented in Figure 2. However, the behavior and requirements described here are not specific to that particular example and can be applied to any scenario where analogous ports can be identified.
在本节中，我们将描述规范行为和要求。为了简化演示，我们参考图2中示例中描述的端口号。但是，此处描述的行为和需求并不特定于该特定示例，可以应用于可以识别类似端口的任何场景。
First of all, a client compliant with this specification MUST be able to include a Token with any type of RTCP message (as described below) when it is needed.
首先，符合此规范的客户机必须能够在需要时将令牌与任何类型的RTCP消息（如下所述）一起包含。
Second, the solution provided in this specification is not applicable in cases where there is RTP traffic flowing from the client to the server in the unicast session. In other words, the direction of RTP traffic MUST be only from the server to the client in the unicast session. If the client wants to send RTP traffic back to the server, the regular session establishment methods such as [RFC3264] need to be used.
第二，本规范中提供的解决方案不适用于单播会话中存在从客户端到服务器的RTP流量的情况。换句话说，RTP通信的方向必须仅在单播会话中从服务器到客户端。如果客户端希望将RTP通信发送回服务器，则需要使用[RFC3264]等常规会话建立方法。
The following steps summarize the Token-based solution:
以下步骤总结了基于令牌的解决方案：
1. The client ascertains server address and port numbers (P3, P4 and PT) from the session description. Port P4 MUST be different from port P3. Port PT MAY be equal to port P3.
1. 客户端根据会话描述确定服务器地址和端口号（P3、P4和PT）。端口P4必须与端口P3不同。端口PT可能等于端口P3。
2. The client selects its local port numbers (*c0, *c1, *c2 and *cT). It is strongly RECOMMENDED that the client uses the same port for c0 and c1. Port cT MAY be equal to ports c0 and c1.
2. 客户端选择其本地端口号（*c0、*c1、*c2和*cT）。强烈建议客户端对c0和c1使用相同的端口。端口cT可能等于端口c0和c1。
3. If the client does not have a Token (or the existing Token has expired):
3. 如果客户端没有令牌（或现有令牌已过期）：
A. The client first sends a Port Mapping Request message (Section 4.1) to port PT. This message is sent from port cT on the client side. The server learns the client's IP address from the received message. The client can send this message anytime it wants (e.g., during initialization) and does not normally ever need to resend this message (see Section 6).
A.客户端首先向端口PT发送端口映射请求消息（第4.1节）。此消息从客户端的端口cT发送。服务器从收到的消息中学习客户端的IP地址。客户端可以随时发送此消息（例如，在初始化期间），并且通常不需要重新发送此消息（参见第6节）。
B. The server generates an opaque encapsulation (i.e., the Token) based on certain information, including the client's IP address.
B.服务器根据特定信息（包括客户端的IP地址）生成不透明封装（即令牌）。
C. The server sends the Token back to the client using a Port Mapping Response message (Section 4.2). This message MUST be sent from port PT towards port cT.
C.服务器使用端口映射响应消息将令牌发送回客户端（第4.2节）。此消息必须从端口PT发送到端口cT。
4. The client needs to provide the Token to the server using a Token Verification Request message (Section 4.3) whenever the client sends an RTCP feedback message for triggering or controlling a unicast session (see Section 4.3.1). If the Token is invalid or missing, the server sends a Token Verification Failure message (Section 4.4) to the client.
4. 每当客户端发送RTCP反馈消息以触发或控制单播会话时，客户端需要使用令牌验证请求消息（第4.3节）向服务器提供令牌（见第4.3.1节）。如果令牌无效或丢失，服务器将向客户端发送令牌验证失败消息（第4.4节）。
Note that the unicast session is only established after the server has received a feedback message (along with a valid Token) from the client for which it needs to react by sending unicast data. Until a unicast session is established, neither the server nor the client needs to send RTCP reports for the unicast session.
请注意，只有在服务器从客户端接收到反馈消息（以及有效令牌）后，才会建立单播会话，服务器需要通过发送单播数据对该消息做出反应。在建立单播会话之前，服务器和客户端都不需要发送单播会话的RTCP报告。
5. Normal flows ensue as shown in Figure 2. It is strongly RECOMMENDED that the client uses the same port for both c0 and c1, as this causes the periodic RTCP reports to keep the NAT mapping alive. However, if the client uses different ports for c0 and c1, the client MUST keep its own NAT mapping alive for the P3->c1 session (see [RFC6263] for additional information).
5. 正常流量如图2所示。强烈建议客户端对c0和c1使用相同的端口，因为这会导致定期RTCP报告保持NAT映射活动。但是，如果客户端对c0和c1使用不同的端口，则客户端必须为P3->c1会话保持其自己的NAT映射处于活动状态（有关更多信息，请参阅[RFC6263]）。
In the unicast session, traffic from the server to the client (i.e., both the RTP and RTCP packets sent from port P3 towards port c1) MUST be multiplexed on the same port [RFC5761].
在单播会话中，从服务器到客户端的通信量（即从端口P3发送到端口c1的RTP和RTCP数据包）必须在同一端口上多路复用[RFC5761]。
The client sends the RTCP receiver and extended reports in the unicast session from port c2 towards port P4. The server correlates these reports with the reports received in the multicast session based on the client's RTCP Canonical Name (CNAME). Thus, the client MUST use the same RTCP CNAME in both sessions, and its RTCP CNAME MUST be unique [RFC6222].
客户端在单播会话中从端口c2向端口P4发送RTCP接收器和扩展报告。服务器根据客户端的RTCP规范名称（CNAME）将这些报告与多播会话中接收到的报告关联起来。因此，客户端必须在两个会话中使用相同的RTCP CNAME，并且其RTCP CNAME必须是唯一的[RFC6222]。
A unicast session on a particular receive port c1 can last as long as the associated multicast session lasts. However, a client cannot keep using the same receive port c1 for different subsequent unicast sessions since there could be packet leakage when switching from one unicast session to another unless each received unicast stream has its own distinct Synchronization Source (SSRC) identifier to allow the client to filter out the undesired packets. Unless this is guaranteed (which is not often easy), a client SHOULD use separate receive ports for subsequent unicast sessions. After a sufficient time (two minutes is RECOMMENDED, similar to one TCP Maximum Segment Lifetime specified in [RFC0793]), a previously used receive port can be used again.
特定接收端口c1上的单播会话可以持续相关联的多播会话的时间。然而，客户端不能为不同的后续单播会话继续使用相同的接收端口c1，因为在从一个单播会话切换到另一个单播会话时可能存在分组泄漏，除非每个接收到的单播流具有其自己的独特同步源（SSRC）标识符以允许客户端过滤掉不想要的分组。除非能保证这一点（这通常并不容易），否则客户端应为后续单播会话使用单独的接收端口。经过足够的时间（建议两分钟，类似于[RFC0793]中指定的TCP最大段生存期），可以再次使用以前使用的接收端口。
The established unicast session can be explicitly terminated by the procedures specified by an application or extension using the port mapping approach described in this document. In addition, the unicast session can also be terminated by the procedure defined below, which is based on timing all participants out following the timeout rules of [RFC3550]. Both the server and client periodically check the liveness of the other peer, and if there is no RTCP traffic from the other peer for a certain amount of time (Section 6.3.5 of [RFC3550] suggests five RTCP reporting intervals), the unicast session SHOULD be considered terminated, and no further RTP and/or RTCP packets SHOULD be sent in that session. The client can attempt to establish a new unicast session if needed. If no explicit procedure for session termination exists, the client MAY stop sending RTCP to the server to accomplish session termination. However, the server SHALL NOT stop sending RTCP until the unicast session is terminated. If Token-based authentication is also signaled to be allowed in the unicast session, i.e., in the RTCP messages sent from port c2 towards port P4, the client SHOULD terminate the unicast session by sending an RTCP BYE message for each SSRC it has used in that unicast session.
使用本文档中描述的端口映射方法，应用程序或扩展指定的过程可以显式终止已建立的单播会话。此外，单播会话也可以通过下面定义的过程终止，该过程基于按照[RFC3550]的超时规则对所有参与者进行计时。服务器和客户端都会定期检查另一个对等方的活动性，如果在一定时间内没有来自另一个对等方的RTCP通信（RFC3550的第6.3.5节建议五个RTCP报告间隔），则应认为单播会话已终止，并且在该会话中不应再发送RTP和/或RTCP数据包。如果需要，客户端可以尝试建立新的单播会话。如果不存在明确的会话终止过程，客户端可能会停止向服务器发送RTCP以完成会话终止。但是，在单播会话终止之前，服务器不得停止发送RTCP。如果单播会话（即从端口c2向端口P4发送的RTCP消息）中也发出允许基于令牌的身份验证的信号，则客户端应通过为其在该单播会话中使用的每个SSRC发送RTCP BYE消息来终止单播会话。
This section defines the formats of the RTCP messages that are exchanged between a server and a client for the purpose of port mapping. A new RTCP control packet type is introduced, and four port mapping messages using this control packet are defined:
本节定义了用于端口映射的服务器和客户端之间交换的RTCP消息的格式。引入了一种新的RTCP控制包类型，并定义了使用该控制包的四个端口映射消息：
1. Port Mapping Request
1. 端口映射请求
2. Port Mapping Response
2. 端口映射响应
3. Token Verification Request
3. 令牌验证请求
4. Token Verification Failure
4. 令牌验证失败
Each message has a fixed-length field for version (V), padding (P), sub-message type (SMT), packet type (PT), length, and SSRC of packet sender. Messages have other fields as defined below. In all messages defined in this section, the PT field is set to TOKEN (210). Individual messages are identified by the SMT field. The length field indicates the message size in 32-bit words minus one, including the header and any padding. This definition is in line with the definition of the Length field used in RTCP sender and receiver reports. In all messages, any Reserved field SHALL be set to zero and ignored.
每个消息都有一个固定长度的字段，用于表示数据包发送方的版本（V）、填充（P）、子消息类型（SMT）、数据包类型（PT）、长度和SSRC。消息具有以下定义的其他字段。在本节中定义的所有消息中，PT字段设置为TOKEN（210）。单个消息由SMT字段标识。长度字段以32位字减去1表示消息大小，包括标题和任何填充。此定义与RTCP发送方和接收方报告中使用的长度字段的定义一致。在所有消息中，任何保留字段都应设置为零并忽略。
Following the rules specified in [RFC3550], all integer fields in the messages defined below are carried in network-byte order, that is, most significant byte (octet) first, also known as big-endian. Unless otherwise stated, numeric constants are in decimal (base 10).
按照[RFC3550]中指定的规则，下面定义的消息中的所有整数字段都以网络字节顺序进行传输，也就是说，最高有效字节（八位字节）优先，也称为big-endian。除非另有说明，否则数值常量为十进制（以10为基数）。
Note that RTCP is not a timely or reliable protocol. The RTCP packets might get lost or reordered in the network, and it is not easy to detect these events. When sending a new Port Mapping Request message, the scheduling rules that apply to sending initial RTCP messages [RFC4585] apply. When a client sends a Port Mapping Request or Token Verification Request message but it does not receive a response back from the server (either a Port Mapping Response or Token Verification Failure message), it MAY resend its request by following the timer rules defined for RTCP feedback messages in Section 3.5 of [RFC4585] as a good practice. However, implementations are advised to avoid sending spurious RTCP messages just because the timer rules (based on some RTCP configuration parameters) allow. Reasonably safe practices are to be used to detect RTCP message loss. When sending an RTCP (feedback) message bundled with a Token Verification Request message, the timer rules of [RFC4585] apply as usual.
请注意，RTCP不是及时或可靠的协议。RTCP数据包可能在网络中丢失或重新排序，并且不容易检测到这些事件。发送新端口映射请求消息时，适用于发送初始RTCP消息[RFC4585]的调度规则适用。当客户端发送端口映射请求或令牌验证请求消息，但未从服务器收到响应（端口映射响应或令牌验证失败消息）时，作为一种良好做法，它可以按照[RFC4585]第3.5节中为RTCP反馈消息定义的计时器规则重新发送其请求。但是，建议实现避免仅仅因为计时器规则（基于某些RTCP配置参数）允许而发送虚假RTCP消息。应使用合理的安全实践来检测RTCP消息丢失。发送与令牌验证请求消息捆绑的RTCP（反馈）消息时，[RFC4585]的计时器规则照常适用。
The Port Mapping Request message is identified by SMT=1. This message is transmitted by the client to a dedicated server port (and possibly a dedicated address) to request a Token. In the Port Mapping Request message, the packet sender's SSRC is set to the client's SSRC, which is chosen randomly by the client. The packet format has the structure depicted in Figure 3.
端口映射请求消息由SMT=1标识。此消息由客户端传输到专用服务器端口（可能还有专用地址）以请求令牌。在端口映射请求消息中，数据包发送方的SSRC设置为客户端的SSRC，客户端随机选择SSRC。数据包格式的结构如图3所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SMT=1 | PT=TOKEN | Length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random |
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SMT=1 | PT=TOKEN | Length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random |
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Packet Format for the Port Mapping Request Message
图3：端口映射请求消息的数据包格式
o Random Nonce (64 bits): Field that contains a random value generated by the client following the procedures of [RFC4086]. This nonce is taken into account by the server when generating a Token for the client to enable better security for clients that
o 随机Nonce（64位）：包含客户机按照[RFC4086]过程生成的随机值的字段。在为客户机生成令牌时，服务器会考虑此nonce，以便为以下客户机提供更好的安全性：
share the same IP address (such clients need to produce a random value extremely unlikely to collide with other clients sharing the same IP address). If the same Port Mapping Request message is transmitted multiple times for redundancy reasons, the random nonce value MUST remain the same in these duplicated messages. However, the client MUST generate a new random nonce for every new Port Mapping Request message.
共享相同的IP地址（此类客户端需要生成一个随机值，该值极不可能与共享相同IP地址的其他客户端发生冲突）。如果由于冗余原因多次传输同一端口映射请求消息，则这些重复消息中的随机nonce值必须保持不变。但是，客户端必须为每个新端口映射请求消息生成一个新的随机nonce。
The Port Mapping Response message is identified by SMT=2. This message is sent by the server and delivers the Token to the client as a response to the Port Mapping Request message. In the Port Mapping Response message, the packet sender's SSRC is set to the server's SSRC. The packet format has the structure depicted in Figure 4.
端口映射响应消息由SMT=2标识。此消息由服务器发送，并将令牌作为对端口映射请求消息的响应传递给客户端。在端口映射响应消息中，数据包发送方的SSRC设置为服务器的SSRC。数据包格式的结构如图4所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SMT=2 | PT=TOKEN | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Requesting Client |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated |
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Token Element :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Absolute |
| Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relative Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Packet Types Element :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SMT=2 | PT=TOKEN | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Requesting Client |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated |
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Token Element :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Absolute |
| Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relative Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Packet Types Element :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Packet Format for the Port Mapping Response Message
图4：端口映射响应消息的数据包格式
o SSRC of Requesting Client (32 bits): Field that contains the SSRC of the client who sent the request.
o 请求客户端的SSRC（32位）：包含发送请求的客户端的SSRC的字段。
o Associated Nonce (64 bits): Field that contains the nonce received in the Port Mapping Request message and used in Token construction.
o 关联的Nonce（64位）：包含在端口映射请求消息中接收并在令牌构造中使用的Nonce的字段。
o Token Element (variable size): Element that is used to carry the Token generated by the server. This element is a 32-bit aligned Length-Value element. The Length field, which is 16 bits, indicates the length (in octets) of the Value field that follows the Length field. While a 16-bit length allows for Tokens with a size of up to 65535 bytes, using Tokens of sizes that make the RTCP compound packet larger than the MTU might have a negative impact on functionality because of IP fragmentation. Some NATs or other middleboxes do not pass IP fragments; thus, a large Token can cause the whole mechanism to fail. In addition, fragmentation increases the risk for packet loss.
o 令牌元素（可变大小）：用于携带服务器生成的令牌的元素。此元素是32位对齐长度值元素。长度字段为16位，表示长度字段后面的值字段的长度（以八位字节为单位）。虽然16位长度允许最大为65535字节的令牌，但使用使RTCP复合数据包大于MTU的令牌可能会因IP碎片而对功能产生负面影响。一些NAT或其他中间盒不传递IP片段；因此，较大的令牌可能导致整个机制失败。此外，碎片会增加数据包丢失的风险。
The length does not include any padding that is required for alignment. The Value field carries the Token (or more accurately, the output of the encoding process on the server). If the Token element does not fall on a 32-bit boundary, the last word MUST be padded to the boundary using further bits set to zero.
长度不包括对齐所需的任何填充。Value字段携带令牌（或者更准确地说，服务器上编码过程的输出）。如果令牌元素不在32位边界上，则必须使用设置为零的其他位将最后一个字填充到边界。
o Absolute Expiration Time (64 bits): Field that contains the absolute expiration time of the Token. The absolute expiration time is expressed as a Network Time Protocol (NTP) timestamp value in seconds since the year 1900 [RFC5905]. The client does not need to use this element directly and thus does not need to synchronize its clock with the server. However, the client needs to send this element back to the server along with the associated nonce in the Token Verification Request message and thus needs to keep it associated with the Token.
o 绝对过期时间（64位）：包含令牌绝对过期时间的字段。绝对过期时间表示为自1900年起的网络时间协议（NTP）时间戳值（以秒为单位）[RFC5905]。客户端不需要直接使用此元素，因此不需要将其时钟与服务器同步。但是，客户机需要将此元素与令牌验证请求消息中的关联nonce一起发送回服务器，因此需要将其与令牌保持关联。
o Relative Expiration Time (32 bits): Field that contains the relative expiration time of the Token. The relative expiration time is expressed in seconds from the time the Token was generated. Whenever a server decides to not grant a Token to a requesting client, the relative expiration time will be set to zero (and hence, the accompanying Token will be invalid).
o 相对过期时间（32位）：包含令牌相对过期时间的字段。相对过期时间以生成令牌后的秒数表示。每当服务器决定不向请求客户端授予令牌时，相对过期时间将设置为零（因此，伴随的令牌将无效）。
The server conveys the relative expiration time in the clear to the client to allow the client to request a new Token well before the expiration time.
服务器以明文形式将相对过期时间传递给客户端，以允许客户端在过期时间之前请求新令牌。
o Packet Types Element (variable size): Element that is used to signal which RTCP packet types require Token-based authentication. This element is a 32-bit aligned Length-Value element. The Length field, which is 8 bits, indicates the length (in octets) of the Value field that follows the Length field. This length does not include any padding that is required for alignment. The Value field carries zero or more 8-bit sub-fields, each carrying an RTCP packet type. If the Packet Types element does not fall on a
o 数据包类型元素（可变大小）：用于指示哪些RTCP数据包类型需要基于令牌的身份验证的元素。此元素是32位对齐长度值元素。长度字段为8位，表示长度字段后面的值字段的长度（以八位字节为单位）。此长度不包括对齐所需的任何填充。值字段携带零个或多个8位子字段，每个子字段携带一个RTCP数据包类型。如果数据包类型元素没有落在
32-bit boundary, the last word MUST be padded to the boundary using further bits set to zero. An example Packet Types element is shown in Figure 5.
32位边界，最后一个字必须使用设置为零的其他位填充到边界。图5显示了一个示例数据包类型元素。
A server MAY change its policy on which RTCP packet types would require Token-based authentication based on observations, configuration, or other policies. However, upon such a change, the server SHALL NOT send a new Port Mapping Response message to the clients who requested a Token earlier. A client learns about this change when and if it gets a Token Verification Failure message.
服务器可以更改其策略，RTCP数据包类型需要基于观察、配置或其他策略的基于令牌的身份验证。但是，一旦发生这种更改，服务器不应向先前请求令牌的客户端发送新的端口映射响应消息。客户机在收到令牌验证失败消息时了解此更改。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length=4 | 205 | 206 | 203 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 204 | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length=4 | 205 | 206 | 203 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 204 | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Example Packet Types Element
图5：示例数据包类型元素
The Token Verification Request message is identified by SMT=3. This message contains the Token and accompanies any RTCP message that would trigger a new unicast session or control an existing unicast session. For a list of such messages, see Section 4.3.1.
令牌验证请求消息由SMT=3标识。此消息包含令牌并伴随任何RTCP消息，该消息将触发新单播会话或控制现有单播会话。有关此类信息的列表，请参见第4.3.1节。
In the Token Verification Request message, the packet sender's SSRC is set to the client's SSRC. The client MUST NOT send a Token Verification Request message with a Token that has expired. The packet format has the structure depicted in Figure 6.
在令牌验证请求消息中，数据包发送方的SSRC设置为客户端的SSRC。客户端不得发送带有已过期令牌的令牌验证请求消息。数据包格式的结构如图6所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SMT=3 | PT=TOKEN | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated |
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Token Element :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated Absolute |
| Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SMT=3 | PT=TOKEN | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated |
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Token Element :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated Absolute |
| Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Packet Format for the Token Verification Request Message
图6：令牌验证请求消息的数据包格式
o Associated Nonce (64 bits): Field that contains the nonce associated with the Token below.
o 关联的Nonce（64位）：包含与以下令牌关联的Nonce的字段。
o Token Element (variable size): Token element that was previously received in the Port Mapping Response message.
o 令牌元素（可变大小）：以前在端口映射响应消息中接收的令牌元素。
o Associated Absolute Expiration Time (64 bits): Field that contains the absolute expiration time associated with the Token above.
o 关联绝对过期时间（64位）：包含与上述令牌关联的绝对过期时间的字段。
This section provides guidelines about which RTCP packet types would need to be accompanied by a Token Verification Request message. However, since a server might determine in real time that other RTCP messages also need to be authenticated by a Token, a client MUST act according to the up-to-date list provided to the client in the Port Mapping Response message (in the Packet Types element). Clients need to support the use of Token-based authentication with any necessary RTCP message (see Section 3.2).
本节提供了关于哪些RTCP数据包类型需要伴随令牌验证请求消息的指南。但是，由于服务器可能会实时确定其他RTCP消息也需要通过令牌进行身份验证，因此客户端必须根据端口映射响应消息（在数据包类型元素中）中提供给客户端的最新列表进行操作。客户端需要支持对任何必要的RTCP消息使用基于令牌的身份验证（参见第3.2节）。
As a general rule, when the Token capability is declared in the session description, the RTCP messages that trigger transmission of RTP packets in a port mapped unicast session are REQUIRED to be authenticated by using a Token. Such messages include but are not limited to:
作为一般规则，当在会话描述中声明令牌能力时，需要使用令牌对触发端口映射单播会话中RTP数据包传输的RTCP消息进行身份验证。此类信息包括但不限于：
o NACK messages [RFC4585]
o NACK消息[RFC4585]
o RAMS Request (RAMS-R) messages [RFC6285]
o RAMS请求（RAMS-R）消息[RFC6285]
Additionally, some RTCP messages might directly or indirectly control an existing unicast session associated with a multicast session. Unless another authentication method as described in their respective specifications is used, implementations MUST support authenticating such RTCP messages by using a Token.
此外，一些RTCP消息可能直接或间接地控制与多播会话关联的现有单播会话。除非使用各自规范中描述的另一种身份验证方法，否则实现必须支持使用令牌对此类RTCP消息进行身份验证。
Examples are:
例如：
o BYE messages [RFC3550]
o 再见信息[RFC3550]
o RAMS Termination (RAMS-T) messages [RFC6285]
o RAMS终端（RAMS-T）消息[RFC6285]
o Codec Control Messages (CCMs) [RFC5104]
o 编解码器控制消息（CCMs）[RFC5104]
Note that even if a packet type is listed to require Token-based authentication, it does not need to be authenticated when it does not control the unicast session. For example, if BYE (203) is listed in the Port Mapping Response message as one of the packet types that requires authentication, the client does not need to bundle the RTCP BYE message with a Token when it is sending it for the multicast session.
注意，即使分组类型被列出需要基于令牌的身份验证，当它不控制单播会话时，也不需要对其进行身份验证。例如，如果BYE（203）在端口映射响应消息中被列为需要认证的分组类型之一，则客户端在为多播会话发送RTCP BYE消息时不需要将其与令牌捆绑在一起。
The Token Verification Request message might also be bundled with packets carrying RTCP receiver and/or extended reports. While such packets do not have a strong security impact, a specific application might desire to have a more controlled reporting scheme from the clients. In this case, the server lists the packet types for the receiver (201) and/or extended reports (207) in the Port Mapping Response message.
令牌验证请求消息也可能与携带RTCP接收器和/或扩展报告的数据包捆绑在一起。虽然这样的数据包不会对安全性产生很大影响，但特定的应用程序可能希望从客户端获得更受控的报告方案。在这种情况下，服务器在端口映射响应消息中列出接收机（201）和/或扩展报告（207）的分组类型。
The Token Verification Failure message is identified by SMT=4. This message is sent by the server and notifies the client that the Token was invalid or that the client did not include a Token Verification Request message in the RTCP packet although it was supposed to (the message is sent from port P3 towards port c1). The packet format has the structure depicted in Figure 7.
令牌验证失败消息由SMT=4标识。此消息由服务器发送，并通知客户端令牌无效，或者客户端未在RTCP数据包中包含令牌验证请求消息，尽管它应该包含（消息从端口P3发送到端口c1）。数据包格式的结构如图7所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SMT=4 | PT=TOKEN | Length=5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Requesting Client |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failed PT | FMT | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated |
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SMT=4 | PT=TOKEN | Length=5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Requesting Client |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failed PT | FMT | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated |
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Packet Format for the Token Verification Failure Message
图7：令牌验证失败消息的数据包格式
o SSRC of Packet Sender: This is the server's SSRC, which equals the SSRC of the respective multicast stream. Note that this SSRC value is from a different SSRC space than the one used in the unicast session.
o 包发送方的SSRC：这是服务器的SSRC，等于相应多播流的SSRC。请注意，此SSRC值来自与单播会话中使用的SSRC空间不同的SSRC空间。
o SSRC of Requesting Client (32 bits): Field that contains the SSRC of the client.
o 请求客户端的SSRC（32位）：包含客户端的SSRC的字段。
o Failed PT (8 bits): Field that indicates the type of the RTCP packet that caused this failure message.
o 失败PT（8位）：指示导致此失败消息的RTCP数据包类型的字段。
o FMT (5 bits): Field that indicates the feedback message type (FMT) value of the RTCP packet that caused this failure. Together with the field above, the client can infer which RTCP message it had previously sent caused this failure message to be sent by the server. For example, if the client did not include a valid Token with an RTCP NACK message, the Failed PT field will indicate 205 (RTPFB) and the FMT field will indicate 1 (Generic NACK). If the RTCP message did not have an associated FMT value (such as an RTCP BYE message), the FMT field SHALL be set to zero.
o FMT（5位）：指示导致此故障的RTCP数据包的反馈消息类型（FMT）值的字段。与上面的字段一起，客户端可以推断它之前发送的RTCP消息导致服务器发送此故障消息。例如，如果客户机没有包含带有RTCP NACK消息的有效令牌，则失败的PT字段将指示205（RTPFB），FMT字段将指示1（通用NACK）。如果RTCP消息没有相关的FMT值（如RTCP BYE消息），FMT字段应设置为零。
o Associated Nonce (64 bits): Field that contains the nonce received in the Token Verification Request message. If there was no Token Verification Request message included by the client, this field is set to zero.
o 关联的Nonce（64位）：包含令牌验证请求消息中接收的Nonce的字段。如果客户端未包含令牌验证请求消息，则此字段设置为零。
The Token encoding is known to the server but opaque to the client. Implementations MUST encode the following information into the Token as a minimum, in order to provide adequate security:
令牌编码对于服务器是已知的，但是对于客户端是不透明的。实现必须至少将以下信息编码到令牌中，以提供足够的安全性：
o Client's IP address as seen by the server (32/128 bits for IPv4/ IPv6 addresses)
o 服务器看到的客户端IP地址（IPv4/IPv6地址为32/128位）
o The nonce generated and inserted in the Port Mapping Request message by the client (64 bits)
o 客户端在端口映射请求消息中生成并插入的nonce（64位）
o The absolute expiration time chosen by the server indicated as an NTP timestamp value in seconds since the year 1900 [RFC5905] (64 bits, to protect against replay attacks)
o 从1900年开始，服务器选择的绝对过期时间表示为NTP时间戳值（以秒为单位）[RFC5905]（64位，用于防止重播攻击）
The RECOMMENDED way for constructing Tokens is to perform HMAC-SHA1 [RFC2104] on the concatenated values of the information listed above (implementations might adopt different approaches). If HMAC-SHA1 is used, the Hashed Message Authentication Code (HMAC) key MUST be at least 160 bits long and generated using a cryptographically secure random source [RFC4086].
构造令牌的推荐方法是对上面列出的信息的串联值执行HMAC-SHA1[RFC2104]（实现可能采用不同的方法）。如果使用HMAC-SHA1，哈希消息认证码（HMAC）密钥必须至少有160位长，并使用加密安全随机源生成[RFC4086]。
In addition to the information listed above, implementations are encouraged to encode whatever additional information is deemed necessary or useful. For example, key rollover is simplified by encoding a key-id into the Token. As another example, a cluster of anycast servers could find advantage by encoding a server identifier into the Token. As another example, while HMAC-SHA1 provides a level of security that is widely regarded as being more than sufficient for providing message authentication and it is secure against all known cryptanalytic attacks that use computational resources that are currently economically feasible, a replacement HMAC algorithm (e.g., HMAC-SHA256) could be used instead if HMAC-SHA1 has been compromised.
除了上面列出的信息之外，鼓励实现对任何认为必要或有用的附加信息进行编码。例如，通过将密钥id编码到令牌中，可以简化密钥滚动。另一个例子是，选播服务器集群可以通过将服务器标识符编码到令牌中找到优势。作为另一个例子，虽然HMAC-SHA1提供了一个被广泛认为足以提供消息认证的安全级别，并且它对使用当前经济上可行的计算资源的所有已知密码分析攻击都是安全的，但替换HMAC算法（例如，HMAC-SHA256）如果HMAC-SHA1已受损，则可以使用。
To protect from offline attacks, the server SHOULD occasionally choose a new HMAC key. To ease implementation, a key-id can be assigned to each HMAC key. This can be encoded as simply as one bit (where the new key is X (e.g., 1) and the old key is the inverted value of X (e.g., 0)), or if several keys are supported at once, the key-id could be encoded into several bits. As the encoding of the Token is entirely private to the server and opaque to the clients, any encoding can be used. By encoding the key-id into the Token element, the server can reject an old key without bothering to do HMAC validation (saving CPU cycles). The key-id can be encoded into the Value field of the Token element by simply concatenating the (plaintext) key-id with the hashed information (i.e., the Token itself).
为了防止脱机攻击，服务器应该偶尔选择一个新的HMAC密钥。为了简化实现，可以为每个HMAC密钥分配一个密钥id。这可以简单地编码为一位（其中新密钥是X（例如，1），旧密钥是X的倒数值（例如，0）），或者如果同时支持多个密钥，则密钥id可以编码为多个位。由于令牌的编码对服务器是完全私有的，对客户端是不透明的，因此可以使用任何编码。通过将密钥id编码到令牌元素中，服务器可以拒绝旧密钥，而无需费心进行HMAC验证（节省CPU周期）。通过简单地将（明文）密钥id与散列信息（即，令牌本身）连接，可以将密钥id编码到令牌元素的值字段中。
For example, the Value field in the Token element can be computed as:
例如，令牌元素中的值字段可以计算为：
key-id || mac-alg (client-ip | nonce | abs-expiration)
密钥id | | mac alg（客户端ip |当前| abs到期）
During Token construction, the expiration time has to be chosen carefully based on the intended service duration. Tokens that are valid for an unnecessarily long period of time (e.g., several hours) might impose security risks. Depending on the application and use cases, a reasonable value needs to be chosen by the server. Note that using shorter lifetimes requires the clients to acquire Tokens more frequently. However, since a client can acquire a new Token well before it will need to use it, the client will not necessarily be penalized for the acquisition delay.
在令牌构造期间，必须根据预期的服务持续时间仔细选择到期时间。在不必要的长时间（如数小时）内有效的代币可能会带来安全风险。根据应用程序和用例，服务器需要选择合理的值。请注意，使用更短的生命周期需要客户机更频繁地获取令牌。然而，由于客户机可以在需要使用新令牌之前很早就获取新令牌，因此客户机不一定会因获取延迟而受到惩罚。
Finally, be aware that NTP timestamps will wrap around in the year 2036. Refer to Section 6 of [RFC5905] for further details.
最后，请注意，NTP时间戳将在2036年结束。有关更多详细信息，请参阅[RFC5905]第6节。
The server MUST validate the Token upon receipt of an RTCP feedback message along with the Token Verification Request message that contains a Token, nonce, and absolute expiration time.
服务器必须在收到RTCP反馈消息以及包含令牌、nonce和绝对过期时间的令牌验证请求消息时验证令牌。
The server first applies its own procedure for constructing the Tokens by using the client's IP address from the received Token Verification Request message and the nonce and absolute expiration time values reported in the received Token Verification Request message. The server then compares the resulting output with the Token sent by the client in the Token Verification Request message. If they match and the absolute expiration time has not passed yet, the server declares that the Token is valid.
服务器首先应用自己的过程，通过使用来自接收到的令牌验证请求消息的客户端IP地址以及在接收到的令牌验证请求消息中报告的nonce和绝对过期时间值来构造令牌。然后，服务器将结果输出与客户机在令牌验证请求消息中发送的令牌进行比较。如果它们匹配且绝对过期时间尚未过去，服务器将声明令牌有效。
Note that if the client's IP address changes, the Token will not validate. Similarly, if the client inserts an incorrect nonce or absolute expiration time value in the Token Verification Request message, validation will fail. It is also possible that the server wants to expire the Token prematurely. In these cases, the server MUST reply back to the client with a Token Verification Failure message (that goes from port P3 on the server towards port c1 on the client).
请注意，如果客户端的IP地址更改，则令牌将不会验证。类似地，如果客户端在令牌验证请求消息中插入不正确的nonce或绝对过期时间值，验证将失败。服务器还可能希望令牌过早过期。在这些情况下，服务器必须使用令牌验证失败消息（从服务器上的端口P3到客户端上的端口c1）回复客户端。
In addition to the Token Verification Failure message, it is RECOMMENDED that applications define an application-specific error response to be sent by the server when the server detects that the Token is invalid. For applications using [RFC6285], this document defines a new 4xx-level response code in the RAMS Response Code Space Registry. A client that receives a Token Verification Failure message can request a new Token from the server.
除了令牌验证失败消息外，建议应用程序定义一个特定于应用程序的错误响应，以便在服务器检测到令牌无效时由服务器发送。对于使用[RFC6285]的应用程序，本文档在RAMS响应代码空间注册表中定义了一个新的4xx级响应代码。接收令牌验证失败消息的客户端可以从服务器请求新令牌。
If a client receives a Port Mapping Response message with an invalid Token (i.e., the relative expiration time is set to zero) two or more times for a particular Port Mapping Request message or the client
如果客户端接收到带有无效令牌的端口映射响应消息（即，相对过期时间设置为零），则针对特定端口映射请求消息或客户端接收两次或两次以上
receives a Token Verification Failure message two or more times for the same Token Verification Request message, the client SHOULD do the following:
对于同一令牌验证请求消息，客户端会收到令牌验证失败消息两次或两次以上，客户端应执行以下操作：
1. Check whether or not the session description has been updated. If it was updated, act according to the new session description.
1. 检查会话描述是否已更新。如果已更新，请根据新会话描述进行操作。
2. Exponentially back off for the third and subsequent attempts. Exponential back-off does not apply when the client sends a Port Mapping Request or Token Verification Request message to a new address and/or port.
2. 在第三次和以后的尝试中以指数级后退。当客户端向新地址和/或端口发送端口映射请求或令牌验证请求消息时，指数回退不适用。
This attribute is used declaratively in any media block that describes an RTP session that uses Token-based authentication for one or more RTCP messages relating to that session. It indicates the port and optionally the address for obtaining a Token.
此属性在描述RTP会话的任何媒体块中声明性地使用，该会话对与该会话相关的一个或多个RTCP消息使用基于令牌的身份验证。它指示用于获取令牌的端口和地址（可选）。
The presence of the 'portmapping-req' attribute indicates that (i) a Token MUST be included in certain RTCP messages sent to the server triggering or controlling a unicast session (see Section 4.3.1) and (ii) the client MUST receive the unicast session's RTP and RTCP packets from the server on the port from which it sent the RTCP message triggering the unicast session.
“portmapping req”属性的存在表明：（i）发送到服务器触发或控制单播会话的某些RTCP消息中必须包含令牌（见第4.3.1节）和（ii）客户端必须在发送触发单播会话的RTCP消息的端口上从服务器接收单播会话的RTP和RTCP数据包。
Note: This does not imply that Token Verification Request messages always need to be sent in the unicast session. Token Verification Request messages accompany RTCP messages that trigger or control this unicast session and are sent either in the multicast session or the unicast session, depending on the RTCP message (see Section 4.3.1).
注意：这并不意味着令牌验证请求消息总是需要在单播会话中发送。令牌验证请求消息伴随触发或控制此单播会话的RTCP消息，并根据RTCP消息在多播会话或单播会话中发送（参见第4.3.1节）。
The formal description of the 'portmapping-req' attribute is defined by the following ABNF [RFC5234] syntax:
“portmapping req”属性的形式描述由以下ABNF[RFC5234]语法定义：
portmapping-req-attr = "a=portmapping-req:" port [SP nettype SP addrtype SP connection-address] CRLF
portmapping req attr=“a=portmapping req:“端口[SP nettype SP addrttype SP连接地址]CRLF
Here, 'port', 'nettype', 'addrtype', and 'connection-address' are defined as specified in Section 9 of [RFC4566].
此处，“端口”、“网络类型”、“地址类型”和“连接地址”的定义见[RFC4566]第9节。
The 'portmapping-req' attribute SHALL only be used as a media-level attribute.
“portmapping req”属性只能用作媒体级属性。
In the optional address value, only unicast addresses SHOULD be used unless one wants to use a multicast address after evaluating the additional security risks such as non-legit servers generating fake Tokens. If the address is not specified, the (source) address in the "c" line applicable to the media description SHALL be used.
在可选地址值中，应仅使用单播地址，除非在评估其他安全风险（如非合法服务器生成假令牌）后想要使用多播地址。如果未指定地址，则应使用适用于媒体描述的“c”行中的（源）地址。
When using the 'portmapping-req' attribute in SDP offer/answer exchanges [RFC3264], the following considerations apply. When an offerer sends an answerer an offer of an SDP description making use of the Token approach described in this specification, the 'portmapping-req' attribute is included declaratively. There will not be offer/answer exchanges between the answerer and the actual server providing the unicast service(s).
在SDP提供/应答交换[RFC3264]中使用“portmapping req”属性时，应考虑以下因素。当报价人使用本规范中描述的令牌方法向应答人发送SDP描述报价时，“portmapping req”属性以声明方式包含。应答者和提供单播服务的实际服务器之间不会进行提供/应答交换。
When the answerer supports the Token approach, it MUST echo in its answer back to the offerer the 'portmapping-req' attribute from the offer including the same port number and address (if any). If the answerer does not implement this specification, it follows normal SDP parsing of unknown attributes (they are ignored and are not sent in the answer). This means that the answerer can still join the multicast session but will not be able to use the unicast service(s) that require the use of Tokens.
当应答方支持令牌方法时，应答方必须在其应答中向报价方回显报价中的“portmapping req”属性，包括相同的端口号和地址（如果有）。如果应答者未实现此规范，则遵循未知属性的正常SDP解析（它们将被忽略，并且不会在应答中发送）。这意味着应答者仍然可以加入多播会话，但不能使用需要使用令牌的单播服务。
The use of SDP for the port mapping solution normatively requires support for:
将SDP用于端口映射解决方案通常需要支持：
o The SDP grouping framework and flow identification (FID) semantics [RFC5888]
o SDP分组框架和流标识（FID）语义[RFC5888]
o The RTP/Audio-Visual Profile with Feedback (AVPF) profile [RFC4585]
o 带反馈的RTP/视听配置文件（AVPF）配置文件[RFC4585]
o The 'rtcp-mux' attribute (to multiplex RTP and RTCP on a single port on both endpoints in the unicast session [RFC5761])
o “rtcp mux”属性（在单播会话[RFC5761]中，在两个端点上的单个端口上多路传输RTP和rtcp）
The declarative SDP describing the scenario given in Figure 2 is written as:
描述图2中给出的场景的声明性SDP编写为：
v=0
o=ali 1122334455 1122334466 IN IP4 nack.example.com
s=Local Retransmissions
t=0 0
a=group:FID 1 2
a=rtcp-unicast:rsi
m=video 41000 RTP/AVPF 98
i=Multicast Stream
c=IN IP4 233.252.0.2/255
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 ; Note 1
a=rtpmap:98 MP2T/90000
a=multicast-rtcp:41500 ; Note 1
a=rtcp:42000 IN IP4 192.0.2.1 ; Note 2
a=rtcp-fb:98 nack ; Note 2
a=portmapping-req:30000 IN IP4 192.0.2.1 ; Note 3
a=mid:1
m=video 42000 RTP/AVPF 99 ; Note 4
i=Unicast Retransmission Stream
c=IN IP4 192.0.2.1
a=sendonly
a=rtpmap:99 rtx/90000
a=rtcp-mux ; Note 5
a=rtcp:42500 ; Note 6
a=fmtp:99 apt=98; rtx-time=5000
a=portmapping-req:30001 ; Note 3
a=mid:2
v=0
o=ali 1122334455 1122334466 IN IP4 nack.example.com
s=Local Retransmissions
t=0 0
a=group:FID 1 2
a=rtcp-unicast:rsi
m=video 41000 RTP/AVPF 98
i=Multicast Stream
c=IN IP4 233.252.0.2/255
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 ; Note 1
a=rtpmap:98 MP2T/90000
a=multicast-rtcp:41500 ; Note 1
a=rtcp:42000 IN IP4 192.0.2.1 ; Note 2
a=rtcp-fb:98 nack ; Note 2
a=portmapping-req:30000 IN IP4 192.0.2.1 ; Note 3
a=mid:1
m=video 42000 RTP/AVPF 99 ; Note 4
i=Unicast Retransmission Stream
c=IN IP4 192.0.2.1
a=sendonly
a=rtpmap:99 rtx/90000
a=rtcp-mux ; Note 5
a=rtcp:42500 ; Note 6
a=fmtp:99 apt=98; rtx-time=5000
a=portmapping-req:30001 ; Note 3
a=mid:2
Figure 8: SDP Describing an SSM Distribution with Support for Retransmissions from a Local Server
图8:SDP描述了支持从本地服务器重新传输的SSM分发
In this description, we highlight the following notes:
在本说明中，我们强调以下注意事项：
Note 1: The source stream is multicast from a distribution source with a source IP address of 198.51.100.1 to the multicast destination address of 233.252.0.2 and port 41000 (P1). The associated RTCP packets are multicast in the same group to port 41500 (P2).
注1：源流是从源IP地址为198.51.100.1的分发源到233.252.0.2的多播目标地址和端口41000（P1）的多播。关联的RTCP分组在同一组中多播到端口41500（P2）。
Note 2: A retransmission server including feedback target functionality with an IP address of 192.0.2.1 and port of 42000 (P3) is specified with the 'rtcp' attribute. The feedback functionality is enabled for the RTP stream with payload type 98 through the 'rtcp-fb' attribute [RFC4585].
注2：IP地址为192.0.2.1、端口为42000（P3）的包含反馈目标功能的重传服务器使用“rtcp”属性指定。通过“rtcp fb”属性[RFC4585]为有效负载类型为98的RTP流启用反馈功能。
Note 3: The "a=portmapping-req" line indicates that one or more RTCP messages relating to the RTP session described in this media block uses Token-based authentication, and a Token needs to be retrieved first from the designated port (PT) before the unicast session can be established. In the first appearance, an explicit address is provided. In the second appearance, there is no address indicated in this line and the client needs to send the Token request to the address specified in the "c" line in the unicast media block.
注3：“a=portmapping req”行表示与此媒体块中描述的RTP会话相关的一个或多个RTCP消息使用基于令牌的身份验证，并且需要首先从指定端口（PT）检索令牌，然后才能建立单播会话。在第一种外观中，提供了显式地址。在第二种外观中，这一行中没有指示地址，客户端需要将令牌请求发送到单播媒体块中“c”行中指定的地址。
Note 4: The port specified in the second "m" line (for the unicast stream) does not mean anything in this scenario as the client does not send any RTP traffic back to the server.
注意4：在第二行“m”中指定的端口（对于单播流）在这种情况下并不意味着什么，因为客户端不会将任何RTP通信发送回服务器。
Note 5: The server multiplexes RTP and RTCP packets sent towards c1 on the same port.
注5：服务器在同一端口上多路传输发送到c1的RTP和RTCP数据包。
Note 6: The server uses port 42500 (P4) for the unicast session.
注6：服务器使用端口42500（P4）进行单播会话。
Large-scale NAT devices have a pool of public IPv4 addresses and map internal hosts to one of those public IPv4 addresses. As long as an internal host maintains an active mapping in the NAT, the same IPv4 address is assigned to new connections. However, once all of the host's mappings have been deleted (e.g., because of timeout), it is possible that a new connection from that same host will be assigned a different IPv4 address from the pool. When that occurs, the Token will be considered invalid by the server, causing an additional round trip for the client to acquire a fresh Token.
大型NAT设备有一个公共IPv4地址池，并将内部主机映射到其中一个公共IPv4地址。只要内部主机在NAT中保持活动映射，就会为新连接分配相同的IPv4地址。但是，一旦删除了主机的所有映射（例如，由于超时），来自同一主机的新连接可能会从池中分配不同的IPv4地址。当这种情况发生时，服务器将认为令牌无效，从而导致客户端获取新令牌的额外往返。
Any traffic from the host that traverses the NAT will prevent this problem. As the host is sending RTCP receiver reports at least every 5 seconds (Section 6.2 of [RFC3550]) for the multicast session it is receiving, those RTCP messages will be sufficient to prevent this problem.
来自主机的任何通过NAT的流量都可以防止此问题。由于主机至少每5秒（RFC3550的第6.2节）就其接收的多播会话发送一次RTCP接收器报告，这些RTCP消息足以防止此问题。
The Token, which is generated based on a client's IP address and expiration date, provides protection against off-path denial-of-service (DoS) attacks. An attacker using a certain IP address cannot cause one or more RTP packets to be sent to a victim client who has a different IP address. However, if the attacker acquires a valid Token for a victim and can spoof the victim's source address, this
该令牌基于客户端的IP地址和到期日期生成，可提供针对非路径拒绝服务（DoS）攻击的保护。使用特定IP地址的攻击者无法将一个或多个RTP数据包发送到具有不同IP地址的受害客户端。但是，如果攻击者获取了受害者的有效令牌，并可以欺骗受害者的源地址，则此
approach becomes vulnerable to replay attacks. This is especially easy if the attacker and victim are behind a large-scale NAT and share the same IP address.
这种方法很容易受到重播攻击。如果攻击者和受害者位于大规模NAT后面并共享相同的IP地址，则这一点尤其容易。
Multicast is deployed on managed networks, not the Internet. These managed networks will choose whether or not to enable network ingress filtering [RFC2827]. If ingress filtering is enabled on a network, an attacker cannot spoof a victim's IP address to use a Token to initiate an attack against a victim. However, if ingress filtering is not enabled on a network, an attacker could obtain a Token and spoof the victim's address, causing traffic to flood the victim. On such a network, the server can reduce the time period for such an attack by expiring a Token in a short period of time. In the extreme case, the server can expire the Token in such a short period of time that the client will have to acquire a new Token immediately before using it in a Token Verification Request message. One should, however, note that such a behavior might have an adverse effect on the delay in establishing or controlling a unicast session.
多播部署在托管网络上，而不是Internet上。这些受管网络将选择是否启用网络入口过滤[RFC2827]。如果在网络上启用了入口过滤，则攻击者无法欺骗受害者的IP地址以使用令牌发起针对受害者的攻击。但是，如果网络上未启用入口过滤，攻击者可能会获取令牌并伪造受害者的地址，从而导致流量泛滥。在这样的网络上，服务器可以通过在短时间内使令牌过期来缩短此类攻击的时间段。在极端情况下，服务器可能会在如此短的时间内使令牌过期，以致客户端必须在令牌验证请求消息中使用新令牌之前立即获取新令牌。然而，应当注意，这种行为可能对建立或控制单播会话的延迟产生不利影响。
RTCP messages could be subject to on-path or man-in-the-middle attacks. For example, an attacker can modify a value in one or more fields in the Port Mapping Response or the Token Verification Request message that are used in Token construction. This will result in Token validation failure. Consequently, the client ends up asking the server to generate a new Token. The resulting delay and extra processing on the server is undesirable.
RTCP消息可能受到路径上或中间人攻击。例如，攻击者可以修改端口映射响应或令牌验证请求消息中用于令牌构造的一个或多个字段中的值。这将导致令牌验证失败。因此，客户端最终要求服务器生成一个新令牌。由此产生的延迟和服务器上的额外处理是不可取的。
Alternatively, the attacker can modify a value in a field that is not used in Token construction. For example, the attacker can reduce the value in the Relative Expiration Time field in the Port Mapping Response message from two hours to two minutes. While the Token will still validate, this attack will result in more frequent requests to the server for a new Token. Oppositely, the attacker can increase the value in the Relative Expiration Time field and make the client think the Token will be valid for a longer time. This attack can be only detected by monitoring the activity on the server. Note that using the relative expiration time in Token construction does not necessarily make this attack easier to detect since the attacker might revert the modified value back to its original value in the Token Verification Request message. This allows the Token to still validate on the server. In this case, the attack is still only detectable by monitoring the server activity.
或者，攻击者可以修改令牌构造中未使用的字段中的值。例如，攻击者可以将端口映射响应消息中相对过期时间字段的值从两小时减少到两分钟。虽然令牌仍然有效，但此攻击将导致更频繁地向服务器请求新令牌。相反，攻击者可以增加相对过期时间字段中的值，使客户端认为令牌的有效期更长。只有通过监视服务器上的活动才能检测到此攻击。请注意，在令牌构造中使用相对过期时间并不一定会使此攻击更容易检测，因为攻击者可能会在令牌验证请求消息中将修改后的值恢复为其原始值。这允许令牌仍然在服务器上进行验证。在这种情况下，攻击仍然只能通过监视服务器活动来检测。
If there is a risk or concern for on-path or man-in-the-middle attacks, RTCP messages SHOULD be protected by Secure RTCP (SRTCP) [RFC3711].
如果存在路径上攻击或中间人攻击的风险或担忧，RTCP消息应受到安全RTCP（SRTCP）[RFC3711]的保护。
To minimize the risk of cross-protocol attacks, a server MUST NOT use the same secret key it used for Token construction for other purposes.
为了将跨协议攻击的风险降至最低，服务器不得将用于令牌构造的密钥用于其他目的。
The 'portmapping-req' attribute is not believed to introduce any significant security risk to multimedia applications. A malevolent third party could use this attribute to redirect the Port Mapping Request messages by altering the port number or cause the unicast session establishment to fail by removing it from the SDP description. However, this requires intercepting and rewriting the packets carrying the SDP description, and if an interceptor can do that, many more attacks are possible, including a wholesale change of the addresses and port numbers at which the media will be sent.
“portmapping req”属性被认为不会给多媒体应用程序带来任何重大的安全风险。恶意的第三方可以使用此属性通过更改端口号重定向端口映射请求消息，或者通过从SDP描述中删除单播会话来导致单播会话建立失败。然而，这需要截取和重写携带SDP描述的数据包，如果拦截器能够做到这一点，则可能会发生更多的攻击，包括彻底更改媒体发送的地址和端口号。
In order to avoid attacks of this sort, the SDP description needs to be integrity protected and provided with source authentication. This can, for example, be achieved on an end-to-end basis using Secure/ Multipurpose Internet Mail Extensions (S/MIME) [RFC5652] [RFC5751] when SDP is used in a signaling packet using MIME types (application/ sdp). Alternatively, HTTPS [RFC2818] or the authentication method in the Session Announcement Protocol (SAP) [RFC2974] could be used as well.
为了避免此类攻击，SDP描述需要完整性保护并提供源身份验证。例如，当在使用MIME类型（应用程序/SDP）的信令分组中使用SDP时，这可以使用安全/多用途Internet邮件扩展（S/MIME）[RFC5652][RFC5751]在端到端的基础上实现。或者，也可以使用HTTPS[RFC2818]或会话公告协议（SAP）[RFC2974]中的身份验证方法。
The following contact information is used for all registrations in this document:
以下联系信息用于本文档中的所有注册：
Ali Begen abegen@cisco.com
阿里出生abegen@cisco.com
This document registers one new attribute name in SDP.
此文档在SDP中注册一个新属性名。
SDP Attribute ("att-field"): Attribute name: portmapping-req Long form: Port and address for requesting Token Type of name: att-field Type of attribute: Media level Subject to charset: No Purpose: See this document Reference: [RFC6284] Values: See this document
SDP属性（“att字段”）：属性名称：端口映射请求长格式：用于请求令牌的端口和地址名称类型：att字段属性类型：媒体级别取决于字符集：无用途：参见本文档参考：[RFC6284]值：参见本文档
In accordance with Section 15 of [RFC3550], this specification adds the following value to the RTCP Control Packet types sub-registry in the Real-Time Transport Protocol (RTP) Parameters registry:
根据[RFC3550]第15节，本规范向实时传输协议（RTP）参数注册表中的RTCP控制数据包类型子注册表添加以下值：
Value Abbrev. Name Reference
-------- --------- ------------------------------------- ---------
210 TOKEN Port Mapping [RFC6284]
Value Abbrev. Name Reference
-------- --------- ------------------------------------- ---------
210 TOKEN Port Mapping [RFC6284]
This document creates a new sub-registry for the sub-message type (SMT) values to be used with the TOKEN packet type. The registry is called the SMT Values for TOKEN Packet Type Registry. This registry is managed by the IANA according to the IETF Review policy of [RFC5226].
本文档为要与令牌数据包类型一起使用的子消息类型（SMT）值创建一个新的子注册表。该注册表称为令牌数据包类型注册表的SMT值。该注册表由IANA根据[RFC5226]的IETF审查政策进行管理。
The length of the SMT field is five bits, allowing 32 values. The registry is initialized with the following entries:
SMT字段的长度为5位，允许32个值。注册表使用以下项进行初始化：
Value Name Reference
----- -------------------------------------------------- ------------
0 Reserved [RFC6284]
1 Port Mapping Request [RFC6284]
2 Port Mapping Response [RFC6284]
3 Token Verification Request [RFC6284]
4 Token Verification Failure [RFC6284]
5-30 Unassigned IETF Review
31 Reserved [RFC6284]
Value Name Reference
----- -------------------------------------------------- ------------
0 Reserved [RFC6284]
1 Port Mapping Request [RFC6284]
2 Port Mapping Response [RFC6284]
3 Token Verification Request [RFC6284]
4 Token Verification Failure [RFC6284]
5-30 Unassigned IETF Review
31 Reserved [RFC6284]
The SMT values 0 and 31 are reserved for future use.
SMT值0和31保留供将来使用。
This document adds the following entry to the RAMS Response Code Space Registry.
本文档将以下条目添加到RAMS响应代码空间注册表中。
Code Description Reference
----- -------------------------------------------------- ------------
405 Invalid Token [RFC6284]
Code Description Reference
----- -------------------------------------------------- ------------
405 Invalid Token [RFC6284]
This response code is used when the Token included by the RTP_Rx in the RAMS-R message is invalid.
当RAMS-R消息中RTP_Rx包含的令牌无效时，使用该响应代码。
The approach presented in this document came out after discussions with various individuals in the AVT and MMUSIC WGs and the breakout session held at the Anaheim meeting. We thank each of these individuals, particularly Magnus Westerlund and Colin Perkins.
本文件中提出的方法是在与AVT和MMUSIC工作组中的不同人士进行讨论以及在阿纳海姆会议上举行的分组会议后提出的。我们感谢每一个人，特别是马格努斯·韦斯特隆德和科林·珀金斯。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[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月。
[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月。
[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月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 45852006年7月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC5760]Ott，J.，Chesterfield，J.，和E.Schooler，“具有单播反馈的单源多播会话的RTP控制协议（RTCP）扩展”，RFC 57602010年2月。
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5761]Perkins，C.和M.Westerlund，“在单个端口上多路传输RTP数据和控制数据包”，RFC 5761，2010年4月。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5888]Camarillo，G.和H.Schulzrinne，“会话描述协议（SDP）分组框架”，RFC 5888，2010年6月。
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905]Mills，D.，Martin，J.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 59052010年6月。
[RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 6222, April 2011.
[RFC6222]Begen，A.，Perkins，C.，和D.Wing，“选择RTP控制协议（RTCP）规范名称（CNAMEs）的指南”，RFC 6222，2011年4月。
[RETRANSMISSION-FOR-SSM] Van Caenegem, T., Ver Steeg, B., and A. Begen, "Retransmission for Source-Specific Multicast (SSM) Sessions", Work in Progress, May 2011.
[RETRANSMISSION-FOR-SSM]Van Caenegem，T.，Ver Steeg，B.，和A.Begen，“源特定多播（SSM）会话的重传”，正在进行的工作，2011年5月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 2974，2000年10月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4145]Yon，D.和G.Camarillo，“会话描述协议（SDP）中基于TCP的媒体传输”，RFC 41452005年9月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC4607，2006年8月。
[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月。
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, February 2008.
[RFC5104]Wenger，S.，Chandra，U.，Westerlund，M.，和B.Burman，“带反馈的RTP视听配置文件（AVPF）中的编解码器控制消息”，RFC 5104，2008年2月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 56522009年9月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows", RFC 6263, June 2011.
[RFC6263]Marjou，X.和A.Sollaud，“与RTP/RTP控制协议（RTCP）流相关的NAT映射保持活动的应用机制”，RFC 6263，2011年6月。
[RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, "Unicast-Based Rapid Acquisition of Multicast RTP Sessions", RFC 6285, June 2011.
[RFC6285]Ver Steeg，B.，Begen，A.，Van Caenegem，T.，和Z.Vax，“基于单播的多播RTP会话的快速获取”，RFC 62852011年6月。
Authors' Addresses
作者地址
Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 Canada
Ali Begen Cisco位于加拿大多伦多湾街181号M5J 2T3
EMail: abegen@cisco.com
EMail: abegen@cisco.com
Dan Wing Cisco 170 West Tasman Dr. San Jose, CA 95134 USA
Dan Wing Cisco 170美国加利福尼亚州圣何塞市西塔斯曼博士，邮编95134
EMail: dwing@cisco.com
EMail: dwing@cisco.com
Tom Van Caenegem Alcatel-Lucent Copernicuslaan 50 Antwerpen 2018 Belgium
2018年比利时安特卫普50号汤姆·范·凯恩杰姆阿尔卡特-朗讯哥白尼公司
EMail: Tom.Van_Caenegem@alcatel-lucent.com
EMail: Tom.Van_Caenegem@alcatel-lucent.com