Network Working Group G. Camarillo Request for Comments: 4583 Ericsson Category: Standards Track November 2006 バイナリフロア制御プロトコル(BFCP)ストリームのための セッション記述プロトコル(SDP)形式 Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準化過 程プロトコルを規定し、改善のための議論や提案を依頼するものである。標 準化の段階や、プロトコルの位置付けについては、最新版の"Internet Official Protocol Standards" (STD 1)を参照されたい。この文書の配信は 無制限である。 著作権表記 Copyright (C) The IETF Trust (2006). 概要 本文書は、セッション記述プロトコル(Session Description Protocol/SDP) の記述におけるバイナリフロア制御プロトコル(Binary Floor Control Protocol/BFCP)ストリームの記載方法について規定する。オファー/アンサー モデルを使用してBFCPストリームを確立するユーザーエージェントは、 オファーとアンサーにこの形式を使用する。 目次 1. はじめに ...................................................... 2 2. 用語 .......................................................... 2 3. 「m」行のフィールド ............................................ 2 4. フロア制御サーバーの決定 ...................................... 3 5. 「confid」と「userid」のSDP属性 ................................ 5 6. ストリームとフロアの関連性 .................................... 5 7. TCP接続の管理 .................................................. 5 8. 認証 .......................................................... 6 9. 例 ............................................................ 7 10. セキュリティの考慮事項 ........................................ 8 11. IANA条項 ...................................................... 8 11.1. 「TCP/BFCP」と「TCP/TLS/BFCP」SDPの 「proto」値の登録 ........................................ 8 11.2. SDP「floorctrl」属性の登録 .............................. 8 11.3. SDP「confid」属性の登録 .................................. 9 11.4. SDP「userid」属性の登録 .................................. 9 11.5. SDP「floorid」属性の登録 ............................... 10 12. 謝辞 ......................................................... 10 13. 規範となる参考文献 ........................................... 10 Camarillo Standards Track [Page 1] RFC 4583 SDP Format for BFCP Streams November 2006 1. はじめに BFCP(バイナリフロア制御プロトコル/Binary Floor Control Protocol)仕様 [8]に記載されているように、特定のBFCPクライアントは、フロア制御サー バーに対してBFCP接続を確立するには、データ群を必要とする。このデータ には、サーバーのトランスポートアドレス、カンファレンス識別子、ユー ザー識別子が含まれる。 クライアントがこの情報を取得する方法の1つは、オファー/アンサー[4]交換 を使用する方法である。本文書は、こうしたオファー/アンサー交換の一部で あるSDPセッション記述に含まれるこの情報を、エンコードする方法について 規定する。 通常、ユーザーエージェントはオファー/アンサーモデルを使用して、異なる 種類の複数のメディアストリームを確立する。このモデルに従って、BFCP接 続は、その他のメディアストリームと同様に、SDPの「m」行を使用して記述 される。このとき、おそらく「a」行でエンコードされる複数の属性が続く。 2. 用語 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONAL」はRFC2119 のBCP 14 [1]に記載されるとおりに解釈されるべきであり、CPL準拠の実装 のための実装レベルを示すものである。 3. 「m」行のフィールド このセクションでは、BFCPストリームについて「m」行を生成する方法を説 明する。 SDP仕様[11]に従い、「m」行の形式は次のとおりである。 m= ... mediaフィールドには「application」の値を指定しなければならない[MUST]。 portフィールドは、[7]の規則に従って設定される。「setup」属性(セクショ ン7参照)の値に応じて、portフィールドには、リモートエンドポイントがTCP 接続を開始するポート番号を含むか、あるいは関係なく(つまり、エンドポイ ントがリモートエンドポイントに対する接続を開始する)、9(破棄ポートを 示す)の値に設定される。BFCPのみがTCPより上位で実行されるため、ポート は常にTCPポートである。ゼロのポートフィールド値には、標準のSDPの意味 がある(つまり、メディアストリームの拒否)。 Camarillo Standards Track [Page 2] RFC 4583 SDP Format for BFCP Streams November 2006 transportフィールドについては、TCP/BFCPとTCP/TLS/BFCPという2つの新し い値を定義する。前者はBFCPをTCPの真上で実行するときに使用され、後者 はBFCPをTLSより上位(つまり、TCPより上位)で実行されるときに使用され る。 BFCPの場合、fmt (format)リストは無視される。BFCPの「m」行のfmtリスト には、1つの「*」文字を含めるべきである[SHOULD]。 次の例は、BFCP接続の「m」行である。 m=application 50000 TCP/TLS/BFCP * 4. フロア制御サーバーの決定 2つのエンドポイントがBFCPストリームを確立する場合、両者はフロア制御 サーバーとして動作する側を決定する必要がある。最も一般的なシナリオ では、クライアントが、フロア制御サーバーとして動作するカンファレン スサーバーと、BFCPストリームを確立する。一方のエンドポイントはクライ アントとしてのみ動作し、他方はフロア制御サーバーとしてのみ動作する ため、フロア制御サーバーの決定は単純である。 ただし、両方のエンドポイントがフロア制御サーバーとして動作するシナリ オもある。たとえば、音声ストリームと共有のホワイトボードを使用する 2パーティのセッションでは、フロア制御サーバーとして動作するパー ティを、エンドポイントが決定する必要がある。 さらに、オファー側とアンサー側の両方が、同じセッションでクライアント とフロア制御サーバーの両方として動作する状況がある。たとえば、音声ス トリームと共有のホワイトボードを使用する2パーティのセッショでは、一 方が音声ストリームのフロア制御サーバーとして動作し、他方が共有のホワ イトボードのフロア制御サーバーとして動作する。 本文書では、フロア制御の決定を実行するための「floorctrl」SDPメディア レベル属性を定義する。このAugmented BNF構文[2]は以下の通り。 floor-control-attribute = "a=floorctrl:" role *(SP role) role = "c-only" / "s-only" / "c-s" オファー側は、この属性を含めて、実行する意志があるすべての役割を表明 する。 c-only: オファー側は、フロア制御クライアントとしてのみ動作する意志 がある。 s-only: オファー側は、フロア制御サーバーとしてのみ動作する意志が ある。 Camarillo Standards Track [Page 3] RFC 4583 SDP Format for BFCP Streams November 2006 c-s: オファー側は、フロア制御クライアントとフロア制御サーバーの両方 として動作する意志がある。 オファーの「m」行に「floorctrl」属性が含まれる場合、アンサー側は対応 する「m」行のいずれかをアンサーに含めなければならない[MUST]。アン サー側は、この属性を含めて、アンサー側が実行する役割を表明する。つま り、アンサー側は、オファー側が実行する意志がある役割のいずれかを1つ を選択し、アンサー側の対応する役割を指定したアンサーを生成する。表1 に、オファー側の役割に対応する、アンサー側の役割を示す。 +------------+------------+ | オファー側 | アンサー側 | +------------+------------+ | c-only | s-only | | s-only | c-only | | c-s | c-s | +------------+------------+ 表1: 役割 アンサー側が選択する場合の役割の説明を次に示す。 c-only: アンサー側はフロア制御クライアントとして動作する。 結果的に、オファー側はフロア制御サーバーとして動作する。 s-only: アンサー側はフロア制御サーバーとして動作する。 結果的に、オファー側はフロア制御クライアントとして動作する。 c-s: アンサー側は、フロア制御クライアントとフロア制御サーバーの両方 として動作する。結果的に、オファー側も、フロア制御クライアントと フロア制御サーバーの両方として動作する。 オファー/アンサーモデルを使用してBFCP接続を確立するエンドポイントは、 「floorctrl」属性に対応しなければならない[MUST]。オファー側またはア ンサー側として動作するフロア制御サーバーは、セッション記述にこの属性 を含めるべきである[SHOULD]。 「floorctrl」属性がオファー/アンサー交換に使用されない場合、デフォル トで、オファー側とアンサー側は、それぞれフロア制御クライアントとフロ ア制御サーバーとして動作する。 次に、オファーの「floorctrl」属性の例を示す。 この属性がアンサーに出現するときは、1つの役割のみを伝達する。 a=floorctrl:c-only s-only c-s Camarillo Standards Track [Page 4] RFC 4583 SDP Format for BFCP Streams November 2006 5. 「confid」と「userid」のSDP属性 本文書では、「confid」と「userid」というSDPのメディアレベル属性を定 義する。これらの属性は、フロア制御サーバーがクライアントにカンファレ ンスIDとユーザーIDをそれぞれ提供するときに使用する。このAugmented BNF構文[2]は以下の通り。 confid-attribute = "a=confid:" conference-id conference-id = token userid-attribute = "a=userid:" user-id user-id = token 「confid」属性と「userid」属性は、それぞれカンファレンスIDとユーザー IDの整数表記を伝達する。 オファー/アンサーモデルを使用してBFCP接続を確立するエンドポイントは、 「confid」属性と「userid」属性に対応しなければならない[MUST]。 オファー側またはアンサー側として動作するフロア制御サーバーは、セッ ション記述にこの属性を含めるべきである[SHOULD]。 6. ストリームとフロアの関連性 本文書では、「floorid」というSDPのメディアレベル属性を定義する。この Augmented BNF構文[2]は以下の通り。 floor-id-attribute = "a=floorid:" token [" mstrm:" token *(SP token)] 「floorid」属性はBFCPの「m」行に使用される。この属性はフロア識別子を 定義する。また、おそらく1つ以上のメディアストリームと関連付けられる。 フロアIDを示すトークンは、BFCPに使用されるフロアIDの整数表記である。 メディアストリームを示すトークンは、メディアストリームを指すポインタ である。これは、SDPのlabel属性[9]で識別される。 オファー/アンサーモデルを使用してBFCP接続を確立するエンドポイントは、 「floorid」属性と「label」属性に対応しなければならない[MUST]。 オファー側またはアンサー側として動作するフロア制御サーバーは、セッ ション記述にこの属性を含めるべきである[SHOULD]。 7. TCP接続の管理 BFCPの送信に使用されるTCP接続の管理は、「setup」属性と「connection」 属性を使用して実行される([7]の定義を参照)。 Camarillo Standards Track [Page 5] RFC 4583 SDP Format for BFCP Streams November 2006 「setup」属性は、TCP接続を開始するエンドポイント(クライアントまたは フロア制御サーバー)を示す。「connection」属性は、TCP接続の再確立を処 理する。 BFCPの仕様[8]には、クライアントとフロア制御サーバー間のTCP接続を再確 立する必要がある状況が多数記載されている。ただし、再確立処理は、最初 の段階で接続を確立した方法によって変わるため、この仕様には再確立処理 について記載していない。オファー/アンサーモデルを使用するBFCPエン ティティは、以下の規則に従う。 [8]の規則に従って、既存のTCP接続が再設定されるとき、クライアントは、 接続を再確立するために、フロア制御サーバーに対してオファーを生成すべ きである[SHOULD]。TCP接続ではBFCPメッセージとタイムアウトを配信でき ない場合、メッセージ(つまり、TCPのタイムアウトを検出したというメッ セージ)の送信を試みるエンティティは、TCP接続を再確立するために オファーを生成すべきである[SHOULD]。 オファー/アンサーモデルを使用してBFCP接続を確立するエンドポイント は、「setup」属性と「connection」属性に対応しなければならない[MUST]。 8. 認証 オファーモデルを使用してBFCP接続が確立されるとき、オファー側とアン サー側は何らかのメカニズムを使用して相互に認証し合う。この相互認証が 実行された後、すべてのオファー側とアンサー側は、BFCPメッセージの送信 元エンティティが、前のオファーまたはアンサーを生成したエンティティと 同じであることを保証する必要がある。 オファー/アンサー交換にSIPを使用する場合、最初の相互認証はSIPレベル で実行される。さらに、SIPはS/MIME [6]を使用して、オファー/アンサー交 換のために、完全性が保護されたチャネルと、オプションで機密性を提供 する。BFCPはこの完全性が保護されたオファー/アンサー交換を使用し、認 証を実行する。オファー/アンサー交換内で、オファー側とアンサー側は、 自己署名証明書(self-signed certificate)のフィンガープリントを交換 する。この自己署名証明書は、オファー側とアンサー側間のBFCPトラフィッ クを伝送するTLS接続の確立に使用される。 BFCPクライアントとフロア制御サーバーは、証明書の選択と提示に関して [10]の規則に従う。つまり、セッション記述に「fingerprint」属性が含ま れない限り、TLSレベルで提供された証明書は、相手側の信頼点(trust anchor)のいずれかによって直接署名されるか、相手側の信頼点のいずれか で終端する証明書パスを使用して検証されなければならない[MUST]。 オファー/アンサーモデルを使用してBFCP接続を確立するエンドポイントは、 Camarillo Standards Track [Page 6] RFC 4583 SDP Format for BFCP Streams November 2006 「fingerprint」属性に対応しなければならない[MUST]。またセッション記 述にその属性を含めるべきである[SHOULD]。 TLSが使用される場合、基礎となるTCP接続が確立されると、TCP確立手順の 役割(パッシブまたはアクティブ)に関係なく、アンサー側はTLSサーバーと して動作する。 9. 例 簡潔にするために、セッション記述のメイン部分は例では省略し、「m」行 とその属性のみを示す。 次に、カンファレンスサーバーからクライアントに対して送信される オファーの例を示す。 m=application 50000 TCP/TLS/BFCP * a=setup:passive a=connection:new a=fingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB a=floorctrl:s-only a=confid:4321 a=userid:1234 a=floorid:1 m-stream:10 a=floorid:2 m-stream:11 m=audio 50002 RTP/AVP 0 a=label:10 m=video 50004 RTP/AVP 31 a=label:11 RFCの書式規約があるため、本文書では1行が72文字を超えるSDPを複数行に 分割している。バックスラッシュ文字は、このような改行が入れられた場所 の印である。このバックスラッシュとそれに続くCRLFと空白は、実際のSDP コンテンツには出現しない。 次に、クライアントから返されるアンサーを示す。 m=application 9 TCP/TLS/BFCP * a=setup:active a=connection:new a=fingerprint:SHA-1 \ 3D:B4:7B:E3:CC:FC:0D:1B:5D:31:33:9E:48:9B:67:FE:68:40:E8:21 a=floorctrl:c-only m=audio 55000 RTP/AVP 0 m=video 55002 RTP/AVP 31 Camarillo Standards Track [Page 7] RFC 4583 SDP Format for BFCP Streams November 2006 10. セキュリティの考慮事項 BFCP [8]、SDP [11]、オファー/アンサー[4]の各仕様では、それぞれBFCP、 SDP、オファー/アンサーに関するセキュリティ問題について論じている。 さらに、[7]と[10]では、オファー/アンサーモデルを使用してTCP接続とTLS 接続を確立する場合に関するセキュリティ問題について論じている。 BFCPでは、最初の完全性が保護されたチャネルを使用して、クライアントと フロア制御サーバー間で自己署名証明書を交換すると想定している。SIP [3] で伝送されるセッション記述については、こうしたチャネルを実現するため の通常の選択はS/MIME [6]である。 11. IANA条項 11.1. 「TCP/BFCP」と「TCP/TLS/BFCP」SDPの「proto」値の登録 IANAは、「Session Description Protocol (SDP) Parameters」登録のSDP 「proto」フィールドについて、以下の2つの新しい値を登録した。 +--------------+-----------+ | 値 | 参考文献 | +--------------+-----------+ | TCP/BFCP | RFC4583 | | TCP/TLS/BFCP | RFC4583 | +--------------+-----------+ 表2: SDP「proto」フィールドの値 11.2. SDP「floorctrl」属性の登録 IANAは、「Session Description Protocol (SDP) Parameters」登録に以下 のSDP属性フィールドを登録した。 連絡先: Gonzalo.Camarillo@ericsson.com 属性名: floorctrl 長い形式の属性名: Floor Control 属性の種類: メディアレベル 文字セットの制約: なし 属性の目的: 「floorctrl」属性は、フロア制御サーバーの決定に使用さ れる。 Camarillo Standards Track [Page 8] RFC 4583 SDP Format for BFCP Streams November 2006 使用できる属性値: 1*("c-only" / "s-only" / "c-s") 11.3. SDP「confid」属性の登録 IANAは、「Session Description Protocol (SDP) Parameters」登録に以下 のSDP属性フィールドを登録した。 連絡先: Gonzalo.Camarillo@ericsson.com 属性名: confid 長い形式の属性名: Conference Identifier 属性の種類: メディアレベル 文字セットの制約: なし 属性の目的: 「confid」はカンファレンスIDの整数表記を伝達する。 使用できる属性値: トークン 11.4. SDP「userid」属性の登録 このセクションでは、IANAに対して、「Session Description Protocol (SDP) Parameters」登録に以下のSDP属性フィールドを登録することを指示 する。 連絡先: Gonzalo.Camarillo@ericsson.com 属性名: userid 長い形式の属性名: User Identifier 属性の種類: メディアレベル 文字セットの制約: なし 属性の目的: 「userid」はユーザーIDの整数表記を伝達する。 使用できる属性値: トークン Camarillo Standards Track [Page 9] RFC 4583 SDP Format for BFCP Streams November 2006 11.5. SDP「floorid」属性の登録 このセクションでは、IANAに対して、「Session Description Protocol (SDP) Parameters」登録に以下のSDP属性フィールドを登録することを指示 する。 連絡先: Gonzalo.Camarillo@ericsson.com 属性名: floorid 長い形式の属性名: Floor Identifier 属性の種類: メディアレベル 文字セットの制約: なし 属性の目的: 「floorid」属性はフロアを1つ以上のメディアストリームと 関連付ける。 使用できる属性値: トークン 12. 謝辞 Joerg Ott、Keith Drage、Alan Johnston、Eric Rescorla、Roni Even、 Oscar Novoの各氏は、本文書に有益なアイデアを提供してくださった。 13. 規範となる参考文献 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [3] 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. [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [6] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004. Camarillo Standards Track [Page 10] RFC 4583 SDP Format for BFCP Streams November 2006 [7] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005. [8] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006. [9] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, July 2006. [10] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006. [11] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. 著者の連絡先 Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: Gonzalo.Camarillo@ericsson.com Camarillo Standards Track [Page 11] RFC 4583 SDP Format for BFCP Streams November 2006 完全な著作権表記 Copyright (C) The IETF Trust (2006). 本文書は、BCP 78に含まれる権利、ライセンス、制限の対象となり、BCP 78 に記載されている例外に従い、著者はすべての権利を持つ。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄 稿者が代表となる組織、または寄稿者を後援する組織(存在する場合)、イン ターネット協会、IETF TSUST、およびIETFは、この情報がいかなる権利も侵 害していないという保証、商用利用および特定目的への適合性への保証を含 め、また、これらだけに限らずすべての保証について、明示的もしくは暗黙 的の保証は行われない。 知的所有権 IETFは、本文書で記述される技術の実装または使用に関して要求される、知 的所有権または他の諸権利の有効性または範囲に関して、またはこのような 権利下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何 ら見解を持たない。このような権利を確認する独自の取り組みを行ったこと も示さない。RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79 に記載されている。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセ ンスの保証すべて、またはこのような所有権の使用に関して、本仕様の実装 者またはユーザーが一般的なライセンスまたは許可の取得を試みた結果につ いては、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能 である。 IETFは、この規格を実装するために必要とされる技術の範囲にある可能性が ある、すべての著作権、特許または特許アプリケーション、あるいは他の所 有権について、すべての関連団体に対して配慮するよう依頼している。情報 については、IETFの ietf-ipr@ietf.org まで連絡されたい。 謝辞 RFC編集職務のための資金は、現在、インターネット協会によって提供され ている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2007年 ----------------------------------------------------------------------- Camarillo Standards Track [Page 12]