RFC 4961 - Symmetric RTP / RTP Control Protocol (RTCP) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc4961
タイトル : RFC 4961 - 対称RTP / RTPコントロールプロトコル（RTCP）
翻訳編集 : 自動生成

[要約] RFC 4961は、対称的なRTP / RTCPの仕様を定義しており、RTPとRTCPの通信を改善するための手法を提供しています。このRFCの目的は、RTPとRTCPの対称的な通信を実現し、ネットワークの効率性と品質を向上させることです。

Network Working Group                                            D. Wing
Request for Comments:  4961                                Cisco Systems
BCP:  131                                                      July 2007
Category:  Best Current Practice

Symmetric RTP / RTP Control Protocol (RTCP)

対称RTP / RTPコントロールプロトコル（RTCP）

Status of This Memo

本文書の位置付け

This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。

著作権表示

著作権（c）The IETF Trust（2007）。

Abstract

概要

This document recommends using one UDP port pair for both communication directions of bidirectional RTP and RTP Control Protocol (RTCP) sessions, commonly called "symmetric RTP" and "symmetric RTCP".

このドキュメントでは、一般に「対称RTP」と「対称RTCP」と呼ばれる双方向RTPおよびRTPコントロールプロトコル（RTCP）セッションの通信方向の両方に1つのUDPポートペアを使用することを推奨しています。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Conventions Used in this Document . . . . . . . . . . . . . . . 2
   3.  Definition of Symmetric RTP and Symmetric RTCP  . . . . . . . . 3
   4.  Recommended Usage . . . . . . . . . . . . . . . . . . . . . . . 3
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 4
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 4

1. Introduction

1. はじめに

TCP [RFC0793], which is inherently bidirectional, transmits and receives data using the same local port. That is, when a TCP connection is established from host A with source TCP port "a" to a remote host, the remote host sends packets back to host A's source TCP port "a".

TCP [RFC0793]は、本質的に双方向であり、同じローカルポートを使用してデータを送信および受信します。つまり、ソースTCPポート「A」を備えたホストAからリモートホストにTCP接続が確立されると、リモートホストはホストAのソースTCPポート「A」にパケットを送り返します。

However, UDP is not inherently bidirectional and UDP does not require using the same port for sending and receiving bidirectional traffic. Rather, some UDP applications use a single UDP port to transmit and receive (e.g., DNS [RFC1035]), some applications use different UDP ports to transmit and receive with explicit signaling (e.g., Trivial File Transfer Protocol (TFTP) [RFC1350]), and other applications don't specify the choice of transmit and receive ports (RTP [RFC3550]).

ただし、UDPは本質的に双方向ではなく、UDPは同じポートを使用して双方向トラフィックを送信および受信する必要はありません。むしろ、一部のUDPアプリケーションは、単一のUDPポートを使用して送信および受信し（例：DNS [RFC1035]）、異なるUDPポートを使用して明示的なシグナル伝達で送信および受信します（例：些細なファイル転送プロトコル（TFTP）[RFC1350]）、およびその他のアプリケーションは、送信ポートと受信ポートの選択を指定していません（RTP [RFC3550]）。

Because RTP and RTCP are not inherently bidirectional protocols, and UDP is not a bidirectional protocol, the usefulness of using the same UDP port for transmitting and receiving has been generally ignored for RTP and RTCP. Many firewalls, Network Address Translators (NATs) [RFC3022], and RTP implementations expect symmetric RTP, and do not work in the presence of asymmetric RTP. However, this term has never been defined. This document defines "symmetric RTP" and "symmetric RTCP".

RTPとRTCPは本質的に双方向プロトコルではなく、UDPは双方向プロトコルではないため、同じUDPポートを使用して受信するために同じUDPポートを使用することの有用性は、RTPとRTCPでは一般に無視されています。多くのファイアウォール、ネットワークアドレス翻訳者（NAT）[RFC3022]、およびRTP実装は対称RTPを期待しており、非対称RTPの存在下では機能しません。ただし、この用語は定義されていません。このドキュメントでは、「対称RTP」および「対称RTCP」を定義します。

The UDP port number to receive media, and the UDP port to transmit media are both selected by the device that receives that media and transmits that media. For unicast flows, the receive port is communicated to the remote peer (e.g., Session Description Protocol (SDP) [RFC4566] carried in SIP [RFC3261], Session Announcement Protocol (SAP) [RFC2974], or Megaco/H.248 [RFC3525]).

メディアを受信するためのUDPポート番号、およびメディアを送信するためのUDPポートは、両方ともそのメディアを受信してそのメディアを送信するデバイスによって選択されます。]）。

