Network Working Group G. Camarillo Request for Comments: 5366 Ericsson Category: Standards Track A. Johnston Avaya October 2008 セッション開始プロトコル(SIP)のリクエストに含まれるリストを使用したカンファレ ンス確立 本文書の位置付け 本文書は、インターネットコミュニティのためのインターネット標準化過程プロトコル を規定し、改善のための議論や提案を依頼するものである。標準化の段階や、プロトコ ルの位置付けについては、最新版の"Internet Official Protocol Standards" (STD 1) を参照されたい。本文書の配信は無制限である。 概要 本文書は、SIP URIリストサービスを使用してカンファレンスを作成する方法について 説明する。特に、ユーザーエージェントクライアントが、INVITEに含まれるURIリスト を使用して、参加者の初期リストをカンファレンスサーバーに提供できるメカニズムに ついて説明する。 目次 1. はじめに ...................................................... 2 2. 用語 .......................................................... 2 3. ユーザーエージェントクライアントの手順 ........................ 2 3.1. 応答の処理 ................................................ 2 3.2. re-INVITEリクエストの生成 ................................ 3 4. URIリストドキュメント形式 ...................................... 3 5. カンファレンスサーバーの手順 .................................. 5 5.1. re-INVITEリクエストの処理 ................................ 6 6. 例 ............................................................ 6 7. セキュリティの考慮事項 ....................................... 10 8. IANA条項 ..................................................... 10 9. 謝辞 ......................................................... 11 10. 参考文献 ..................................................... 11 10.1. 規範となる参考文献 ..................................... 11 10.2. 有益な参考文献 ......................................... 12 Camarillo & Johnston Standards Track [Page 1] RFC 5366 INVITE-Contained Lists October 2008 1. はじめに [RFC4579]のセクション5.4では、アドホックSIP [RFC3261]メソッドを使用 してカンファレンスを作成する方法について説明している。クライアント は、カンファレンスファクトリURIにINVITEリクエストを送信し、"isfocus "フィーチャータグを含む実際のカンファレンスURIを応答(通常、200 (OK) 応答)のContactヘッダーフィールドで受信する。 UAC (User Agent Client)はカンファレンスURIを受信した場合、新しく作 成したカンファレンスにいくつかの方法で参加者を追加することができる。 その方法については[RFC4579]を参照のこと。 環境によっては、カンファレンスの確立時間について厳しい要件がある。 この場合、UACはアドホックカンファレンスの作成を要求し、一度の操作で カンファレンスサーバーに参加者の初期セットを提供することができる。 本文書では、[RFC5363]に記載されているSIPメッセージでURIリストを送信 するメカニズムを使用して、この要件を満たす方法について説明する。 2. 用語 本書中のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、 「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、 「OPTIONAL」は、[RFC2119]で記述されている通りに解釈される。 3. ユーザーエージェントクライアントの手順 初期参加者のセットを最初のINVITEリクエストに含めてアドホックカン ファレンスを作成したいUACは、UACがカンファレンスサーバーに招待させ たい参加者を含むURIリストが指定され、ディスポジションタイプが 'recipient-list' ([RFC5363]で定義)のボディを追加する。さらに、UACは Requireヘッダーフィールドに'recipient-list-invite'オプションタグ(セ クション8でIANAに登録されている)を含めなければならない[MUST]。UACは このINVITEリクエストをカンファレンスファクトリURIに送信する。 INVITEトランザクションは、UACとカンファレンスサーバー間にセッション を確立するオファー/アンサー交換の一部でもある([RFC4579]で規定)。し たがって、場合によっては、INVITEリクエストでセキュリティ記述とURIリ ストというマルチパートボディを伝達する必要がある。 3.1. 応答の処理 INVITEリクエストに対する応答のステータスコードは、カンファレンス サーバーがURIリストのユーザーをカンファレンスに参加させることができ たかどうかについて何も情報を提供しない。 つまり、200 (OK)応答は、カンファレンスの作成が成功したこと、INVITE リクエストを生成したUACがカンファレンスに参加していること、および Camarillo & Johnston Standards Track [Page 2] RFC 5366 INVITE-Contained Lists October 2008 サーバーがURIリストを理解したことを意味している。UACがカンファレン スに参加する他のユーザーのステータスに関する情報を取得したい場合、 汎用的なカンファレンスメカニズムを使用すべきである[SHOULD]。たとえ ば、[RFC4575]に定義されているカンファレンスパッケージなどである。 3.2. re-INVITEリクエストの生成 前述の各セクションでは、カンファレンスサーバーに対する最初のINVITE リクエストにURIリストを含める方法について規定した。INVITEによって開 始されたUACとカンファレンスサーバー間のダイアログが確立すると、UAC は後続のINVITEリクエスト(一般的に、re-INVITEリクエストと呼ばれる)を カンファレンスサーバーに対して送信して、たとえばサーバーと交換する メディアの特性を変更することなどができる。 現時点で、re-INVITEリクエストの'recipient-list'ボディに関連するセマ ンティクスはない(ただし、将来的な拡張で定義される可能性はある)。し たがって、UACはカンファレンスサーバーに送信するre-INVITEリクエスト に'recipient-list'ボディを含めるべきではない[SHOULD NOT]。 最初のINVITEリクエストとre-INVITEリクエストの違いは、最初の INVITEリクエストはカンファレンスファクトリURIに送信されるが、 re-INVITEリクエストは、ダイアログの確立時にContactヘッダーフィー ルドでサーバーが提示したURIに送信される点である。したがって、UAC の観点からすると、前者のURIによって識別されるリソースは 'recipient-list'ボディをサポートするが、後者のURIで識別されるリ ソースはサポートしない。 4. URIリストドキュメント形式 [RFC5363]に記載されているように、各URIリストサービスの仕様では、本 文書に記載されているカンファレンスサービスと同様に、特定のサービス 内で使用する'recipient-list'ボディのデフォルト形式を指定する必要が ある。 カンファレンスUA (User Agents)の'recipient-list'ボディのデフォルト 形式は、「Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists」[RFC5364]で 拡張したXMLリソースリスト形式([RFC4826]で規定)である。したがって、 'recipient-list'ボディを生成するカンファレンスUACは、これら両方の形 式をサポートしなければならない[MUST]。また、他の形式をサポートして もよい[MAY]。'recipient-list'ボディを処理する機能を持つカンファレン スサーバーは、これら両方の形式をサポートしなければならない[MUST]。 また、他の形式をサポートしてもよい[MAY]。 「Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists」[RFC5364]に 記載されているように、"to"、"cc"、または"bcc"に設定した 'copyControl'属性を使用して、各URIにタグを付けることができる。これ Camarillo & Johnston Standards Track [Page 3] RFC 5366 INVITE-Contained Lists October 2008 は、受信者がINVITEリクエストを取得する際の役割を示す。さらに、URIに 'anonymize'属性でタグを付けることで、カンファレンスサーバーがURIリ ストのターゲットURIを公開することを防ぐことができる。 さらに、Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists」[RFC5364]で は、受信者リストを含む'recipient-list-history'ボディを定義している。 また、カンファレンスUA (User Agents)の'recipient-list-history'ボ ディのデフォルト形式も、「Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists」[RFC5364]で拡張したXMLリソースリスト形式([RFC4826]で規定)で ある。したがって、'recipient-list-history'ボディを生成する機能を持 つカンファレンスUACは、これら両方の形式をサポートしなければならない [MUST]。また、他の形式をサポートしてもよい[MAY]。 'recipient-list-history'ボディを理解する機能を持つカンファレンスUA は、これら両方の形式をサポートしなければならない[MUST]。また、他の 形式をサポートしてもよい[MAY]。'recipient-list-history'ボディを処理 する機能を持つカンファレンスサーバーは、これら両方の形式をサポート しなければならない[MUST]。また、他の形式をサポートしてもよい[MAY]。 ただし、[RFC4826]に規定されているXMLリソースリストドキュメントには、 階層的リストや、XML Configuration Access Protocol (XCAP)ルートURIに 対する相対参照によってエントリを含める機能などが用意されている。こ れらの機能は本文書で定義しているカンファレンスサービスには不要であ る。カンファレンスサービスでは、UA (User Agent)とカンファレンスサー バー間で単一階層のURIリストを転送する必要しかないためである。 したがって、デフォルトのリソースリストドキュメントを使用する場合、 カンファレンスUAは単一階層のリスト(つまり非階層的リスト)を使用すべ きである[SHOULD]。また、要素を使用すべきではない[SHOULD NOT]カンファレンスファクトリアプリケーションは、ここで説明した以外 の情報を含むURIリストを受信した場合、その余計な情報をすべて破棄して もよい[MAY]。 図1は、「Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists」[RFC5364]で 拡張したXMLリソースリストドキュメント([RFC4826]で規定)に従う単一階 層リストの一例である。 図1: URIリスト Camarillo & Johnston Standards Track [Page 4] RFC 5366 INVITE-Contained Lists October 2008 5. カンファレンスサーバーの手順 'recipient-list'ボディを含むINVITEリクエストを受信および処理する機 能を持つカンファレンスサーバーは、OPTIONSリクエストに応答する際に Supportedヘッダーフィールドへ'recipient-list-invite'オプションタグ を含めるべきである[SHOULD]。 'recipient-list'ボディを含むINVITEリクエストを受信した場合(セクショ ン3参照)、カンファレンスサーバーは[RFC4579]に記載されている規則に従 い、アドホックカンファレンスを作成しなければならない[MUST]。アド ホックカンファレンスが作成された場合、カンファレンスサーバーは、 [RFC4579]に記載されているいずれかの方法を使用して追加が要求された場 合と同様に、URIリスト内の参加者をカンファレンスに追加することを試み るべきである[SHOULD]。 INVITEトランザクションは、UACとカンファレンスサーバー間にセッション を確立するオファー/アンサー交換の一部でもある([RFC4579]で規定)。し たがって、場合によっては、INVITEリクエストでセキュリティ記述とURIリ ストというマルチパートボディを伝達することがある。 カンファレンスサーバーがアドホックカンファレンスを作成し、初期参加 者セットの追加を試みる場合、カンファレンスサーバーは通常のカンファ レンスとして動作する。また、[RFC4579]の規則に従わなければならない [MUST]。 受信INVITEリクエストには、URIリストボディと参照([RFC5363]で規定)と、 実際の受信者リストが含まれる。このURIリストに、"to"または"cc"の値に 設定した'copyControl'属性でタグを付けられたリソースが含まれる場合、 カンファレンスサーバーは、各送信INVITEリクエストにURIリストを含める べきである[SHOULD]。 このリストは、リソースリストドキュメント形式([RFC4826]で規定)、およ びcopyControl拡張([RFC5364]で規定)を表現するXML形式に従って書式を設 定すべきである[SHOULD]。 URIリストサービスは、'anonymize'、'count'、および'copyControl'の各 属性の処理に関して、[RFC5364]に規定されている手順に従わなければなら ない[MUST]。 カンファレンスサーバーが送信INVITEリクエストにURIリストを含める場合、 値を'recipient-list-history'に設定したContent-Dispositionヘッダー フィールド([RFC2183]で規定)を含め、さらに"optional"に設定した 'handling'パラメータ([RFC3204]で規定)を含めなければならない[MUST]。 Camarillo & Johnston Standards Track [Page 5] RFC 5366 INVITE-Contained Lists October 2008 5.1. re-INVITEリクエストの処理 この時点で、re-INVITEリクエストの'recipient-list'ボディに関連するセ マンティクスはない(ただし、将来的な拡張で定義される可能性がある)。 したがって、カンファレンスサーバーは、'recipient-list'ボディを含む re-INVITEリクエスト、その結果として'recipient-list-invite'オプショ ンタグを受信した場合、標準のSIP手順に従い、420 (Bad Extension)で拒 否する。このre-INVITEリクエストは、'recipient-list-invite'オプショ ンタグを指定したサポート対象外のヘッダーフィールドを伝達しているた めである。 この理由は、カンファレンスURIによって識別されるリソースが、実際 にはこの拡張をサポートしていないためである。一方、カンファレンス ファクトリURIによって識別されるリソースは、この拡張をサポートし ていない。その結果、たとえばOPTIONSリクエストに対する応答に 'recipient-list-invite'オプションタグを含める。 6. 例 図2は操作例である。UACは、SDPボディとURIリストを含むINVITEリクエス トをカンファレンスサーバーに送信する。カンファレンスサーバーは200 (OK)で応答し、そのURIリストに含まれるURIで識別される各UAS (User Agent Server)に対してINVITEリクエストを生成する。カンファレンスサー バーはSDPと操作したURIリストを書く送信INVITEリクエストに含める。 Camarillo & Johnston Standards Track [Page 6] RFC 5366 INVITE-Contained Lists October 2008 +--------+ +---------+ +--------+ +--------+ +--------+ |SIP UAC | | confer. | |SIP UAS | |SIP UAS | |SIP UAS | | | | server | | 1 | | 2 | | n | +--------+ +---------+ +--------+ +--------+ +--------+ | | | | | | F1 INVITE | | | | | ---------------->| | | | | F2 200 OK | | | | |<---------------- | F3 INVITE | | | | | ------------->| | | | | F4 INVITE | | | | | ------------------------>| | | | F5 INVITE | | | | | ----------------------------------->| | | F6 200 OK | | | | |<------------- | | | | | F7 200 OK | | | | |<------------------------ | | | | F8 200 OK | | | | |<----------------------------------- | | | | | | | | | | | | | | | | 図2: 操作例 図3は、INVITEリクエストF1の一例である。このINVITEリクエストには、異 なる2つのボディから構成されるmultipart/mixedボディが含まれる。セッ ションを説明するapplication/sdpボディと、ターゲットURIのリストを含 むapplication/resource-lists+xmlボディである。 INVITE sip:conf-fact@example.com SIP/2.0 Via: SIP/2.0/TCP atlanta.example.com ;branch=z9hG4bKhjhs8ass83 Max-Forwards: 70 To: "Conf Factory" From: Alice ;tag=32331 Call-ID: d432fa84b4c76e66710 CSeq: 1 INVITE Contact: Allow: INVITE, ACK, CANCEL, BYE, REFER Allow-Events: dialog Accept: application/sdp, message/sipfrag Require: recipient-list-invite Content-Type: multipart/mixed;boundary="boundary1" Content-Length: 690 Camarillo & Johnston Standards Track [Page 7] RFC 5366 INVITE-Contained Lists October 2008 --boundary1 Content-Type: application/sdp v=0 o=alice 2890844526 2890842807 IN IP4 atlanta.example.com s=- c=IN IP4 192.0.2.1 t=0 0 m=audio 20000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 20002 RTP/AVP 31 a=rtpmap:31 H261/90000 --boundary1 Content-Type: application/resource-lists+xml Content-Disposition: recipient-list --boundary1-- 図3: カンファレンスサーバーが受信するINVITEリクエスト INVITEリクエストF3、F4、およびF5は性質が似ている。これらすべての INVITEリクエストには、2つの異なるボディから構成された multipart/mixedボディが含まれる。セッションを説明する application/sdpボディと、受信者のリストを含む application/resource-lists+xmlである。 application/resource-lists+xmlボディは、受信したINVITEリクエストF1 に含まれるapplication/resource-lists+xmlとは異なる。その理由は、カ ンファレンスサーバーが'anonymize'属性でタグが付けられたURIを匿名化 し、"bcc" 'copyControl'属性でタグが付けられたURIを削除したためであ る。図4は、メッセージF3の一例である。 Camarillo & Johnston Standards Track [Page 8] RFC 5366 INVITE-Contained Lists October 2008 INVITE sip:bill@example.com SIP/2.0 Via: SIP/2.0/TCP conference.example.com ;branch=z9hG4bKhjhs8as454 Max-Forwards: 70 To: From: Conference Server ;tag=234332 Call-ID: 389sn189dasdf CSeq: 1 INVITE Contact: ;isfocus Allow: INVITE, ACK, CANCEL, BYE, REFER Allow-Events: dialog, conference Accept: application/sdp, message/sipfrag Content-Type: multipart/mixed;boundary="boundary1" Content-Length: 690 --boundary1 Content-Type: application/sdp v=0 o=conf 2890844343 2890844343 IN IP4 conference.example.com s=- c=IN IP4 192.0.2.5 t=0 0 m=audio 40000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 40002 RTP/AVP 31 a=rtpmap:31 H261/90000 --boundary1 Content-Type: application/resource-lists+xml Content-Disposition: recipient-list-history; handling=optional --boundary1-- 図4: カンファレンスサーバーが送信するINVITEリクエスト Camarillo & Johnston Standards Track [Page 9] RFC 5366 INVITE-Contained Lists October 2008 7. セキュリティの考慮事項 本文書は、リクエストに含まれるURIリストを使用したSIPカンファレンス のセットアップについて論じている。カンファレンスサービスとURIリスト サービスにはそれぞれ固有の要件がある。ここではその要件についてまと める。 カンファレンスには、通常、カンファレンスに参加可能/不可能なユーザー、 使用可能/不可能なメディアの種類などに関する認可規則がある。フォーカ スは、この情報を、カンファレンスへの参加を認めたり拒否する際に使用 する。このような種類の認可規則は、SIPカンファレンスのセキュリティ保 護のために使用することが推奨される[RECOMMENDED]。 フォーカスは、使用されるこの認可情報のために、参加する可能性のある ユーザーを認証できる必要がある。ダイジェスト認証と証明書を含め、通 常のSIPの仕組みを使用できる。こうしたカンファレンス独自のセキュリ ティ要件は、要件およびフレームワークの文書([RFC4245]と[RFC4353])で さらに詳しく論じられている。 リストを使用したカンファレンスの作成については、セキュリティに関す る考慮事項が他にもいくつかある。「Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services」[RFC5363]では、SIP URIリストサービスに関する問題が論じら れている。複数のユーザーに対してINVITEリクエストを送信するサーバー が、URIリストサービスとして動作する場合、リストを処理するカンファレ ンスサーバーの実装は、[RFC5363]のセキュリティ関連の規則に従わなけれ ばならない[MUST]。この規則には、クライアントのオプトインリストおよ び必須の認証と認可が含まれる。 8. IANA条項 本文書は'recipient-list-invite'オプションタグを定義する。このオプ ションタグは、SIPパラメータ登録の下位の「Option Tags」に登録された。 以下の表は、登録の記述内容である。 +------------------------+------------------------------+-----------+ | Name | Description | Reference | +------------------------+------------------------------+-----------+ | recipient-list-invite | The body contains a list of | [RFC5366] | | | URIs that indicates the | | | | recipients of the SIP INVITE | | | | request | | +------------------------+------------------------------+-----------+ 表1: SIPの'recipient-list-invite'オプションタグの登録 Camarillo & Johnston Standards Track [Page 10] RFC 5366 INVITE-Contained Lists October 2008 9. 謝辞 Cullen Jennings、Hisham Khartabil、Jonathan Rosenberg、Keith Drage からは、本文書について有益なコメントをいただいた。Miguel Garcia- Martinは'copyControl'属性拡張に依存する部分をまとめてくださった。 10. 参考文献 10.1. 規範となる参考文献 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997. [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG Objects", RFC 3204, December 2001. [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. [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006. [RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007. [RFC5363] Camarillo, G. and A.B. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) URI- List Services", RFC 5363, October 2008. [RFC5364] Garcia-Martin, M. and G. Camarillo, "Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists", RFC 5364, October 2008. Camarillo & Johnston Standards Track [Page 11] RFC 5366 INVITE-Contained Lists October 2008 10.2. 有益な参考文献 [RFC4245] Levin, O. and R. Even, "High-Level Requirements for Tightly Coupled SIP Conferencing", RFC 4245, November 2005. [RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006. [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006. 著者の連絡先 Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: Gonzalo.Camarillo@ericsson.com Alan Johnston Avaya St. Louis, MO 63124 USA EMail: alan@sipstation.com Camarillo & Johnston Standards Track [Page 12] RFC 5366 INVITE-Contained Lists October 2008 完全な著作権表記 Copyright (C) The IETF Trust (2008). 本文書は、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の原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2009年 ----------------------------------------------------------------------- Camarillo & Johnston Standards Track [Page 13]