Network Working Group C. Huitema Request for Comments: 3605 Microsoft Category: Standards Track October 2003 セッション記述プロトコル(SDP)の リアルタイムコントロールプロトコル(RTCP)属性 Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP) 本書の位置付け この文書は、インターネットコミュニティのためのインターネット標準トラッ クプロトコルを規定するものであり、改善のための議論や提案を依頼するもの である。標準化の段階や、プロトコルの位置付けについては、最新版の "Internet Official Protocol Standards" (STD 1)を参照されたい。この文書 の配信は無制限である。 著作権表記 Copyright (C) The Internet Society (2003).All Rights Reserved. 概要 セッション記述プロトコル(Session Description Protocol/SDP)は、マルチ メディアセッションに使用するメディアストリームのパラメータを記述すると きに使用する。セッションで複数ポートが必要な場合、SDPは、そのポートに 連続番号が振られていると仮定する。ただし、ポートのマッピングにも使用さ れるNAT(network address translation)デバイスをセッションが経由する と、ポートの順序は変換によって変わってしまう可能性がある。この問題に対 処するために、本書ではSDPの拡張属性を提案する。 1. はじめに セッション招待プロトコル(session invitation protocol/SIP、[RFC3261]) は、インターネット上でマルチメディアセッションを確立するときによく使用 される[訳注： 「招待(invitation)」は原文のまま]。現在では、接続の一端 または両端がNATデバイスの背後にあることがよくある[RFC2766]。この場合、 SDPテキストで、NATの「パブリックインターネット」に表示されるようにIPア ドレスとUDPポートを記述する必要がある。本書では、NATの背後にあるホスト が、このような番号を取得する方法があると想定する。このような番号を知る 方法についてはセクション3で概説しているが、番号を知るだけでは十分では ない。 SIPメッセージでは、SDP [RFC2327]で定義されたエンコーディングを使用し て、さまざまなメディアで使用されるIPアドレスとTCP/UDPポートを記述して いる。音声とビデオは一般的にRTP [RFC3550]を使用して送信され、メディア 用とコントロールプロトコル(RTCP)用に2つのUDPポートが必要である。SDPで はメディアごとに1つのポートしか伝達せず、「メディアアプリケーションで Huitema Standards Track [Page 1] RFC 3605 RTCP attribute in SDP October 2003 使用する他のポート(RTCPポートなど)は、ベースメディアポートからアルゴリ ズム的に取得する必要がある」と記載されている。古いバージョンのRTP ([RFC1889]など)では、RTCPポート番号をベースメディアポートから取得する 必要があった。現在では、この制限は取り除かれ、SDPで明示的にRTCPポート を指定する必要がある。ただし、RTPの実装で初期の仕様[RFC1889]に準拠して いる場合、本書で規定されるSDP属性を利用できない可能性がある、という点 に注意が必要。 NATデバイスがポートのマッピングを実行すると、マッピングされた2つのポー トが、元のポート番号の連続性や対称性が維持されるとは限らない。実際、 NATでIPアドレスのプールを管理すると、RTPポートとRTCPポートが異なるアド レスにマッピングされることさえある。NATによってポート番号の順序変更や 対称性の切り替えが発生した場合でも、接続を正常に確立できるように、特定 のSDP属性を使用して、RTCPポートとRTCPアドレス(オプション)を記述するこ とを提案する。 本書中のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、 「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、 「OPTIONAL」は、[RFC2119]で記述されている通りに解釈される。 2. ソリューションの説明 本書で提案するソリューションの要点は、RTCPで使用するポートを記述する SDP属性の宣言である。 2.1. RTCP属性 メディアストリームに使用するRTCPポートがメディア行に記述されるRTPポー トより1つ高い(奇数の)ポート番号ではない場合に、このRTCPポートを記述す るためにRTCP属性を使用する。RTCP属性は、「value」属性であり、[RFC2327] の18ページで規定されている一般的な構文に従う(「a=<属性>:<値>」)。RTCP 属性について次のことが言える。 * 名前はASCII文字列「rtcp」(小文字)である。 * 値は、RTCPポート番号とアドレス(オプション)である。 属性の正式な説明は、次のABNF [RFC2234]構文で定義される。 rtcp-attribute = "a=rtcp:" port [nettype space addrtype space connection-address] CRLF Huitema Standards Track [Page 2] RFC 3605 RTCP attribute in SDP October 2003 ここで、「port」、「nettype」、「addrtype」、「connection-address」 の各トークンは、[RFC2327]の「Appendix A: SDP Grammar (付録A: SDPの 文法)」で規定されている。 エンコーディング例は次のようになる。 m=audio 49170 RTP/AVP 0 a=rtcp:53020 m=audio 49170 RTP/AVP 0 a=rtcp:53020 IN IP4 126.16.64.4 m=audio 49170 RTP/AVP 0 a=rtcp:53020 IN IP6 2001:2345:6789:ABCD:EF01:2345:6789:ABCD メディアレベルの属性として、RTCP属性を使用してもよい[MAY]。セッション レベルの属性として使用してはならない[MUST NOT]。以下の例では、ユニキャ ストアドレスのみを返す方法を説明しているが、ユニキャスト値とマルチキャ スト値のどちらも有効である。 3. ソリューションの議論 ソリューションの実装は、実に単純である。このソリューションに関してよく 聞かれた質問は、有効か(つまり、NATを修正しないで、ホストが実際にポート 番号を検出できるか)、十分か(つまりメディアタイプごとに補助のポートを複 数記述する必要はあるかどうか)、メディア定義の方を変更せず新しい属性を 追加するのはなぜか、という点である。 3.1. ポート番号の検出方法 ここで提案するソリューションは、ホストが「変換されたポート番号」(つま り、NATの「外側」に見えるポート値)を検出できる場合にのみ、有効である。 1つの可能性として、STUNに対応するサーバーとして動作する、親密な関係の サードパーティに協力を要請する方法がある。この場合、4つのプロセス手順 がある。 1 - ホストは、RTP/RTCPペア用に2つのUDPポート番号を割り当てる。 2 - ホストは、各ポートのUDPメッセージをSTUNサーバーに送信する。 3 - STUNサーバーは、パケットのソースアドレスとポートを読み取り、返信の テキストにコピーする。 Huitema Standards Track [Page 3] RFC 3605 RTCP attribute in SDP October 2003 4 - ホストは、STUNプロトコルに従って返信を解析し、2つのUDPポートに対応 する外部のアドレスとポートを知る。 このアルゴリズムでは、NATが、サードパーティおよびホストが接続を確立し ようとしている「SDPの相手」に送信されたパケットと同じ変換を使用してい る、と仮定している。インターネットに配置されているすべてのNATボックス にこのような特徴があるとは限らない。多様なNATの詳しい議論については、 STUN仕様[RFC3489]を参照のこと。 3.2. 複数ポートをサポートする必要性 ほとんどのメディアストリームは、RTPポートとRTCPポートの1組を使用して送 信される。ただし、複数のRTPフロー上で1つのメディアを送信することは可能 である。たとえば、階層的エンコーディング(hierarchical encoding)を使用 した場合など。この場合、SDPでは、次のように、最初のフローでRTPが使用す るポート番号と、フローの数をエンコードする。 m=video 49170/2 RTP/AVP 31 この例で、メディアは2つの連続するポートのペア上で送信される。最初のフ ローのRTP(偶数の49170)と最初のフローのRTCP(奇数の49171)は、それぞれ2番 目のフローのRTP(偶数の49172)と2番目のフローのRTCP(奇数の49173)に相当す る。 理論的には、SDPを修正し、別個のエンコーディング層に相当する複数のポー トを記述することが可能である。ただし、複数層のエンコーディングは、実際 にはあまり使用されず、使用されてもマルチキャスト送信と連携する場合がほ とんどである。本書で説明する送信の問題は、ユニキャスト独自のものであ る。そのため、複数ポートの記述をサポートするための短期的な要件はない。 メディアが1つのRTP/RTCPストリーム上で送信されるという単純な場合を中心 にする方が、便利であり、また強固でもある。 3.3. メディア定義を拡張しない理由 RTPポートはメディア記述行に記述するため、RTCP属性を作成するよりも、メ ディア記述行にRTCPポートを記述する方が便利なように考えられる。メディア 記述行にRTCPポートを記述するという方法も検討したが、2つの理由から却 下した。メディア記述に新たなポート番号とオプションのアドレスを追加する のはおかしい。また、さらに重要な点は、既存アプリケーションとの間に問題 が生じる。つまり、アプリケーションが拡張を理解しない場合、メディア記述 全体が拒否される。対照的に、属性を追加する場合、定義済みのエラーモード がある。「a=rtcp」属性を理解しない実装は単に属性を無視する。この実装は Huitema Standards Track [Page 4] RFC 3605 RTCP attribute in SDP October 2003 指定したアドレスへのRTCPパケット送信には失敗するが、少なくともRTPパ ケットでメディアを受信することはできる。 4. UNSAFの考慮事項 SDPのRTCP属性は、NAT経由のRTP/RTCPフローを確立できるようにするために使 用される。このメカニズムは、STUN [RFC3489]などのアドレス検出メカニズム と連携して使用することができる。STUNは、NATトラバーサル問題に対する一 時的な解決方法である。そのため、「Unilateral self- address fixing」 [RFC3424]に関連する一般的な問題について考慮する必要がある。 RTCP属性は、ポートのマッピングを行うNATがアドレス変換した後に表示され るポート番号を記述する、という非常に限定された問題に対処するためのもの である。RTCP属性は、他の用途に使用すべきではない[SHOULD NOT]。 本書では、将来的に、次に示す2つの出口戦略のいずれかが開発されると予想 している。IETFで、アプリケーションがRTPとRTCPに適したポート番号ペアを 取得できる、明快な「ミドルボックス制御(middlebox control)」プロトコル を開発する可能性がある。もう1つの可能性は、IPv6の展開である。IPv6に よって、「エンドツーエンド」のアドレス指定を使用できるようになり、2つ のホストが確実に適切なポートを使用することができる。どちらの場合でも、 RTCP属性が指定された「規格外の」RTCPポートを記述する必要はなくなる。 5. セキュリティの考慮事項 このSDP拡張によって、マルチメディアアプリケーションに重大なセキュリ ティリスクが生じるとは考えられていない。悪意のある第三者がこの拡張を利 用して、RTP交換のRTCPの一部をリダイレクトすることを心配するかもしれな いが、これを実行するにはSDPテキストを伝達するシグナリングパケットの盗 聴と書き換えが必要である。盗聴者がこのようなことを実行できる場合、メ ディアを送信するアドレスとポート番号の大規模な変更など、数多くの攻撃が 可能である。 このような攻撃を防ぐために、application/sdp形式のシグナリングパケット でSDPを使用するときに、実装および適用が必要な技術的な方法は、S/MIME [RFC3369]を使用したエンドツーエンドの整合性である。これは、SIP [RFC3261]と互換性がある。 6. IANA条項 本書では、新しいSDPパラメータとして属性フィールド「rtcp」を定義する。 これは、[RFC2327]を通じてIANAで登録されている。この属性フィールドは、 メディアレベルのみで使用するように設計されている。 Huitema Standards Track [Page 5] RFC 3605 RTCP attribute in SDP October 2003 7. 知的所有権表記 IETFは、知的所有権、あるいは本文書に記載される他の技術の実装または使用 に関して主張される可能性のある他のいかなる権利についても、有効期間また は範囲に関して、あるいはこのような権利下でどのようなライセンスの範囲ま でが利用可能か否かに関して、何ら見解を持たない。また、このような権利を 特定しようともしていない。標準化過程および標準化関連の文書における権利 についてIETFの手続き上の情報は、BCP-11を参照すること。こうした所有権に ついて、本仕様の実装者あるいはユーザーが公開のために利用可能とされた権 利請求のコピー、および、利用可能とされたライセンスの保証、あるいは、一 般的なライセンスまたは許可を取得しようと試みた結果は、IETF事務局から入 手できる。 IETFは、この規格を実行するために必要とされる技術の範囲にある可能性があ る、すべての著作権、特許または特許アプリケーション、あるいは他の所有権 について、すべての関連団体に対して配慮するよう依頼している。これらの情 報については、IETFの事務局長への連絡を請う。 8. 謝辞 「rtcp」属性を使用するという元の概念は、Ann Demirtjisによって開発され た。本書は、IETFのMMUSICとAVTの各ワーキンググループでレビューされた。 9. 参考文献 9.1. 規範となる参考文献 [RFC1889] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson. "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. Huitema Standards Track [Page 6] RFC 3605 RTCP attribute in SDP October 2003 [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, March 2003. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson. "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003. 9.2. 有益な参考文献 [RFC2766] Tsirtsis, G. and P. Srisuresh. "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [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. [RFC3369] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, August 2002. [RFC3424] Daigle, L., "IAB considerations for UNilateral Self- Address Fixing (UNSAF) across network address translation", RFC 3424, November 2002. 10. 著者の連絡先 Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 EMail: huitema@microsoft.com Huitema Standards Track [Page 7] RFC 3605 RTCP attribute in SDP October 2003 11. 完全な著作権表示 Copyright (C) The Internet Society (2003).All Rights Reserved. 本記述とその翻訳はコピーし他に提供することができる。また論評を加えた派 生的製品や、この文書を説明したり、その実装を補助するもので、上記の著作 権表示およびこの節を付加するものはすべて、全体であってもその一部であっ ても、いっさいの制約を課されること無く、準備、複製、発表、配布すること ができる。しかし、この文書自体にはいかなる方法にせよ、著作権表示やイン ターネット協会もしくは他のインターネット関連団体への参照を取り除くなど の変更を加えてはならない。インターネット標準を開発するために必要な場 合は例外とされるが、その場合はインターネット標準化過程で定義されている 著作権のための手続きに従わなければならない。またRFCを英語以外の言語に 翻訳する必要がある場合も例外である。 以上に述べられた制限は永久的なものであり、インターネット協会もしくはそ の継承者および譲渡者によって破棄されることはない。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、インターネッ ト協会およびIETFは、この情報がいかなる権利も侵害していないという保証、 商用利用および特定目的への適合性への保証を含め、また、これらだけに限ら ずすべての保証について、明示的もしくは暗黙的の保証は行われない。 謝辞 RFC編集職務のための資金は、現在、インターネット協会によって提供されて いる。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2005年 ----------------------------------------------------------------------- Huitema Standards Track [Page 8]