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
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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）パケットを受信します）。言い換えれば、受信機は、その受信ポート、送信者（s）は事前に定義されたポートを使用を選択することはできません。
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]のためのオファー/アンサーモデル[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.
この仕様では、私たちは一緒に一つ以上のユニキャストとマルチキャストの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]（また、ユニキャストRTCPフィードバックターゲットとして機能する）[RFC5760]を送信する場合それが欠落しているパケットの再送信を要求し、そしてローカルリペアサーバは、ユニキャストRTPセッションの[再送信-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セッションを取得し、一つ以上のRTPは、SSMのセッションに参加する前に、ユニキャストセッションを介してパケットをバースト受信したい場合、別のシナリオです。マルチキャスト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）の1つまたは複数のRTPパケットを引き起こすために使用することができ、パケット増幅攻撃に対するトークンベースの保護機構を備えています。この溶液は、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：ユニキャストとマルチキャストサービスの両方を用いて同時に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].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "推奨NOT"、および「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アドレス（サーバによって見られるように）、生存時間値、およびクライアントが提供するランダムナンスに基づいており、不透明なカプセル化したものです。
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.
クライアントがユニキャストセッションを確立することを望んでいる第二のステップとして、クライアントはそのRTCPフィードバックメッセージにトークンが含まれています。サーバーは、IPアドレス情報が一致することを確認して、トークンを検証します。これは、例えば、攻撃者は、単に別のクライアントのIPアドレスを偽装して、ランダムなクライアントへのユニキャスト送信を開始することはできません、DoS攻撃に対して有効です。検証に合格した場合、ユニキャストセッションを確立します。そうでなければ、サーバは、検証が失敗したクライアントに通知し、この場合には、ユニキャストセッションが確立されることはありません。
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.
検証が成功したときにユニキャストセッションが確立されると、それが終了するまで、すべてのRTPおよびRTCP [RFC3550]で指定されたルールやその他の関連仕様も、このセッションに適用されます。ユニキャストセッションの存続期間中に、クライアントは、認証が必要な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].
[RFC5760]これらのクライアントからのユニキャストRTCPフィードバックを収集するために、フィードバック対象として大きなクライアントの数、および1つまたは複数の再送サーバ機能へ配信元マルチキャストのRTPパケットSSM配信ネットワークを考えます。再送サーバは、マルチキャストパケットを受信し、一定の期間のためにそれらをキャッシュするマルチキャストセッションに参加します。クライアントがマルチキャストセッションに欠落パケットを検出すると、RTCP NACKメッセージ[RFC4585]を使用して再送サーバのいずれかからの再送を要求します。再送サーバはキャッシュから要求されたパケット（複数可）を引くと、要求元のクライアント[再送信-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は、上記のシナリオに係る流れ、我々は、少なくとも一つのNATデバイス[RFC4787]が存在すると仮定し、クライアントとサーバとの間で図2に示されています。 （サーバとクライアントの間に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は、マルチキャストセッションでユニキャストRTCPフィードバックメッセージを送信すると、RTPパケットとユニキャストセッションでのRTCP送信者レポートを受信するために使用するクライアント側のポートを示しています。 * c2は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のが唯一のアクティブなバインディングを保つ（REQ-6のセクション4.3のを見る[RFC4787]）。クライアントからサーバに送信されるパケット間のギャップが長い場合、これは、タイムアウト制限を超えることができます。 C0 = C1の場合は、（マルチキャストセッションのRTCPポートP3用）ポートC0から送信された臨時の（周期的）RTCPレシーバレポートは、NATは、ポートC1への着信ユニキャストトラフィックに関連付けられたパブリックポートをタイムアウトしないことを確認します。
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は、それぞれ、トークン要求と検索サーバとクライアント側で起こり、それを通してポートを示します。同じポートは、サーバによって供給2つの以上のユニキャストセッションのために使用することができるが、ポート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).
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）を使用して、クライアントにトークンを送信します。このメッセージは、ポートCTの方にポートPTから送らなければなりません。
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.
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).
図2に示すように5.通常の流れは、強く、これは定期的なRTCPが生きNATマッピングを維持するために報告する原因として、クライアントは、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].
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].
クライアントは、RTCP受信機およびポートP4に向けたポートC2からのユニキャストセッションで拡張されたレポートを送信します。サーバーはクライアントの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）識別子を有します望ましくないパケットをフィルタリングします。これは、（多くの場合、容易ではないもの）が保証されていない限り、クライアントは、後続のユニキャストセッション用のポートを受け取る別の使用すべきです。十分な時間（2分間は、[RFC0793]で指定された1つの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]のタイムアウトルールに従って、すべての参加者がタイムアウトに基づいている以下に定義する手順によって終了することができます。サーバとクライアントの両方は、定期的に他のピアの生存性をチェックし、一定時間他のピア（[RFC3550]のセクション6.3.5は、5つのRTCPレポート間隔を示唆している）、ユニキャスト・セッションからのRTCPトラフィックが存在しない場合終了考慮しなければならない、そしてそれ以上のRTPおよび/またはRTCPパケットは、そのセッションで送信されるべきではありません。クライアントは、必要に応じて新しいユニキャストセッションを確立しようとすることができます。セッション終了のための明示的な手順が存在しない場合、クライアントはセッション終了を達成するために、サーバーにRTCPの送信を停止するかもしれません。ただし、サーバーは、ユニキャストセッションが終了するまで、RTCPの送信を停止しないものとします。トークンベースの認証は、ユニキャストセッションで許可されるように合図された場合、すなわち、ポートP4に向けてポートC2から送信された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件のポートマッピングメッセージが定義されています。
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]で指定されたルールは、以下に定義されたメッセージ内のすべての整数フィールドはネットワークバイトオーダーで運ばれた後、それは、最初に、また、ビッグエンディアンとして知られている最上位バイト（オクテット）です。特に断りのない限り、数値定数は、小数点（基数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]は適用されます。クライアントは、ポートマッピング要求またはトークン検証要求メッセージを送信しますが、それは戻って、サーバ（いずれかのポートマッピングの対応やトークン検証失敗メッセージ）からの応答を受信しない、それはRTCPのために定義されたタイマーのルールに従うことによってその要求を再送信される場合があり良い方法として、[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アドレスを共有するクライアントに対してより優れたセキュリティを有効にするには、クライアント用のトークンを生成するときに、このナンスは（例えばクライアントが同じIPアドレスを共有する他のクライアントと衝突する可能性は極めて低いランダムな値を生成する必要があります）サーバーによって考慮されます。同じポートマッピング要求メッセージは、冗長性の理由から、複数回送信されている場合は、ランダムなナンス値は、これらの重複したメッセージに同じでなければなりません。ただし、クライアントは、すべての新しいポートマッピング要求メッセージのための新しいランダムな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.
クライアント（32ビット）を要求するSSRC（O）要求を送信したクライアントのSSRCを含むフィールド。
o Associated Nonce (64 bits): Field that contains the nonce received in the Port Mapping Request message and used in Token construction.
O関連ノンス（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ビットのLengthフィールドは、Lengthフィールドを次のValueフィールドの（オクテットで）長さを示します。 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年[RFC5905]からの秒数でネットワークタイムプロトコル（NTP）タイムスタンプ値として表現されます。クライアントは、直接この要素を使用する必要はありませんので、サーバとそのクロックを同期する必要はありません。ただし、クライアントは、トークン検証要求メッセージに関連したナンスと一緒にサーバに戻って、この要素を送信する必要があるので、それがトークンに関連付けられて維持する必要があります。
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ビット）：トークンの相対的な有効期限を含むフィールド。相対有効期限は、トークンが生成された時刻から秒単位で表されます。サーバーは、要求元のクライアントにトークンを付与しないことを決定したときはいつでも、相対的な有効期限は0に設定されます（したがって、付随するトークンは無効になります）。
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ビットのLengthフィールドは、Lengthフィールドを次のValueフィールドの（オクテットで）長さを示します。この長さは、位置合わせのために必要とされる任意の詰め物が含まれていません。 Valueフィールドは、それぞれのRTCPパケットタイプを運ぶ、ゼロまたはそれ以上の8ビットのサブフィールドを運びます。パケットタイプの要素が上にない場合
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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関連ノンス（64ビット）：以下のトークンに関連付けられたノンスを含むフィールド。
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メッセージもトークンによって認証される必要があることをリアルタイムで判断する場合がありますので、クライアントは、パケット内の（ポートマッピング応答メッセージでクライアントに提供最新のリストに基づいて行動しなければなりませんタイプ要素）。クライアントは、（3.2節を参照）任意の必要なRTCPメッセージを持つトークンベースの認証の使用をサポートする必要があります。
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]
メッセージ[RFC3550] BYE O
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で識別されます。このメッセージは、サーバから送信されたとトークンが無効であったか、またはそれが（メッセージは、ポートC1に向けてポートP3から送信される）ことになっていたが、クライアントは、RTCPパケットにトークン検証要求メッセージが含まれていなかったということをクライアントに通知されます。パケットフォーマットは、図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スペースからのものであることに留意されたいです。
o SSRC of Requesting Client (32 bits): Field that contains the SSRC of the client.
クライアント（32ビット）を要求するSSRC O：クライアントのSSRCを含むフィールド。
o Failed PT (8 bits): Field that indicates the type of the RTCP packet that caused this failure message.
このエラーメッセージの原因となったRTCPパケットのタイプを示すフィールド：O PT（8ビット）に失敗しました。
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メッセージは、（例えば、RTCP BYEメッセージ等）関連FMT値を持っていなかった場合、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関連ノンス（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)
トークンのエンコードは、サーバーに知られているが、クライアントには不透明されます。実装は、十分なセキュリティを提供するために、最低でもトークンに次の情報を符号化しなければならない：クライアントのIPアドレスO（のIPv4 / IPv6アドレスのために128分の32ビット）サーバによって見られるように
o The nonce generated and inserted in the Port Mapping Request message by the client (64 bits)
Oクライアントによって生成され、ポートマッピング要求メッセージに挿入されたノンス（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)
1900年以来の秒におけるNTPタイムスタンプ値として示すサーバによって選択された絶対有効期限O [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-SHA1が侵害された場合例えば、HMAC-SHA256）が代わりに使用することができます。
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キーを選択する必要があります。実装を容易にするために、キーIDは、各HMACキーに割り当てることができます。これは、単に1つのビット（新しいキーがX（例えばある、1）と古いキーがX（例えば、0）の反転値である）、または複数のキーを一度にサポートされている場合は、キー - などとしてエンコードすることができますIDは、いくつかのビットに符号化することができます。トークンのエンコードが完全にサーバーにプライベートとクライアントに不透明であるように、任意のエンコーディングを使用することができます。トークン要素にキーIDを符号化することにより、サーバは、（CPUサイクルを節約）HMACの検証を行うために悩まずに、古いキーを拒否することができます。鍵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タイムスタンプは、さらに詳細については、[RFC5905]の第6章を参照してください年2036にラップアラウンドされることに注意してください。
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アドレスを使用してトークンを構築するための独自の手順が適用されます。その後、サーバーは、トークン検証要求メッセージ内のクライアントから送信されたトークンによる出力結果を比較します。それらが一致すると絶対有効期限が経過していない場合、サーバは、トークンが有効であることを宣言します。
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または絶対有効期限の値を挿入した場合も同様に、検証が失敗します。サーバーが途中でトークンを期限切れにしたいということも可能です。これらのケースでは、サーバーは、トークンの検証失敗メッセージ（つまり、クライアント上のポートC1へのサーバーのポートP3からなる）をクライアントに返信しなければなりません。
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回以上とポートマッピング応答メッセージは、トークンの検証失敗メッセージ2回以上を受け取ります同じトークン検証要求メッセージは、クライアントは次のことを行う必要があります。
1. Check whether or not the session description has been updated. If it was updated, act according to the new session description.
セッション記述が更新されているかどうかをチェックします。それが更新された場合は、新しいセッション記述に従って行動します。
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メッセージに含まなければならないことを示している（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:
「ポートマッピング-REQ」属性の正式な説明は以下のABNF [RFC5234]の構文で定義されます。
portmapping-req-attr = "a=portmapping-req:" port [SP nettype SP addrtype SP connection-address] CRLF
ポートマッピング-REQ-ATTR = "A =ポートマッピング-REQ：" ポート[SPのNETTYPE SPのADDRTYPE SPの接続アドレス] CRLF
Here, 'port', 'nettype', 'addrtype', and 'connection-address' are defined as specified in Section 9 of [RFC4566].
[RFC4566]のセクション9で指定されるように、ここで、「ポート」、「NETTYPE」、「ADDRTYPE」、及び「接続アドレス」が定義されています。
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.
1は、このような偽のトークンを生成する非合法的なサーバなどの追加のセキュリティリスクを評価した後、マルチキャストアドレスを使用したい場合を除き、オプションのアドレス値では、唯一のユニキャストアドレスを使用する必要があります。アドレスが指定されていない場合、メディア記述に適用可能な「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オファー/アンサー交換の「ポートマッピング-REQ」属性[RFC3264]を使用する場合は、次の点に注意してください。オファー側はアンサーにこの明細書に記載されたトークンのアプローチを利用したSDP記述の提供を送信すると、「ポートマッピング-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.
回答は、トークンのアプローチをサポートしている場合、それは戻って、申出人にその答えに同じポート番号とアドレス（もしあれば）を含むプランから「ポートマッピング-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]
SDPグルーピングフレームワークOおよび識別（FID）意味論[RFC5888]を流れ
o The RTP/Audio-Visual Profile with Feedback (AVPF) profile [RFC4585]
フィードバック付きRTP /オーディオビジュアルプロファイルO（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」属性は、（ユニキャストセッションの両方のエンドポイント上の単一のポートで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：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：ソースストリームは233.252.0.2、ポート41000のマルチキャスト宛先アドレスに198.51.100.1の送信元IPアドレス（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と42000（P3）のポートのIPアドレスを持つフィードバック目標機能を含む再送サーバは、「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 =ポートマッピング-REQ」ラインは、このメディアのブロックに記載RTPセッションに関連する1つのまたは複数の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：クライアントがサーバーへのRTPトラフィックを送信しないよう（ユニキャストストリーム用）は、第2の「M」の行で指定されたポートは、このシナリオでは何の意味もありません。
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アドレスの1つに内部ホストをマッピングします。限り内部ホストは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アドレスを使用して、攻撃者は、一つ以上の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メッセージは、パス上またはman-in-the-middle攻撃を受ける可能性があります。例えば、攻撃者がトークンの建設に使用されているポートマッピング応答またはトークン検証要求メッセージ内の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].
上のパスやman-in-the-middle攻撃のリスクや懸念がある場合は、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）を使用して、シグナリングパケットで使用される場合、これは、例えば、[RFC5652]、[RFC5751]多目的インターネットメール拡張（S / MIME）/セキュアを使用して、エンドツーエンドベースで達成することができます。代替的に、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で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
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）の値のための新しいサブレジストリを作成します。レジストリはTOKENパケットタイプレジストリのための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フィールドの長さは32の値を可能にする、5ビットです。レジストリは、次のエントリで初期化されます。
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]
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のWGとアナハイムの会議で開催されたブレイクアウトセッションでは、さまざまな個人との協議の後に出てきました。私たちは、特にマグヌスウェスターとコリンパーキンス、これらの個人のそれぞれに感謝します。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、フレデリック、R.、およびV.ヤコブソン、 "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.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "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]オット、J.、ウェンガー、S.、佐藤、N.、Burmeister、C.、およびJ.レイ「ベースのフィードバック（RTP / AVPF）リアルタイムトランスポート制御プロトコル（RTCP）の拡張RTPプロファイル」、RFC 4585、2006年7月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、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]オット、J.、チェスターフィールド、J.、およびE.学生、 "ユニキャストフィードバックを有する単一ソースマルチキャストセッションのために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]パーキンス、C.とM.ウェスター、 "シングルポートの多重化RTPデータおよび制御パケット"、RFC 5761、2010年4月。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5888]キャマリロ、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]ミルズ、D.、マーティン、J.、バーバンク、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]、RFC 6222、2011年4月Begen、A.、パーキンス、C.、およびD.翼、 "RTP制御プロトコル（RTCP）正規名（のCNAME）を選択するためのガイドライン"。
[RETRANSMISSION-FOR-SSM] Van Caenegem, T., Ver Steeg, B., and A. Begen, "Retransmission for Source-Specific Multicast (SSM) Sessions", Work in Progress, May 2011.
[再送信-FOR-SSM]ヴァンCaenegem、T.、版シュテーク、B.、およびA. Begen、 "ソース固有マルチキャスト（SSM）セッションの再送信" 進行中、作業投稿日：2011年05月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]レスコラ、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. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス攻撃の敗北拒否"、BCP 38、RFC 2827、2000年5月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]ハンドリー、M.、パーキンス、C.、およびE.ウィーラン、 "セッションアナウンスメントプロトコル"、RFC 2974、2000年10月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4145]ヨン、D.とG.カマリロ、 "TCPベースのセッション記述プロトコル（SDP）にメディアトランスポート"、RFC 4145、2005年9月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]ホルブルック、H.、およびB.カイン、 "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.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、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]ウェンガー、S.、チャンドラ、U.、ウェスター、M.、およびB.ビルマ、RFC 5104、2008年2月 "フィードバック付きRTPオーディオビジュアルプロファイル（AVPF）におけるコーデック制御メッセージ"。
[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.ターナー、 "/セキュア多目的インターネットメール拡張（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]版シュテーク、B.、Begen、A.、RFC 6285、2011年6月ヴァンCaenegem、T.、およびZ. Vaxの、 "マルチキャストRTPセッションのユニキャストベースの高速取得"。
Authors' Addresses
著者のアドレス
Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 Canada
M5J 2T3カナダONアリBegenのCisco 181ベイストリートトロント、
EMail: abegen@cisco.com
メールアドレス：abegen@cisco.com
Dan Wing Cisco 170 West Tasman Dr. San Jose, CA 95134 USA
ダン・ウィングのCisco 170西タスマン博士サンノゼ、CA 95134 USA
EMail: dwing@cisco.com
メールアドレス：dwing@cisco.com
Tom Van Caenegem Alcatel-Lucent Copernicuslaan 50 Antwerpen 2018 Belgium
トム・ヴァンCaenegemアルカテル・ルーセントCopernicuslaan 50アントワープベルギー
EMail: Tom.Van_Caenegem@alcatel-lucent.com
メールアドレス：Tom.Van_Caenegem@alcatel-lucent.com