There is no correspondence between the local RTP (or RTCP) port and the remote RTP (or RTCP) port. That is, device "A" might choose its local transmit and receive port to be 1234. Its peer, device "B", is not constrained to also use port 1234 for its port. In fact, such a constraint is impossible to meet because device "B" might already be using that port for another application.

ローカルRTP（またはRTCP）ポートとリモートRTP（またはRTCP）ポートの間に対応はありません。つまり、デバイス「A」はローカル送信を選択し、ポートを1234にすることができます。そのピア、デバイス「B」は、ポートにポート1234を使用するように制約されていません。実際、このような制約は、デバイスの「B」がすでにそのポートを別のアプリケーションに使用している可能性があるため、満たすことは不可能です。

The benefits of using one UDP port pair is described below in Section 4.

1つのUDPポートペアを使用することの利点については、以下にセクション4で説明します。

2. Conventions Used in this Document

2. このドキュメントで使用されている規則

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。

3. Definition of Symmetric RTP and Symmetric RTCP

3. 対称RTPおよび対称RTCPの定義

A device supports symmetric RTP if it selects, communicates, and uses IP addresses and port numbers such that, when receiving a bidirectional RTP media stream on UDP port "A" and IP address "a", it also transmits RTP media for that stream from the same source UDP port "A" and IP address "a". That is, it uses the same UDP port to transmit and receive one RTP stream.

IPアドレスとポート番号を選択、通信、および使用する場合、デバイスは対称RTPをサポートします。同じソースUDPポート「A」とIPアドレス「A」。つまり、同じUDPポートを使用して1つのRTPストリームを送信および受信します。

A device that doesn't support symmetric RTP would transmit RTP from a different port, or from a different IP address, than the port and IP address used to receive RTP for that bidirectional media steam.

対称RTPをサポートしないデバイスは、その双方向メディアスチームのRTPを受信するために使用されるポートおよびIPアドレスよりも、異なるポートまたは異なるIPアドレスからRTPを送信します。

A device supports symmetric RTCP if it selects, communicates, and uses IP addresses and port numbers such that, when receiving RTCP packets for a media stream on UDP port "B" and IP address "b", it also transmits RTCP packets for that stream from the same source UDP port "B" and IP address "b". That is, it uses the same UDP port to transmit and receive one RTCP stream.

IPアドレスとポート番号を選択、通信、および使用する場合、デバイスは対称RTCPをサポートします。これにより、UDPポート「B」およびIPアドレス「B」のメディアストリームのRTCPパケットを受信すると、そのストリームのRTCPパケットも送信します。同じソースUDPポート「B」とIPアドレス「B」から。つまり、同じUDPポートを使用して、1つのRTCPストリームを送信および受信します。

A device that doesn't support symmetric RTCP would transmit RTCP from a different port, or from a different IP address, than the port and IP address used to receive RTCP.

対称RTCPをサポートしないデバイスは、RTCPを受信するために使用されるポートおよびIPアドレスよりも、異なるポートまたは別のIPアドレスからRTCPを送信します。

4. Recommended Usage

4. 推奨される使用法

There are two specific instances where symmetric RTP and symmetric RTCP are REQUIRED:

対称RTPと対称RTCPが必要な2つの特定のインスタンスがあります。

The first instance is NATs that lack integrated Application Layer Gateway (ALG) functionality. Such NATs require that endpoints use symmetric UDP ports to establish bidirectional traffic. This requirement exists for all types of NATs described in Section 4 of [RFC4787]. ALGs are defined in Section 4.4 of [RFC3022].

最初のインスタンスは、統合されたアプリケーションレイヤーゲートウェイ（ALG）機能を欠いているNATです。このようなNATでは、エンドポイントが対称UDPポートを使用して双方向トラフィックを確立する必要があります。この要件は、[RFC4787]のセクション4に記載されているすべてのタイプのNATに存在します。ALGは[RFC3022]のセクション4.4で定義されています。

The second instance is Session Border Controllers (SBCs) and other forms of RTP and RTCP relays (e.g., [TURN]). Media relays are necessary to establish bidirectional UDP communication across a NAT that is 'Address-Dependent' or 'Address and Port-Dependent' [RFC4787]. However, even with a media relay, symmetric UDP ports are still required to traverse such a NAT.

2番目のインスタンスは、セッションボーダーコントローラー（SBCS）およびその他のフォームのRTPおよびRTCPリレー（[ターン]）です。メディアリレーは、「アドレス依存」または「アドレス依存」であるNAT全体で双方向UDP通信を確立するために必要です[RFC4787]。ただし、メディアリレーがあっても、このようなNATを通過するには対称UDPポートが必要です。

