[要約] RFC 6284は、ユニキャストとマルチキャストのRTPセッション間のポートマッピングに関する仕様です。このRFCの目的は、ネットワーク上でのRTPセッションの効率的なマッピングを提供することです。
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アプリケーションで補助ユニキャストセッション用に独自のポートを選択できるようにするポートマッピングソリューションを提示します。このソリューションは、1つ以上の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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
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.
Unicast RTPアプリケーションでは、RTPとRTCPのポートを選択する必要があります。これらのポートはローカルリソースであり、受信側のみが使用可能なポートを決定できるためです。さらに、ネットワークアドレスポート翻訳（NAPT、以下NATと呼ばれる）デバイスは、一般的にネットワークに展開されます。したがって、静的ポート割り当ては使用できません。受信側は、セッション説明プロトコル（SDP）[RFC4566]のオファー/回答モデル[RFC3264]であるさまざまな方法で、送信端に要求を伝えることができます。ただし、オファー/回答モデルでは、エンドポイント間のオファー/回答の交換が必要であり、結果の遅延は遅延に敏感なリアルタイムアプリケーションでは望ましくない場合があります。さらに、オファー/回答モデルは、他のエンドポイントとの多数のユニキャストセッションを同時に実行しているエンドポイントに対して負担がかかる場合があります。
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.
この仕様では、1つ以上のユニキャストとマルチキャストの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 NACKフィードバック[RFC4585]をローカル修理サーバーに送信する場所です（Unicast RTCPフィードバックターゲットとしても機能する）[RFC5760]欠落しているパケットの再送信を要求し、ローカル修理サーバーはユニキャストRTPセッション[再送信-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セッションに参加する前にユニキャストセッションで1つ以上のRTPバーストパケットを受信したい場合です。マルチキャストRTPセッション（RAMS）の迅速な買収については[RFC6285]を参照してください。図1に示すように、コンテンツの一部がマルチキャストを通じてコンテンツの一部がマルチキャストを通じて配布され、レシーバーが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）またはパケット増幅攻撃に対するトークンベースの保護メカニズムが含まれます。このソリューションは、ユニキャストセッションのトランスポートプロトコルとしてTCPが使用される場合には適用できません。このようなシナリオについては、[RFC4145]を参照してください。
-----------
| Unicast |................
| Source |............. :
| (Server) | : :
----------- : :
v v
----------- ---------- -----------
| Multicast |------->| Router |---------->|Client RTP |
| Source | | |..........>|Application|
----------- ---------- -----------
| :
| : -----------
| :..............>|Client RTP |
+---------------->|Application|
-----------
-------> Multicast RTP Flow
.......> Unicast RTP Flow
Figure 1: RTP Applications Simultaneously Using Both Unicast and Multicast Services
図1：Unicastサービスとマルチキャストサービスの両方を使用して同時に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].
キーワードは「必須」、「必要」、「必須」、「shall」、「shall "、" bood "、" low "of" bould "、" becommended "、" bodement "、" may "、" optional「このドキュメントでは、[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）ユニキャストセッションの確立の2つのステップで構成されています。
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.
2番目のステップとして、クライアントがユニキャストセッションを確立したい場合、クライアントは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].
分布ソースが多数のクライアントにRTPパケットをマルチキャストするSSM配信ネットワークを考え、1つ以上の再送信サーバーがフィードバックターゲットとして機能して、これらのクライアントからユニキャストRTCPフィードバックを収集します[RFC5760]。また、再送信サーバーはマルチキャストセッションに参加して、マルチキャストパケットを受信し、特定の期間キャッシュします。クライアントがマルチキャストセッションで不足しているパケットを検出すると、RTCP NACKメッセージ[RFC4585]を使用して、再送信サーバーの1つから再送信を要求します。再送信サーバーは、要求されたパケットをキャッシュから引き出し、リクエストクライアント[再送信-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に示します。クライアントとサーバーの間に、少なくとも1つの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 |
| | | | | |
---------------- --- ----------
-------> 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は、マルチキャストセッションでUnicast RTCPフィードバックメッセージを送信し、UnicastセッションでRTPパケットとRTCP送信者レポートを受信するために使用されるクライアントのポートを示します。*C2は、UnicastセッションでRTCPレシーバーと拡張レポートを送信するために使用されるクライアントのポートを示します。ポートC0、C1、およびC2は、同じポートまたは異なるポートである可能性があります。C0とC1の両方に同じポートを使用することには2つの利点があります。
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は、ユニカストごとのセッションごとに宣言されていますが、同じポートをサーバーがソースした2つ以上のユニキャストセッションに使用できます。ポート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.クライアントは、最初にポートマッピング要求メッセージ（セクション4.1）をポートPTに送信します。このメッセージは、クライアント側のポート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の両方に同じポートを使用することを強くお勧めします。ただし、クライアントが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 Canonical Name（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に関するユニキャストセッションは、関連するマルチキャストセッションが続く限り持続できます。ただし、クライアントは、1つのユニキャストセッションから別のユニキャストセッションに切り替えるときにパケット漏れが発生する可能性があるため、異なる後続のユニキャストセッションに同じ受信ポートC1を使用し続けることはできません。望ましくないパケットを除外します。これが保証されていない限り（これは簡単ではないことが多い）、クライアントはその後のユニキャストセッションに個別の受信ポートを使用する必要があります。十分な時間（[RFC0793]で指定された1つのTCP最大セグメント寿命と同様に、2分を推奨）の後、以前に使用された受信ポートを再度使用できます。
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が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コントロールパケットタイプが導入され、このコントロールパケットを使用した4つのポートマッピングメッセージが定義されています。
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フィールドはトークン（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]で指定されたルールに従って、以下に定義されたメッセージのすべての整数フィールドは、ネットワークバイト順序で運ばれます。つまり、最も重要なバイト（Octet）が最初に、Big-Endianとしても知られています。特に明記しない限り、数値定数は10進数です（ベース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（フィードバック）メッセージを送信すると、[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に設定され、クライアントがランダムに選択します。パケット形式には、図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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 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.
o ランダムノンセ（64ビット）：[RFC4086]の手順に従ってクライアントによって生成されたランダム値を含むフィールド。クライアントが同じIPアドレスを共有するクライアントにより良いセキュリティを可能にするためにクライアントにトークンを生成するときに、このNonCEはサーバーによって考慮されます（そのようなクライアントは、同じ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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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バイトのサイズのトークンが可能になりますが、MTUよりもRTCPコンパウンドパケットを大きくするサイズのトークンを使用して、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.
長さには、アライメントに必要なパディングは含まれていません。値フィールドにはトークンが搭載されています（より正確には、サーバー上のエンコードプロセスの出力）。トークン要素が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 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.
o パケットタイプ要素（可変サイズ）：どのRTCPパケットタイプがトークンベースの認証を必要とするかを信号するために使用される要素。この要素は、32ビットアライメントされた長さ価値要素です。8ビットの長さフィールドは、長さフィールドに続く値フィールドの長さ（オクテット）を示します。この長さには、アライメントに必要なパディングは含まれていません。値フィールドにはゼロ以上の8ビットサブフィールドがあり、それぞれがRTCPパケットタイプを搭載しています。パケットタイプの要素が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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 関連する非CE（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] 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.
o Rams要求（RAMS-R）メッセージ[RFC6285]さらに、一部のRTCPメッセージは、マルチキャストセッションに関連付けられた既存のユニキャストセッションを直接または間接的に制御する場合があります。それぞれの仕様で説明されている別の認証方法が使用されない限り、実装はトークンを使用してそのようなRTCPメッセージの認証をサポートする必要があります。
Examples are:
例は次のとおりです。
o BYE messages [RFC3550]
o さようならメッセージ[RFC3550]
o RAMS Termination (RAMS-T) messages [RFC6285]
o ラムズ終了（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）が認証を必要とするパケットタイプの1つとしてPortマッピング応答メッセージにリストされている場合、クライアントはマルチキャストセッションのために送信するときにトークンを使用して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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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をトークンにエンコードすることにより、キーロールオーバーが簡素化されます。別の例として、Anycastサーバーのクラスターは、サーバー識別子をトークンにエンコードすることで利点を見つけることができます。別の例として、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を割り当てることができます。これは、単に1つのビット（新しいキーはx（例：1）で、古いキーはxの反転値（例：0））としてエンコードできます。IDはいくつかのビットにエンコードできます。トークンのエンコードはサーバーに完全にプライベートであり、クライアントに不透明であるため、エンコードを使用できます。キーIDをトークン要素にエンコードすることにより、サーバーはHMAC検証（CPUサイクルの保存）を実行することなく、古いキーを拒否できます。Key-IDは、（Plantext）Key-IDをハッシュされた情報（つまり、トークン自体）と単純に連結することにより、トークン要素の値フィールドにエンコードできます。
For example, the Value field in the Token element can be computed as:
たとえば、トークン要素の値フィールドは、次のように計算できます。
key-id || mac-alg (client-ip | nonce | abs-expiration)
key-id ||Mac-alg（client-ip | nonce | abs-expiration）
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フィードバックメッセージを受信したときにトークンを検証する必要があります。
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アドレスが変更された場合、トークンは検証されないことに注意してください。同様に、クライアントがトークン検証リクエストメッセージに誤ったノンセまたは絶対有効期限の時間値を挿入すると、検証は失敗します。また、サーバーがトークンを早期に期限切れにしたい可能性もあります。これらの場合、サーバーは、トークン検証障害メッセージ（サーバーのポート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:
特定のポートマッピングリクエストメッセージに対してクライアントが無効なトークン（つまり、相対的な有効期限がゼロに設定されている）を使用してポートマッピング応答メッセージを受信した場合、またはクライアントはトークン検証障害メッセージを2回以上受信します同じトークン検証要求メッセージ、クライアントは次のことを行う必要があります。
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. 3回目と後続の試行のために指数関数的にオフに戻ります。クライアントがポートマッピングリクエストまたはトークン検証リクエストメッセージを新しいアドレスおよび/またはポートに送信した場合、指数バックオフは適用されません。
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.
この属性は、そのセッションに関連する1つ以上のRTCPメッセージにトークンベースの認証を使用するRTPセッションを説明する任意のメディアブロックで宣言的に使用されます。ポートとオプションでトークンを取得するためのアドレスを示します。
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.
「ポートマッピングReq」属性の存在は、（i）トークンをサーバーに送信した特定のRTCPメッセージに含める必要があることを示しています。ユニキャストセッションのRTPおよびRTCPパケットは、ユニキャストセッションをトリガーする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:
「ポートマッピングリクエアされた」属性の正式な説明は、次のABNF [RFC 5234]構文によって定義されます。
portmapping-req-attr = "a=portmapping-req:" port [SP nettype SP addrtype SP connection-address] CRLF
portmapping-req-attr = "a = portmapping-req：" port [sp nettype sp addrtype sp connection-address] crlf
Here, 'port', 'nettype', 'addrtype', and 'connection-address' are defined as specified in Section 9 of [RFC4566].
ここでは、「ポート」、「netType」、「addRType」、および「接続アドレス」は、[RFC4566]のセクション9で指定されているように定義されています。
The 'portmapping-req' attribute SHALL only be used as a media-level attribute.
「ポートマッピング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]で「ポートマッピングReq」属性を使用する場合、次の考慮事項が適用されます。この仕様で説明されているトークンアプローチを使用するSDP説明の申し出を提供者に送信者に送信すると、「ポートマッピング-Req」属性が宣言的に含まれています。Unicastサービスを提供するAnswererと実際のサーバーの間には、提供/回答の交換はありません。
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.
応答者がトークンアプローチをサポートする場合、同じポート番号と住所（ある場合）を含むオファーからの「ポートマッピングレク」属性を提供者に戻すことに反映する必要があります。回答者がこの仕様を実装していない場合、未知の属性の通常の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」属性（ユニキャストセッションの両方のエンドポイントの単一ポートのMultiplex RTPおよびRTCP [RFC5761]）
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
Figure 8: SDP Describing an SSM Distribution with Support for Retransmissions from a Local Server
図8：ローカルサーバーからの再送信をサポートするSSM分布を説明するSDP
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：ソースストリームは、198.51.100.1のソースIPアドレスを持つ配布ソースから、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：192.0.2.1のIPアドレスと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セッションに関連する1つ以上のRTCPメッセージがトークンベースの認証を使用し、最初に指定ポート（PT）からトークンを取得する必要があることを示しています。ユニキャストセッションを確立する前に。最初に、明示的なアドレスが提供されます。2回目の外観では、この行に示されたアドレスはありません。クライアントは、ユニキャストメディアブロックの「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：2番目の「M」行（ユニキャストストリーム用）で指定されたポートは、クライアントがRTPトラフィックをサーバーに送り返さないため、このシナリオでは何も意味しません。
Note 5: The server multiplexes RTP and RTCP packets sent towards c1 on the same port.
注5：サーバーマルチプレックスRTPおよびRTCPパケットは、同じポートのC1に送信されました。
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を横断するホストからのトラフィックは、この問題を防ぎます。ホストがRTCPレシーバーレポートを送信しているため、少なくとも5秒ごと（[RFC3550]のセクション6.2）が受信しているため、これらの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 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.
クライアントのIPアドレスと有効期限に基づいて生成されるトークンは、オフパスサービス拒否（DOS）攻撃に対する保護を提供します。特定のIPアドレスを使用する攻撃者は、1つ以上のRTPパケットを、異なるIPアドレスを持っている被害者クライアントに送信することはできません。ただし、攻撃者が被害者に対して有効なトークンを取得し、被害者の情報源アドレスを押し上げることができる場合、このアプローチは攻撃を再生することに対して脆弱になります。これは、攻撃者と被害者が大規模な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.
マルチキャストは、インターネットではなくマネージドネットワークに展開されます。これらのマネージドネットワークは、ネットワークイングレスフィルタリングを有効にするかどうかを選択します[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メッセージは、オンパスまたは中間の攻撃の対象となる可能性があります。たとえば、攻撃者は、ポートマッピング応答の1つ以上のフィールドまたはトークン検証要求メッセージの1つ以上のフィールドの値を変更できます。これにより、トークン検証障害が発生します。その結果、クライアントはサーバーに新しいトークンを生成するように依頼することになります。結果の遅延とサーバーの追加処理は望ましくありません。
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.
あるいは、攻撃者は、トークン構造では使用されていないフィールドの値を変更できます。たとえば、攻撃者は、ポートマッピング応答メッセージの相対有効期限時間フィールドの値を2時間から2分に減らすことができます。トークンは引き続き検証されますが、この攻撃は新しいトークンのサーバーへのより頻繁なリクエストをもたらします。反対に、攻撃者は相対的な有効期限のフィールドの値を増やし、クライアントにトークンがより長い時間有効であると考えさせることができます。この攻撃は、サーバー上のアクティビティを監視することによってのみ検出できます。トークン構造で相対的な有効期限を使用すると、攻撃者が修正値をトークン検証要求メッセージの元の値に戻す可能性があるため、必ずしもこの攻撃が検出されやすくなるわけではないことに注意してください。これにより、トークンはサーバー上でまだ検証できます。この場合、攻撃はサーバーのアクティビティを監視することによってのみ検出可能です。
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メッセージはSecure 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.
「ポートマッピング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の説明は整合性保護され、ソース認証を提供する必要があります。たとえば、これは、SDPがMIMEタイプ（アプリケーション/ SDP）を使用したシグナリングパケットでSDPを使用している場合、安全な/多目的インターネットメールエクステンション（S/ MIME）[RFC5652] [RFC5751] [RFC5652] [RFC5751] [RFC5652] [RFC5751]を使用してエンドツーエンドベースで達成できます。。あるいは、セッションアナウンスプロトコル（SAP）[RFC2974]のHTTPS [RFC2818]または認証方法も使用できます。
The following contact information is used for all registrations in this document:
次の連絡先情報は、このドキュメントのすべての登録に使用されます。
Ali Begen abegen@cisco.com
Ali Begen abegen@cisco.com
This document registers one new attribute name in SDP.
このドキュメントは、SDPに1つの新しい属性名を登録します。
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-field"）：属性名：portmapping-req longフォーム：トークンの要求のためのポートとアドレス：att-fieldタイプの属性タイプ：メディアレベルcharset：なし目的：このドキュメントリファレンスを参照：[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]
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値と呼ばれます。このレジストリは、[RFC5226]のIETFレビューポリシーに従ってIANAによって管理されます。
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]
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 Response Code Spaceレジストリに追加します。
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 WGSのさまざまな個人との議論と、アナハイム会議で開催されたブレイクアウトセッションの後に発表されました。これらのそれぞれ、特にマグナス・ウェスターランドとコリン・パーキンスに感謝します。
[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 3550、2003年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、「The Secure Real-Time Transport Protocol（SRTP）」、RFC 3711、2004年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：セッション説明プロトコル」、RFC 4566、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 4585、2006年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 5760、2010年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 5905、2010年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）標準名（CNAME）を選択するためのガイドライン」、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.
[再送信-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。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「TLS上のHTTP」、RFC 2818、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]ファーガソン、P。およびD.セニー、「ネットワークイングレスフィルタリング：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 4145、2005年9月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607] Holbrook、H。およびB. Cain、「IP用のソース固有のマルチキャスト」、RFC 4607、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、「Unicast 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）のコーデックコントロールメッセージ」、2008年2月、RFC 5104。
[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 5652、2009年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、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.2メッセージ仕様」、RFC 5751、2010年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、「UnicastベースのマルチキャストRTPセッションの迅速な獲得」、RFC 6285、2011年6月。
Authors' Addresses
著者のアドレス
Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 Canada
Ali Begen Cisco 181 Bay Street Toronto、M5J 2T3カナダ
EMail: abegen@cisco.com
Dan Wing Cisco 170 West Tasman Dr. San Jose, CA 95134 USA
ダンウィングシスコ170ウェストタスマン博士サンノゼ、カリフォルニア95134 USA
EMail: dwing@cisco.com
Tom Van Caenegem Alcatel-Lucent Copernicuslaan 50 Antwerpen 2018 Belgium
Tom Van Caenegem Alcatel-Lucent Copernicuslaan 50 Antwerpen 2018 Belgium
EMail: Tom.Van_Caenegem@alcatel-lucent.com