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

URL : https://tools.ietf.org/html/rfc4961
タイトル : RFC 4961 - 対称RTP / 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)

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.

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

著作権表示

著作権（C）IETFトラスト（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接続が元TCPポートとホストAから確立されたときに、ある「」リモートホストへ、リモートホストが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アプリケーションは、（例えば、DNS [RFC1035]）を送信および受信するために、単一のUDPポートを使用して、いくつかのアプリケーションは、明示的なシグナリング（例えば、簡易ファイル転送プロトコル（TFTP）[RFC1350]）を送受信するために、異なるUDPポートを使用します、およびその他のアプリケーションは、送信の選択を指定し、ポート（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ポートを使用しての有用性は、一般的に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ポートが両方のメディアことを受けて、メディアことを送信デバイスによって選択されます。ユニキャストフローについて、受信ポートがリモートピアに通信される（例えば、セッション記述プロトコル（SDP）SIP [RFC3261]、セッションアナウンスメントプロトコル（SAPで運ば[RFC4566]）[RFC2974]、またはMegacoの/ H.248 [RFC3525 ]）。

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）ポートとの間には対応関係がありません。すなわち、デバイス「」そのローカル送信を選択し、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].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。

3. Definition of Symmetric RTP and Symmetric RTCP

対称RTPとRTCP対称の3の定義

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.

デバイスは、それが選択した場合、対称的なRTPをサポートして通信し、UDPポート「A」とIPアドレス「A」に、双方向RTPメディアストリームを受信した場合、それはまたからそのストリームのためのRTPメディアを送信するよう、そのIPアドレスとポート番号を使用します同じ送信元UDPポート「A」およびIPアドレス「A」。つまり、1つのRTPストリームを送受信するために、同じUDPポートを使用しています、です。

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.

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

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.

第二のインスタンスは、セッションボーダコントローラ（SBCS）とRTPとRTCPリレー（例えば、[TURN]）の他の形態です。メディアリレーは、「アドレス依存性」や「アドレスとポート依存」[RFC4787]でNAT越えて双方向のUDP通信を確立する必要があります。しかし、メディアリレーで、対称UDPポートは、まだ、そのようなNATを通過するために必要とされています。

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パケットを送信することができます。これにより、攻撃者は、それがそのホストにパケットを送信することができます前に、逆方向トラフィックのために使用されるUDPの送信元ポートおよび宛先ポートを学習している非対称RTPとRTCP非対称とは異なります。ホストは対称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.

この文書とその支援のための著者のおかげフランソワAudet、スニルBhargo、ラースEggertの、フランソワ・ルFaucheur、カレン・ジェニングス、ベニーRodrig、ロバートスパークス、そしてジョー・ストーン。

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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、フレデリック、R.、およびV.ヤコブソン、 "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.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、BCP 127、RFC 4787、2007年1月。

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

[RFC0793]ポステル、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]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "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] Sollins、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]ローゼンバーグ、J.、進歩、2007年7月の作業 "リレーを取得することは簡単なトラバーサルの下側にNAT（STUN）からアドレス"。

[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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。

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

[RFC2974]ハンドリー、M.、パーキンス、C.、およびE.ウィーラン、 "セッションアナウンスメントプロトコル"、RFC 2974、2000年10月。

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

[RFC3525]グローブ、C.、パンタレオ、M.、アンダーソン、T.、およびT.テイラー、 "ゲートウェイ制御プロトコルバージョン1"、RFC 3525、2003年6月。

Author's Address

著者のアドレス

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

ダン・ウイングシスコシステムズ170西タスマン・ドライブサンノゼ、CA 95134 USA

EMail: dwing@cisco.com

メールアドレス：dwing@cisco.com

Full Copyright Statement

完全な著作権声明

著作権（C）IETFトラスト（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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。

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.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。