There are other instances where symmetric RTP and symmetric RTCP are helpful, but not required. For example, if a firewall can expect symmetric RTP and symmetric RTCP, then the firewall's dynamic per-call port filter list can be more restrictive compared to asymmetric RTP and asymmetric RTCP. Symmetric RTP and symmetric RTCP can also ease debugging and troubleshooting.

対称RTPと対称RTCPが役立つが必須ではない他のインスタンスがあります。たとえば、ファイアウォールが対称RTPと対称RTCPを期待できる場合、ファイアウォールの動的なポートフィルターリストは、非対称RTPおよび非対称RTCPと比較してより制限的になります。対称RTPと対称RTCPは、デバッグやトラブルシューティングを容易にすることもできます。

Other UDP-based protocols can also benefit from common local transmit and receive ports.

他のUDPベースのプロトコルは、一般的なローカル送信および受信ポートの恩恵を受けることもできます。

There are no known cases where symmetric RTP or symmetric RTCP are harmful.

対称RTPまたは対称RTCPが有害な場合は既知のケースはありません。

For these reasons, it is RECOMMENDED that symmetric RTP and symmetric RTCP always be used for bidirectional RTP media streams.

これらの理由から、対称RTPと対称RTCPを常に双方向RTPメディアストリームに使用することをお勧めします。

5. Security Considerations

5. セキュリティに関する考慮事項

If an attacker learns the source and destination UDP ports of a symmetric RTP or symmetric RTCP flow, the attacker can send RTP or RTCP packets to that host. This differs from asymmetric RTP and asymmetric RTCP, where an attacker has to learn the UDP source and destination ports used for the reverse traffic, before it can send packets to that host. Thus, if a host uses symmetric RTP or symmetric RTCP, an attacker need only see one RTP or RTCP packet in order to attack either RTP endpoint. Note that this attack is similar to that of other UDP-based protocols that use one UDP port pair (e.g., DNS [RFC1035]).

攻撃者が対称RTPまたは対称RTCPフローのソースおよび宛先UDPポートを学習する場合、攻撃者はRTPまたはRTCPパケットをそのホストに送信できます。これは、非対称RTPおよび非対称RTCPとは異なり、攻撃者はそのホストにパケットを送信する前に、逆トラフィックに使用されるUDPソースと宛先ポートを学習する必要があります。したがって、ホストが対称RTPまたは対称RTCPを使用する場合、攻撃者は、いずれかのRTPエンドポイントを攻撃するために1つのRTPまたはRTCPパケットを表示する必要があります。この攻撃は、1つのUDPポートペアを使用する他のUDPベースのプロトコルの攻撃と類似していることに注意してください（例：DNS [RFC1035]）。

6. Acknowledgments

6. 謝辞

The author thanks Francois Audet, Sunil Bhargo, Lars Eggert, Francois Le Faucheur, Cullen Jennings, Benny Rodrig, Robert Sparks, and Joe Stone for their assistance with this document.

著者は、フランソワ・オーデット、スニル・バルゴ、ラース・エガート、フランソワ・ル・フォーシュール、カレン・ジェニングス、ベニー・ロドリッグ、ロバート・スパークス、ジョー・ストーンに感謝します。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

7.2. Informative References

7.2. 参考引用

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.

[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。

[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.

[RFC4787] Audet、F。およびC. Jennings、「Unicast UDPのネットワークアドレス変換（NAT）行動要件」、BCP 127、RFC 4787、2007年1月。

[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。

[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.

[RFC3022] Srisuresh、P。およびK. Egevang、「従来のIPネットワークアドレス翻訳者（従来のNAT）」、RFC 3022、2001年1月。

[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.

[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

[RFC1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。

[RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992.

[RFC1350]ソリンズ、K。、「TFTPプロトコル（改訂2）」、STD 33、RFC 1350、1992年7月。

[TURN] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal Underneath NAT (STUN)", Work in Progress, July 2007.

[Turn] Rosenberg、J。、「NAT（Stun）の下の単純なトラバーサルからリレーアドレスを取得する」、2007年7月の作業。

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。

[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.

[RFC2974] Handley、M.、Perkins、C。、およびE. Whelan、「セッションアナウンスプロトコル」、RFC 2974、2000年10月。

[RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway Control Protocol Version 1", RFC 3525, June 2003.

[RFC3525] Groves、C.、Pantaleo、M.、Anderson、T.、およびT. Taylor、「Gateway Control Protocol 1」、RFC 3525、2003年6月。

Author's Address

著者の連絡先

Dan Wing Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA

Dan Wing Cisco Systems 170 West Tasman Drive San Jose、CA 95134 USA

   EMail:  dwing@cisco.com

Full Copyright Statement

完全な著作権声明

著作権（c）The IETF Trust（2007）。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。