Network Working Group A. Johnston Request for Comments: 4579 Avaya BCP: 119 O. Levin Category: Best Current Practice Microsoft Corporation August 2006 セッション開始プロトコル(SIP)の 呼制御 - ユーザーエージェントのカンファレンス Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents 本文書の位置付け この文書は、インターネットコミュニティのために、現段階でのインター ネットのベストプラクティス(Internet Best Current Practices)を提示し、 改善のための議論や提案を依頼するものである。本文書の配信は無制限で ある。 著作権表記 Copyright (C) The Internet Society (2006). 概要 本仕様では、セッション開始プロトコル(Session Initiation Protocol/ SIP)のカンファレンスの呼制御(conferencing call control)機能を定義 する。本文書は、カンファレンス要件およびフレームワークの文書に基づい て構成され、密接に結びついたSIPカンファレンスの機能方法について定義 する。さまざまなユーザーエージェント(UA)タイプの観点から手法が検討さ れている。カンファレンスを意識しない(conference-unaware)UA、カンファ レンスを意識する(conference-aware)UA、フォーカス(focus)UAというUAタ イプがある。カンファレンスにおける統合リソース識別子(Uniform Resource Identifiers/URI)の使用、能力検出のためのOPTIONS、REFERを使用する呼制 御の詳細について、コールフロー例の図とともに、説明されている。また、 isfocus機能タグの用法が定義される。 目次 1. はじめに ....................................................... 2 2. 用語 ........................................................... 3 3. SIPユーザーエージェントのカンファレンス能力タイプ ............. 3 3.1. フォーカスUA ............................................. 4 3.2. カンファレンスファクトリURI ............................... 4 3.3. カンファレンスを意識しないUA ............................. 5 3.4. カンファレンスを意識するUA ............................... 5 4. 「isfocus」フィーチャーパラメータの用法 ....................... 6 4.1. 概要 ..................................................... 6 4.2. セッション確立 ........................................... 6 4.3. 検出 ..................................................... 7 5. SIPのカンファレンス原型 ....................................... 7 5.1. INVITE: カンファレンスURIを使用してカンファレンスに 参加- ダイヤルイン ....................................... 7 Johnston & Levin Best Current Practice [Page 1] RFC 4579 SIP CC Conferencing for UAs August 2006 5.2. INVITE: フォーカスによる参加者の追加 - ダイヤルアウト .... 11 5.3. INVITE: カンファレンスアプリケーションへのダイヤル によるカンファレンスの手動作成 .......................... 15 5.4. INVITE: アドホックSIPの手法を使用したカンファレンス作成 .. 16 5.5. REFER: カンファレンスに新しいリソースを追加する フォーカスの要求(新しい参加者へのダイヤルアウト) ........ 18 5.6. REFER: カンファレンスURIを使用してカンファレンスに ダイヤルインするようにユーザーへ要求 .................... 21 5.7. REFERを使用したREFER: カンファレンスにダイヤルインする 参加者をREFERするようにフォーカスへ要求 .................. 23 5.8. Joinヘッダーフィールド: (サードパーティの)ダイアログ 識別子を使用してカンファレンスにダイヤルイン ............ 26 5.9. Replacesヘッダーフィールド: カンファレンス内で ユーザーエージェントの切り替え .......................... 28 5.10. Replacesヘッダーフィールド: ポイントツーポイント セッションからカンファレンスへの転送 .................... 29 5.11. BYEありのREFER: フォーカスへカンファレンスから参加者 を削除するように要求 .................................... 31 5.12. カンファレンスの削除 .................................... 33 5.13. OPTIONSを使用してURIプロパティの検出 .................... 34 6. セキュリティの考慮事項 ........................................ 36 7. 寄稿者 ........................................................ 37 8. 参考文献 ...................................................... 38 8.1. 規範となる参考文献 ...................................... 38 8.2. 有益な参考文献 .......................................... 38 付録A: カンファレンスを意識しないUAによるカンファレンス作成 ...... 40 1. はじめに 本仕様は、高レベルの要件[14]と、SIPのカンファレンスフレームワーク[8] の文書の概念および定義を使用する。このアプローチは、SIPカンファレン スと密接に結び付けられている。このアーキテクチャでは、参加者と呼ばれ るユーザーエージェント(UA)が、フォーカスと呼ばれる別のUAとの間にSIP ダイアログを確立する。フォーカスは制御、認証、認可の中心点である。本 仕様はフォーカスUAと参加者UAの操作について定義する。このモデルではシ グナリング(SIP)にのみ集中する必要があるということに注意。メディアの ミックス、配信、さらにはマルチキャストも中央で行われる可能性がある。 このアーキテクチャの詳細な議論については、SIPカンファレンスフレーム ワーク文書[8]を参照のこと。 本文書に記載される手法では、SIPの原型のみを使用したカンファレンス フレームワークの主な機能を使用する。これによって、SIPの仕組みと条件 を使用した定義済みの機能を持つ、単純なカンファレンスを実行することが できるようになる。別の手段を使用して、他の高度な機能の多くを実装する ことができるが、それは本文書の範囲ではない。 Johnston & Levin Best Current Practice [Page 2] RFC 4579 SIP CC Conferencing for UAs August 2006 本文書は、UAの観点からブロックを構築するカンファレンスの基本的な呼制 御(ダイヤルイン、ダイヤルアウト)の手順を提示する。アドホックカンファ レンス、スケジュールされたカンファレンスなどのアプリケーションが可能 である。 1個のカンファレンスは、異なる能力を持つ参加者間、および異なる方法(ダ イヤルイン、ダイヤルアウト、スケジュール、アドホック)でカンファレン スに参加した可能性がある参加者間の橋渡しができる、ということに注意。 呼制御およびダイアログ操作の手法は、複数パーティのフレームワークの文 書[15]に基づく。この文書では、以下を含め、SIPに適用されるサービス設 計の基本的な手法を定義する。 - サービスではなく、原型を定義 - シグナリングモデルには非依存 - インボーク側指向 - 原型はURIを完全に利用する - 認証、認可、ログなどのポリシーを含む - 基本のSIPの適切な代替システム(fallback)を定義 RFC 3087[11]で論じられているように、不透明なURI(opaque URI)の使用と、 呼制御のコンテキスト情報を(サービス関連のヘッダーフィールドとは反対 に)URIで通信する能力が、この手法の基礎である。 能力検出はSIPシステムの重要な機能であり、カンファレンスシステムは この機能を利用できる。カンファレンスでフォーカスとして動作しているUA 向けに、本仕様では「isfocus」フィーチャーパラメータの用法を定義する。 2. 用語 本文書では、以下のキーワードはRFC 2119 に記述されている通りに解釈さ れるべきであり、準拠する実装に対する要求レベルを示すものである[1]。 「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、 「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」 3. SIPユーザーエージェントのカンファレンス能力タイプ カンファレンスの観点から、フレームワークの文書では、カンファレンスを 意識しない参加者、カンファレンスを意識する参加者、フォーカスなど、考 え得る多様なSIPコンポーネントが概説されている。 本文書では、カンファレンスのコンポーネントのうち、SIP呼制御部分につ いて、上記の概念を適用する。また、様々なカンファレンスの状況(「シナ リオ」として後述)におけるSIP UAの規範的動作を定義する。 Johnston & Levin Best Current Practice [Page 3] RFC 4579 SIP CC Conferencing for UAs August 2006 3.1. フォーカスUA フォーカスは、フレームワークでも定義されているように、SIPカンファレ ンスを主催(host)し、カンファレンスの各参加者とのSIPシグナリング関係 を維持する。フォーカスには、本文書で定義される、カンファレンスの呼制 御仕様に対応した、カンファレンスを意識するユーザーエージェントが含ま れる。 フォーカスは、カンファレンスパッケージのRFC 4575 [5]に対応し、その パッケージのノーティファイアとして動作し、さらにリクエストと応答の Allow-Eventsヘッダーフィールドで対応することを示すべきである [SHOULD]。フォーカスは、通常のSIPシグナリングの一部として送信される セッション記述プロトコル(Session Description Protocol/SDP)ボディに、 セッション情報、URI、電子メールアドレス、電話番号のSDPフィールドを組 み込んで、カンファレンスに関する情報を含めてもよい[MAY]。 2つのエンドポイント間で確立したセッションが中央のカンファレンスに移 行するなど、高度な機能に対応するために、フォーカスはReplaces[6] ヘッダーフィールドに対応すべきである[SHOULD]。 フォーカス能力を持つユーザーエージェントは、エンドユーザーの機器に 実装することもでき、アドホックカンファレンスの作成にも使用される。 専用のカンファレンスサーバー(conferencing server)の主な役割は、任意 の種類およびサイズの複数カンファレンスを同時に主催することだが、SIP 呼制御手法を使用して任意数のアドホックカンファレンス(および、その後 にフォーカスも)を作成する場合に、カンファレンスファクトリURI(次セク ションで定義)を割り当てたり、発行したりすることができる。 3.2. カンファレンスファクトリURI フレームワークによると、カンファレンスを作成するには多くの方法が ある。カンファレンスサーバー実装は、それらの方法から自由に選択するこ とができる。たとえば、自動化されていない手法(双方向音声応答 (Interactive Voice Response/IVR)システムなど)、SIP、任意のカンファレ ンス制御プロトコルなどである。 SIP呼制御の手法を使用して自動的に任意数のアドホックカンファレンス(お よび、その後にフォーカス)を作成するために、グローバルにルート可能な カンファレンスファクトリURI(Conference Factory URI)を割り当て、発行 することができる。 このURIに対する呼の確立が成功した場合、自動的に新規カンファレンスと そのフォーカスが作成される結果になる。結果的に、カンファレンスファク トリURIと新規に作成されたフォーカスのURIは、異なる物理デバイスに解決 されてもよい[MAY]、ということに注意。 カンファレンスファクトリURIの使用に関するシナリオは、セクション5.4に 記載されている。 Johnston & Levin Best Current Practice [Page 4] RFC 4579 SIP CC Conferencing for UAs August 2006 3.3. カンファレンスを意識しないUA 最も単純なユーザーエージェントでも、すべてのSIPカンファレンス関連の 情報を無視して、カンファレンスに参加できる。最も単純なユーザーエー ジェントは、カンファレンスにダイヤルすることができ、またカンファレン スに招待されることもできる。すべてのカンファレンス情報は、SIP以外の 手段を使用して、オプションでやり取りすることができる。このような ユーザーエージェントは、通常、(少なくとも、SIPを明示的に使用せずに) カンファレンスを主催しない。カンファレンスを意識しないUAは、RFC 3261 [2]のみに対応する必要がある。カンファレンスを意識しないUAのコール フローは、本文書では一般論として示されないが、SIPコールフローの文書 [13]に記載されているものと同様である。 Contactヘッダーフィールドに「isfocus」フィーチャータグが存在しても、 フォーカスUAとカンファレンスを意識しないUAとの間に相互運用性の問題は 発生しない、ということに注意。これは、標準のSIP動作に従って、isfocus が未知のヘッダーパラメータとして扱われて無視されるためである。 3.4. カンファレンスを意識するUA カンファレンスを意識するユーザーエージェントは、カンファレンス参加者 として、RFC 3261[2]への対応に加え、本文書で定義されるSIPカンファレン スの呼制御仕様に対応する。カンファレンスを意識するUAは、RFC 3261のセ クション8.1.3.4の説明などに従って、SIPのリダイレクトを処理できるべき である。 カンファレンスを意識するUAは、「isfocus」フィーチャーパラメータを認 識しなければならない[MUST]。カンファレンスを意識するUAは、REFER [4]、 SIPイベント [3]、カンファレンスパッケージ [9]に対応すべきであ る[SHOULD]。 「isfocus」パラメータがダイアログのリモートターゲットURIに存在する 場合、およびフォーカスがAllow-Eventsヘッダーフィールドにカンファレン スパッケージを列挙している場合、カンファレンスを意識するUAはカンファ レンスパッケージにサブスクライブすべきである[SHOULD]。カンファレンス パッケージに対するSUBSCRIBEは、INVITEで開始されたダイアログの外部で 送信されるべきである[SHOULD]。INVITEダイアログをBYEで終了するとき、 SUBSCRIBEダイアログも終了する必要はない。 カンファレンスを意識するUAは、フォーカスから受け取ったSIPのヘッダー フィールドおよびSDPフィールドに含まれるカンファレンス情報を、すべ てユーザーに提供してよい[MAY]。 カンファレンスを意識するUAは、SIPカンファレンスパッケージから取得し たカンファレンスに関する情報を、ユーザーに表示すべきである[SHOULD]。 Johnston & Levin Best Current Practice [Page 5] RFC 4579 SIP CC Conferencing for UAs August 2006 4. 「isfocus」フィーチャーパラメータの用法 4.1. 概要 カンファレンス向けにSIPの拡張および仕様を開発する際の主な設計指針は、 定義する拡張の数を最低限にし、また、カンファレンスを意識しないSIP UA との間にシームレスな下位互換性を持つことである。SIPの最低限の要件は、 ダイアログが、URIによって参照される特定カンファレンスの一部であると 表せることである。こうした拡張の結果、SIPを使用して以下のことが可能 になる。 - カンファレンスの作成 - カンファレンスへの参加 - ユーザーをカンファレンスへ招待 - サードパーティがカンファレンスからユーザーを外す - URIがカンファレンスURIかどうかを検出 - カンファレンスの削除 採用される手法では、フィーチャーパラメータ「isfocus」を使用して、SIP ダイアログがカンファレンスに所属することを表す。UAの特徴と能力を記述 するためにContactヘッダーフィールドにフィーチャーパラメータを使用す る方法は、User Agent Capabilities [5]の文書に記載されている。また、 この文書には、「isfocus」フィーチャーパラメータの定義も記載されて いる。 4.2. セッション確立 セッション確立時に、フォーカスは「isfocus」フィーチャーパラメータ をContactヘッダーフィールドに含めなければならない[MUST]。ただし、 フォーカスが自身がフォーカスであることを隠したい場合は、この限りでは ない。参加者から見ると、フィーチャーパラメータはダイアログのリモー トターゲットURIに関連付けられる。カンファレンスを意識するUAにとっ ては、結果のダイアログがContactヘッダーフィールドのURIで特定されるカ ンファレンスに所属し、また本文書で定義される呼制御仕様を適用可能で ある、ということを意味する。 本質的に、この仕様で対応するカンファレンスは、中央に集中する。 したがって、一般的に、SIPカンファレンスURIに対するSIPリクエストが分岐 されず、専用のカンファレンスフォーカスにルーティングされるように、カン ファレンスシステムはカンファレンスURIを割り当てる必要がある。たとえ ば、グローバルにアクセス可能なSIPカンファレンスは、グローバルにルー ティング可能なユーザーエージェントURI (Globally Routable User Agent URI/GRUU)を使用したカンファレンスURIで構築される。GRUUは、分岐せず、 グローバルにルーティング可能な要件に対応できるためである。 Johnston & Levin Best Current Practice [Page 6] RFC 4579 SIP CC Conferencing for UAs August 2006 4.3. 検出 このセクションで説明するメカニズムを使用すると、不透明なURIを仮定し て、特定のカンファレンスに所属する(つまり、カンファレンスURIである) かどうかを認識することができる。この検出機能は、OPTIONSリクエストを 使用してSIPで実装できる。また、アクティブなダイアログ内またはダイア ログ外のどちらでも実行できる。フォーカスはOPTIONSに対する200 OK応答 に「isfocus」フィーチャーパラメータを含めなければならない[MUST]。た だし、フォーカスが自身がフォーカスであることを隠したい場合は、この限 りではない。 5. SIPのカンファレンス原型 このセクションで提示するSIPカンファレンスの呼制御フローは、カンファ レンス要件[14]およびフレームワーク[8]の文書に記載されているような、 SIPと関係がある多様なカンファレンスアプリケーションの基礎となるSIP呼 制御である。主な設計目標は、同じSIPカンファレンス原型が、異なるカン ファレンス能力を持ち、異なるアプリケーションを実装するユーザーエー ジェントによって使用される、ということである。 5.1. INVITE: カンファレンスURIを使用してカンファレンスに参加 - ダイヤルイン このセクションでは、ユーザーはカンファレンスURIを知っており、このカ ンファレンスに参加するために「ダイヤルイン(dial in)」する。フォーカ スは、参加者がカンファレンスに参加することを許可する前に、参加者を認 証し、認可ポリシーを適用する。 UAが最初にカンファレンスへダイヤルインする最初の参加者の場合、この INVITEによってフォーカスがアクティブ化され、それによってカンファレン スもアクティブ化される、ということはあり得る。ただし、カンファレンス URIは、使用する前に予約されている必要がある。 カンファレンスが起動済みの場合、ダイヤルインの参加者は、フォーカスに よってカンファレンスに追加される。 既存のカンファレンスに参加するために、UAは、カンファレンスURIに設定 されているRequest-URIを使用してINVITEを送信する。フォーカスは、 INVITEに対する200 OKのContactヘッダーフィールドに、「isfocus」フィー チャーパラメータを含めなければならない[MUST]。 Johnston & Levin Best Current Practice [Page 7] RFC 4579 SIP CC Conferencing for UAs August 2006 カンファレンスに参加するコールフロー例を図1に示す。 Alice Focus Bob Carol | | | | | Carolがカンファレンスに参加 | | | | | | INVITE sip:Conf-ID F1 | | |<----------------------------------------| | | 180 Ringing F2 | | |---------------------------------------->| | | 200 OK Contact:Conf-ID;isfocus F3 | | |---------------------------------------->| | | ACK F4 | | |<----------------------------------------| | | RTP | | |<=======================================>| | | SUBSCRIBE sip:Conf-ID F5 | | |<----------------------------------------| | | 200 OK F6 | | |---------------------------------------->| | | NOTIFY F7 | | |---------------------------------------->| | | 200 OK F8 | | |<----------------------------------------| 図1. 参加者がカンファレンスURIを使用してカンファレンスに参加 F1 INVITE sip:3402934234@conf.example.com SIP/2.0 Via: SIP/2.0/UDP client.chicago.example.com ;branch=z9hG4bKhjhs8ass83 Max-Forwards: 70 To: From: Carol ;tag=32331 Call-ID: d432fa84b4c76e66710 CSeq: 45 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Allow-Events: dialog Accept: application/sdp, message/sipfrag Supported: replaces Content-Type: application/sdp Content-Length: ... (SDPは示されない) Johnston & Levin Best Current Practice [Page 8] RFC 4579 SIP CC Conferencing for UAs August 2006 F3 SIP/2.0 200 OK Via: SIP/2.0/UDP client.chicago.example.com ;branch=z9hG4bKhjhs8ass83;received=192.0.2.4 To: ;tag=733413 From: Carol ;tag=32331 Call-ID: d432fa84b4c76e66710 CSeq: 45 INVITE Contact: ;isfocus Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Allow-Events: dialog, conference Accept: application/sdp, application/conference-info+xml, message/sipfrag Supported: replaces, join, gruu Content-Type: application/sdp Content-Length: ... v=0 o=focus431 2890844526 2890842807 IN IP4 ms5.conf.example.com s=- i=Example Conference Hosted by Example.com u=http://conf.example.com/3402934234 e=3402934234@conf-help.example.com p=+1-888-2934234 c=IN IP4 ms5.conf.example.com t=0 0 m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 31 F5 SUBSCRIBE sip:3402934234@conf.example.com SIP/2.0 Via: SIP/2.0/UDP client.chicago.example.com ;branch=z9hG4bKdf334 Max-Forwards: 70 To: From: Carol ;tag=43524545 Call-ID: k3l43id034ksereree CSeq: 22 SUBSCRIBE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Event: conference Accept: application/conference-info+xml Supported: replaces Content-Length: 0 Johnston & Levin Best Current Practice [Page 9] RFC 4579 SIP CC Conferencing for UAs August 2006 F7 NOTIFY sip:carol@chicago.example.com SIP/2.0 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK3343d1 Max-Forwards: 70 To: Carol ;tag=43524545 From: ;tag=a3343df32 Call-ID: k3l43id034ksereree CSeq: 34321 NOTIFY Contact: ;isfocus Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Event: conference Accept: application/sdp, message/sipfrag Subscription-State: active;expires=3600 Supported: replaces, join, gruu Content-Type: application/conference-info+xml Content-Length: ... tel:+18882934234 Carol connected dialed-in Main Audio audio 583398 sendrecv video 345212 sendrecv Johnston & Levin Best Current Practice [Page 10] RFC 4579 SIP CC Conferencing for UAs August 2006 5.2. INVITE: フォーカスによる参加者の追加 - ダイヤルアウト 参加者を直接カンファレンスに追加するには、フォーカスは、その参加者 に、カンファレンスURIと「isfocus」フィーチャーパラメータを指定した Contactヘッダーフィールドを含むINVITEを送信すべきである[SHOULD]。 カンファレンスを意識しないUAは、カンファレンス情報を無視するだけで あり、そのセッションを(SIPの観点から)ポイントツーポイントのセッショ ンとして扱う、ということに注意。これは、標準のRFC 3261 [2]の動作が 「isfocus」などの未知のヘッダーパラメータを無視するためである。 コールフロー例を図2に示す。この例では、Aliceはすでにカンファレンスに 参加している。フォーカスは、INVITEを送信してCarolをカンファレンスに 招待する。セッションが確立した後、CarolはカンファレンスURIにサブスク ライブする。CarolのSUBSCRIBE(F5)とAlice(F9)へのNOTIFYの間に依存関係 はない点に注意することは重要である。これらは、非同期に、独立して発生 する。 Johnston & Levin Best Current Practice [Page 11] RFC 4579 SIP CC Conferencing for UAs August 2006 Alice Focus Bob Carol | | | | |<==================>| | | | | | | フォーカスがCarolをカンファレンスに追加するために | | 「ダイヤルアウト」 | | | | | | INVITE Contact:Conf-ID;isfocus F1 | | |---------------------------------------->| | | 180 Ringing F2 | | |<----------------------------------------| | | 200 OK F3 | | |<----------------------------------------| | | ACK F4 | | |---------------------------------------->| | | RTP | | |<=======================================>| | | SUBSCRIBE sip:Conf-ID F5 | | |<----------------------------------------| | | 200 OK F6 | | |---------------------------------------->| | | NOTIFY F7 | | |---------------------------------------->| | | 200 OK F8 | | |<----------------------------------------| | NOTIFY F9 | | |<-------------------| | | 200 OK F10 | | |------------------->| | 図2. フォーカスがカンファレンスに参加者を追加するために「ダイヤル アウト」 F7 NOTIFY sip:carol@chicago.example.com SIP/2.0 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK3343d1 Max-Forwards: 70 To: Carol ;tag=43524545 From: ;tag=a3343df32 Call-ID: k3l43id034ksereree CSeq: 34321 NOTIFY Contact: ;isfocus Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Event: conference Accept: application/sdp, message/sipfrag Subscription-State: active;expires=3600 Supported: replaces, gruu Content-Type: application/conference-info+xml Content-Length: ... Johnston & Levin Best Current Practice [Page 12] RFC 4579 SIP CC Conferencing for UAs August 2006 tel:+18882934234 Alice connected dialed-in Main Audio audio 647231 sendrecv video 21345 sendrecv Carol connected dialed-out Main Audio audio 583398 sendrecv video 345212 sendrecv Johnston & Levin Best Current Practice [Page 13] RFC 4579 SIP CC Conferencing for UAs August 2006 F9 NOTIFY sip:alice@atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK3432 Max-Forwards: 70 To: Alice ;tag=43524545 From: ;tag=a3343df32 Call-ID: 8820450524545 CSeq: 998 NOTIFY Contact: ;isfocus Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Event: conference Accept: application/sdp, message/sipfrag Subscription-State: active;expires=2450 Supported: replaces, gruu Content-Type: application/conference-info+xml Content-Length: ... Carol connected dialed-out Main Audio audio 583398 sendrecv video 345212 sendrecv Johnston & Levin Best Current Practice [Page 14] RFC 4579 SIP CC Conferencing for UAs August 2006 5.3. INVITE: カンファレンスアプリケーションへのダイヤルによる カンファレンスの手動作成 このセクションでは、ユーザーがカンファレンスサーバーアプリケーション に対してINVITEを送信する。カンファレンスが作成される前に、システム でユーザーからの補足入力を必要とするため、アプリケーション(IVRシス テム、Webページなど)が実装される。通常のダイアログが確立した後に、補 足情報が受信され、フォーカスとともにカンファレンスが作成される。 現在、UAはフォーカスとのダイアログ中なので、フォーカスは、 「isfocus」フィーチャータグを指定したContactヘッダーフィールドのカン ファレンスURIで、ユーザーをre-INVITEする。 また、初期ダイアログ中にユーザーから追加情報が提供される可能性もあ る(SIPの初期ダイアログに関する議論については、RFC 3261 [2]を参照)。 これは、カンファレンスのアプリケーションが送信する183 Session Progress応答によって達成される。カンファレンスが作成された後に、カン ファレンスURIは200 OKのContactヘッダーフィールドで返される。 このフローはカンファレンスアプリケーションでのユーザー操作次第なの で、あらゆるエラーまたは障害がユーザーに返される(録音済みのアナウ ンス、エラー音など)。 カンファレンスフレームワークで論じられているように、カンファレンス URIは同じドメイン内のすべてのカンファレンスにわたって固有である必要 がある。一般的に、カンファレンスURIのユーザー部には、疑似ランダム文 字列が含まれる。 コールフロー例を図3に示す。この例では、Aliceが使用するカンファレンス アプリケーションは、AliceがINVITEをカンファレンスアプリケーションに 送信するときにトリガされる。この例で、Conf-Appは、カンファレンスアプ リケーションのURIを示すために使用される。カンファレンスを意識する AliceのUAは、「isfocus」フィーチャーパラメータから、カンファレンスが 存在することを知り、カンファレンスパッケージにサブスクライブしてカン ファレンスステートの通知を受け取る。 Johnston & Levin Best Current Practice [Page 15] RFC 4579 SIP CC Conferencing for UAs August 2006 Alice Focus Bob Carol | | | | | Aliceはカンファレンスアプリケーションとセッションを確立。 | | | | | | INVITE sip:Conf-App F1 | | |------------------->| | | | 180 Ringing F2 | | | |<-------------------| | | | 200 OK F3 | | | |<-------------------| | | | ACK F4 | | | |------------------->| | | | RTP | | | |<==================>| | | | | | | | Aliceはカンファレンス作成にアプリケーションを使用 | | | | | | INVITE Contact:Conf-ID;isfocus F5 | | |<-------------------| | | | 200 OK F6 | | | |------------------->| | | | ACK F7 | | | |<-------------------| | | | RTP | | | |<==================>| | | | | | | | SUBSCRIBE sip:Conf-ID F8 | | |------------------->| | | | 200 OK F9 | | | |<-------------------| | | | NOTIFY F10 | | | |<-------------------| | | | 200 OK F11 | | | |------------------->| | | 図3. 参加者がアプリケーションを使用してカンファレンスを作成 5.4. INVITE: アドホックSIPの手法を使用したカンファレンス作成 このセクションでは、アドホック(ad-hoc)のSIP手法を使用してカンファレ ンスを作成する方法を説明する。この例では、カンファレンスファクトリ URI(セクション3.2で定義)は、自動的にカンファレンスを作成するために使 用される。これは、ユーザー操作が必要ないという点で前のシナリオとは異 なる。自動装置がカンファレンスの作成と参加者の追加を行うことができ る。カンファレンスのスケジュールや予約は必要ないが、「オンザフライ」 で作成されるため、これは「アドホック」カンファレンスの作成である。 Johnston & Levin Best Current Practice [Page 16] RFC 4579 SIP CC Conferencing for UAs August 2006 この手法の利点は、カンファレンスURIをユーザーに知らせる必要がないこ とである。その代わり、カンファレンスURIはフォーカスによって作成され、 参加者のUAで使用される。このシナリオとセクション5.3との主な違いは、 カンファレンスを作成するためにユーザーの介入(IVR、Webページのフォー ムなど)が必要ない点である。 カンファレンスファクトリのSIP URIは、(SIP電話の「新規カンファレンス 作成」ボタンのように)UAに組み込んだり、他の手段を使用して検出するこ とができる。 SIPエンティティ(カンファレンスサーバーなど)は、新規のアドホックカン ファレンスを作成するリクエストとしてのこのINVITEリクエストと、既存カ ンファレンスに参加するリクエストとを、Request-URIによって区別するこ とができる。つまり、両方のリクエストは同じアプリケーションにルーティ ングされる可能性があるが、要求される異なるサービスが、そのリクエスト 自体で異なるURIによって識別される可能性もある。 すべてのセキュリティ要件およびポリシー要件が満たされていると仮定し て、200 OKで返されるカンファレンスURIとしてのContact URIで、新規の カンファレンスが作成される。Contactヘッダーフィールドには、このURIが カンファレンス用であると示す「isfocus」フィーチャーパラメータを含め なければならない[MUST]。 コールフロー例を図4に示す。Conf-FactoryはカンファレンスファクトリURI の省略表現であり、Conf-IDはカンファレンスURIの省略である。このフロー では、Aliceはカンファレンスを意識するUAを持ち、カンファレンスファク トリURIにINVITEを送信することでカンファレンスを作成する。カンファレ ンスファクトリアプリケーションがカンファレンスを作成し、302 Moved Temporarily応答を使用して、Aliceをフォーカスにリダイレクトする。 プロキシの再帰(標準のRFC 3261 [2]の動作に含まれる)があると、Aliceは リダイレクトを確認せずに、メッセージF5から始まる応答をフォーカスから 受け取るだけの可能性がある、ということに注意。メディアセッションが確 立すると、Aliceは、フォーカスから受け取った200 OK応答のContactヘッ ダーフィールドで取得したカンファレンスURIに、サブスクライブする。 Johnston & Levin Best Current Practice [Page 17] RFC 4579 SIP CC Conferencing for UAs August 2006 Alice Conf-Factory App Focus Bob | | | | | Aliceはカンファレンスを作成。 | | | | | | | INVITE sip:Conf-Factory F1 | | |------------------->| | | | 302 Moved Contact:Conf-ID;isfocus F2 | | |<-------------------| | | | ACK F3 | | | |------------------->| | | | INVITE sip:Conf-ID F4 | | |---------------------------------------->| | | 180 Ringing F5 | | |<----------------------------------------| | | 200 OK Contact:Conf-ID;isfocus F6 | | |<----------------------------------------| | | ACK F7 | | |---------------------------------------->| | | RTP | | |<=======================================>| | | | | | AliceはカンファレンスURIにサブスクライブ| | | | | | SUBSCRIBE sip:Conf-ID F8 | | |---------------------------------------->| | | 200 OK F9 | | |<----------------------------------------| | | NOTIFY F10 | | |<----------------------------------------| | | 200 OK F11 | | |---------------------------------------->| | 図4. SIPのアドホック手法を使用したカンファレンス作成 5.5. REFER: カンファレンスに新しいリソースを追加するフォーカスの要求 (新しい参加者へのダイヤルアウト) SIPカンファレンスURIは、異なる種類の情報をカンファレンスに挿入するた めに使用することもできる。例には、新規の参加者、新規のリアルタイムメ ディアソース、新規のIMメッセージ、受動的情報の参照先(HTTP URIなど)へ のポインタが含まれる。 フォーカスに対して、新規の情報リソースを特定のカンファレンスに追加す るように要求するために、SIP UAは、新規リソースのURIを含むRefer-Toを 使用するカンファレンスURIにREFERを送信することができる。このREFERは、 カンファレンスファクトリURIではなくカンファレンスURIに送信されるた め、フォーカスのセマンティクスは、リソースをカンファレンスに取り入 Johnston & Levin Best Current Practice [Page 18] RFC 4579 SIP CC Conferencing for UAs August 2006 れ、カンファレンスの参加者に見えるようにすることである。この結果、 フォーカスの手順は、(URIで表される)新規リソースの性質と、フォーカス のポリシー(IMや、リアルタイムメディアの中央処理または分散処理など)に 関するとのどちらにも依存する。 新規のUA参加者を追加するシナリオに対応することは重要である。理由は、 新規の参加者がREFERと転送呼制御に対応しない場合でも機能するためであ る。リクエスト側の参加者とフォーカスのみが、REFERと転送呼制御に対応 する必要がある。 SIP URIを持つRefer-Toヘッダーフィールドが含まれるREFERを受け取った 場合、フォーカスは、Refer-To SIP URIで特定されるSIP新規の参加者に、 カンファレンスURIと「isfocus」フィーチャーパラメータが指定された Contactヘッダーフィールドを含むINVITEを送信すべきである[SHOULD]。 カンファレンスを意識しないUAは、カンファレンス情報を無視するだけで あり、そのセッションを(SIPの観点から)ポイントツーポイントのセッショ ンとして扱う。 コールフロー例を図5に示す。このフローは新規の参加者をカンファレンス に追加するREFERの使用例だが、このメカニズムは一般的に、URIに識別され るとおりにリソースをカンファレンスに追加することができる。この例で は、Aliceはすでにカンファレンスに参加している。Aliceはカンファレン スURIにREFERを送信する。フォーカスは、INVITEを送信してCarolをカン ファレンスに招待する。セッションが確立した後、Carolはカンファレンス URIにサブスクライブする。CarolのSUBSCRIBE(F11)とAlice(F15)へのNOTIFY の間に依存関係はない点に注意することは重要である。これらは、非同期 に、独立して発生する。 Johnston & Levin Best Current Practice [Page 19] RFC 4579 SIP CC Conferencing for UAs August 2006 Alice Focus Bob Carol | | | | |<==================>| | | | REFER sip:Conf-ID Refer-To:Carol F1 | | |------------------->| | | 202 Accepted F2 | | |<-------------------| | | NOTIFY (Trying) F3 | |<-------------------| | | 200 OK F4 | | |------------------->| | | | | | フォーカスがCarolをカンファレンスに追加するために | | 「ダイヤルアウト」 | | | | | | INVITE Contact:Conf-ID;isfocus F5 | | |---------------------------------------->| | | 180 Ringing F6 | | |<----------------------------------------| | | 200 OK F7 | | |<----------------------------------------| | | ACK F8 | | |---------------------------------------->| | | RTP | | |<=======================================>| | NOTIFY (OK) F9 | | |<-------------------| | | 200 OK F10 | | |------------------->| | | | SUBSCRIBE sip:Conf-ID F11 | | |<----------------------------------------| | | 200 OK F12 | | |---------------------------------------->| | | NOTIFY F13 | | |---------------------------------------->| | | 200 OK F14 | | |<----------------------------------------| | NOTIFY F15 | | |<-------------------| | | 200 OK F16 | | |------------------->| | 図5. 参加者がフォーカスに対して別の参加者をカンファレンスに追加する ように要求 Johnston & Levin Best Current Practice [Page 20] RFC 4579 SIP CC Conferencing for UAs August 2006 F1 REFER sip:3402934234@conf.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg4534 Max-Forwards: 70 To: From: Alice ;tag=5534562 Call-ID: 849392fklgl43 CSeq: 476 REFER Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Accept: application/sdp, message/sipfrag Refer-To: Supported: replaces Content-Length: 0 5.6. REFER: カンファレンスURIを使用してカンファレンスにダイヤルインす るようにユーザーへ要求 新規の参加者を追加したいと望む参加者は、その参加者に対して、INVITEを カンファレンスURIに送信するように要求する。これは、SIP以外の手段(電子 メール、IM、WebページでカンファレンスURIを渡す、発行するなど)を使用 して実行できる。SIP以外の手段が使用される場合のフローと要件は、セク ション5.1と同様である。 実行するためのSIPの仕組みでは、REFERメソッドが使用される。 新規の参加者を追加したいと望む参加者は、その参加者に、カンファレン スURIが指定されたRefer-Toヘッダーフィールドを含むREFERリクエストを送 信すべきである[SHOULD]。 要件は、セクション5.1の「ダイヤルイン」の場合と同様である。招待する 側の参加者は、カンファレンスパッケージを通じて受け取る通知の他に、新 規の参加者が追加されるREFERアクションを通じて通知を受け取ってもよ い[MAY]。 例を図6に示す。このコールフロー例では、Aliceはすでにカンファレンスに 参加している。AliceはBobに「帯域外の(out of band)」REFE、つまり、確立 したダイアログ外でREFERを送信する。万が一BobがREFERを拒否した場合は、 AliceはINVITEをBobに送信を試みて、まずセッションを確立し、次にREFER をダイアログ内で送信して、効果的にBobをカンファレンスに転送する可能 性がある[17]。 Johnston & Levin Best Current Practice [Page 21] RFC 4579 SIP CC Conferencing for UAs August 2006 Alice Focus Bob Carol | | | | |<==================>| | | | | | | | AliceはBobをカンファレンスに追加 | | | | | | | REFER Refer-To:Conf-ID F1 | | |---------------------------------------->| | | 202 Accepted F2 | | | |<----------------------------------------| | | NOTIFY (Trying) F3| | | |<----------------------------------------| | | 200 OK F4 | | | |---------------------------------------->| | | | INVITE sip:Conf-ID F5 | | |<-------------------| | | | 180 Ringing F6 | | | |------------------->| | | | 200 OK Contact:Conf-ID;isfocus F7 | | |------------------->| | | | ACK F8 | | | |<-------------------| | | | RTP | | | |<==================>| | | NOTIFY (OK) F9 | | | |<----------------------------------------| | | 200 OK F10 | | | |---------------------------------------->| | | NOTIFY F11 | | | |<-------------------| | | | 200 OK F12 | | | |------------------->| | | | | SUBSCRIBE sip:Conf-ID F13 | | |<-------------------| | | | 200 OK F14 | | | |------------------->| | | | NOTIFY F15 | | | |------------------->| | | | 200 OK F16 | | | |<-------------------| | 図6. 既存カンファレンスに参加者を追加 Johnston & Levin Best Current Practice [Page 22] RFC 4579 SIP CC Conferencing for UAs August 2006 5.7. REFERを使用したREFER: カンファレンスにダイヤルインする参加者を REFERするようにフォーカスへ要求 参加者は、フォーカスに対して、REFERメソッドを送信して参加者をカン ファレンスにREFERするように要求することができる。Refer-Toヘッダー フィールドには、REFERとエスケープされたRefer-Toヘッダーフィールド (カンファレンスURIを含む)に対するメソッドセットが含まれる。 以下のメッセージF1のフローで、Refer-Toヘッダーフィールドが、2行にわ たって継続していることに注意。これは実際のメッセージであればこのよう なことはなく、URIが継続しているのは、本文書の構成制限を超えている。 このシナリオを図7に示す。 Johnston & Levin Best Current Practice [Page 23] RFC 4579 SIP CC Conferencing for UAs August 2006 Alice Focus Bob Carol | | | | |<==================>| | | | Aliceはフォーカスに対し、BobをカンファレンスにREFERする | | ことを要求する | | | | | |REFER sip:Conf-ID Refer-To:Bob;method=REFER?Refer-To=Conf-ID F1 |------------------->| | | | 202 Accepted F2 | | | |<-------------------| | | | NOTIFY (Trying) F3| | | |<-------------------| | | | 200 OK F4 | | | |------------------->| | | | フォーカスはBobをカンファレンスにREFERする | | | | | | | REFER Refer-To:Conf-ID F5 | | |------------------->| | | | 202 Accepted F6 | | | NOTIFY (202) F7 |<-------------------| | |<-------------------| NOTIFY (Trying) F8 | | | 200 OK F9 |<-------------------| | |------------------->| 200 OK F10 | | | |------------------->| | | | INVITE sip:Conf-ID F11 | | |<-------------------| | | | 180 Ringing F12 | | | |------------------->| | | | 200 OK Contact:Conf-ID;isfocus F13 | | |------------------->| | | | ACK F14 | | | NOTIFY F15 |<-------------------| | |<-------------------| RTP | | | 200 OK F16 |<==================>| | |------------------->| NOTIFY (200) F17 | | | |<-------------------| | | | 200 OK F18 | | | |------------------->| | | | SUBSCRIBE sip:Conf-ID F17 | | |<-------------------| | | | 200 OK F19 | | | |------------------->| | | | NOTIFY F20 | | | |------------------->| | | | 200 OK F21 | | | |<-------------------| | 図7. フォーカスへ参加者をカンファレンスにREFERするように要求 Johnston & Levin Best Current Practice [Page 24] RFC 4579 SIP CC Conferencing for UAs August 2006 F1 REFER sip:3402934234@conf.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg4534 Max-Forwards: 70 To: From: Alice ;tag=5534562 Call-ID: 849392fklgl43 CSeq: 476 REFER Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Accept: application/sdp, message/sipfrag Refer-To: Supported: replaces Content-Length: 0 F5 REFER sip:3402934234@conf.example.com SIP/2.0 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK33445243 Max-Forwards: 70 To: From: ;tag=345621412 Call-ID: 5494204 CSeq: 4524323 REFER Contact: ;isfocus Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Accept: application/sdp, message/sipfrag Refer-To: Supported: join, gruu, replaces Content-Length: 0 F11 INVITE sip:3402934234@conf.example.com SIP/2.0 Via: SIP/2.0/UDP client.biloxi.com;branch=z9hG4bKh3887 Max-Forwards: 70 To: From: Bob ;tag=32411 Call-ID: 5d4324fa84b4c76e66710 CSeq: 764 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Allow-Events: dialog Accept: application/sdp, message/sipfrag Supported: replaces, join Content-Type: application/sdp Content-Length: ... Johnston & Levin Best Current Practice [Page 25] RFC 4579 SIP CC Conferencing for UAs August 2006 (SDPは示されない) 5.8. Joinヘッダーフィールド: (サードパーティの)ダイアログ識別子を使用 してカンファレンスにダイヤルイン 状況によって、カンファレンスに参加するために待機している参加者は、 カンファレンスのレグのうち1つのダイアログ識別子を知っているだけの場 合がある。カンファレンスの別の参加者から情報を取得する、ダイアログ パッケージ[18]またはSIP以外の何らかの手段を使用して、この情報を知る ことができる。 UAは、カンファレンス(別の参加者とフォーカス間のダイアログ)のあるレグ のダイアログ識別子が指定された、Join[7]ヘッダーフィールドを含むリク エストを、フォーカスに送信することで、カンファレンスに自身を追加する ように要求することができる。 カンファレンス呼制御のシナリオによっては、UAがJoinヘッダーフィールド を仕様できる場合のシナリオが他にもある。他の例と詳細は、[7]を参照の こと。 例を図8に示す。この例では、Aliceはカンファレンスに参加している。 Aliceとフォーカス間のダイアログ識別子は、A-Fと省略表記され、またBob はこの識別子を知っている。Bobは、INVITEメッセージ(F1)をフォーカスに 送信して、自身をカンファレンスに追加するように要求する。このINVITE には、ダイアログ識別子A-Fが指定されたJoinヘッダーフィールドが含ま れる。Bobはフォーカスによってカンファレンスに追加される。 Johnston & Levin Best Current Practice [Page 26] RFC 4579 SIP CC Conferencing for UAs August 2006 Alice Focus Bob Carol | | | | |<==================>| | | | | | | | Bobは自身をカンファレンスに追加するように要求。 | | | | | | | INVITE Join:A-F F1| | | |<-------------------| | | | 180 Ringing F2 | | | |------------------->| | | | 200 OK Contact:Conf-ID;isfocus F3 | | |------------------->| | | | ACK F4 | | | |<-------------------| | | | RTP | | | NOTIFY F5 |<==================>| | |<-------------------| SUBSCRIBE sip:Conf-ID F6 | | 200 OK F7 |<-------------------| | |------------------->| 200 OK F8 | | | |------------------->| | | | NOTIFY F9 | | | |------------------->| | | | 200 OK F10 | | | |<-------------------| | 図8. Joinを使用して既存カンファレンスに参加者を追加 F1 INVITE sip:3402934234@conf.example.com SIP/2.0 Via: SIP/2.0/UDP client.biloxi.com;branch=z9hG4bKh3832 Max-Forwards: 70 To: From: Bob ;tag=32411 Call-ID: d432fa84b4c76e66710 CSeq: 8 INVITE Contact: Join: 3434034-293553453;to-tag=fdj3l34;from-tag=12f331 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Allow-Events: dialog Accept: application/sdp, message/sipfrag Supported: replaces, join Content-Type: application/sdp Content-Length: ... (SDPは示されない) Johnston & Levin Best Current Practice [Page 27] RFC 4579 SIP CC Conferencing for UAs August 2006 5.9. Replacesヘッダーフィールド: カンファレンス内でユーザーエージェント の切り替え カンファレンスの参加者は、カンファレンスに参加するユーザーエージェン ト(つまりエンドポイントまたはデバイス)を変更したい場合がある。これ は、カンファレンスから抜けるためにユーザーエージェントからBYEを送信 し、改めて参加するために、他のユーザーエージェントからINVITEを送信す るだけで実行することができる。一方で、SIPのReplaces[6]の原型が、この 操作には最適である。 例を図9に示す。この例では、Aliceはユーザーエージェント#1を使用してカ ンファレンスに参加している。Aliceのユーザーエージェント#1とフォーカ ス間のダイアログ識別子は、A-Fと省略表記される。Aliceはユーザーエー ジェント#2に切り替え、INVITEメッセージ(F1)をフォーカスに送信する。こ のINVITEにはダイアログ識別子A-Fが指定されたReplacesヘッダーフィール ドが含まれている。このダイアログ識別子は、何らかのSIP以外の仕組みを 使用するか、SUBSCRIBE/NOTIFYとダイアログイベントパッケージ[18]を使用 して、知ることができる、ということに注意。Aliceのユーザーエージェント #2は、フォーカスによってカンファレンスに追加される。フォーカスは ユーザーエージェント#1にBYEを送信する。ユーザーエージェント#1は、サ ブスクリプションを終了するようにExpires:0を指定したSUBSCRIBEを送信す ることで、自動的にサブスクリプションを終了する。このシナリオでは、 Aliceのユーザーエージェント(つまりエンドポイント)に関する詳細情報が カンファレンスステート通知に含まれていない場合、参加者一覧(名簿)は必 ずしも変化するとは限らない、ということに注意。カンファレンスパッケー ジの通知に関する詳細な議論については、[9]を参照のこと。 Johnston & Levin Best Current Practice [Page 28] RFC 4579 SIP CC Conferencing for UAs August 2006 Alice UA#1 Focus Alice UA#2 Carol | | | | |<==================>| | | | | | | | Aliceはカンファレンス中にユーザーエージェントを切り替え。 | | | | | | | INVITE sip:Conf-ID Replaces:A-F F1 | | |<-------------------| | | | 200 OK Contact:Conf-ID;isfocus F2 | | |------------------->| | | | ACK F3 | | | |<-------------------| | | | RTP | | | |<==================>| | | BYE F4 | | | |<-------------------| | | | 200 OK F5 | | | |------------------->| | | | SUBSCRIBE Expires:0 F6 | | |------------------->| | | | 200 OK F7 | | | |<-------------------| | | | NOTIFY Subscription-State:terminated F8 | | |<-------------------| | | | 200 OK F9 | | | |------------------->| | | | | SUBSCRIBE sip:Conf-ID F10 | | |<-------------------| | | | 200 OK F11 | | | |------------------->| | | | NOTIFY F12 | | | |------------------->| | | | 200 OK F13 | | | |<-------------------| | 図9. カンファレンス内のユーザーエージェントの切り替え 5.10. Replacesヘッダーフィールド: ポイントツーポイントセッションから カンファレンスへの転送 このコールフローは、ポイントツーポイントの呼を、外部のフォーカスが関 与するカンファレンスコールに転送(transfer)する方法を示す。 AliceとBob間で、ダイアログ識別子A-Bを持つセッションが確立している。 Aliceは、INVITEをカンファレンスURIに送信することで、フォーカスとの カンファレンスに参加する。次に、Aliceは、INVITEを他の参加者に送信す るように、REFERリクエストをフォーカスに送信する。Aliceは、Refer-To ヘッダーフィールドに指定されたURIに、エスケープされたReplacesヘッ Johnston & Levin Best Current Practice [Page 29] RFC 4579 SIP CC Conferencing for UAs August 2006 ダーフィールドをを含める。Bobは、フォーカスからINVITEを受信し、 Replacesヘッダーフィールドのダイアログと、Aliceとのダイアログとを マッチングする。結果として、Bobは、INVITEを受け入れ、カンファレンス に参加し、AliceにBYEを送信してポイントツーポイントのダイアログを終了 する。 Alice Focus Bob Carol | | | | | AliceはBobとセッション中 | | |<=======================================>| | | | | | | Aliceがカンファレンスに参加 | | | | | | | INVITE sip:Conf-ID F1 | | |------------------->| | | | 200 OK Contact:sip:Conf-ID;isfocus F2 | | |<-------------------| | | | ACK F3 | | | |------------------->| | | | SUBSCRIBE F4 | | | |------------------->| | | | 200 OK F5 | | | |<-------------------| | | | NOTIFY F6 | | | |<-------------------| | | | 200 OK F7 | | | |------------------->| | | |<==================>| | | | | | | | Aliceはフォーカスに対し、BobをカンファレンスにREFERする | | ことを要求する | | | | | | REFER sip:Conf-ID Refer-To:Bob?Replaces=A-B F8 | |------------------->| | | | 202 Accepted F9 | | | |<-------------------| | | | NOTIFY (Trying) F10| | | |<-------------------| | | | 200 OK F11 | | | |------------------->| | | | | | | | フォーカスはBobをカンファレンスに招待する | | | | | | | INVITE sip:Conf-ID Replaces:A-B F12 | | |------------------->| | | | 200 OK F13 | | | |<-------------------| | | | ACK F14 | | | |------------------->| | | | RTP | | Johnston & Levin Best Current Practice [Page 30] RFC 4579 SIP CC Conferencing for UAs August 2006 | |<==================>| | | BYE F15 | | |<----------------------------------------| | | 200 OK F16 | | |---------------------------------------->| | | NOTIFY (200) F17 | | | |<-------------------| | | | 200 OK F18 | | | |------------------->| | | | NOTIFY F19 | | | |<-------------------| | | | 200 OK F20 | | | |------------------->| | | | | SUBSCRIBE sip:Conf-ID F21 | | |<-------------------| | | | 200 OK F22 | | | |------------------->| | | | NOTIFY F23 | | | |------------------->| | | | 200 OK F24 | | | |<-------------------| | | | | | 図10. ポイントツーポイントセッションからカンファレンスへの移行 5.11. BYEありのREFER: フォーカスへカンファレンスから参加者を削除するよ うに要求 フォーカスに対して、特定のカンファレンスから参加者を削除するように要 求するために、適切な権限を持つSIP UA(通常はカンファレンスのオーナー) は、カンファレンスURIに、削除する参加者のURIが指定されたRefer-Toを含 むREFERと、BYEに設定されたメソッドを送信する。リクエスト側は、フォー カスと削除される参加者間のダイアログ情報を知る必要はない。そのダイア ログ情報はフォーカスが知っており、BYEリクエストを生成するときに指定 される。 コールフロー例を図11に示す。この例では、AliceとCarolはすでにカンファ レンスに参加しており、Aliceはカンファレンスからメンバーを削除する権 限を持つ。Aliceは、sip:carol@chicago.example.com;method=BYEという形 式のURIが指定されたRefer-Toヘッダーフィールドと共に、REFERをカンファ レンスURIに送信する。 Johnston & Levin Best Current Practice [Page 31] RFC 4579 SIP CC Conferencing for UAs August 2006 Alice Focus Bob Carol | | | | |<==================>| | | REFER sip:Conf-ID Refer-To:Carol;method=BYE F1 | |------------------->| | | 202 Accepted F2 | | |<-------------------| | | NOTIFY (Trying) F3 | |<-------------------| | | 200 OK F4 | | |------------------->| | | | | | フォーカスはCarolをカンファレンスから削除 | | | | | | BYE sip:Carol F5 | | |---------------------------------------->| | | 200 OK F6 | | |<----------------------------------------| | | NOTIFY Subscription-State:terminated F7 | | |---------------------------------------->| | | 200 OK F8 | | |<----------------------------------------| | NOTIFY (200) F9 | | |<-------------------| | | 200 OK F10 | | |------------------->| | | NOTIFY F11 | | |<-------------------| | | 200 OK F12 | | |------------------->| | 図11. 参加者がフォーカスに対して別の参加者をカンファレンスから削除 するように要求 F1 REFER sip:3402934234@conf.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg4534 Max-Forwards: 70 To: From: Alice ;tag=5534562 Call-ID: 849392fklgl43 CSeq: 476 REFER Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Accept: application/sdp, message/sipfrag Refer-To: Supported: replaces Content-Length: 0 Johnston & Levin Best Current Practice [Page 32] RFC 4579 SIP CC Conferencing for UAs August 2006 F5 BYE sip:carol@client.chicago.example.com SIP/2.0 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK343gf4 Max-Forwards: 70 From: ;tag=5393k2312 To: Carol ;tag=32331 Call-ID: d432fa84b4c76e66710 CSeq: 78654 BYE Content-Length: 0 5.12. カンファレンスの削除 カンファレンスファクトリURIを使用して作成されたカンファレンスの場合、 デフォルトのカンファレンスポリシーは、作成者が外れたときにカンファレ ンスを削除する、というものである。 図12に、作成者Aliceが外れたことで、カンファレンスが削除される場合 のコールフローを示す。BYEと最終的なNOTIFYを送信する順序は重要では ない、という点に注意。 Johnston & Levin Best Current Practice [Page 33] RFC 4579 SIP CC Conferencing for UAs August 2006 Alice Focus Bob Carol | | | | |<==================>|<==================>| | | BYE F1 |<=======================================>| |------------------->| | | | 200 OK F2 | | | |<-------------------| | | | | BYE F3 | | | |------------------->| | | | 200 OK F4 | | | |<-------------------| | | | BYE F5 | | |---------------------------------------->| | | 200 OK F6 | | |<----------------------------------------| | NOTIFY Subscription-State:terminated F7 | |<-------------------| | | | 200 OK F8 | | | |------------------->| NOTIFY Subscription-State:terminated F9 | | |------------------->| | | | 200 OK F10 | | | |<-------------------| | | | NOTIFY Subscription-State:terminated F11| | |---------------------------------------->| | | 200 OK F12 | | |<----------------------------------------| 図12. カンファレンスの削除 5.13. OPTIONSを使用してURIプロパティの検出 UAは、不透明なURIがカンファレンスURI(フォーカスに解決される)かどうか を確認するために、OPTIONSリクエストを送信してもよい[MAY]。さらに、 OPTIONSリクエストに対する応答に、本文書で使用される多様なSIP呼制御拡 張への対応を示すことができる。 通常のダイアログ確立処理の一部として、フォーカスからのINVITE、また はINVITEに対するフォーカスからの200 OK応答では、Allow、Accept、 Allow-Events、Supportedヘッダーフィールドを提示すべきである、という ことに注意。 図13では、Aliceが、フォーカスに解決されるURIに対して、OPTIONSを送信 する例を示す。 Johnston & Levin Best Current Practice [Page 34] RFC 4579 SIP CC Conferencing for UAs August 2006 Alice Focus Bob Carol | | | | | OPTIONS sip:Conf-ID F1 | | |------------------->| | | | 200 OK Contact:Conf-ID;isfocus F2 | | |<-------------------| | | 図13. 参加者がフォーカスのURIの機能をクエリ 以下に図13のメッセージF2の詳細なメッセージ例を示す。応答に基づいて、 AliceのUAは、URIがカンファレンスURIであることと、応答側のUAが多くの SIP呼制御拡張に対応するフォーカスであることを知る。 応答の詳細は以下の通り。 F2 SIP/2.0 200 OK Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKhjsas87 ;received=192.0.2.4 To: ;tag=93810874 From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 63104 OPTIONS Contact: ;isfocus Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Allow-Events: refer, conference Accept: application/sdp, message/sipfrag Accept-Language: en Supported: replaces, join, gruu Content-Type: application/sdp Content-Length: ... v=0 o=focus431 2890844563 2890842835 IN IP4 ms5.conf.example.com s=- i=Example Conference Hosted by Example.com u=http://conf.example.com/3402934234 e=3402934234@conf-help.example.com p=+18882934234 c=IN IP4 ms5.conf.example.com t=0 0 m=audio 0 RTP/AVP 0 3 5 7 m=video 0 RTP/AVP 31 32 これらの各ヘッダーから得られる有益な情報について、詳しくは以下に記載 する。 Johnston & Levin Best Current Practice [Page 35] RFC 4579 SIP CC Conferencing for UAs August 2006 Allow: REFER、SUBSCRIBE、NOTIFYなどのメソッドに対応することは、ユー ザーエージェントが呼制御およびSIP Eventsに対応していることを示す。 Accept: message/sipfrag [12]などのボディに対応することは、呼制御に対 応していることも示す。 Allow-Events: REFER[4]、カンファレンスなどのイベントパッケージへの対 応を示す。 Supported: Replaces、Join、gruuなどの拡張への対応を示す。 Contact: Contactヘッダーフィールドに「isfocus」フィーチャーパラメー タが存在することは、そのURIがカンファレンスURIであり、そのUAがフォー カスであることを示す。 6. セキュリティの考慮事項 この仕様は、カンファレンスアプリケーションにおけるフォーカスUAと参加 者UA間の相互作用について定義している。結果として、RFC 3261 [1]に定義 されているセキュリティの考慮事項とメカニズムが適用される。ただし、こ こで論じるカンファレンス固有の側面もいくつかある。 カンファレンスには、多大なネットワーク帯域と計算リソースが使用される ことがよくある。結果として、単純なピアツーピアセッションよりも認証が さらに重要になる。カンファレンスフレームワーク[8]で論じられているよう に、多くの場合、カンファレンスにはカンファレンスリソースに関するポリ シーがある。フォーカスは、参加者をカンファレンスに追加してカンファレ ンスリソースの使用を許可する前に、参加者を認証すべきである[SHOULD]。 認証結果に基づいて、参加者ごとに異なるポリシーをフォーカスが適用する こともできる。 参加者は、フォーカス経由で複数の参加者と対話することになる。結果とし て、参加者はフォーカスを認証すべきであり、カンファレンスに使用される フォーカスが信頼できることを確認すべきである。通常のSIP認証メカニズム は、参加者とフォーカスの認証に適している。たとえば、共有秘密を利用し たSIPダイジェスト、証明書、セキュリティで保護されたSIP IDメカニズム などである。さらに、TLSによって提供されるホップごとの相互認証と機密 性を達成できるように、フォーカスはSecure SIP接続に対応すべきであ る[SHOULD]。 参加者とフォーカス間のSIPダイアログで、フォーカスは「isfocus」フィー チャータグを使用して、そのUAがフォーカスとして動作していることを示 す。したがって、ContactなどのSIPヘッダーフィールドは、エンドツーエン ドの完全性を保持すべきである[SHOULD]。参加者とフォーカスは、S/MIME など、エンドツーエンドの完全性メカニズムに対応すべきである[SHOULD]。 Johnston & Levin Best Current Practice [Page 36] RFC 4579 SIP CC Conferencing for UAs August 2006 参加者が他のUAをフォーカスと認識した後は、SIP呼制御操作(REFERなど)を 実装したり、フォーカスのカンファレンスパッケージに対するサブスクリプ ションを試行したりすることができる。RFC 3515 [4]に記載されているセ キュリティの考慮事項は、すべてのREFER呼制御操作に適用される。フォー カスと参加者は、許可する呼制御操作を決定するためのポリシーを適用す る。 カンファレンスパッケージに対するサブスクリプションを受け入れるフォー カスは、RFC 4575 [9]に記載されているセキュリティの考慮事項に従う必要 がある。通知には機密情報が記載されている可能性があるため、サブスクリ プションを認証し、機密性と完全性を保護して通知を配信すべきである。参 加者は他の参加者を直接認証することはできないため、認証の実行はフォー カスに頼る必要がある。 フォーカスは、カンファレンスポリシーまたはシグナリングによる表現に 従って、プライバシに関する参加者のリクエストに対応しなければならな い[MUST]。たとえば、カンファレンスに参加し、Privacyヘッダーフィール ド[10]を使用する参加者のID情報は、フォーカスが他の参加者に公開しては ならない。他のシグナリングプロトコルを使用する場合、そのプロトコルに よってシグナリングされたプライバシも尊重する必要がある。 7. 寄稿者 Rohan Mahy、Jonathan Rosenberg、Roni Even、Petri Koskelainen、Brian Rosen、Paul Kyzivat、Eric Burgerの各氏、およびメーリングリストの議論 に参加された方々に感謝を述べたい。 また、Miguel Garciaに、最終的な確認と提案を詳しく行っていただいたこ とに感謝を述べたい。 Johnston & Levin Best Current Practice [Page 37] RFC 4579 SIP CC Conferencing for UAs August 2006 8. 参考文献 8.1. 規範となる参考文献 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] 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. [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [4] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [5] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. [6] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. [7] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004. [8] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006. [9] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006. [10] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. 8.2.有益な参考文献 [11] Campbell, B. and R. Sparks, "Control of Service Context using SIP Request-URI", RFC 3087, April 2001. [12] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002. [13] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, December 2003. Johnston & Levin Best Current Practice [Page 38] RFC 4579 SIP CC Conferencing for UAs August 2006 [14] Levin, O. and R. Even, "High Level Requirements for Tightly Coupled SIP Conferencing", RFC 4245, November 2005. [15] Mahy, R., "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", Work in Progress, February 2005. [16] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Work in Progress, February 2005. [17] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation Protocol Call Control - Transfer", Work in Progress, April 2005. [18] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005. Johnston & Levin Best Current Practice [Page 39] RFC 4579 SIP CC Conferencing for UAs August 2006 付録A: カンファレンスを意識しないUAによるカンファレンス作成 ここでは、カンファレンスを意識しないUAを操作するユーザーが、参加者を カンファレンスを作成して、参加者を追加する方法について論ずる。この方 法は推奨されない[NOT RECOMMENDED]ため、付録に記載する。臨時(ad-hoc) の方法または手動の方法でカンファレンスを作成する場合、このシナリオで 行うことが推奨される。ただし、このシナリオが含まれたのは、シナリオを 網羅するためである。 ユーザー(人間)は、システムの規則に従ってカンファレンスURIを選択し、 INVITEのRequest-URIに挿入する。これと同じURIは、特定のアドレス指定仕 様に従うフォーカスによって、Contactヘッダーフィールドで反復される。 SIP以外の手段によって新規の参加者を追加することができる(Webページ、 電子メール、IMなどを使用して選択したカンファレンスURIを発行)。ある いは、カンファレンスを意識しないUAは、目的のユーザーとセッションを確 立してからカンファレンスURIに転送[17]するSIP呼制御を使用することに よって、カンファレンスに参加者を追加することができる。このシナリオで 注意が必要なのは、ユーザー(人間)のみがカンファレンスアプリケーション を意識しており、カンファレンスを意識しないUAはRFC 3261 [2]のみに対応 する必要があり、呼の転送はオプションで対応する、ということである。 これを機能させることによって、システムにアドレス指定仕様が課せられ る。サービスまたは実装上の選択として、システムは、カンファレンスの作 成者がカンファレンスURIのユーザー部分を選択できるようにすることがで きる。ただし、そのためにURI形式がユーザーとシステム間で合意が取れる 必要がある。 たとえば、サービスプロバイダは、すべてのカンファレンスURI用にドメイ ンconf.example.comを予約する可能性がある。conf.example.comドメイン内 のURIは、フォーカスに解決される。フォーカスは、conf.example.comドメ インに含まれる未知のユーザー部分を、Request-URIとしてのカンファレン スURIを使用して作成されるカンファレンスに対するリクエストとして解釈 できるように、構成される可能性がある。たとえば、 sip:k32934208ds72@conf.example.comのRequest-URIとともに送信される INVITEは、カンファレンスを作成するフォーカスにルートされる可能性が ある。このカンファレンスURIは、新規に作成されたフォーカスによって登 録され、conf.example.comドメイン内でカンファレンスURIとしてルート可 能になる。返されるContactヘッダーフィールドは以下のようになる。 Contact: ;isfocus Johnston & Levin Best Current Practice [Page 40] RFC 4579 SIP CC Conferencing for UAs August 2006 ただし、この手法は、ユーザー(人間)とフォーカスの間で採用される仕様に 依存する、ということに注意。また、この手法は、カンファレンス名の衝突 に対しては耐性がない。第2のユーザーが、新規カンファレンスの作成時に、 既存カンファレンスと同じユーザー部分を選択してしまった場合、結果と して、新規カンファレンスが作成される代わりに、第2のユーザーは既存カ ンファレンスに追加されることになる。 結果的に、カンファレンスURIがフォーカスによって生成された不透明なURI である場合、カンファレンス作成の手法が望ましい。 コールフロー例を図14に示す。参加者Aliceは(フォーカスのドメインと合意 が取れている何らかの仕様を使用して)カンファレンスURIを作成し、フォー カスを作成するそのURIにINVITEを送信する。フォーカスはカンファレンス を作成し、同じカンファレンスURIをINVITEに対する200 OK応答で返す(カン ファレンスを意識しないUAはこのINVITEを無視する)。 Alice Focus Bob Carol | | | | | Aliceはカンファレンスを作成し、カンファレンスURIを選択。 | | | | | | INVITE sip:Conf-ID F1 | | |------------------->| | | | 180 Ringing F2 | | | |<-------------------| | | | 200 OK Contact:Conf-ID;isfocus F3 | | |<-------------------| | | | ACK F4 | | | |------------------->| | | | RTP | | | |<==================>| | | 図14. 推奨されない - カンファレンスを意識しない参加者がカンファレン スを作成 Johnston & Levin Best Current Practice [Page 41] RFC 4579 SIP CC Conferencing for UAs August 2006 著者の連絡先 Alan Johnston Avaya St. Louis, MO 63102 EMail: alan@sipstation.com Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: oritl@microsoft.com Johnston & Levin Best Current Practice [Page 42] RFC 4579 SIP CC Conferencing for UAs August 2006 完全な著作権表示 Copyright (C) The Internet Society (2006). 本文書は、BCP 78に含まれる権利、ライセンス、制限の対象となり、BCP 78 に記載されている例外に従い、著者はすべての権利を持つ。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄 稿者が代表となる組織、または寄稿者を後援する組織(存在する場合)、イ ンターネット協会およびIETFは、この情報がいかなる権利も侵害していない という保証、商用利用および特定目的への適合性への保証を含め、また、こ れらだけに限らずすべての保証について、明示的もしくは暗黙的の保証は行 われない。 知的財産権 IETFは、本文書で記述される技術の実装または使用に関して要求される、知 的所有権または他の諸権利の有効性または範囲に関して、またはこのような 権利下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何 ら見解を持たない。このような権利を確認する独自の取り組みを行ったこと も示さない。RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79 に記載されている。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセ ンスの保証すべて、またはこのような所有権の使用に関して、本仕様の実装 者またはユーザーが一般的なライセンスまたは許可の取得を試みた結果につ いては、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能 である。 IETFは、この規格を実装するために必要とされる技術の範囲にある可能性が ある、すべての著作権、特許または特許アプリケーション、あるいは他の所 有権について、すべての関連団体に対して配慮するよう依頼している。情報 については、IETFの ietf-ipr@ietf.org まで連絡されたい。 謝辞 RFC編集職務のための資金は、IETF Administrative Support Activity (IASA)によって提供されている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2007年 ----------------------------------------------------------------------- Johnston & Levin Best Current Practice [Page 43]