RFC4961 日本語訳

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

コメントを求めるワーキンググループD.翼の要求をネットワークでつないでください: 4961シスコシステムズBCP: 131 2007年7月のカテゴリ: 最も良い現在の習慣

              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.

このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(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 Controlプロトコル(RTCP)セッションの両方に1UDPポート組を使用することを勧めると呼びました。

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. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 このDocument. . . . . . . . . . . . . . . 2 3のコンベンションUsed。 左右対称のRTPと左右対称のRTCP. . . . . . . . 3 4の定義。 お勧めの用法. . . . . . . . . . . . . . . . . . . . . . . 3 5。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 4 6。 承認. . . . . . . . . . . . . . . . . . . . . . . . 4 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 4 7.1。 引用規格. . . . . . . . . . . . . . . . . . . 4 7.2。 有益な参照. . . . . . . . . . . . . . . . . . 4

Wing                     Best Current Practice                  [Page 1]

RFC 4961                 Symmetric RTP and RTCP                July 2007

翼の最も良い現在の習慣[1ページ]RFC4961の左右対称のRTPとRTCP2007年7月

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のソース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のために無視されました。 多くのファイアウォール、Network Address Translators(NATs)[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ポートはそのメディアを受け取って、そのメディアを伝える装置によってともに選択されます。 ポートを受けてください。ユニキャスト流れのためにコミュニケートする、リモート同輩(例えばSIP[RFC3261]で運ばれたSession記述プロトコル(SDP)[RFC4566]、Session Announcementプロトコル(SAP)[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)ポートの間には、通信が全くありません。 すなわち、「A」がローカルに選ぶかもしれない装置は、1234年になるようにポートを送受信します。 また、同輩(装置「B」)がポートにポート1234を使用するのが抑制されません。 事実上、そのような規制は装置「B」が別のアプリケーションに既にそのポートを使用しているかもしれないので会うのは不可能です。

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

1UDPポート組を使用する利益はセクション4で以下で説明されます。

2.  Conventions Used in this Document

2. このDocumentのコンベンションUsed

   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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?

Wing                     Best Current Practice                  [Page 2]

RFC 4961                 Symmetric RTP and RTCP                July 2007

翼の最も良い現在の習慣[2ページ]RFC4961の左右対称のRTPとRTCP2007年7月

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"における双方向のRTPメディアの流れを受けるとき、また、それは同じソースのUDPポート「A」とIPアドレス“a"からその流れのためのRTPメディアを伝えます。 すなわち、それは、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を支持しない装置は異なったポート、または、異なったIPアドレスからRTPを伝えるでしょう、アドレスがその双方向のメディア蒸気のためにRTPを受け取るのに使用したポートとIPより。

   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パケットを受けるとき、また、それはその流れのために同じソースUDP港「B」とIPアドレス「b」からRTCPパケットを伝えます。 すなわち、それは、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を支持しない装置は異なったポート、または、異なったIPアドレスからRTCPを伝えるでしょう、アドレスがRTCPを受け取るのに使用したポートとIPより。

4.  Recommended Usage

4. お勧めの用法

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

2つの特定の例が左右対称のRTPと左右対称のRTCPがREQUIREDであるところにあります:

   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].

最初の例は統合Application Layerゲートウェイ(ALG)の機能性を欠いているNATsです。 そのようなNATsは、終点が双方向の交通を証明するのに左右対称のUDPポートを使用するのを必要とします。 この要件は[RFC4787]のセクション4で説明されたNATsのすべてのタイプのために存在しています。 ALGsは[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番目の例は、Session Border Controllers(SBCs)と他の形式のRTPとRTCPリレー(例えば、[TURN])です。 メディアリレーが、'アドレス依存する'NATか'アドレスとPort-扶養家族'[RFC4787]の向こう側に双方向の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はデバッグとトラブルシューティングを緩和できます。

Wing                     Best Current Practice                  [Page 3]

RFC 4961                 Symmetric RTP and RTCP                July 2007

翼の最も良い現在の習慣[3ページ]RFC4961の左右対称のRTPとRTCP2007年7月

   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メディアの流れにいつも使用されるのは、RECOMMENDEDです。

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パケットしか見ません。 この攻撃が1UDPポート組(例えば、DNS[RFC1035])を使用する他のUDPベースのプロトコルのものと同様であることに注意してください。

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、Sunil Bhargo、ラース・エッゲルト、フランソアLe Faucheur、Cullenジョニングス、ベニー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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、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.ジョニングス)は「ユニキャストUDPのためのアドレス変換(NAT)の行動の要件をネットワークでつなぎます」、BCP127、RFC4787、2007年1月。

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

[RFC0793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。

Wing                     Best Current Practice                  [Page 4]

RFC 4961                 Symmetric RTP and RTCP                July 2007

翼の最も良い現在の習慣[4ページ]RFC4961の左右対称のRTPとRTCP2007年7月

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

[RFC3022] SrisureshとP.とK.Egevang、「伝統的なIPネットワークアドレス変換機構(伝統的なNAT)」、RFC3022、2001年1月。

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

[RFC4566] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。

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

[RFC1035]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日

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

[RFC1350] Sollins、K.、「TFTPプロトコル(改正2)」、STD33、RFC1350、1992年7月。

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

[ターンします] 「簡単な縦断下部のNAT(気絶させる)からリレーアドレスを得」て、ローゼンバーグ、J.は進歩、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] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。

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

[RFC2974] ハンドレーとM.とパーキンス、C.とE.ウィーラン、「セッション発表プロトコル」、RFC2974、2000年10月。

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

[RFC3525] 木立とC.とPantaleoとM.とアンダーソン、T.とT.テイラー、「ゲートウェイ制御プロトコルバージョン1インチ、RFC3525、2003年6月。」

Author's Address

作者のアドレス

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

西タスマン・Driveダン翼のシスコシステムズ170カリフォルニア95134サンノゼ(米国)

   EMail:  dwing@cisco.com

メール: dwing@cisco.com

Wing                     Best Current Practice                  [Page 5]

RFC 4961                 Symmetric RTP and RTCP                July 2007

翼の最も良い現在の習慣[5ページ]RFC4961の左右対称のRTPとRTCP2007年7月

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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機能のための基金は現在、インターネット協会によって提供されます。

Wing                     Best Current Practice                  [Page 6]

最も良い現在の習慣に翼をつけさせてください。[6ページ]