[要約] RFC 7825は、RTSPによって制御されるメディアのためのNATトラバーサルメカニズムに関するものです。このRFCの目的は、RTSPセッションを通じてメディアストリームを正常に転送するためのNATトラバーサルの手法を提供することです。
Internet Engineering Task Force (IETF) J. Goldberg
Request for Comments: 7825 Cisco
Category: Standards Track M. Westerlund
ISSN: 2070-1721 Ericsson
T. Zeng
Nextwave Wireless, Inc.
December 2016
A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP)
リアルタイムストリーミングプロトコル（RTSP）によって制御されるメディアのネットワークアドレス変換（NAT）トラバーサルメカニズム
Abstract
概要
This document defines a solution for Network Address Translation (NAT) traversal for datagram-based media streams set up and controlled with the Real-Time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signaling channel, defining the necessary RTSP extensions and procedures.
このドキュメントでは、リアルタイムストリーミングプロトコルバージョン2（RTSP 2.0）でセットアップおよび制御されるデータグラムベースのメディアストリームのネットワークアドレス変換（NAT）トラバーサルのソリューションを定義します。 RTSPをシグナリングチャネルとして使用するように構成されたInteractive Connectivity Establishment（ICE）を使用して、必要なRTSP拡張と手順を定義します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7825.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7825で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Key Words .......................................................4
3. Solution Overview ...............................................4
4. RTSP Extensions .................................................6
4.1. ICE Transport Lower Layer ..................................6
4.2. ICE Candidate Transport Header Parameter ...................8
4.3. ICE Password and Username Transport Header Parameters .....11
4.4. ICE Feature Tag ...........................................11
4.5. Status Codes ..............................................12
4.5.1. 150 Server still working on ICE
connectivity checks ................................12
4.5.2. 480 ICE Connectivity check failure .................12
4.6. New Reason for PLAY_NOTIFY ................................12
4.7. Server-Side SDP Attribute for ICE Support .................13
5. ICE-RTSP .......................................................13
5.1. ICE Features Not Required .................................13
5.1.1. ICE-Lite ...........................................13
5.1.2. ICE-Mismatch .......................................13
5.1.3. ICE Remote Candidate Transport Header Parameter ....14
5.2. High-Reachability Configuration ...........................14
6. Detailed Solution ..............................................14
6.1. Session Description and RTSP DESCRIBE (Optional) ..........14
6.2. Setting Up the Media Streams ..............................15
6.3. RTSP SETUP Request ........................................16
6.4. Gathering Candidates ......................................16
6.5. RTSP Server Response ......................................17
6.6. Server-to-Client ICE Connectivity Checks ..................18
6.7. Client-to-Server ICE Connectivity Check ...................19
6.8. Client Connectivity Checks Complete .......................20
6.9. Server Connectivity Checks Complete .......................20
6.10. Freeing Candidates .......................................20
6.11. Steady State .............................................21
6.12. Re-SETUP .................................................21
6.13. Server-Side Changes after Steady State ...................22
7. ICE and Proxies ................................................24
7.1. Media-Handling Proxies ....................................24
7.2. Signaling-Only Proxies ....................................25
7.3. Non-supporting Proxies ....................................25
8. RTP and RTCP Multiplexing ......................................26
9. Fallback and Using Partial ICE Functionality to Improve
NAT/Firewall Traversal .........................................27
10. IANA Considerations ...........................................28
10.1. RTSP Feature Tags ........................................28
10.2. Transport Protocol Identifiers ...........................28
10.3. RTSP Transport Parameters ................................29
10.4. RTSP Status Codes ........................................29
10.5. Notify-Reason Value ......................................29
10.6. SDP Attribute ............................................29
11. Security Considerations .......................................30
11.1. ICE and RTSP .............................................30
11.2. Logging ..................................................30
12. References ....................................................31
12.1. Normative References .....................................31
12.2. Informative References ...................................32
Acknowledgments ...................................................33
Authors' Addresses ................................................33
"Real Time Streaming Protocol (RTSP)" [RFC2326] and RTSP 2.0 [RFC7826] are protocols used to set up and control one or more media streams delivering media to receivers. It is RTSP's functionality of setting up media streams that causes serious issues with Network Address Translators (NATs) [RFC3022] unless extra provisions are made by the protocol. Thus, there is a need for a NAT traversal mechanism for the media setup using RTSP.
「リアルタイムストリーミングプロトコル（RTSP）」[RFC2326]およびRTSP 2.0 [RFC7826]は、レシーバーにメディアを配信する1つ以上のメディアストリームをセットアップおよび制御するために使用されるプロトコルです。プロトコルによって追加のプロビジョニングが行われない限り、ネットワークストリームトランスレーター（NAT）[RFC3022]で深刻な問題を引き起こすのは、RTSPのメディアストリームの設定機能です。したがって、RTSPを使用してメディアをセットアップするためのNATトラバーサルメカニズムが必要です。
RTSP 1.0 [RFC2326] has suffered from the lack of a standardized NAT traversal mechanism for a long time; however, due to quality of the RTSP 1.0 specification, the work was difficult to specify in an interoperable fashion. This document is therefore built on the specification of RTSP 2.0 [RFC7826]. RTSP 2.0 is similar to RTSP 1.0 in many respects, but, significantly for this work, it contains a well-defined extension mechanism that allows a NAT traversal extension to be defined that is backwards compatible with RTSP 2.0 peers not supporting the extension. This extension mechanism was not possible in RTSP 1.0 as it would break RTSP 1.0 syntax and cause compatibility issues.
RTSP 1.0 [RFC2326]は、長い間、標準化されたNATトラバーサルメカニズムの欠如に悩まされてきました。ただし、RTSP 1.0仕様の品質のため、相互運用可能な方法で作業を指定することは困難でした。したがって、このドキュメントはRTSP 2.0 [RFC7826]の仕様に基づいています。 RTSP 2.0は多くの点でRTSP 1.0と似ていますが、この作業で重要な点として、拡張をサポートしていないRTSP 2.0ピアと下位互換性のあるNATトラバーサル拡張を定義できる明確に定義された拡張メカニズムが含まれています。この拡張メカニズムは、RTSP 1.0構文を壊し、互換性の問題を引き起こすため、RTSP 1.0では不可能でした。
There have been a number of suggested ways of resolving the NAT traversal of media for RTSP, most of which are already used in implementations. The evaluation of these NAT-traversal solutions in [RFC7604] has shown that there are many issues to consider. After extensive evaluation, a mechanism based on Interactive Connectivity Establishment (ICE) [RFC5245] was selected. There were mainly two reasons: the mechanism supports RTSP servers behind NATs and the mechanism mitigates the security threat of using RTSP servers as Distributed Denial-of-Service (DDoS) attack tools.
RTSPのメディアのNATトラバーサルを解決する方法はいくつか提案されていますが、そのほとんどは実装ですでに使用されています。 [RFC7604]でのこれらのNATトラバーサルソリューションの評価は、考慮すべき多くの問題があることを示しています。広範な評価の後、Interactive Connectivity Establishment（ICE）[RFC5245]に基づくメカニズムが選択されました。主に2つの理由がありました。NATの背後にあるRTSPサーバーをサポートするメカニズムと、RTSPサーバーを分散サービス拒否（DDoS）攻撃ツールとして使用することによるセキュリティ上の脅威を軽減するメカニズムです。
This document specifies an ICE-based solution that is optimized for media delivery from server to client. If future extensions are specified for other delivery modes than "PLAY", then the optimizations in regard to when PLAY requests are sent needs to be reconsidered.
このドキュメントでは、サーバーからクライアントへのメディア配信用に最適化されたICEベースのソリューションを指定します。 「PLAY」以外の配信モードに将来の拡張が指定されている場合は、PLAYリクエストが送信されるタイミングに関する最適化を再検討する必要があります。
The NAT problem for RTSP signaling traffic is a less prevalent problem than the NAT problem for RTSP media streams. Consequently, the former is left for future study.
RTSPシグナリングトラフィックのNAT問題は、RTSPメディアストリームのNAT問題よりも一般的な問題です。したがって、前者は将来の研究に残されています。
The ICE usage defined in this specification is called "ICE-RTSP" and does not match the full ICE for SIP/SDP (Session Description Protocol) or ICE-Lite as defined in the ICE specification [RFC5245]. ICE-RTSP is tailored to the needs of RTSP and is slightly simpler than ICE-Full for both clients and servers.
この仕様で定義されているICEの使用法は「ICE-RTSP」と呼ばれ、ICE仕様[RFC5245]で定義されているSIP / SDP（Session Description Protocol）またはICE-Liteの完全なICEとは一致しません。 ICE-RTSPはRTSPのニーズに合わせて調整されており、クライアントとサーバーの両方でICE-Fullよりも少し単純です。
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 RFC 2119 [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの "は、RFC 2119 [RFC2119]で説明されているように解釈されます。
This overview assumes that the reader has some familiarity with how ICE [RFC5245] in the context of "SIP: Session Initiation Protocol" [RFC3261] and "An Offer/Answer Model with the Session Description Protocol (SDP)" [RFC3264] works, as it primarily points out how the different ICE steps are accomplished in RTSP.
この概要は、読者が「SIP：セッション開始プロトコル」[RFC3261]および「セッション記述プロトコル（SDP）を使用したオファー/アンサーモデル」[RFC3264]のコンテキストでICE [RFC5245]がどのように機能するかをある程度理解していることを前提としていますこれは、RTSPでさまざまなICEステップがどのように実行されるかを主に指摘しているためです。
1. The RTSP server should indicate it has support for ICE via a new SDP [RFC4566] attribute ("a=rtsp-ice-d-m") in, for example, the SDP returned in the RTSP DESCRIBE message. This allows RTSP clients to only perform the new ICE exchanges with servers that support ICE. If RTSP DESCRIBE is used, the normal capability determination mechanism should also be used, i.e., Supported header with a new ICE feature tag. Note: both mechanisms should be supported, as there are various use cases where only one of them is used.
1. RTSPサーバーは、たとえば、RTSP DESCRIBEメッセージで返されたSDPの新しいSDP [RFC4566]属性（ "a = rtsp-ice-d-m"）を介してICEをサポートしていることを示す必要があります。これにより、RTSPクライアントは、ICEをサポートするサーバーとの新しいICE交換のみを実行できます。 RTSP DESCRIBEを使用する場合は、通常の機能決定メカニズムも使用する必要があります。つまり、新しいICE機能タグでサポートされるヘッダーです。注：どちらか一方のメカニズムのみを使用するさまざまなユースケースがあるため、両方のメカニズムをサポートする必要があります。
2. The RTSP client reviews the session description returned, for example by an RTSP DESCRIBE message, to determine what media streams need to be set up. For each of these media streams where the transport protocol supports connectivity checks based on Session Traversal Utilities for (NAT) (STUN) [RFC5389], the client gathers candidate addresses. See Section 4.1.1 in ICE [RFC5245]. The client then runs a STUN server on each of the local candidate's transport addresses it has gathered.
2. RTSPクライアントは、RTSP DESCRIBEメッセージなどによって返されたセッションの説明を確認して、設定する必要のあるメディアストリームを決定します。トランスポートプロトコルが（NAT）（STUN）[RFC5389]のセッショントラバーサルユーティリティに基づく接続チェックをサポートするこれらのメディアストリームごとに、クライアントは候補アドレスを収集します。 ICE [RFC5245]のセクション4.1.1を参照してください。次に、クライアントは、収集したローカル候補の各トランスポートアドレスでSTUNサーバーを実行します。
3. The RTSP client sends SETUP requests containing a transport specification with a lower layer indicating ICE and a new RTSP Transport header parameter "candidates" listing the ICE candidates for each media stream.
3. RTSPクライアントは、ICEを示す下位層のトランスポート仕様と、各メディアストリームのICE候補をリストする新しいRTSPトランスポートヘッダーパラメーター「候補」を含むSETUP要求を送信します。
4. After receiving the list of candidates from a client, the RTSP server gathers its own candidates. If the server is not behind a NAT, then a single candidate per address family (e.g., IPv4 and IPv6), media stream, and media component tuple can be included to reduce the number of combinations and speed up the completion.
4. クライアントから候補のリストを受信した後、RTSPサーバーは独自の候補を収集します。サーバーがNATの背後にない場合は、アドレスファミリごとに1つの候補（IPv4やIPv6など）、メディアストリーム、およびメディアコンポーネントタプルを含めることで、組み合わせの数を減らし、完了を高速化できます。
5. The server sets up the media and, if successful, responds to the SETUP request with a 200 OK response. In that response, the server selects the transport specification using ICE and includes its candidates in the candidates parameter.
5. サーバーはメディアをセットアップし、成功した場合は、200 OK応答でSETUP要求に応答します。その応答で、サーバーはICEを使用してトランスポート仕様を選択し、その候補を候補パラメーターに含めます。
6. The server starts the connectivity checks following the procedures described in Sections 5.7 and 5.8 of ICE [RFC5245]. If the server is not behind a NAT and uses a public IP address with a single candidate per (media stream, component, address family) tuple, then the server may be configured to not initiate connectivity checks.
6. サーバーは、ICE [RFC5245]のセクション5.7および5.8で説明されている手順に従って接続チェックを開始します。サーバーがNATの背後になく、（メディアストリーム、コンポーネント、アドレスファミリ）タプルごとに単一の候補を持つパブリックIPアドレスを使用する場合、サーバーは接続チェックを開始しないように構成できます。
7. The client receives the SETUP response and learns the candidate addresses to use for the connectivity checks and then initiates its connectivity check, following the procedures in Section 6 of ICE [RFC5245].
7. クライアントはSETUP応答を受信し、接続チェックに使用する候補アドレスを学習してから、ICE [RFC5245]のセクション6の手順に従って接続チェックを開始します。
8. When a connectivity check from the client reaches the server, it will result in a triggered check from the server. This is why servers not behind a NAT can wait until this triggered check to send out any checks for itself, so saving resources and mitigating the DDoS potential from server-initiated connectivity checks.
8. クライアントからの接続チェックがサーバーに到達すると、サーバーからトリガーされたチェックが行われます。これが、NATの背後にないサーバーが、このトリガーされたチェックがそれ自体のチェックを送信するまで待機できるため、リソースを節約し、サーバー起動の接続チェックによるDDoSの可能性を軽減します。
9. When the client has concluded its connectivity checks, including nominating candidates, and has correspondingly received the server connectivity checks on the nominated candidates for all mandatory components of all media streams, it can issue a PLAY request. If the connectivity checks have not concluded successfully, then the client may send a new SETUP request if it has any new information or believes the server may be able to do more that can result in successful checks.
9. クライアントは、候補の候補を含む接続チェックを完了し、それに応じて、すべてのメディアストリームのすべての必須コンポーネントの候補のサーバー接続チェックを受信すると、PLAY要求を発行できます。接続チェックが正常に完了しなかった場合、クライアントは、新しい情報がある場合、またはサーバーがチェックを成功させる結果をもたらす可能性があると考えている場合、新しいSETUP要求を送信できます。
10. When the RTSP server receives a PLAY request, it checks to see that the connectivity checks have concluded successfully, and only then can it play the stream. If there is a problem with the checks, then the server sends either a 150 (Server still working on ICE connectivity checks) response to show that it is still working on the connectivity checks, or a 480 (ICE Connectivity check failure) response to indicate a failure of the checks. If the checks are successful, then the server sends a 200 OK response and starts delivering media.
10. RTSPサーバーは、PLAYリクエストを受信すると、接続性チェックが正常に終了したことを確認し、その後で初めてストリームを再生できます。チェックに問題がある場合、サーバーは150（サーバーが引き続きICE接続チェックを処理している）応答を送信して接続チェックを処理中であることを示すか、480（ICE接続チェックが失敗した）応答を送信して示しますチェックの失敗。チェックが成功した場合、サーバーは200 OK応答を送信し、メディアの配信を開始します。
The client and server may release unused candidates when the ICE processing has concluded, a single candidate per component has been nominated, and a PLAY response has been received (client) or sent (server).
ICE処理が完了し、コンポーネントごとに1つの候補が指定され、PLAY応答が受信（クライアント）または送信（サーバー）されると、クライアントとサーバーは未使用の候補を解放します。
The client needs to continue to use STUN as a keep-alive mechanism for the used candidate pairs to keep their NAT bindings current. RTSP servers behind NATs will also need to send keep-alive messages when not sending media. This is important since RTSP media sessions often contain only media traffic from the server to the client so the bindings in the NAT need to be refreshed by client-to-server traffic provided by the STUN keep-alive.
クライアントは、NATバインディングを最新に保つために、使用される候補ペアのキープアライブメカニズムとしてSTUNを引き続き使用する必要があります。メディアを送信しない場合、NATの背後にあるRTSPサーバーもキープアライブメッセージを送信する必要があります。 RTSPメディアセッションにはサーバーからクライアントへのメディアトラフィックのみが含まれることが多いため、これは重要です。NATのバインディングは、STUNキープアライブによって提供されるクライアントからサーバーへのトラフィックによって更新する必要があります。
This section defines the necessary RTSP extensions for performing ICE with RTSP. Note that these extensions are based on the SDP attributes in the ICE specification unless expressly indicated otherwise.
このセクションでは、RTSPでICEを実行するために必要なRTSP拡張を定義します。これらの拡張は、特に明記されていない限り、ICE仕様のSDP属性に基づいていることに注意してください。
A new lower layer "D-ICE" for transport specifications is defined. This lower layer is datagram clean except that the protocol used must be possible to demultiplex from STUN messages (see STUN [RFC5389]). By "datagram clean" we mean that it has to be capable of describing the length of the datagram, transport that datagram (as a binary chunk of data), and provide it at the receiving side as one single item. This lower layer can be any transport type defined for ICE that does provide datagram transport capabilities. UDP-based transport candidates are defined in ICE [RFC5245] and MUST be supported. It is OPTIONAL to also support TCP-based candidates as defined by "TCP Candidates with Interactive Connectivity Establishment (ICE)" [RFC6544]. The TCP-based candidate fulfills the requirements on providing datagram transport and can thus be used in combination with RTP. Additional transport types for candidates may be defined in the future.
トランスポート仕様の新しい下位層「D-ICE」が定義されています。この下位層は、使用されるプロトコルがSTUNメッセージから逆多重化できる必要があることを除いて、データグラムがクリーンです（STUN [RFC5389]を参照）。 「データグラムクリーン」とは、データグラムの長さを記述し、そのデータグラムを（データのバイナリチャンクとして）転送し、受信側で単一のアイテムとして提供できる必要があることを意味します。この下位層は、データグラム転送機能を提供するICE用に定義された任意の転送タイプにすることができます。 UDPベースのトランスポート候補はICE [RFC5245]で定義されており、サポートする必要があります。 「インタラクティブ接続確立（ICE）を備えたTCP候補」[RFC6544]で定義されているように、TCPベースの候補もサポートすることはオプションです。 TCPベースの候補は、データグラム転送の提供に関する要件を満たしているため、RTPと組み合わせて使用できます。候補者の追加のトランスポートタイプは、将来定義される可能性があります。
This lower layer uses ICE to determine which of the different candidates shall be used and then, when the ICE processing has concluded, uses the selected candidate to transport the datagrams over this transport.
この下位層は、ICEを使用してどの候補を使用するかを決定し、ICE処理が終了すると、選択された候補を使用してこのトランスポートを介してデータグラムをトランスポートします。
This lower-layer transport can be combined with all upper-layer media transport protocols that are possible to demultiplex with STUN and that use datagrams. This specification defines the following combinations:
この下位層トランスポートは、STUNで逆多重化が可能で、データグラムを使用するすべての上位層メディアトランスポートプロトコルと組み合わせることができます。この仕様では、次の組み合わせを定義しています。
o RTP/AVP/D-ICE
o RTP / AVP / D-ICE
o RTP/AVPF/D-ICE
o RTP / AVPF / D-ICE
o RTP/SAVP/D-ICE
o RTP / SAVP / D-ICE
o RTP/SAVPF/D-ICE
o RTP / SAVPF / D-ICE
This list can be extended with more transport specifications after having performed the evaluation that they are compatible with D-ICE as lower layer. The registration is required to follow the registry rules for the Transport Protocol Identifier (see Section 22.13.1 of [RFC7826]).
このリストは、下位層としてD-ICEと互換性があるという評価を行った後、より多くのトランスポート仕様で拡張できます。登録は、トランスポートプロトコル識別子のレジストリルールに従う必要があります（[RFC7826]のセクション22.13.1を参照）。
The lower-layer "D-ICE" has the following rules for the inclusion of the RTSP Transport header (Section 18.54 of RTSP 2.0 [RFC7826]) parameters:
下位層の「D-ICE」には、RTSPトランスポートヘッダー（RTSP 2.0 [RFC7826]のセクション18.54）を含めるための次のルールがあります。
unicast: ICE only supports unicast operations; thus, it is REQUIRED that one include the unicast indicator parameter (see Section 18.54 in RTSP 2.0 [RFC7826]).
ユニキャスト：ICEはユニキャスト操作のみをサポートします。したがって、ユニキャストインジケーターパラメータを含める必要があります（RTSP 2.0 [RFC7826]のセクション18.54を参照）。
candidates: The "candidates" parameter SHALL be included as it specifies at least one candidate with which to try to establish a working transport path.
候補：「candidates」パラメータは、稼働中のトランスポートパスの確立を試みる候補を少なくとも1つ指定するため、含める必要があります。
dest_addr: This parameter MUST NOT be included since "candidates" is used instead to provide the necessary address information.
dest_addr：必要なアドレス情報を提供するために「候補」が代わりに使用されるため、このパラメーターを含めることはできません。
ICE-Password: This parameter SHALL be included (see Section 4.2).
ICE-Password：このパラメーターは含まれる必要があります（セクション4.2を参照）。
ICE-ufrag: This parameter SHALL be included (see Section 4.2).
ICE-ufrag：このパラメーターを含める必要があります（セクション4.2を参照）。
This section defines a new RTSP transport parameter for carrying ICE candidates related to the transport specification they appear within, which may then be validated with an end-to-end connectivity check using STUN [RFC5389]. Transport parameters may only occur once in each transport specification. For transport specifications using "D-ICE" as lower layer, this parameter MUST be present. The parameter can contain one or more ICE candidates. In the SETUP response, there is only a single transport specification; if that uses the "D-ICE" lower layer, this parameter MUST be present and include the server-side candidates.
このセクションでは、内部に表示されるトランスポート仕様に関連するICE候補を運ぶための新しいRTSPトランスポートパラメーターを定義します。これは、STUN [RFC5389]を使用したエンドツーエンドの接続チェックで検証できます。トランスポートパラメータは、各トランスポート仕様で1回だけ使用できます。下位層として「D-ICE」を使用するトランスポート仕様の場合、このパラメーターが存在する必要があります。パラメータには1つ以上のICE候補を含めることができます。 SETUP応答では、トランスポート指定は1つしかありません。それが「D-ICE」下位層を使用する場合、このパラメーターが存在し、サーバー側の候補を含める必要があります。
The ABNF [RFC5234] for these transport header parameters are:
これらのトランスポートヘッダーパラメータのABNF [RFC5234]は次のとおりです。
trns-parameter = <Defined in Section 20.2.3 of [RFC7826]>
trns-parameter =/ SEMI ice-trn-par
ice-trn-par = "candidates" EQUAL DQUOTE SWS ice-candidate
*(SEMI ice-candidate) SWS DQUOTE
ice-candidate = foundation SP
component-id SP
transport SP
priority SP
connection-address SP
port SP
cand-type
[SP rel-addr]
[SP rel-port]
[SP tcp-type-ext] ; Mandatory if transport = TCP
*(SP extension-att-name SP extension-att-value)
foundation = <See Section 15.1 of [RFC5245]>
component-id = <See Section 15.1 of [RFC5245]>
transport = <See Section 15.1 of [RFC5245]>
priority = <See Section 15.1 of [RFC5245]>
cand-type = <See Section 15.1 of [RFC5245]>
rel-addr = <See Section 15.1 of [RFC5245]>
rel-port = <See Section 15.1 of [RFC5245]>
tcp-type-ext = <See Section 4.5 of [RFC6544]>
extension-att-name = <See Section 15.1 of [RFC5245]>
extension-att-value = <See Section 15.1 of [RFC5245]>
connection-address = <See [RFC4566]>
port = <See [RFC4566]>
EQUAL = <Defined in [RFC7826]>
DQUOTE = <Defined in [RFC7826]>
SWS = <Defined in [RFC7826]>
SEMI = <Defined in [RFC7826]>
SP = <Defined in [RFC7826]>
<connection-address>: is the unicast IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and Fully Qualified Domain Names (FQDNs), taken from SDP [RFC4566]. Note, this context MUST have a unicast address for this parameter, even though a multicast address would be syntactically valid. The connection address SHOULD use the same format (explicit IP or FQDN) as in the dest_addr parameter used in the transport specification that express any fallback. An IP address is preferred for simplicity, but both an IP Address and FQDN can be used. In the FQDN case, when receiving a SETUP request or response containing an FQDN in an ice-candidate parameter, the FQDN is looked up in the DNS first using a AAAA record (assuming the agent supports IPv6), and if no result is found or the agent only supports IPv4, using an A record. If the DNS query returns more than one IP address, one is chosen, and then used for the remainder of ICE processing, which in RTSP is subsequent RTSP SETUPs for the same RTSP session.
<connection-address>：候補のユニキャストIPアドレスで、IPv4アドレス、IPv6アドレス、および完全修飾ドメイン名（FQDN）を許可し、SDP [RFC4566]から取得されます。マルチキャストアドレスが構文的に有効であっても、このコンテキストにはこのパラメーターのユニキャストアドレスが必要です。接続アドレスは、フォールバックを表すトランスポート仕様で使用されるdest_addrパラメータと同じ形式（明示的なIPまたはFQDN）を使用する必要があります（SHOULD）。簡単にするためにIPアドレスが推奨されますが、IPアドレスとFQDNの両方を使用できます。 FQDNの場合、ice-candidateパラメーターにFQDNを含むSETUP要求または応答を受信すると、最初にAAAAレコードを使用してDNSでFQDNが検索され（エージェントがIPv6をサポートしていると想定）、結果が見つからない場合、またはエージェントは、Aレコードを使用してIPv4のみをサポートします。 DNSクエリが複数のIPアドレスを返す場合は、1つが選択され、残りのICE処理に使用されます。これは、RTSPでは、同じRTSPセッションの後続のRTSPセットアップです。
<port>: is the port of the candidate; the syntax is defined by SDP [RFC4566].
<port>：候補者のポートです。構文はSDP [RFC4566]で定義されています。
<transport>: indicates the transport protocol for the candidate. The ICE specification defines UDP. "TCP Candidates with Interactive Connectivity Establishment (ICE)" [RFC6544] defines how TCP is used as candidates. Additional extensibility is provided to allow for future transport protocols to be used with ICE, such as the Datagram Congestion Control Protocol (DCCP) [RFC4340].
<transport>：候補のトランスポートプロトコルを示します。 ICE仕様はUDPを定義しています。 「Interactive Connectivity Establishment（ICE）を使用したTCP候補」[RFC6544]は、TCPが候補としてどのように使用されるかを定義します。データグラム輻輳制御プロトコル（DCCP）[RFC4340]などの将来のトランスポートプロトコルをICEで使用できるように、追加の拡張性が提供されます。
<foundation>: is an identifier that is equivalent for two candidates that are of the same type, share the same base IP address, and come from the same STUN server. It is composed of one to thirty two <ice-char>. The foundation is used to optimize ICE performance in the Frozen algorithm (as described in [RFC5245]).
<foundation>：同じタイプで、同じベースIPアドレスを共有し、同じSTUNサーバーからの2つの候補に相当する識別子。 1〜32個の<ice-char>で構成されています。基盤は、凍結アルゴリズム（[RFC5245]で説明）でのICEパフォーマンスを最適化するために使用されます。
<component-id>: identifies the specific component of the media stream for which this is a candidate and is a positive integer belonging to the range 1-256. It MUST start at 1 and MUST increment by 1 for each component of a particular media stream. For media streams based on RTP, candidates for the actual RTP media MUST have a component ID of 1, and candidates for RTCP MUST have a component ID of 2 unless RTP and RTCP Multiplexing (Section 8) is used, in which case the second component is omitted and RTP and RTCP are both transported over the first component. Other types of media streams that require multiple components MUST develop specifications that define the mapping of components to component IDs. See Section 14 in [RFC5245] for additional discussion on extending ICE to new media streams.
<component-id>：これが候補であり、1〜256の範囲に属する正の整数であるメディアストリームの特定のコンポーネントを識別します。特定のメディアストリームのコンポーネントごとに1から始まり、1ずつインクリメントする必要があります。 RTPに基づくメディアストリームの場合、RTPおよびRTCP多重化（セクション8）が使用されない限り、実際のRTPメディアの候補はコンポーネントIDが1でなければならず、RTCPの候補はコンポーネントIDが2でなければなりません。省略され、RTPとRTCPの両方が最初のコンポーネントを介して転送されます。複数のコンポーネントを必要とする他のタイプのメディアストリームは、コンポーネントのコンポーネントIDへのマッピングを定義する仕様を開発する必要があります。 ICEを新しいメディアストリームに拡張する方法の詳細については、[RFC5245]のセクション14をご覧ください。
<priority>: is a positive integer in the range 1 to (2**31 - 1).
<priority>：1から（2 ** 31-1）の範囲の正の整数です。
<cand-type>: encodes the type of candidate. The ICE specification defines the values "host", "srflx", "prflx", and "relay" for host, server-reflexive, peer-reflexive, and relayed candidates, respectively. The set of candidate types is extensible for the future.
<cand-type>：候補のタイプをエンコードします。 ICE仕様では、ホスト、サーバー再帰、ピア再帰、およびリレーされた候補に対して、それぞれ値「host」、「srflx」、「prflx」、および「relay」を定義しています。候補タイプのセットは、将来的に拡張可能です。
<rel-addr> and <rel-port>: convey transport addresses related to the candidate, useful for diagnostics and other purposes. <rel-addr> and <rel-port> MUST be present for server-reflexive, peer-reflexive, and relayed candidates. If a candidate is server- or peer-reflexive, <rel-addr> and <rel-port> are equal to the base for that server- or peer-reflexive candidate. If the candidate is relayed, <rel-addr> and <rel-port> are equal to the mapped address in the TURN Allocate Response that provided the client with that relayed candidate (see Appendix B.3 of ICE [RFC5245] for a discussion of its purpose). If the candidate is a host candidate, <rel-addr> and <rel-port> MUST be omitted.
<rel-addr>および<rel-port>：候補に関連するトランスポートアドレスを伝達します。診断やその他の目的に役立ちます。 <rel-addr>と<rel-port>は、サーバー再帰、ピア再帰、およびリレーされた候補に存在する必要があります。候補がサーバーまたはピア再帰的である場合、<rel-addr>および<rel-port>は、そのサーバーまたはピア再帰的候補のベースに等しくなります。候補がリレーされる場合、<rel-addr>および<rel-port>は、クライアントにそのリレーされた候補を提供したTURN Allocate Responseのマッピングアドレスと同じです（説明については、ICE [RFC5245]の付録B.3を参照してください）。その目的の）。候補がホスト候補である場合、<rel-addr>と<rel-port>は省略しなければなりません。
<tcp-type-ext>: conveys the candidate's connection type (active, passive, or simultaneous-open (S-O)) for TCP-based candidates. This MUST be included for candidates that have <transport> set to TCP and MUST NOT be included for other transport types, including UDP.
<tcp-type-ext>：TCPベースの候補の候補の接続タイプ（アクティブ、パッシブ、または同時オープン（S-O））を伝えます。これは、<transport>がTCPに設定されている候補に含める必要があり、UDPを含む他のトランスポートタイプには含めないでください。
<extension-att-name> and <extension-att-value>: These are prototypes for future extensions of the candidate line. The ABNF for these allows any 8-bit value except NUL, CR, or LF. However, the extensions will occur within a structured line that uses the DQUOTE, SEMI, SWS, and SP ABNF constructs as delimiters; thus, those delimiter characters MUST be escaped if they would occur within an extension-att-name or extension-att-value. The escape mechanism that MUST be used is the Percent-Encoding defined in Section 2.1 of [RFC3986]. This mechanism is selected as it needs to be supported in an RTSP implementation to deal with URIs anyway. The byte values (in hex) that MUST be escaped are the following: 0x09, 0x20, 0x22, 0x25, and 0x3B.
<extension-att-name>および<extension-att-value>：これらは、候補ラインの将来の拡張のためのプロトタイプです。これらのABNFでは、NUL、CR、LF以外の8ビット値を使用できます。ただし、拡張は、DQUOTE、SEMI、SWS、およびSP ABNF構成子を区切り文字として使用する構造化された行内で発生します。したがって、これらの区切り文字は、extension-att-nameまたはextension-att-value内で発生する場合はエスケープする必要があります。使用する必要があるエスケープメカニズムは、[RFC3986]のセクション2.1で定義されているパーセントエンコーディングです。このメカニズムは、いずれにしてもURIを処理するためにRTSP実装でサポートする必要があるために選択されています。エスケープする必要があるバイト値（16進数）は、0x09、0x20、0x22、0x25、および0x3Bです。
The ICE password and username for each agent need to be transported using RTSP. For that purpose, new Transport header parameters are defined (see Section 18.54 of [RFC7826].
各エージェントのICEパスワードとユーザー名は、RTSPを使用して転送する必要があります。そのために、新しいトランスポートヘッダーパラメータが定義されています（[RFC7826]のセクション18.54を参照）。
There MUST be an "ICE-Password" and "ICE-ufrag" parameter for each media stream. The ICE-ufrag and ICE-Password parameter values MUST be chosen randomly at the beginning of a session. The ICE-ufrag value MUST contain at least 24 bits of randomness, and the ICE-Password value MUST contain at least 128 bits of randomness. This means that the ICE-ufrag value will be at least 4 characters long, and the ICE-Password value at least 22 characters long, since the grammar for these attributes allows for 6 bits of randomness per character. The values MAY be longer than 4 and 22 characters respectively, of course, up to 256 characters. The upper limit allows for buffer sizing in implementations. Its large upper limit allows for increased amounts of randomness to be added over time.
各メディアストリームには、「ICE-Password」および「ICE-ufrag」パラメータが必要です。 ICE-ufragおよびICE-Passwordパラメータ値は、セッションの開始時にランダムに選択する必要があります。 ICE-ufrag値には少なくとも24ビットのランダム性が含まれている必要があり、ICE-Password値には少なくとも128ビットのランダム性が含まれている必要があります。これは、これらの属性の文法では文字ごとに6ビットのランダム性が許可されているため、ICE-ufrag値は少なくとも4文字、ICE-Password値は少なくとも22文字になることを意味します。値はそれぞれ4文字と22文字より長くてもかまいません（もちろん256文字まで）。上限により、実装でのバッファサイズ設定が可能になります。その大きな上限により、時間の経過とともにランダム性の量を増やすことができます。
The ABNF [RFC5234] for these parameters is:
これらのパラメータのABNF [RFC5234]は次のとおりです。
trns-parameter =/ SEMI ice-password-par
trns-parameter =/ SEMI ice-ufrag-par
ice-password-par = "ICE-Password" EQUAL DQUOTE password DQUOTE
ice-ufrag-par = "ICE-ufrag" EQUAL DQUOTE ufrag DQUOTE
password = <Defined in [RFC5245], Section 15.4>
ufrag = <Defined in [RFC5245], Section 15.4>
EQUAL = <Defined in [RFC7826]>
SEMI = <Defined in [RFC7826]>
DQUOTE = <Defined in [RFC7826]>
A feature tag is defined for use in the RTSP capabilities mechanism for ICE support of media transport using datagrams: "setup.ice-d-m". This feature tag indicates that one supports all the mandatory functions of this specification. It is applicable to all types of RTSP agents: clients, servers, and proxies.
機能タグは、データグラムを使用したメディアトランスポートのICEサポートのRTSP機能メカニズムで使用するために定義されています： "setup.ice-d-m"。この機能タグは、この仕様のすべての必須機能をサポートすることを示します。これは、すべてのタイプのRTSPエージェント（クライアント、サーバー、プロキシ）に適用できます。
The RTSP client SHOULD send the feature tag "setup.ice-d-m" in the Supported header in all SETUP requests that contain the "D-ICE" lower-layer transport. Note, this is not a "MUST" as an RTSP client can always attempt to perform a SETUP using ICE to see if it functions or fails. However, including the feature tag in the Supported header ensures that proxies supporting this specification explicitly indicate such support; see Section 7.
RTSPクライアントは、「D-ICE」下位層トランスポートを含むすべてのSETUPリクエストのサポートヘッダーで機能タグ「setup.ice-d-m」を送信する必要があります（SHOULD）。 RTSPクライアントは常にICEを使用してセットアップを実行し、機能するか失敗するかを確認できるため、これは「必須」ではないことに注意してください。ただし、Supportedヘッダーに機能タグを含めると、この仕様をサポートするプロキシがそのようなサポートを明示的に示すことが保証されます。セクション7を参照してください。
For ICE, there are two new RTSP response codes to indicate progress and errors.
ICEの場合、進行状況とエラーを示す2つの新しいRTSP応答コードがあります。
+------+----------------------------------------------+-------------+
| Code | Description | Method |
+------+----------------------------------------------+-------------+
| 150 | Server still working on ICE connectivity | PLAY |
| | checks | |
| | | |
| 480 | ICE Connectivity check failure | PLAY, SETUP |
+------+----------------------------------------------+-------------+
Table 1: New Status Codes and Their Usage with RTSP Methods
表1：RTSPメソッドでの新しいステータスコードとその使用法
The 150 response code indicates that ICE connectivity checks are still in progress and haven't concluded. This response SHALL be sent within 200 milliseconds of receiving a PLAY request that currently can't be fulfilled because ICE connectivity checks are still running. A client can expect network delays between the server and client resulting in a response longer than 200 milliseconds. Subsequently, every 3 seconds after the previous one was sent, a 150 reply SHALL be sent until the ICE connectivity checks conclude either successfully or in failure, and a final response for the request can be provided.
150応答コードは、ICE接続性チェックがまだ進行中であり、まだ完了していないことを示しています。この応答は、ICE接続チェックがまだ実行されているために現在実行できないPLAY要求を受信してから200ミリ秒以内に送信する必要があります。クライアントは、サーバーとクライアント間のネットワーク遅延を予期して、200ミリ秒より長い応答をもたらす可能性があります。その後、前のものが送信されてから3秒ごとに、ICE接続性チェックが成功または失敗のいずれかで終了するまで150応答が送信され、要求の最終応答が提供されます。
The 480 client error response code is used in cases when the request can't be fulfilled due to a failure in the ICE processing, such as all the connectivity checks have timed out. This error message can appear either in response to a SETUP request to indicate that no candidate pair can be constructed or in response to a PLAY request to indicate that the server's connectivity checks resulted in failure.
480クライアントエラー応答コードは、すべての接続チェックがタイムアウトしたなど、ICE処理の失敗が原因で要求を実行できない場合に使用されます。このエラーメッセージは、SETUP要求への応答として表示され、候補ペアを構築できないことを示すか、PLAY要求への応答として表示され、サーバーの接続チェックが失敗したことを示します。
A new value used in the PLAY_NOTIFY methods Notify-Reason header is defined: "ice-restart". This reason indicates that an ICE restart needs to happen on the identified resource and session.
PLAY_NOTIFYメソッドのNotify-Reasonヘッダーで使用される新しい値「ice-restart」が定義されています。この理由は、ICEの再起動が、識別されたリソースとセッションで発生する必要があることを示しています。
Notify-Reas-val =/ "ice-restart"
Notify-Reas-val = / "ice-restart"
If the server supports the media NAT traversal for RTSP-controlled sessions as described in this RFC, then the server SHOULD include the "a=rtsp-ice-d-m" SDP attribute in any SDP (if used) describing content served by the server. This is a session-level-only attribute; see [RFC4566].
このRFCで説明されているように、サーバーがRTSP制御セッションのメディアNATトラバーサルをサポートしている場合、サーバーは、サーバーが提供するコンテンツを説明するSDP（使用されている場合）に「a = rtsp-ice-d-m」SDP属性を含める必要があります（SHOULD）。これはセッションレベルのみの属性です。 [RFC4566]を参照してください。
The ABNF [RFC5234] for the "rtsp-ice-d-m" attribute is:
「rtsp-ice-d-m」属性のABNF [RFC5234]は次のとおりです。
rtsp-ice-d-m-attr = "a=" "rtsp-ice-d-m"
rtsp-ice-d-m-attr = "a =" "rtsp-ice-d-m"
This section discusses differences between the regular ICE usage defined in [RFC5245] and ICE-RTSP. The reasons for the differences relate to the clearer client/server roles that RTSP provides and how the RTSP session establishment signaling occurs within RTSP compared to SIP/SDP offer/answer.
このセクションでは、[RFC5245]で定義されている通常のICEの使用とICE-RTSPの違いについて説明します。違いの理由は、RTSPが提供するより明確なクライアント/サーバーの役割と、SIP / SDPオファー/アンサーと比較してRTSP内でRTSPセッション確立シグナリングがどのように発生するかに関連しています。
A number of ICE signaling features are not needed with RTSP and are discussed below.
RTSPでは多くのICEシグナリング機能は不要であり、以下で説明します。
The ICE-Lite attribute SHALL NOT be used in the context of RTSP. The ICE specification describes two implementations of ICE: Full and Lite, where hosts that are not behind a NAT are allowed to implement only Lite. For RTSP, the Lite implementation is insufficient because it does not cause the media server to send a connectivity check, which is used to protect against making the RTSP server a denial-of-service tool.
ICE-Lite属性は、RTSPのコンテキストでは使用しないでください。 ICE仕様では、ICEの2つの実装について説明しています。NATの背後にないホストは、Liteのみを実装できます。 RTSPの場合、RTSPサーバーをサービス拒否ツールにすることから保護するために使用される接続チェックをメディアサーバーに送信させないため、Liteの実装は不十分です。
The ice-mismatch parameter indicates that the offer arrived with a default destination for a media component that didn't have a corresponding candidate attribute. This is not needed for RTSP as the ICE-based lower-layer transport specification either is supported or another alternative transport is used. This is always explicitly indicated in the SETUP request and response.
ice-mismatchパラメータは、対応する候補属性を持たないメディアコンポーネントのデフォルトの宛先でオファーが到着したことを示します。 ICEベースの下位層トランスポート仕様がサポートされているか、別のトランスポートが使用されているため、これはRTSPには必要ありません。これは、常にSETUP要求と応答で明示的に示されます。
The Remote candidate attribute is not needed for RTSP for the following reasons. Each SETUP request results in an independent ICE processing chain that either fails or results in nominating a single candidate pair to use. If a new SETUP request for the same media is sent, it needs to use a new username fragment and password to avoid any race conditions or uncertainty about to which round of processing the STUN requests relate.
以下の理由により、リモート候補属性はRTSPには必要ありません。各SETUP要求により、独立したICE処理チェーンが失敗するか、単一の候補ペアを指定して使用することになります。同じメディアに対する新しいSETUP要求が送信された場合は、新しいユーザー名フラグメントとパスワードを使用して、競合状態や、STUN要求の処理のラウンドに関する不確実性を回避する必要があります。
ICE-RTSP contains a high-reachability configuration when the RTSP servers are not behind NATs. Please note that "not behind NATs" may apply in some special cases also for RTSP servers behind NATs given that they are in an address space that has reachability for all the RTSP clients intended to able to reach the server. The high-reachability configuration is similar to ICE-Lite as it allows for some reduction in the server's burden. However, due to the need to still verify that the client is actually present and wants to receive the media stream, the server must also initiate binding requests and await binding responses. The reduction for the high-reachability configuration of ICE-RTSP is that they don't need to initiate their own checks and instead rely on triggered checks for verification. This also removes a denial-of-service threat where an RTSP SETUP request will trigger large amount of STUN connectivity checks towards provided candidate addresses.
RTSPサーバーがNATの背後にない場合、ICE-RTSPには高到達性構成が含まれます。 「NATの背後にない」は、NATの背後にあるRTSPサーバーにも適用される可能性があることに注意してください。NATの背後にあるRTSPサーバーは、サーバーに到達できるすべてのRTSPクライアントに到達可能であるアドレス空間にあるためです。高到達可能性構成は、サーバーの負担をある程度軽減できる点でICE-Liteに似ています。ただし、クライアントが実際に存在し、メディアストリームの受信を希望していることを引き続き確認する必要があるため、サーバーもバインディング要求を開始し、バインディング応答を待機する必要があります。 ICE-RTSPの高到達可能性構成の削減は、独自のチェックを開始する必要がなく、代わりにトリガーされたチェックに依存して検証を行うことです。これにより、RTSP SETUP要求が、提供された候補アドレスに対して大量のSTUN接続チェックをトリガーするサービス拒否の脅威も排除されます。
This section describes, in detail, how the interaction and flow of ICE works with RTSP messages.
このセクションでは、ICEの相互作用とフローがRTSPメッセージとどのように連携するかについて詳しく説明します。
The RTSP server is RECOMMENDED to indicate it has support for ICE by sending the "a=rtsp-ice-d-m" SDP attribute in the response to the RTSP DESCRIBE message if SDP is used. This allows RTSP clients to only send the new ICE exchanges with servers that support ICE thereby limiting the overhead on current non-ICE supporting RTSP servers. When not using RTSP DESCRIBE, it is still RECOMMENDED to use the SDP attribute for the session description.
RTSPサーバーは、SDPが使用されている場合、RTSP DESCRIBEメッセージへの応答で「a = rtsp-ice-d-m」SDP属性を送信することにより、ICEをサポートしていることを示すために推奨されます。これにより、RTSPクライアントは、ICEをサポートするサーバーとの新しいICE交換のみを送信できるため、現在のICEをサポートしないRTSPサーバーのオーバーヘッドを制限できます。 RTSP DESCRIBEを使用しない場合でも、セッションの説明にSDP属性を使用することをお勧めします。
A client can also use the DESCRIBE request to determine explicitly if both server and any proxies support ICE. The client includes the Supported header with its supported feature tags, including "setup.ice-d-m". Upon seeing the Supported header, any proxy will include the Proxy-Supported header with the feature tags it supports.
クライアントはDESCRIBEリクエストを使用して、サーバーとプロキシの両方がICEをサポートしているかどうかを明示的に判断することもできます。クライアントには、「setup.ice-d-m」などのサポートされている機能タグとともに、Supportedヘッダーが含まれています。サポートされているヘッダーを確認すると、プロキシには、サポートされている機能タグが付いたProxy-Supportedヘッダーが含まれます。
The server will echo back the Proxy-Supported header and its own version of the Supported header so enabling a client to determine whether or not all involved parties support ICE. Note that even if a proxy is present in the chain that doesn't indicate support for ICE, it may still work (see Section 7).
サーバーは、Proxy-Supportedヘッダーとそれ自体のバージョンのSupportedヘッダーをエコーバックして、クライアントがすべての関係者がICEをサポートしているかどうかを判断できるようにします。 ICEのサポートを示さないプロキシがチェーンに存在していても、機能する場合があることに注意してください（セクション7を参照）。
For example:
例えば：
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0
CSeq: 312
User-Agent: PhonyClient 1.2
Accept: application/sdp, application/example
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
S->C: RTSP/2.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.1
Content-Type: application/sdp
Content-Length: 367
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
v=0
o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/lectures/sdp.ps
e=seminar@example.com (Seminar Management)
t=2873397496 2873404696
a=recvonly
a=rtsp-ice-d-m
a=control: *
m=audio 3456 RTP/AVP 0
a=control: /audio
m=video 2232 RTP/AVP 31
a=control: /video
The RTSP client reviews the session description returned, for example, by an RTSP DESCRIBE message, to determine what media resources need to be set up. For each of these media streams where the transport protocol supports ICE connectivity checks, the client SHALL gather candidate addresses for UDP transport as described in Section 4.1.1 in ICE [RFC5245] according to standard ICE rather than the ICE-Lite implementation and according to Section 5 of ICE TCP [RFC6544] for TCP-based candidates.
RTSPクライアントは、RTSP DESCRIBEメッセージなどによって返されたセッションの説明を確認して、設定する必要のあるメディアリソースを決定します。トランスポートプロトコルがICE接続チェックをサポートするこれらの各メディアストリームについて、クライアントは、ICE-Lite実装ではなく標準ICEに従って、ICEのセクション4.1.1で説明されているように（RFC5245] TCPベースの候補のICE TCP [RFC6544]のセクション5。
The RTSP client will then send at least one SETUP request per media stream to establish the media streams required for the desired session. For each media stream where it desires to use ICE, it MUST include a transport specification with "D-ICE" as the lower layer, and each media stream SHALL have its own unique combination of ICE candidates and ICE-ufrag. This transport specification SHOULD be placed first in the list to give it highest priority. It is RECOMMENDED that additional transport specifications be provided as a fallback in case of proxies that do not support ICE. The RTSP client will be initiating and thus the controlling party in the ICE processing. For example (note that some lines are broken in contradiction with the defined syntax due to space restrictions in the documenting format):
次に、RTSPクライアントは、メディアストリームごとに少なくとも1つのSETUP要求を送信して、目的のセッションに必要なメディアストリームを確立します。 ICEを使用するメディアストリームごとに、下位層として「D-ICE」を含むトランスポート仕様を含める必要があり、各メディアストリームは、ICE候補とICE-ufragの独自の組み合わせを持つ必要があります。このトランスポート仕様は、最高の優先順位を与えるために、リストの最初に配置する必要があります（SHOULD）。 ICEをサポートしないプロキシの場合のフォールバックとして、追加のトランスポート仕様を提供することをお勧めします。 RTSPクライアントが開始し、ICE処理の制御当事者となります。例（ドキュメント形式のスペース制限により、定義された構文と矛盾して一部の行が壊れていることに注意してください）：
C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0
CSeq: 313
Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=8hhY;
ICE-Password=asd88fgpdd777uzjYhagZg; candidates="
1 1 UDP 2130706431 10.0.1.17 8998 typ host;
2 1 UDP 1694498815 192.0.2.3 45664 typ srflx
raddr 10.0.1.17 rport 8998"; RTCP-mux,
RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971",
RTP/AVP/TCP; unicast;interleaved=0-1
Accept-Ranges: NPT, UTC
User-Agent: PhonyClient/1.2
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
Upon receiving a SETUP request, the server can determine what media resource should be delivered and which transport alternatives the client supports. If one based on D-ICE is on the list of supported transports and preferred among the supported, the below applies.
SETUP要求を受信すると、サーバーは、配信するメディアリソースと、クライアントがサポートする代替トランスポートを決定できます。 D-ICEに基づくものがサポートされているトランスポートのリストにあり、サポートされているトランスポートの中で優先されている場合、以下が適用されます。
The transport specification will indicate which media protocol is to be used and, based on this and the client's candidates, the server determines the protocol and if it supports ICE with that protocol. The server SHALL then gather its UDP candidates according to Section 4.1.1 in ICE [RFC5245] and any TCP-based ones according to Section 5 of ICE TCP [RFC6544].
トランスポート仕様は、使用するメディアプロトコルを示し、これとクライアントの候補に基づいて、サーバーはプロトコルを決定し、そのプロトコルでICEをサポートするかどうかを決定します。次に、サーバーは、ICE [RFC5245]のセクション4.1.1に従ってUDP候補を収集し、ICE TCP [RFC6544]のセクション5に従ってTCPベースの候補を収集する必要があります。
Servers that have an address that is generally reachable by any client within the address scope the server intends to serve MAY be specially configured (high-reachability configuration). This special configuration has the goal of reducing the server-side candidate to preferably a single one per (address family, media stream, media component) tuple. Instead of gathering all possible addresses including relayed and server-reflexive addresses, the server uses a single address per address family that the server knows should be reachable by a client behind one or more NATs. The reason for this special configuration is twofold: Firstly, it reduces the load on the server in address gathering and in ICE processing during the connectivity checks. Secondly, it will reduce the number of permutations for candidate pairs significantly thus potentially speeding up the conclusion of the ICE processing. However, note that using this option on a server that doesn't fulfill the requirement of being reachable is counterproductive, and it is important that this is correctly configured.
サーバーがサービスを提供する予定のアドレススコープ内の任意のクライアントから通常到達可能なアドレスを持つサーバーは、特別に構成できます（高到達性構成）。この特別な構成の目的は、サーバー側の候補を（アドレスファミリ、メディアストリーム、メディアコンポーネント）タプルごとに1つに減らすことです。リレーアドレスやサーバー再帰アドレスを含むすべての可能なアドレスを収集する代わりに、サーバーは、1つ以上のNATの背後にあるクライアントから到達可能であることがわかっているアドレスファミリごとに1つのアドレスを使用します。この特別な構成の理由は2つあります。1つ目は、接続性チェック中のアドレス収集とICE処理におけるサーバーの負荷を軽減することです。第2に、候補ペアの順列の数を大幅に減らし、ICE処理の結論をスピードアップする可能性があります。ただし、到達可能であるという要件を満たさないサーバーでこのオプションを使用することは逆効果であり、これが正しく構成されていることが重要です。
The above general consideration for servers applies also for TCP-based candidates. A general implementation should support several candidate collection techniques and connection types. For TCP-based candidates, a high-reachability configured server is recommended to only offer Host candidates. In addition to passive connection types, the server can select to provide active or S-O connection types to match the client's candidates.
サーバーに関する上記の一般的な考慮事項は、TCPベースの候補にも適用されます。一般的な実装では、いくつかの候補収集手法と接続タイプをサポートする必要があります。 TCPベースの候補の場合、ホスト候補のみを提供するために、高到達可能性構成サーバーが推奨されます。サーバーは、パッシブ接続タイプに加えて、クライアントの候補に一致するアクティブまたはS-O接続タイプを提供するように選択できます。
The server determines if the SETUP request is successful and, if so, returns a 200 OK response; otherwise, it returns an error code. At that point, the server, having selected a transport specification using the "D-ICE" lower layer, will need to include that transport specification in the response message. The transport specification SHALL include the candidates gathered in Section 6.4 in the "candidates" transport header parameter as well as the server's ICE username fragment and password. In the case that there are no valid candidate pairs with the combination of the client and server candidates, a 480 (ICE Connectivity check failure) error response SHALL be returned, which MUST include the server's candidates. The return of a 480 error may allow both the server and client to release their candidates; see Section 6.10.
サーバーは、SETUP要求が成功したかどうかを判断し、成功した場合は200 OK応答を返します。それ以外の場合は、エラーコードを返します。その時点で、「D-ICE」下位層を使用してトランスポート仕様を選択したサーバーは、そのトランスポート仕様を応答メッセージに含める必要があります。トランスポート仕様は、サーバーのICEユーザー名フラグメントとパスワードだけでなく、「candidates」トランスポートヘッダーパラメーターのセクション6.4で収集された候補を含むものとします（SHALL）。クライアントとサーバーの候補の組み合わせで有効な候補ペアがない場合、480（ICE接続性チェックの失敗）エラー応答が返されます（サーバーの候補を含める必要があります）。 480エラーが返されると、サーバーとクライアントの両方が候補を解放できる場合があります。セクション6.10を参照してください。
Below is an example of a successful response to the request in Section 6.3.
以下は、セクション6.3のリクエストに対する正常な応答の例です。
S->C: RTSP/2.0 200 OK
CSeq: 313
Session: 12345678
Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=MkQ3;
ICE-Password=pos12Dgp9FcAjpq82ppaF; candidates="
1 1 UDP 2130706431 192.0.2.56 50234 typ host"
Accept-Ranges: NPT
Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.1
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
The server SHALL start the connectivity checks following the procedures described in Sections 5.7 and 5.8 of ICE [RFC5245] unless it is configured to use the high-reachability option. If it is, then it MAY suppress its own checks until the server's checks are triggered by the client's connectivity checks.
サーバーは、高到達性オプションを使用するように構成されていない限り、ICE [RFC5245]のセクション5.7および5.8で説明されている手順に従って接続チェックを開始する必要があります（SHALL）。そうである場合、サーバーのチェックがクライアントの接続性チェックによってトリガーされるまで、それ自体のチェックを抑制してもよい（MAY）。
Please note that Section 5.8 of ICE [RFC5245] does specify that the initiation of the checks are paced and new ones are only started every Ta milliseconds. The motivation for this is documented in Appendix B.1 of ICE [RFC5245] as for SIP/SDP all media streams within an offer/answer dialog are running using the same queue. To ensure the same behavior with RTSP, the server SHALL use a single pacer queue for all media streams within each RTSP session.
ICE [RFC5245]のセクション5.8は、チェックの開始がペース調整され、新しいチェックはTaミリ秒ごとにのみ開始されることを指定していることに注意してください。この動機は、ICE [RFC5245]の付録B.1に記載されています。SIP/ SDPの場合、オファー/回答ダイアログ内のすべてのメディアストリームは、同じキューを使用して実行されます。 RTSPで同じ動作を保証するには、サーバーは各RTSPセッション内のすべてのメディアストリームに対して単一のペーサーキューを使用する必要があります（SHALL）。
The values for the pacing of STUN and TURN transactions Ta and RTO can be configured but have the same minimum values defined in the ICE specification.
STUNおよびTURNトランザクションのペーシングの値TaおよびRTOは構成できますが、ICE仕様で定義されている最小値と同じです。
When a connectivity check from the client reaches the server, it will result in a triggered check from the server as specified in Section 7.2.1.4 of ICE [RFC5245]. This is why servers with a high-reachability address can wait until this triggered check to send out any checks for itself, so saving resources and mitigating the DDoS potential.
クライアントからの接続チェックがサーバーに到達すると、ICE [RFC5245]のセクション7.2.1.4で指定されているように、サーバーからトリガーされたチェックが行われます。これが、高到達可能性アドレスを持つサーバーが、このトリガーされたチェックがそれ自体のチェックを送信するまで待機できるため、リソースを節約し、DDoSの可能性を軽減することができる理由です。
The client receives the SETUP response and learns the candidate addresses to use for the connectivity checks. The client SHALL initiate its connectivity check(s), following the procedures in Section 6 of ICE [RFC5245]. The pacing of STUN transactions (Appendix B.1 of [RFC5245]) SHALL be used across all media streams that are part of the same RTSP session.
クライアントはSETUP応答を受信し、接続チェックに使用する候補アドレスを学習します。クライアントは、ICE [RFC5245]のセクション6の手順に従って、接続チェックを開始する必要があります（SHALL）。 STUNトランザクションのペーシング（[RFC5245]の付録B.1）は、同じRTSPセッションの一部であるすべてのメディアストリームで使用する必要があります。
Aggressive nomination SHOULD be used with RTSP during initial SETUP for a resource. This doesn't have all the negative impact that it has in offer/answer as media playing only starts after issuing a PLAY request. Thus, the issue with a change of the media path being used for delivery can be avoided by not issuing a PLAY request while STUN connectivity checks are still outstanding. Aggressive nomination can result in multiple candidate pairs having their nominated flag set, but according to Section 8.1.1.2 of ICE [RFC5245], when the PLAY request is sent, the media will arrive on the pair with the highest priority. Note, different media resources may still end up with different foundations.
積極的な指名は、リソースの初期セットアップ中にRTSPで使用する必要があります（SHOULD）。メディアの再生はPLAYリクエストを発行した後にのみ開始されるため、これはオファー/アンサーに悪影響を及ぼしません。したがって、配信に使用されているメディアパスの変更に関する問題は、STUNの接続性チェックがまだ未解決の間にPLAY要求を発行しないことで回避できます。積極的な指名は、指名されたフラグが設定された複数の候補ペアをもたらす可能性がありますが、ICE [RFC5245]のセクション8.1.1.2によると、PLAY要求が送信されると、メディアは最も優先度の高いペアに到着します。メディアリソースが異なると、基盤が異なる場合があります。
The above does not change ICE and its handling of aggressive nomination. When using aggressive nomination, a higher-priority candidate pair with an outstanding connectivity check message can move into the Succeeded state and the candidate pair will have its Nominated flag set. This results in the higher-priority candidate pair being used instead of the previous pair, which is also in the Succeeded state.
上記はICEと積極的な指名の取り扱いを変更しません。積極的な指名を使用する場合、未処理の接続性チェックメッセージを含む優先度の高い候補ペアが成功状態に移行し、候補ペアに指名フラグが設定されます。これにより、優先順位の高い候補ペアが前のペアの代わりに使用され、これも成功状態になります。
To avoid this occurring during actual media transport, the RTSP client can add additional logic when the ICE processing overall is completed to indicate if there are still higher-priority connectivity checks outstanding. If some check is still outstanding, the implementation can choose to wait until some additional timeout is triggered or the outstanding checks complete before progressing with a PLAY request. An alternative is to accept the risk for a path change during media delivery and start playing immediately.
実際のメディアトランスポート中にこれが発生するのを回避するために、ICE処理全体が完了したときにRTSPクライアントは追加のロジックを追加して、未解決の優先度の高い接続チェックがあるかどうかを示すことができます。一部のチェックがまだ未解決の場合、実装は、追加のタイムアウトがトリガーされるか、未解決のチェックが完了するまで待機してからPLAYリクエストに進むことができます。別の方法は、メディア配信中にパスが変更されるリスクを受け入れ、すぐに再生を開始することです。
RTSP clients that want to ensure that each media resource uses the same path can use regular nomination where both 1) the ICE processing completion criteria and 2) which media streams are nominated for use can be controlled. This does not affect the RTSP server, as its role is the one of being controlled.
各メディアリソースが同じパスを使用することを保証するRTSPクライアントは、1）ICE処理完了基準と2）使用するメディアストリームの両方を制御できる定期的な指定を使用できます。これはRTSPサーバーには影響しません。その役割は制御されているためです。
When the client has concluded all of its connectivity checks and has nominated its desired candidate pair for a particular media stream, it MAY issue a PLAY request for that stream. Note that due to the aggressive nomination, there is a risk that any outstanding check may nominate another pair than what was already nominated. The candidate pair with the highest priority will be used for the media. If the client has locally determined that its checks have failed, it may try providing an extended set of candidates and update the server candidate list by issuing a new SETUP request for the media stream.
クライアントがすべての接続性チェックを完了し、特定のメディアストリームの希望する候補ペアを指定した場合、そのストリームに対してPLAY要求を発行できます（MAY）。積極的な指名が原因で、未処理のチェックがすでに指名されたペア以外のペアを指名するリスクがあることに注意してください。最も優先度の高い候補ペアがメディアに使用されます。クライアントは、チェックが失敗したことをローカルで判断した場合、候補の拡張セットの提供を試み、メディアストリームに対する新しいSETUP要求を発行してサーバー候補リストを更新します。
If the client concluded its connectivity checks successfully and therefore sent a PLAY request but the server cannot conclude successfully, the server will respond with a 480 (ICE Connectivity check failure) error response. Upon receiving the 480 (ICE Connectivity check failure) response, the client may send a new SETUP request assuming it has any new information that can be included in the candidate list. If the server is still performing the checks when receiving the PLAY request, it will respond with a 150 (Server still working on ICE connectivity checks) response to indicate this.
クライアントが接続チェックを正常に完了したためにPLAY要求を送信したが、サーバーが正常に完了できない場合、サーバーは480（ICE接続チェックの失敗）エラー応答で応答します。 480（ICE接続性チェックの失敗）応答を受信すると、クライアントは、候補リストに含めることができる新しい情報があると想定して、新しいSETUP要求を送信できます。サーバーがPLAYリクエストの受信時にまだチェックを実行している場合、150（サーバーは引き続きICE接続性チェックを実行中）応答で応答してこれを示します。
When the RTSP server receives a PLAY request, it checks to see that the connectivity checks have concluded successfully and only then will it play the stream. If the PLAY request is for a particular media stream, the server only needs to check that the connectivity checks for that stream completed successfully. If the server has not concluded its connectivity checks, the server indicates that by sending the 150 (Server still working on ICE connectivity checks) (Section 4.5.1). If there is a problem with the checks, then the server sends a 480 response to indicate a failure of the checks. If the checks are successful, then the server sends a 200 OK response and starts delivering media.
RTSPサーバーはPLAYリクエストを受信すると、接続性チェックが正常に終了したことを確認し、その後でのみストリームを再生します。 PLAY要求が特定のメディアストリームに対するものである場合、サーバーは、そのストリームの接続性チェックが正常に完了したことを確認するだけで済みます。サーバーがその接続性チェックを完了していない場合、サーバーは150（サーバーは引き続きICE接続性チェックを実行中）を送信することでそれを示します（セクション4.5.1）。チェックに問題がある場合、サーバーはチェックの失敗を示す480応答を送信します。チェックが成功した場合、サーバーは200 OK応答を送信し、メディアの配信を開始します。
Both server and client MAY free their non-selected candidates as soon as a 200 OK response has been issued/received for the PLAY request and no outstanding connectivity checks exist.
サーバーとクライアントの両方が、PLAYリクエストに対して200 OK応答が発行/受信され、未処理の接続性チェックが存在しなくなるとすぐに、選択されていない候補を解放できます（MAY）。
Clients and servers MAY free all their gathered candidates after having received or sent, respectively, a 480 response to a SETUP request. Clients will likely free their candidates first after having tried any additional actions that may resolve the issue, e.g., verifying the address gathering, or use additional STUN or TURN servers. Thus, a server will have to weigh the cost of doing address gathering versus maintaining the gathered address for some time to allow any new SETUP request to be issued by the client.
クライアントとサーバーは、それぞれSETUP要求に対する480応答を受信または送信した後、収集したすべての候補を解放してもよい（MAY）。クライアントは、問題を解決する可能性のある追加のアクション（アドレス収集の確認、または追加のSTUNまたはTURNサーバーの使用など）を試みた後、最初に候補者を解放します。したがって、サーバーは、クライアントが新しいSETUP要求を発行できるようにするために、アドレス収集を実行するコストと収集したアドレスをしばらく維持するコストを比較検討する必要があります。
If the 480 response is sent in response to a PLAY request, the server MUST NOT free its gathered candidates. Instead, it will have to wait for additional actions from the client or terminate the RTSP session due to inactivity.
PLAY要求に応答して480応答が送信される場合、サーバーは収集した候補を解放してはなりません（MUST NOT）。代わりに、非アクティブのために、クライアントからの追加のアクションを待つか、RTSPセッションを終了する必要があります。
The client and server SHALL use STUN to send keep-alive messages for the nominated candidate pair(s) following the rules of Section 10 of ICE [RFC5245]. This is important, as normally RTSP play mode sessions only contain traffic from the server to the client so the bindings in the NAT need to be refreshed by the client-to-server traffic provided by the STUN keep-alive.
クライアントとサーバーは、STUNを使用して、ICE [RFC5245]のセクション10のルールに従って、指名された候補ペアのキープアライブメッセージを送信する必要があります。これは重要です。通常、RTSP再生モードセッションにはサーバーからクライアントへのトラフィックしか含まれないため、NATのバインディングは、STUNキープアライブによって提供されるクライアントからサーバーへのトラフィックによって更新される必要があるためです。
A client that decides to change any parameters related to the media stream setup will send a new SETUP request. In this new SETUP request, the client MAY include a new different ICE username fragment and password to use in the ICE processing. The new ICE username and password SHALL cause the ICE processing to start from the beginning again, i.e., an ICE restart (Section 9.1.1.1 of [RFC5245]). The client SHALL in case of ICE restart, gather candidates and include the candidates in the transport specification for D-ICE.
メディアストリームの設定に関連するパラメータを変更することを決定したクライアントは、新しいSETUP要求を送信します。この新しいSETUP要求では、クライアントは、ICE処理で使用する新しい異なるICEユーザー名フラグメントとパスワードを含めることができます（MAY）。新しいICEユーザー名とパスワードを使用すると、ICE処理が最初から再開されます。つまり、ICEが再起動します（[RFC5245]のセクション9.1.1.1）。クライアントは、ICEの再起動の場合にSHALLし、候補を収集し、D-ICEのトランスポート仕様に候補を含めます。
ICE restarts may be triggered due to changes of client or server attachment to the network, such as changes to the media streams destination or source address or port. Most RTSP parameter changes would not require an ICE restart, but would use existing mechanisms in RTSP to indicate from what point in the RTP stream they apply. These include the following: performing a pause prior to the parameter change and then resume; assuming the server supports using SETUP during the PLAY state; or using the RTP-Info header (Section 18.45 of [RFC7826]) to indicate from where in the media stream the change shall apply.
メディアストリームの宛先または送信元アドレスまたはポートの変更など、ネットワークへのクライアントまたはサーバー接続の変更が原因で、ICEの再起動がトリガーされる場合があります。ほとんどのRTSPパラメータの変更ではICEの再起動は必要ありませんが、RTSPの既存のメカニズムを使用して、RTPストリームのどのポイントから適用するかを示します。これらには次のものが含まれます。パラメータの変更前に一時停止を実行してから再開します。サーバーがPLAY状態でのSETUPの使用をサポートしていると想定します。または、RTP-Infoヘッダー（[RFC7826]のセクション18.45）を使用して、メディアストリームのどこから変更が適用されるかを示します。
Even if the server does not normally support SETUP during PLAY state, it SHALL support SETUP requests in PLAY state for the purpose of changing only the ICE parameters, which are ICE-Password, ICE-ufrag, and the content of ICE candidates.
サーバーが通常、PLAY状態でSETUPをサポートしていない場合でも、ICEパラメーター（ICE-Password、ICE-ufrag、およびICE候補の内容）のみを変更する目的で、PLAY状態のSETUP要求をサポートする必要があります（SHALL）。
If the RTSP session is in playing state at the time of sending the SETUP request requiring ICE restart, then the ICE connectivity checks SHALL use Regular nomination. Any ongoing media delivery continues on the previously nominated candidate pairs until the new pairs have been nominated for the individual media stream. Once the nomination of the new candidate pair has completed, all unused candidates may be released. If the ICE processing fails and no new candidate pairs are nominated for use, then the media stream MAY continue to use the previously nominated candidate pairs while they still function. If they appear to fail to transport media packets anymore, then the client can select between two actions: attempting any actions that might make ICE work or terminating the RTSP session. Firstly, it can attempt any actions available that might make ICE work, like trying another STUN/TURN server or changing the transport parameters. In that case, the client modifies the RTSP session, and if ICE is still to be used, the client restarts ICE once more. Secondly, if the client is unable to modify the transport or ICE parameters, it MUST NOT restart the ICE processing, and it SHOULD terminate the RTSP session.
ICEの再起動を必要とするSETUP要求を送信するときにRTSPセッションが再生状態にある場合、ICE接続チェックは通常の指定を使用する必要があります。進行中のメディア配信は、新しいペアが個々のメディアストリームにノミネートされるまで、以前にノミネートされた候補ペアで続行されます。新しい候補ペアの指名が完了すると、すべての未使用の候補が解放されます。 ICE処理が失敗し、新しい候補ペアが使用のために指定されていない場合、メディアストリームは、以前に指定された候補ペアが引き続き機能する間、引き続き使用できます（MAY）。メディアパケットの転送に失敗したように見える場合、クライアントは2つのアクションから選択できます。ICEを機能させる可能性のあるアクションを試行するか、RTSPセッションを終了します。まず、別のSTUN / TURNサーバーの試行やトランスポートパラメータの変更など、ICEを機能させる可能性のあるすべてのアクションを試行できます。その場合、クライアントはRTSPセッションを変更し、ICEを引き続き使用する場合は、クライアントはもう一度ICEを再起動します。次に、クライアントがトランスポートまたはICEパラメータを変更できない場合は、ICE処理を再開してはならず（MUST NOT）、RTSPセッションを終了する必要があります（SHOULD）。
A server may require an ICE restart because of server-side load balancing or a failure resulting in an IP address and a port number change. In that case, the server SHALL use the PLAY_NOTIFY method to inform the client (Section 13.5 [RFC7826]) with a new Notify-Reason header: ice-restart. The server will identify if the change is for a single media or for the complete session by including the corresponding URI in the PLAY_NOTIFY request.
サーバー側のロードバランシング、またはIPアドレスとポート番号の変更につながる障害のために、サーバーでICEの再起動が必要になる場合があります。その場合、サーバーはPLAY_NOTIFYメソッドを使用してクライアントに通知する必要があります（セクション13.5 [RFC7826]）。新しいNotify-Reasonヘッダー：ice-restart。サーバーは、PLAY_NOTIFYリクエストに対応するURIを含めることにより、変更が単一のメディアに対するものか、セッション全体に対するものかを識別します。
Upon receiving and responding to this PLAY_NOTIFY with an ice-restart reason, the client SHALL gather new ICE candidates and send SETUP requests for each media stream part of the session. The server provides its candidates in the SETUP response the same way as for the first time ICE processing. Both server and client SHALL provide new ICE usernames and passwords. The client MAY issue the SETUP request while the session is in PLAYING state.
このPLAY_NOTIFYを受信し、ice-restartの理由で応答すると、クライアントは新しいICE候補を収集し、セッションの各メディアストリーム部分に対してSETUP要求を送信する必要があります（SHALL）。サーバーは、初回のICE処理と同じ方法で、SETUP応答で候補を提供します。サーバーとクライアントの両方が新しいICEユーザー名とパスワードを提供するものとします（SHALL）。クライアントは、セッションがPLAYING状態のときにSETUP要求を発行する場合があります。
If the RTSP session is in PLAYING state when the client issues the SETUP request, the client SHALL use Regular nomination. If not, the client will use the same procedures as for when first creating the session.
クライアントがSETUP要求を発行したときにRTSPセッションがPLAYING状態にある場合、クライアントは通常の指定を使用する必要があります（SHALL）。そうでない場合、クライアントは最初にセッションを作成するときと同じ手順を使用します。
Note that for each media stream keep-alive messages on the previous set of candidate pairs SHOULD continue until new candidate pairs have been nominated. After having nominated a new set of candidate pairs, the client may continue to receive media for some additional time. Even if the server stops delivering media over that candidate pair at the time of nomination, media may arrive for up to one maximum segment lifetime as defined in TCP (2 minutes). Unfortunately, if the RTSP server is divided into a separate controller and media stream, a failure may result in continued media delivery for a longer time than the maximum segment lifetime, thus source filtering is RECOMMENDED.
各メディアストリームについて、前の候補ペアのセットのキープアライブメッセージは、新しい候補ペアが指名されるまで続行する必要があることに注意してください。新しい候補ペアのセットを指名した後、クライアントはさらにしばらくの間メディアを受信し続けることができます。指名時にサーバーが候補ペアを介したメディアの配信を停止した場合でも、TCPで定義されている最大1つのセグメントライフタイム（2分）でメディアが到着する場合があります。残念ながら、RTSPサーバーが別のコントローラーとメディアストリームに分割されている場合、障害が発生すると、最大セグメントライフタイムよりも長い時間メディア配信が継続される可能性があるため、ソースフィルタリングをお勧めします。
For example:
例えば：
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 854
Notify-Reason: ice-restart
Session: uZ3ci0K+Ld
Server: PhonyServer 1.1
C->S: RTSP/2.0 200 OK
CSeq: 854
User-Agent: PhonyClient/1.2
C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0
CSeq: 314
Session: uZ3ci0K+Ld
Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=Kl1C;
ICE-Password=H4sICGjBsEcCA3Rlc3RzLX; candidates="
1 1 UDP 2130706431 10.0.1.17 8998 typ host;
2 1 UDP 1694498815 192.0.2.3 51456 typ srflx
raddr 10.0.1.17 rport 9002"; RTCP-mux,
RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971",
RTP/AVP/TCP; unicast;interleaved=0-1
Accept-Ranges: NPT, UTC
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
User-Agent: PhonyClient/1.2
C->S: SETUP rtsp://server.example.com/fizzle/foo/video RTSP/2.0
CSeq: 315
Session: uZ3ci0K+Ld
Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=hZv9;
ICE-Password=JAhA9myMHETTFNCrPtg+kJ; candidates="
1 1 UDP 2130706431 10.0.1.17 9000 typ host;
2 1 UDP 1694498815 192.0.2.3 51576 typ srflx
raddr 10.0.1.17 rport 9000"; RTCP-mux,
RTP/AVP/UDP; unicast; dest_addr=":6972"/":6973",
RTP/AVP/TCP; unicast;interleaved=0-1
Accept-Ranges: NPT, UTC
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 314
Session: uZ3ci0K+Ld
Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=CbDm;
ICE-Password=OfdXHws9XX0eBr6j2zz9Ak; candidates="
1 1 UDP 2130706431 192.0.2.56 50234 typ host"
Accept-Ranges: NPT
Date: 11 March 2011 13:17:46 GMT
Server: PhonyServer 1.1
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
S->C: RTSP/2.0 200 OK
CSeq: 315
Session: uZ3ci0K+Ld
Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=jigs;
ICE-Password=Dgx6fPj2lsa2WI8b7oJ7+s; candidates="
1 1 UDP 2130706431 192.0.2.56 47233 typ host"
Accept-Ranges: NPT
Date: 11 March 2011 13:17:47 GMT
Server: PhonyServer 1.1
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
RTSP allows for proxies that can be of two fundamental types depending on whether or not they relay and potentially cache the media. Their differing impact on the RTSP NAT traversal solution, including backwards compatibility, is explained below.
RTSPでは、メディアを中継してキャッシュする可能性があるかどうかに応じて、2つの基本的なタイプのプロキシを使用できます。下位互換性を含め、RTSP NATトラバーサルソリューションへの異なる影響について、以下で説明します。
An RTSP proxy that relays or caches the media stream for a particular media session can be considered to split the media transport into two parts: firstly, a media transport between the server and the proxy according to the proxy's need, and, secondly, delivery from the proxy to the client. This split means that the NAT traversal solution will be run on each individual media leg according to need.
特定のメディアセッションのメディアストリームを中継またはキャッシュするRTSPプロキシは、メディアトランスポートを2つの部分に分割すると見なすことができます。1つ目は、プロキシのニーズに応じてサーバーとプロキシ間のメディアトランスポート、もう1つは、クライアントへのプロキシ。この分割は、NATトラバーサルソリューションが必要に応じて個々のメディアレッグで実行されることを意味します。
It is RECOMMENDED that any media-handling proxy support the media NAT traversal defined within this specification. This is for two reasons: firstly, to enable clients to perform NAT traversal for the media between the proxy and itself and secondly to allow the proxy to be topology independent to support performing NAT traversal (to the server) for clients not capable of NAT traversal present in the same address domain as the proxy.
すべてのメディア処理プロキシが、この仕様で定義されているメディアNATトラバーサルをサポートすることをお勧めします。これには2つの理由があります。1つ目は、クライアントがプロキシとそれ自体の間のメディアに対してNATトラバーサルを実行できるようにすること、2つ目は、プロキシがトポロジーに依存しないようにして、NATトラバーサルを実行できないクライアントに対して（サーバーへの）NATトラバーサルを実行できるようにすることです。プロキシと同じアドレスドメインに存在します。
For a proxy to support the media NAT traversal defined in this specification, a proxy will need to implement the solution fully and be able to act as both a controlling and a controlled ICE peer. The proxy also SHALL include the "setup.ice-d-m" feature tag in any applicable capability negotiation headers, such as Proxy-Supported.
プロキシがこの仕様で定義されているメディアNATトラバーサルをサポートするには、プロキシがソリューションを完全に実装し、制御と制御の両方のICEピアとして機能できる必要があります。プロキシは、Proxy-Supportedなどの該当する機能ネゴシエーションヘッダーに「setup.ice-d-m」機能タグを含める必要があります（SHALL）。
A signaling-only proxy handles only the RTSP signaling and does not have the media relayed through proxy functions. This type of proxy is not likely to work unless the media NAT traversal solution is in place between the client and the server, because the DoS protection measures, as discussed in Section 21.2.1 of RTSP 2.0 [RFC7826], usually prevent media delivery to addresses other than from where the RTSP signaling arrives at the server.
シグナリング専用プロキシは、RTSPシグナリングのみを処理し、プロキシ機能を介して中継されるメディアはありません。 RTSP 2.0 [RFC7826]のセクション21.2.1で説明されているDoS保護対策により、通常はメディアへのメディア配信が妨げられるため、このタイプのプロキシは、クライアントとサーバー間にメディアNATトラバーサルソリューションが配置されていないと機能しない可能性があります。 RTSPシグナリングがサーバーに到着する場所以外のアドレス。
The solution for the signaling-only proxy is that it must forward the RTSP SETUP requests including any transport specification with the "D-ICE" lower layer and the related transport parameters. A proxy supporting this functionality SHALL indicate its capability by always including the "setup.ice-d-m" feature tag in the Proxy-Supported header in any SETUP request or response.
シグナリング専用プロキシのソリューションは、「D-ICE」下位層と関連するトランスポートパラメータを含むトランスポート仕様を含むRTSP SETUP要求を転送する必要があることです。この機能をサポートするプロキシは、SETUP要求または応答のProxy-Supportedヘッダーに常に「setup.ice-d-m」機能タグを含めることによって、その機能を示す必要があります（SHALL）。
A media-handling proxy that doesn't support the ICE media NAT traversal specified here is assumed to remove the transport specification and use any of the lower prioritized transport specifications if provided by the requester. The specification of such a non-ICE transport enables the negotiation to complete, although with a less preferred method since a NAT between the proxy and the client may result in failure of the media path.
ここで指定されたICEメディアNATトラバーサルをサポートしないメディア処理プロキシは、トランスポート指定を削除し、リクエスタから提供された場合は優先順位の低いトランスポート指定を使用すると想定されます。このような非ICEトランスポートの指定により、ネゴシエーションを完了することができますが、プロキシとクライアント間のNATがメディアパスの障害を引き起こす可能性があるため、あまり好ましくない方法を使用します。
A non-media-handling proxy is expected to ignore and simply forward all unknown transport specifications. However, this can only be guaranteed for proxies following the RTSP 2.0 specification [RFC7826].
非メディア処理プロキシは、すべての不明なトランスポート仕様を無視して転送することが期待されています。ただし、これはRTSP 2.0仕様[RFC7826]に従ったプロキシに対してのみ保証できます。
The usage of the "setup.ice-d-m" feature tag in the Proxy-Require header is NOT RECOMMENDED because it can have contradictory results. For a proxy that does not support ICE but is media handling, the inclusion of the feature tag will result in aborting the setup and indicating that it isn't supported, which is desirable if providing other fallbacks or other transport configurations to handle the situation is wanted. For non-ICE-supporting non-media-handling proxies, the result will be aborting the setup. However, the setup might have worked if the feature tag wasn't present in the Proxy-Require header. This variance in results is the reason we don't recommend the usage of the Proxy-Require header. Instead, we recommend the usage of the Supported header to force proxies to include the feature tags for the intersection of what the proxy chain supports in the Proxy-Supported header. This will provide a positive indication when all proxies in the chain between the client and server support the functionality.
Proxy-Requireヘッダーの「setup.ice-d-m」機能タグの使用は、矛盾する結果になる可能性があるためお勧めしません。 ICEをサポートしないがメディア処理であるプロキシの場合、機能タグを含めると、セットアップが中止され、サポートされていないことが示されます。これは、状況を処理する他のフォールバックまたは他のトランスポート構成を提供する場合に望ましいです。欲しかった。 ICEをサポートしていない非メディア処理プロキシの場合、結果はセットアップを中止します。ただし、機能タグがProxy-Requireヘッダーに存在しない場合は、設定が機能している可能性があります。この結果の違いが、Proxy-Requireヘッダーの使用を推奨しない理由です。代わりに、Supportedヘッダーを使用して、プロキシチェーンがProxy-Supportedヘッダーでサポートするものの共通部分の機能タグをプロキシに強制的に含めることをお勧めします。これは、クライアントとサーバー間のチェーン内のすべてのプロキシが機能をサポートする場合に前兆を示します。
If a proxy doesn't support the "setup.ice-d-m" feature, but that proxy is not a media-handling proxy, the ICE-based setup could still work, since such a proxy may do pass through on any transport parameters. Unfortunately ,the Proxy-Require and Proxy-Supported RTSP headers failed to provide that information. The only way of finding whether or not this is the case is to try perform a SETUP including a Transport header with transport specifications using ICE.
プロキシが「setup.ice-d-m」機能をサポートしていないが、そのプロキシがメディア処理プロキシではない場合でも、ICEベースのセットアップは機能する可能性があります。そのようなプロキシは、トランスポートパラメータでパススルーする可能性があるためです。残念ながら、Proxy-RequireおよびProxy-Supported RTSPヘッダーはその情報を提供できませんでした。これが当てはまるかどうかを見つける唯一の方法は、ICEを使用してトランスポート仕様を含むトランスポートヘッダーを含むセットアップを実行することです。
"Multiplexing RTP Data and Control Packets on a Single Port" [RFC5761] specifies how and when RTP and RTCP can be multiplexed on the same port. This multiplexing is beneficial when combined with ICE for RTSP as it makes RTP and RTCP need only a single component per media stream instead of two, so reducing the load on the connectivity checks. For details on how to negotiate RTP and RTCP multiplexing, see Appendix C of RTSP 2.0 [RFC7826].
「単一ポートでのRTPデータと制御パケットの多重化」[RFC5761]では、RTPとRTCPを同じポートで多重化する方法とタイミングを指定しています。この多重化は、RTSPのICEと組み合わせると、RTPとRTCPにメディアストリームごとに2つではなく1つのコンポーネントしか必要ないため、接続性チェックの負荷が軽減されるため、有益です。 RTPおよびRTCPの多重化をネゴシエートする方法の詳細については、RTSP 2.0の付録C [RFC7826]を参照してください。
Multiplexing RTP and RTCP has the benefit that it avoids the need for handling two components per media stream when RTP is used as the media transport protocol. This eliminates at least one STUN check per media stream and will also reduce the time needed to complete the ICE processing by at least the time it takes to pace out the additional STUN checks of up to one complete round-trip time for a single media stream. In addition to the protocol performance improvements, the server and client-side complexities are reduced as multiplexing halves the total number of STUN instances and holding the associated state. Multiplexing will also reduce the combinations and length of the list of possible candidates.
RTPとRTCPの多重化には、RTPがメディアトランスポートプロトコルとして使用されている場合に、メディアストリームごとに2つのコンポーネントを処理する必要がなくなるという利点があります。これにより、メディアストリームごとに少なくとも1つのSTUNチェックが不要になり、ICE処理を完了するために必要な時間を、少なくとも1つのメディアストリームの最大1つの完全なラウンドトリップ時間の追加のSTUNチェックのペースを落とすのにかかる時間まで削減できます。 。プロトコルのパフォーマンス向上に加えて、多重化によりSTUNインスタンスの総数が半分になり、関連する状態が保持されるため、サーバー側とクライアント側の複雑さが軽減されます。多重化はまた、可能な候補のリストの組み合わせと長さを減らします。
The implementation of RTP and RTCP multiplexing is additional work required for this solution. However, when implementing the ICE solution, a server or client will need to implement a demultiplexer between the STUN and RTP or RTCP packets below the RTP/RTCP implementation anyway, so the additional work of one new demultiplexing point directly connected to the STUN and RTP/RTCP seems small relative to the benefits provided.
RTPおよびRTCP多重化の実装は、このソリューションに必要な追加作業です。ただし、ICEソリューションを実装する場合、サーバーまたはクライアントは、STUNとRTPまたはRTCPパケットの間にRTP / RTCP実装の下にデマルチプレクサを実装する必要があるため、STUNおよびRTPに直接接続された1つの新しい逆多重化ポイントの追加作業が必要になります。 / RTCPは、提供される利点に比べて小さいようです。
Due to the benefits mentioned above, RTSP servers and clients that support "D-ICE" lower-layer transport in combination with RTP SHALL also implement and use RTP and RTCP multiplexing as specified in Appendix C.1.6.4 of [RFC7826] and [RFC5761].
上記の利点により、「D-ICE」下位層トランスポートをRTPと組み合わせてサポートするRTSPサーバーおよびクライアントは、[RFC7826]の付録C.1.6.4および[RFC7826]で指定されているRTPおよびRTCP多重化を実装および使用します。 RFC5761]。
9. Fallback and Using Partial ICE Functionality to Improve NAT/Firewall Traversal
9. フォールバックと部分的なICE機能の使用によるNAT /ファイアウォールトラバーサルの改善
The need for fallback from ICE in RTSP should be less than for SIP using ICE in SDP offer/answer where a default destination candidate is very important to enable interworking with non-ICE capable endpoints. In RTSP, capability determination for ICE can happen prior to the RTSP SETUP request. This means a client should normally not need to include fallback alternatives when offering ICE, as the capability for ICE will already be determined. However, as described in this section, clients may wish to use part of the ICE functionality to improve NAT/firewall traversal where the server is not ICE capable.
RTSPでのICEからのフォールバックの必要性は、SDPオファー/アンサーでICEを使用するSIPの場合よりも少なくなければなりません。この場合、ICEに対応していないエンドポイントとのインターワーキングを可能にするためにデフォルトの宛先候補が非常に重要です。 RTSPでは、ICEの機能決定はRTSP SETUP要求の前に行うことができます。これは、ICEの機能が既に決定されているため、ICEを提供するときにクライアントが通常は代替手段を含める必要がないことを意味します。ただし、このセクションで説明するように、クライアントはICE機能の一部を使用して、サーバーがICEに対応していない場合のNAT /ファイアウォールトラバーサルを改善したい場合があります。
Section 4.1.4 of the ICE [RFC5245] specification does recommend that the default destination, i.e., what is used as fallback if the peer isn't ICE capable, is a candidate of relayed type to maximize the likelihood of successful transport of media. This is based on the peer in SIP using SDP offer/answer is almost as likely as the RTSP client to be behind a NAT. For RTSP, the deployment of servers is much more heavily weighted towards deployment with public reachability. In fact, since publicly reachable servers behind NAT either need to support ICE or have static configurations that allow traversal, one can assume that the server will have a public address or support ICE. Thus, the selection of the default destination address for RTSP can be differently prioritized.
ICE [RFC5245]仕様のセクション4.1.4では、デフォルトの宛先、つまり、ピアがICEに対応していない場合にフォールバックとして使用されるものを、メディアの正常な転送の可能性を最大化するためのリレータイプの候補にすることを推奨しています。これは、SDPオファー/アンサーを使用するSIPのピアに基づいており、NATの背後にあるRTSPクライアントとほぼ同じです。 RTSPの場合、サーバーの展開は、パブリック到達可能性を備えた展開にはるかに重きを置いています。実際、NATの背後にある公的に到達可能なサーバーはICEをサポートするか、トラバーサルを可能にする静的構成を持っている必要があるため、サーバーがパブリックアドレスを持つか、ICEをサポートすると想定できます。したがって、RTSPのデフォルトの宛先アドレスの選択には、異なる優先順位を付けることができます。
As an ICE-enabled client behind a NAT needs to be configured with a STUN server address to be able to gather candidates successfully, this can be used to derive a server reflexive candidate for the client's port. How useful this is for a NATed RTSP client as a default candidate depends on the properties of the NAT. As long as the NAT uses an address-independent mapping, then using a STUN-derived reflexive candidate is likely to be successful. However, this is brittle in several ways, and the main reason why the original specification of STUN [RFC3489] and direct usage for NAT traversal was obsoleted. First, if the NAT's behavior is attempted to be determined using STUN as described in [RFC3489], the determined behavior might not be representative of the behavior encountered in another mapping. Secondly, filter state towards the ports used by the server needs to be established. This requires that the server actually includes both address and ports in its response to the SETUP request. Thirdly, messages need to be sent to these ports for keep-alive at a regular interval. How a server reacts to such unsolicited traffic is unknown. This brittleness may be accepted in fallback due to lack of support on the server side.
NATの背後にあるICE対応クライアントは、候補を正常に収集できるようにSTUNサーバーアドレスで構成する必要があるため、これを使用してクライアントのポートのサーバー再帰候補を導出できます。これがNATed RTSPクライアントにとってデフォルトの候補としてどれほど役立つかは、NATのプロパティによって異なります。 NATがアドレスに依存しないマッピングを使用している限り、STUNから導出された再帰候補を使用すると成功する可能性があります。ただし、これはいくつかの点で脆弱であり、STUN [RFC3489]の元の仕様とNATトラバーサルの直接使用が廃止された主な理由は廃止されました。まず、[RFC3489]で説明されているように、NATの動作をSTUNを使用して決定しようとすると、決定された動作が別のマッピングで発生した動作を代表しない場合があります。次に、サーバーが使用するポートに対するフィルター状態を確立する必要があります。これには、サーバーが実際にSETUP要求への応答にアドレスとポートの両方を含める必要があります。 3番目に、キープアライブを定期的に行うには、これらのポートにメッセージを送信する必要があります。サーバーがそのような一方的なトラフィックにどのように反応するかは不明です。この脆弱性は、サーバー側のサポートが不足しているため、フォールバックで受け入れられる可能性があります。
To maximize the likelihood that an RTSP client is capable of receiving media, a relay-based address should be chosen as the default fallback address. However, for RTSP clients lacking a relay server, such as a TURN server, or where usage of such a server has significant cost associated with it, the usage of a STUN-derived server reflexive address as client default has a reasonable likelihood of functioning and may be used as an alternative.
RTSPクライアントがメディアを受信できる可能性を最大化するには、リレーベースのアドレスをデフォルトのフォールバックアドレスとして選択する必要があります。ただし、TURNサーバーなどのリレーサーバーがないRTSPクライアントの場合、またはTURNサーバーなどのサーバーの使用にかなりのコストがかかる場合、クライアントのデフォルトとしてSTUN派生サーバーの再帰アドレスを使用すると、機能する可能性が高く、代替として使用できます。
Fallback addresses need to be provided in their own transport specification using a specifier that does not include the D-ICE lower-layer transport. Instead, the selected protocol, e.g., UDP, needs to be explicitly or implicitly indicated. Secondly, the selected default candidate needs to be included in the SETUP request. If this candidate is server reflexive or relayed, the aspect of keep-alive needs to be ensured.
フォールバックアドレスは、D-ICE下位層トランスポートを含まない指定子を使用して、独自のトランスポート仕様で提供する必要があります。代わりに、選択したプロトコル（UDPなど）を明示的または暗黙的に示す必要があります。次に、選択したデフォルトの候補をSETUPリクエストに含める必要があります。この候補がサーバー再帰型または中継型である場合、キープアライブの側面を確保する必要があります。
Per this document, registrations have been made in a number of registries, both for RTSP and SDP. For all the below registrations, the contact person on behalf of the IETF WG MMUSIC is Magnus Westerlund <magnus.westerlund@ericsson.com>.
このドキュメントによれば、RTSPとSDPの両方について、いくつかのレジストリで登録が行われています。以下のすべての登録について、IETF WG MMUSICを代表する連絡担当者はMagnus Westerlund <magnus.westerlund@ericsson.com>です。
Per this document, one RTSP 2.0 feature tag has been registered in the "RTSP 2.0 Feature-tags" registry.
このドキュメントによれば、1つのRTSP 2.0機能タグが「RTSP 2.0機能タグ」レジストリに登録されています。
setup.ice-d-m: A feature tag representing the support of the ICE-based establishment of datagram media transport that is capable of transport establishment through NAT and firewalls. This feature tag applies to clients, servers, and proxies and indicates support of all the mandatory functions of this specification.
setup.ice-d-m：データグラムメディアトランスポートのICEベースの確立のサポートを表す機能タグ。NATおよびファイアウォールを介してトランスポートを確立できます。この機能タグは、クライアント、サーバー、およびプロキシに適用され、この仕様のすべての必須機能のサポートを示します。
Per this document, a number of transport protocol combinations have been registered in the RTSP 2.0 "Transport Protocol Identifiers" registry:
このドキュメントによれば、RTSP 2.0の "Transport Protocol Identifiers"レジストリにいくつかのトランスポートプロトコルの組み合わせが登録されています。
RTP/AVP/D-ICE: RTP using the AVP profile over an ICE-established datagram flow.
RTP / AVP / D-ICE：ICEが確立したデータグラムフローでAVPプロファイルを使用するRTP。
RTP/AVPF/D-ICE: RTP using the AVPF profile over an ICE-established datagram flow.
RTP / AVPF / D-ICE：ICEが確立したデータグラムフローでAVPFプロファイルを使用するRTP。
RTP/SAVP/D-ICE: RTP using the SAVP profile over an ICE-established datagram flow.
RTP / SAVP / D-ICE：ICEが確立したデータグラムフローでSAVPプロファイルを使用するRTP。
RTP/SAVPF/D-ICE: RTP using the SAVPF profile over an ICE-established datagram flow.
RTP / SAVPF / D-ICE：ICEが確立したデータグラムフローでSAVPFプロファイルを使用するRTP。
Per this document, three transport parameters have been registered in the RTSP 2.0's "Transport Parameters" registry.
このドキュメントによれば、3つのトランスポートパラメータがRTSP 2.0の「トランスポートパラメータ」レジストリに登録されています。
candidates: Listing the properties of one or more ICE candidates. See Section 4.2.
候補：1つ以上のICE候補のプロパティをリストします。セクション4.2を参照してください。
ICE-Password: The ICE password used to authenticate the STUN binding request in the ICE connectivity checks. See Section 4.3.
ICE-Password：ICE接続性チェックでSTUNバインディング要求を認証するために使用されるICEパスワード。セクション4.3を参照してください。
ICE-ufrag: The ICE username fragment used to authenticate the STUN binding requests in the ICE connectivity checks. See Section 4.3.
ICE-ufrag：ICE接続チェックでSTUNバインディング要求を認証するために使用されるICEユーザー名フラグメント。セクション4.3を参照してください。
Per this document, two assignments have been made in the "RTSP 2.0 Status Codes" registry. See Section 4.5.
このドキュメントによれば、「RTSP 2.0ステータスコード」レジストリで2つの割り当てが行われています。セクション4.5を参照してください。
Per this document, one assignment has been made in the RTSP 2.0 Notify-Reason header value registry. The defined value is:
このドキュメントでは、RTSP 2.0 Notify-Reasonヘッダー値レジストリで1つの割り当てが行われています。定義されている値は次のとおりです。
ice-restart: This Notify-Reason value allows the server to notify the client about the need for an ICE restart. See Section 4.6.
ice-restart：このNotify-Reason値により、サーバーはICEの再起動の必要性についてクライアントに通知できます。セクション4.6を参照してください。
One SDP attribute has been registered:
1つのSDP属性が登録されています：
SDP Attribute ("att-field"):
SDP属性（ "att-field"）：
Attribute name: rtsp-ice-d-m
Long form: ICE for RTSP datagram media NAT traversal
Type of attribute: Session-level only
Subject to charset: No
Purpose: RFC 7825, Section 4.7
Values: No values defined
Contact: Magnus Westerlund
Email: magnus.westerlund@ericsson.com
Phone: +46 10 714 82 87
ICE [RFC5245] and ICE TCP [RFC6544] provide an extensive discussion on security considerations that apply here as well.
ICE [RFC5245]およびICE TCP [RFC6544]は、ここでも適用されるセキュリティの考慮事項についての広範な議論を提供します。
A long-standing risk with transmitting a packet stream over UDP is that the host may not be interested in receiving the stream. On today's Internet, many hosts are behind NATs or operate host firewalls that do not respond to unsolicited packets with an ICMP port unreachable error. Thus, an attacker can construct RTSP SETUP requests with a victim's IP address and cause a flood of media packets to be sent to a victim. The addition of ICE, as described in this document, provides protection from the attack described above. By performing the ICE connectivity check, the media server receives confirmation that the RTSP client wants the media. While this protection could also be implemented by requiring the IP addresses in the SDP match the IP address of the RTSP signaling packet, such a mechanism does not protect other hosts with the same IP address (such as behind the same NAT), and such a mechanism would prohibit separating the RTSP controller from the media play-out device (e.g., an IP-enabled remote control and an IP-enabled television); it also forces RTSP proxies to relay the media streams through them, even if they would otherwise be only signaling proxies.
UDPを介したパケットストリームの送信に関する長年のリスクは、ホストがストリームの受信に関心がない可能性があることです。今日のインターネットでは、多くのホストがNATの背後にあるか、ICMPポート到達不能エラーで迷惑なパケットに応答しないホストファイアウォールを運用しています。したがって、攻撃者は被害者のIPアドレスを使用してRTSP SETUPリクエストを作成し、メディアパケットのフラッドを被害者に送信させることができます。このドキュメントで説明するように、ICEを追加すると、上記の攻撃から保護されます。 ICE接続チェックを実行することにより、メディアサーバーは、RTSPクライアントがメディアを必要としているという確認を受け取ります。この保護は、SDPのIPアドレスがRTSPシグナリングパケットのIPアドレスと一致することを要求することによっても実装できますが、このようなメカニズムは、同じIPアドレス（同じNATの背後など）を持つ他のホストを保護しません。メカニズムは、RTSPコントローラをメディアプレイアウトデバイス（IP対応のリモートコントロールおよびIP対応のテレビなど）から分離することを禁止します。また、RTSPプロキシがシグナリングプロキシだけである場合でも、それらを介してメディアストリームを中継するように強制します。
To protect against attacks on ICE based on signaling information, RTSP signaling SHOULD be protected using TLS to prevent eavesdropping and modification of information.
シグナリング情報に基づくICEへの攻撃から保護するために、RTSPシグナリングは、情報の盗聴や変更を防ぐためにTLSを使用して保護する必要があります（SHOULD）。
The STUN amplification attack described in Section 18.5.2 in ICE [RFC5245] needs consideration. Servers that are able to run according to the high-reachability option have good mitigation of this attack as they only send connectivity checks towards an address and port pair from which they have received an incoming connectivity check. This means an attacker requires both the capability to spoof source addresses and to signal the RTSP server a set of ICE candidates. Independently, an ICE agent needs to implement the mitigation to reduce the volume of the amplification attack as described in the ICE specification.
ICE [RFC5245]のセクション18.5.2で説明されているSTUN増幅攻撃は、考慮する必要があります。高到達可能性オプションに従って実行できるサーバーは、接続チェックを受信したアドレスとポートのペアにのみ接続チェックを送信するため、この攻撃を緩和できます。つまり、攻撃者は送信元アドレスを偽装する機能と、RTSPサーバーにICE候補のセットを通知する機能の両方を必要とします。独立して、ICEエージェントは、ICE仕様で説明されているように、増幅攻撃の量を減らすための緩和策を実装する必要があります。
The logging of NAT translations is helpful to analysts, particularly in enterprises, who need to be able to map sessions when investigating possible issues where the NAT happens. When using logging on the public Internet, it is possible that the logs are large and privacy invasive, so procedures for log flushing and privacy protection SHALL be in place. Care should be taken in the protection of these logs and consideration taken to log integrity, privacy protection, and purging logs (retention policies, etc.). Also, logging of connection errors and other messages established by this document can be important.
NAT変換のログは、NATが発生する可能性のある問題を調査するときにセッションをマップできる必要があるアナリスト、特に企業に役立ちます。公衆インターネットでログを使用する場合、ログが大きく、プライバシーを侵害する可能性があるため、ログのフラッシュとプライバシー保護の手順を実施する必要があります。これらのログの保護、およびログの整合性、プライバシーの保護、ログのパージ（保持ポリシーなど）に注意を払う必要があります。また、このドキュメントで確立された接続エラーやその他のメッセージのログも重要です。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<http：/ /www.rfc-editor.org/info/rfc3986>。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<http://www.rfc-editor.org/ info / rfc4566>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, <http://www.rfc-editor.org/info/rfc5245>.
[RFC5245] Rosenberg、J。、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal for Offer / Answer Protocols」、RFC 5245、DOI 10.17487 / RFC5245、2010年4月、<http：// www .rfc-editor.org / info / rfc5245>。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <http://www.rfc-editor.org/info/rfc5389>.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NAT用セッショントラバーサルユーティリティ（STUN）」、RFC 5389、DOI 10.17487 / RFC5389、2008年10月、<http：// www.rfc-editor.org/info/rfc5389>。
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, <http://www.rfc-editor.org/info/rfc5761>.
[RFC5761] Perkins、C。およびM. Westerlund、「Multiplexing RTP Data and Control Packets on a Single Port」、RFC 5761、DOI 10.17487 / RFC5761、2010年4月、<http://www.rfc-editor.org/info / rfc5761>。
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, March 2012, <http://www.rfc-editor.org/info/rfc6544>.
[RFC6544] Rosenberg、J.、Kerenen、A.、Lowekamp、B。、およびA. Roach、「Interactive Connectivity Establishment（ICE）を使用するTCP候補」、RFC 6544、DOI 10.17487 / RFC6544、2012年3月、<http：/ /www.rfc-editor.org/info/rfc6544>。
[RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, Ed., "Real-Time Streaming Protocol Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December 2016, <http://www.rfc-editor.org/info/rfc7826>.
[RFC7826] Schulzrinne、H.、Rao、A.、Lanphier、R.、Westerlund、M。、およびM. Stiemerling、編、「Real-Time Streaming Protocol Version 2.0」、RFC 7826、DOI 10.17487 / RFC7826、12月2016、<http://www.rfc-editor.org/info/rfc7826>。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, DOI 10.17487/RFC2326, April 1998, <http://www.rfc-editor.org/info/rfc2326>.
[RFC2326] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「Real Time Streaming Protocol（RTSP）」、RFC 2326、DOI 10.17487 / RFC2326、1998年4月、<http：//www.rfc-editor。 org / info / rfc2326>。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, <http://www.rfc-editor.org/info/rfc3022>.
[RFC3022] Srisuresh、P。およびK. Egevang、「Traditional IP Network Address Translator（Traditional NAT）」、RFC 3022、DOI 10.17487 / RFC3022、2001年1月、<http://www.rfc-editor.org/info/ rfc3022>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <http://www.rfc-editor.org/info/rfc3264>.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション記述プロトコル（SDP）を備えたオファー/アンサーモデル」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<http://www.rfc-editor.org / info / rfc3264>。
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, DOI 10.17487/RFC3489, March 2003, <http://www.rfc-editor.org/info/rfc3489>.
[RFC3489] Rosenberg、J.、Weinberger、J.、Huitema、C。、およびR. Mahy、「STUN-Simple Data Traversal of User Datagram Protocol（UDP）Through Network Address Translators（NATs）」、RFC 3489、DOI 10.17487 / RFC3489、2003年3月、<http://www.rfc-editor.org/info/rfc3489>。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <http://www.rfc-editor.org/info/rfc4340>.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram Congestion Control Protocol（DCCP）」、RFC 4340、DOI 10.17487 / RFC4340、2006年3月、<http：//www.rfc-editor。 org / info / rfc4340>。
[RFC7604] Westerlund, M. and T. Zeng, "Comparison of Different NAT Traversal Techniques for Media Controlled by the Real-Time Streaming Protocol (RTSP)", RFC 7604, DOI 10.17487/RFC7604, September 2015, <http://www.rfc-editor.org/info/rfc7604>.
[RFC7604] Westerlund、M。およびT. Zeng、「リアルタイムストリーミングプロトコル（RTSP）によって制御されるメディアのさまざまなNATトラバーサル手法の比較」、RFC 7604、DOI 10.17487 / RFC7604、2015年9月、<http：// www.rfc-editor.org/info/rfc7604>。
Acknowledgments
謝辞
The authors would like to thank: Remi Denis-Courmont for suggesting the method of integrating ICE in RTSP signaling, Dan Wing for help with the security section and numerous other issues, Ari Keranen for review of the document and its ICE details, and Flemming Andreasen and Alissa Cooper for a thorough review. In addition, Bill Atwood has provided comments and suggestions for improvements.
著者は感謝したいと思います：RTSPシグナリングにICEを統合する方法を提案してくれたRemi Denis-Courmont、セキュリティセクションと他の多くの問題の助けをしてくれたDan Wing、ドキュメントとそのICE詳細のレビューをしてくれたAri Keranen、そしてFlemming Andreasenと徹底的なレビューのためのアリッサクーパー。さらに、Bill Atwoodは改善のためのコメントと提案を提供しています。
Authors' Addresses
著者のアドレス
Jeff Goldberg Cisco 32 Hamelacha St. South Netanya 42504 Israel
ジェフゴールドバーグシスコ32ハメラチャセントサウスネタニア42504イスラエル
Phone: +972 9 8927222
Email: jgoldber@cisco.com
Magnus Westerlund Ericsson Farogatan 6 Stockholm SE-164 80 Sweden
Magnus Westerlund Ericsson Farogatan 6ストックホルムSE-164 80スウェーデン
Phone: +46 8 719 0000
Email: magnus.westerlund@ericsson.com
Thomas Zeng Nextwave Wireless, Inc. 12670 High Bluff Drive San Diego, CA 92130 United States of America
Thomas Zeng Nextwave Wireless、Inc. 12670 High Bluff Drive San Diego、CA 92130アメリカ合衆国
Phone: +1 858 480 3100
Email: thomas.zeng@gmail.com