Network Working Group                                       J. Rosenberg
Request for Comments: 4575                                 Cisco Systems
Category: Standards Track                                 H. Schulzrinne
                                                     Columbia University
                                                           O. Levin, Ed.
                                                   Microsoft Corporation
                                                             August 2006


                     カンファレンスステートに関する
             セッション開始プロトコル(SIP)イベントパッケージ
                  A Session Initiation Protocol (SIP)
                   Event Package for Conference State

本文書の位置付け

   本文書は、インターネットコミュニティのためのインターネット標準化過程
   プロトコルを規定し、改善のための議論や提案を依頼するものである。標準
   化の段階や、プロトコルの位置付けについては、最新版の"Internet 
   Official Protocol Standards" (STD 1)を参照されたい。本文書の配信は無
   制限である。

著作権表記

   Copyright (C) The Internet Society (2006).

概要

   本文書は、セッション開始プロトコル(Session Initiation Protocol/SIP)
   イベントフレームワークを使用して、厳密に組み合わされたカンファレンス
   のカンファレンスイベントパッケージと、このパッケージの通知で使用され
   るデータ形式を定義する。カンファレンスパッケージを使用すると、ユー
   ザーはカンファレンスUniform Resource Identifier (URI)にサブスクライ
   ブできるようになる。送信される通知は、このカンファレンスのメンバシッ
   プにおける変化、およびオプションでその他のカンファレンスコンポーネン
   トのステートにおける変化である。


















Rosenberg, et al.           Standards Track                     [Page 1]

RFC 4575                   Conference Package                August 2006


目次

   1. はじめに ....................................................... 4
   2. 用語 ........................................................... 4
   3. カンファレンスイベントパッケージ ............................... 4
      3.1. イベントパッケージ名  ..................................... 5
      3.2. フィルタ処理  ............................................. 5
      3.3. サブスクリプションの有効期間  ............................. 5
      3.4. NOTIFYのボディ  ........................................... 5
      3.5. SUBSCRIBEリクエストのノーティファイア処理 ................. 6
      3.6. NOTIFYリクエストのノーティファイア生成  ................... 6
      3.7. NOTIFYリクエストのサブスクライバ処理  ..................... 6
      3.8. 分岐したリクエストの処理  ................................. 7
      3.9. 通知の頻度  ............................................... 7
      3.10. ステートエージェント ..................................... 7
   4. カンファレンスドキュメント ..................................... 7
      4.1. 書式  ..................................................... 7
      4.2. 名前空間  ................................................. 7
      4.3. バージョン処理  ........................................... 8
      4.4. 部分的通知メカニズム  ..................................... 8
      4.5. 要素キー  ................................................. 9
      4.6. 一貫したステートの構築手順  ............................... 9
   5. カンファレンスデータ .......................................... 11
      5.1. 概要  .................................................... 11
      5.2. <conference-info> ........................................ 13
      5.3. <conference-description>  ................................ 14
           5.3.1. <conf-uris>  ...................................... 14
           5.3.2. <service-uris> .................................... 15
           5.3.3. <maximum-user-count> .............................. 16
           5.3.4. <available-media>  ................................ 16
      5.4. <host-info> .............................................. 17
           5.4.1. <display-text> .................................... 17
           5.4.2. <web-page> ........................................ 17
           5.4.3. <uris> ............................................ 17
      5.5. <conference-state>  ...................................... 17
           5.5.1. <user-count> ...................................... 17
           5.5.2. <active> .......................................... 18
           5.5.3. <locked> .......................................... 18
      5.6. <users>とその<user>下位要素 .............................. 18
           5.6.1. <display-text> .................................... 19
           5.6.2. <associated-aors>  ................................ 19
           5.6.3. <roles>  .......................................... 19
           5.6.4. <languages>  ...................................... 19
           5.6.5. <cascaded-focus> .................................. 19
           5.6.6. <endpoint> ........................................ 20
      5.7. <endpoint>  .............................................. 20
           5.7.1. <display-text> .................................... 20
           5.7.2. <referred> ........................................ 21



Rosenberg, et al.           Standards Track                     [Page 2]

RFC 4575                   Conference Package                August 2006


           5.7.3. <status> .......................................... 21
           5.7.4. <joining-method> .................................. 22
           5.7.5. <joining-info> .................................... 23
           5.7.6. <disconnection-method> ............................ 23
           5.7.7. <disconnection-info> .............................. 23
           5.7.8. <media>  .......................................... 24
           5.7.9. <call-info>  ...................................... 24
      5.8. <media> .................................................. 24
           5.8.1. <display-text> .................................... 25
           5.8.2. <type> ............................................ 25
           5.8.3. <label>  .......................................... 25
           5.8.4. <src-id> .......................................... 25
           5.8.5. <status> .......................................... 26
      5.9. サイドバー  .............................................. 26
           5.9.1. <sidebars-by-ref>  ................................ 26
           5.9.2. <sidebar-by-val> .................................. 26
   6. XMLスキーマ  .................................................. 26
   7. 例 ............................................................ 35
      7.1. 基本的な例  .............................................. 35
      7.2. 高度な例  ................................................ 36
   8. セキュリティの考慮事項 ........................................ 40
      8.1. 接続のセキュリティ  ...................................... 40
      8.2. 認可の考慮事項  .......................................... 41
   9. IANA条項 ...................................................... 41
      9.1. カンファレンスイベントパッケージ登録  .................... 41
      9.2. application/conference-info+xml MIME登録  ................ 42
      9.3. URN下位名前空間登録 ...................................... 43
      9.4. XMLスキーマ登録 .......................................... 43
      9.5. URI Purposesの下位登録の確立  ............................ 44
   10. 謝辞  ........................................................ 45
   11. 参考文献  .................................................... 45
   11.1. 規範となる参考文献  ........................................ 45
   11.2. 有益な参考文献  ............................................ 46


















Rosenberg, et al.           Standards Track                     [Page 3]

RFC 4575                   Conference Package                August 2006


1.  はじめに

   セッション開始プロトコル(Session Initiation Protocol/SIP)のイベントフ
   レームワーク[10]は、SIPネットワーク内のイベントに対する、サブスクライ
   ブおよび通知の受信に関する一般的なメカニズムを定義している。また、
   パッケージとは、定義済みの複数イベントのイベントフレームワークに特化
   した「インスタンス化(instantiation)」である、というの概念が紹介され
   ている。本文書では、カンファレンスと厳密に組み合わされたSIPイベント
   パッケージを定義する。このイベントパッケージは、SIPカンファレンス
   フレームワーク[16]で概説されているような、カンファレンスの通知サービ
   スで使用することができる。[9]に記載されているが、カンファレンスURIに
   対するサブスクリプションは、カンファレンスを操作しているフォーカスに
   ルートされる。フォーカスはノーティファイアとして動作し、カンファレン
   スステートの更新をクライアントに伝達する。

   このパッケージで提供する情報は、カンファレンス識別子、カンファレンス
   参加者(オプションで参加者のステータスとメディア記述も)、カンファレン
   スの補足(sidebars)、カンファレンスサービスURIなどで構成される。

2.  用語

   本文書では、「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、
   「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、
   「MAY」、「OPTIONAL」のキーワードはRFC 2119 [1]の記述に従って解釈さ
   れるべきであり、準拠する実装に対する要求レベルを示すものである。

   本文書は、カンファレンスフレームワーク[16]で定義されているカンファレ
   ンス用語を使用する。さらに、カンファレンスまたは下位カンファレンスの
   参加者をまとめて呼ぶときに、「登録者(roster)」という用語を使用する。

3.  カンファレンスイベントパッケージ

   カンファレンスイベントパッケージを使用すると、ユーザーはカンファレン
   スに関する情報にサブスクライブできるようになる。SIPでは、カンファレ
   ンスはURIで表される。このSIPユーザーエージェント(UA)にルートされる
   URIは、フォーカスと呼ばれ、カンファレンスフレームワーク[16]に記載さ
   れるように、カンファレンス内の全ユーザーが相互に通信できるようにする
   役割を持つ。フォーカスは、カンファレンスのステートについて、サブスク
   ライバに対して通知できる情報を持っている。

   カンファレンスのある参加者が、もう1人のフォーカスである、という場合
   もある。より完全な参加者リストを提示するには、フォーカスは、カスケー
   ドされたカンファレンスの参加者リストを検出できるように、他のフォーカ
   スのカンファレンスパッケージにサブスクライブしてもよい[MAY]。それか
   ら、この情報は、本パッケージで規定される<cascaded-focus>要素を使用
   して、通知に含むことができる。




Rosenberg, et al.           Standards Track                     [Page 4]

RFC 4575                   Conference Package                August 2006


   このセクションでは、RFC 3265 [10]の規定に従って、SIP固有のイベント通
   知パッケージを定義するための詳細を記載する。

3.1.  イベントパッケージ名

   このイベントパッケージの名称は「conference」である。このパッケージ
   名は、RFC 3265 [10]で定義されるように、EventおよびAllow-Eventsヘッ
   ダーで伝達される。

3.2.  フィルタ処理

   フィルタは、カンファレンスのサブスクリプションに適用できるが、望まし
   い機能であり、将来的な標準化活動の主題として考えることができる。本文
   書では、SUBSCRIBEボディに含めるカンファレンスパッケージのフィルタは
   定義しない。

   ボディなしで送信されたカンファレンスパッケージのSUBSCRIBEは、デフォ
   ルトでサブスクリプションのフィルタ処理ポリシーを暗示する。デフォルト
   ポリシーを以下に示す。

   o  通知は、カンファレンスのステートに何らかの変更があるたびに毎回生成
      される。

   o  通知には、通常、完全なステートは含まれず、変更されたステートが示さ
      れるのみである。例外は、SUBSCRIBEに対する応答で送信されるNOTIFYで
      ある。この場合のNOTIFYには、サブスクライバから要求された情報の完
      全なステートが含まれる。

3.3.  サブスクリプションの有効期間

   カンファレンスに対するサブスクリプションのデフォルトの有効期間は、1時
   間である。RFC 3265 [10]に定義されているように、カンファレンスが終了す
   ると、そのカンファレンスに対するすべてのサブスクリプションは、
   「noresource」という理由で終了する。

3.4.  NOTIFYのボディ

   RFC 3265 [10]に従って、NOTIFYメッセージには、サブスクライブされた
   リソースのステートが記述されているボディを含める。このボディは、
   SUBSCRIBEのAcceptヘッダーフィールドに列挙された形式か、Acceptヘッダー
   フィールドがSUBSCRIBEから省略された場合は、パッケージ独自のデフォルト
   である。

   本イベントパッケージでは、通知のボディにはカンファレンスの状態を説明
   したカンファレンス情報ドキュメントが含まれる。すべてのサブスクライバ
   とノーティファイアは、セクション9と5に記載される
   「application/conference-info+xml」データ形式に対応しなければならな



Rosenberg, et al.           Standards Track                     [Page 5]

RFC 4575                   Conference Package                August 2006


   い[MUST]。デフォルトでは、つまりAcceptヘッダーフィールドがSUBSCRIBE
   リクエストに指定されていない場合、NOTIFYには
   「application/conference-info+xml」データ形式のボディが含まれる。
   Acceptヘッダーフィールドが存在する場合、
   「application/conference-info+xml」を含めなければならない[MUST]。
   また、他のタイプを含めてもよい[MAY]。

3.5.  SUBSCRIBEリクエストのノーティファイア処理

   カンファレンス情報には、機密性の高い情報が含まれる。
   そのため、すべてのサブスクリプションは、承認(approval)の前に、認証
   (authenticated)および認可(authorized)されるべきである[SHOULD]。認可
   ポリシーは、通例通り、管理者の裁量にある。

   ただし、カンファレンスの全ユーザーは、カンファレンスイベントパッケー
   ジにサブスクライブすることを許可されることが推奨される[RECOMMENDED]。

3.6.  NOTIFYリクエストのノーティファイア生成

   新規参加者が参加するとき(つまり、「接続」するとき)、または参加者がカ
   ンファレンスを退席するとき(つまり、「接続解除」するとき)、カンファレ
   ンスステートの通知を生成すべきである[SHOULD]。

   ローカルのフォーカスのポリシーに従って、参加者のステータスの新たな変
   化、メディアタイプの変化、その他のオプション情報が、フォーカスによっ
   て報告されてもよい[MAY]。

   サイドバー登録者の変化は、フォーカスから参加者に対して報告すべきであ
   り[SHOULD]、ローカルポリシーに従って他のユーザーに報告してもよい
   [MAY]。

   カンファレンス識別子とサービスURIの変化は、フォーカスからカンファレ
   ンスパッケージサブスクライバに対して報告すべきである[SHOULD]。

   カンファレンスステート情報の変化は、フォーカスからカンファレンス
   パッケージサブスクライバに対して報告してもよい[MAY]。

3.7.  NOTIFYリクエストのサブスクライバ処理

   SIPイベントのフレームワークでは、パッケージ独自の方法でサブスクライ
   バがNOTIFYリクエストを処理する方法、および、特に、サブスクライブされ
   たリソースの一貫したビューを構築するためにNOTIFYを使用する方法を指定
   するパッケージが期待されている。

   通常、カンファレンスパッケージに対するNOTIFYには、カンファレンスの
   ステートが変わったユーザーに関する情報のみが含まれる。全ユーザーの
   ステート全体の整合性がとれたビューを構築するために、カンファレンス
   パッケージに対するサブスクライバは、長期間に渡って受け取ったNOTIFYを
   結合する必要がある。




Rosenberg, et al.           Standards Track                     [Page 6]

RFC 4575                   Conference Package                August 2006


   このパッケージ内の通知で、部分的情報を伝達することができる。
   つまり、サブスクリプションに関連するステートのサブセットについての情
   報を示すことができる。これは、一貫性があり矛盾のないステートを構築す
   るには、明確なアルゴリズムを定義する必要があるということを意味する。
   この仕組みの詳細は、個々のドキュメントタイプ固有のものである。
   application/ conference-info+xmlドキュメントから整合性のとれた情報を
   構築するための情報については、セクション4.6を参照のこと。

3.8.  分岐したリクエストの処理

   本質的に、本パッケージで対応するカンファレンスは、中央に集中する。し
   たがって、カンファレンスに対するSUBSCRIBEリクエストは、通常、分岐すべ
   きではない。ネットワークで分岐が発生した場合、このパッケージのサブス
   クライバは、単一のSUBSCRIBEリクエストの結果として複数のSIPダイアログ
   を確立してはならない[MUST NOT]。複数のフォーカスがカスケードする場
   合、詳細なカンファレンス情報は、参加している各フォーカスとの間に個々
   のSUBSCRIBEダイアログを確立することで取得することができる。

3.9.  通知の頻度

   輻輳制御(congestion control)の理由から、通知頻度が過度にならないよう
   にすることが重要である。したがって、サーバーは、毎5秒に1回よりも速い
   レートで、1個のサブスクライバに対する通知を生成しないことを推奨す
   る[RECOMMENDED]。

3.10.  ステートエージェント

   カンファレンスステートは、カンファレンスが存在する要素に、完全に保持
   されている。したがって、カンファレンスフォーカスは、サブスクリプショ
   ンを処理するための最適な要素である。カスケードされたフォーカスは、こ
   のパッケージのステートエージェントを実装してもよい(RFC 3265 [10]の定
   義に従う)。

4.  カンファレンスドキュメント

4.1.  書式

   カンファレンス情報は、XMLドキュメントとして、整形済みかつ有効でなけ
   ればならない[MUST]。また、拡張可能マークアップ言語(Extensible Markup
   Language/XML) 1.0に基づかなければならず[MUST]、UTF-8 [14]を使用して
   エンコードしなければならない[MUST]。

4.2.  名前空間

   本仕様では、カンファレンス情報ドキュメントとドキュメントの断片を特定
   するために、XML名前空間を利用する。本仕様で定義される要素に対する名前
   空間URIは、Uniform Resource Namespace (URN) [2]であり、[6]で定義さ




Rosenberg, et al.           Standards Track                     [Page 7]

RFC 4575                   Conference Package                August 2006


   れ、RFC 3688 [21]で拡張される名前空間識別子「ietf」を使用している。
   このURNを以下に示す。

   urn:ietf:params:xml:ns:conference-info

4.3.  バージョン処理

   カンファレンス情報は、ルート要素が<conference-info>の階層的なXML構造
   で記述される。ルート要素は、ドキュメント内の全要素について意味がある
   バージョン番号を伝達する、スキーマ内で唯一の要素である。全体のカン
   ファレンス情報はこのバージョン番号に関連付けられている。

   「version」属性はルートの<conference-info>要素に含めなければならな
   い[MUST]。

4.4.  部分的通知メカニズム

   本仕様は、以下に示すように、「state」属性を使用して基本の部分的通知
   メカニズムを定義する。このメカニズムは、すべてのサブスクライブするク
   ライアントが対応しなければならない[MUST]。将来的に、その他の一般的な
   部分的通知メカニズムを定義し、このパッケージに適用される可能性もあ
   る。

   <conference-info>の階層的XML構造のすべての下位要素は、部分的通知が許
   容されているかどうかによって2つのグループに分類できる。頻繁に変化し
   やすい大部分のデータを伝達する要素は、部分的通知が許容されており、
   「state」属性が所属している。このスキーマのすべての将来的な拡張は、
   このメカニズムも使用できる拡張要素を定義しなければならない[MUST]。他
   のすべての要素は、分解不能(atomic)なデータ断片としてのみ更新すること
   ができる。

   本仕様で定義される部分的通知メカニズムを使用できる要素リストを以下に
   示す。(将来的な部分的通知メカニズムが、新規要素に適用される可能性も
   ある。)

   o  要素<conference-info>
   o  要素<users>
   o  要素<user>
   o  要素<endpoint>
   o  要素<sidebars-by-val>
   o  要素<sidebars-by-ref>







Rosenberg, et al.           Standards Track                     [Page 8]

RFC 4575                   Conference Package                August 2006


   「state」属性値は、要素に関する報告情報が「full (完全)」か「partial
   (部分的)」かを示す。または要素がカンファレンスステートドキュメントか
   ら「deleted (削除)」されたかどうかを示す。「state」属性のデフォルト値
   は「full」である。

   ドキュメントの子要素の「state」属性は、親の「state」と一致しなければ
   ならない[MUST]。つまり、親の「state」が「full」の場合、子の「state」
   も「full」でなければならない[MUST]。親の「state」が「partial」の場
   合、子の「state」は「partial」、「full」、または「deleted」のいずれ
   かの可能性がある[MAY]。「deleted」「state」の親要素に子要素は含める
   べきではない[SHOULD NOT]。パッケージのサブスクライバは、「deleted」
   の親の子要素に提供された情報を無視しなければならない[MUST]。

4.5.  要素キー

   定義済みXMLスキーマには、共通する親の下位要素の中で一意な識別のプロパ
   ティがある。これによって、本文書で定義される部分的通知メカニズムを使
   用することができる。このプロパティは、共通する親の下に複数回出現する
   各下位要素に対してキーを定義することで達成される。

   本仕様の文脈では、要素キーは必須属性群または要素の下位要素群である。
   キー値は、同じ種類の兄妹の中で、その要素に対して一意でなければならな
   い[MUST]。

   本仕様の文脈では、xs:anyURIという種類の2つのキーは、キーのUTF-8表
   記(URIに含めることができるすべてのURIパラメータを含む)が同一の場合、
   等値と見なされる。したがって、このようなキーに相対的URIや語彙的なホ
   ワイトスペースを使用することは推奨されない[NOT RECOMMENDED]。

   本仕様の定義により、このようなキーを持つ(親要素の部分的通知に従う)要
   素リストを以下に示す。

   o  要素<user>はキー「entity」として使用する
   o  要素<endpoint>はキー「entity」として使用する
   o  要素<media>はキー「id」として使用する
   o  要素<entry> (<sidebars-by-val>の子)はキー「entity」として使用する
   o  要素<sidebars-by-ref>はキー「uri」として使用する

4.6.  一貫したステートの構築手順

   このセクションでは、サブスクライバがカンファレンスパッケージに対して
   一貫したカンファレンスステートを構築するアルゴリズムについて説明す
   る。ソフトウェアプログラミングによる抽出を使用して、サブスクライバ



Rosenberg, et al.           Standards Track                     [Page 9]

RFC 4575                   Conference Package                August 2006


   は、全体のカンファレンスドキュメントに対して単一のローカルバージョン
   番号と、スキーマの各要素について1つのローカル要素インスタンスを維持
   する。また、キーを持つ要素(前述の定義に従う)ごとに、サブスクライバ
   は、各既存のキー値について1行を持つ仮想的な表を維持する。

   「full」ドキュメントを含むNOTIFYを初めて受信したとき
   (<conference-info>要素の「state」属性値で示される)、カンファレンス
   パッケージのサブスクライバは、受信した<conference-info>の「version」
   属性値にローカルの「version」番号を設定し、受信情報でローカルデータ
   を作成しなければならない[MUST]。

   新規ドキュメントを受信するたびに、ローカルバージョン番号値と、新規の
   受信ドキュメント内の「version」値が比較される。ドキュメントの値が
   ローカルのバージョン番号以下の場合、そのドキュメントは破棄され、処理
   は行われない。

   その他の場合で、受信したNOTIFYに「full」または「deleted」ステートが
   含まれる場合、カンファレンスパッケージのサブスクライバは、受信した
   <conference-info>の「version」属性値にローカル「version」番号を設
   定し、ローカル情報を受信ドキュメントで置換しなければならない[MUST]。
   <conference-info>要素に「deleted」ステートを受信することは、カンファ
   レンスの存続が中止されたことを示す。また、この場合、サブスクライバ
   はExpires = 0のSUBSCRIBEを送信してサブスクリプションを停止すべきであ
   る[SHOULD]。

   その他の場合(つまり、受信したNOTIFYに「partial」ステートが含まれる
   場合)で、受信ドキュメントの「version」番号が前のローカルバージョン番
   号よりも1つ高い場合、サブスクライバはサブスクリプションの更新リクエ
   ストを生成して完全なステート通知をトリガしなければならない[MUST]。ド
   キュメントの「version」番号がローカルバージョン番号よりも1つ高い場
   合、それに従ってローカルバージョン番号は更新され、後述のようにそのド
   キュメントはローカルコンテンツの更新に使用される。

   受信ドキュメントに含まれる<conference-info>要素の各下位要素について、

   1. 要素に「full」ステートが含まれる場合、全体のローカル要素コンテン
      ツは消去され、ドキュメントから再作成される。

   2. その他の場合で要素に「deleted」ステートが含まれる場合、全体の要素
      はローカルコンテンツから削除しなければならない[MUST]。

   3. その他の場合で要素に「partial」ステートが含まれる場合、





Rosenberg, et al.           Standards Track                    [Page 10]

RFC 4575                   Conference Package                August 2006


      3.1. キーがある要素の場合、サブスクライバは更新で受信したキーと
           ローカル表のキーとを比較する。

           3.1.1. キーがローカル表に存在しない場合、行が追加され、その
                  コンテンツは更新の要素情報に設定される。

           3.1.2. その他の場合で同じ値のキーが存在する場合、行の各下位
                  要素について、手順3.2のアルゴリズムが適用される。

      3.2. スキーマで受信した各分解不能要素について、要素全体が新しい情
           報で置換される。スキーマで受信した各非分解不能要素に「state」
           属性が含まれないか、「state」属性が「full」に設定されている
           場合、要素全体が新しい情報で置換される。また、「state」属性
           が「deleted」に設定された各要素は、ローカルコンテンツから全
           体の要素が削除される。

      3.3. 「state」属性が「partial」に設定された各非分解不能要素は、手
           順3.1以降のアルゴリズムが再帰的に適用される。

5.  カンファレンスデータ

5.1.  概要

   <conference-info>ドキュメント形式は、カンファレンスとカンファレンス
   の参加に関する情報を伝達するために設計されている。以下の非規範的な図
   は、この形式に使用される全体の階層例である。カンファレンスには、複数
   のエンドポイントで表現できるユーザーが含まれ、それぞれに複数のメディ
   アストリームを持つことができる。また、カンファレンスは「サイドバーカ
   ンファレンス」を含めたり参照したりすることができる。サイドバー情報が
   <sidebars-by-val>要素のカンファレンス情報ドキュメントに組み込まれる
   場合、各<entry>要素はサイドバーを表し、<conference-info>トップレベル
   要素に許容されている任意の下位要素を含めることができる。













Rosenberg, et al.           Standards Track                    [Page 11]

RFC 4575                   Conference Package                August 2006


   conference-info
     |
     |-- conference-description
     |
     |-- host-info
     |
     |-- conference-state
     |
     |-- users
     |    |-- user
     |    |    |-- endpoint
     |    |    |    |-- media
     |    |    |    |-- media
     |    |    |    |-- call-info
     |    |    |
     |    |    |-- endpoint
     |    |         |-- media
     |    |-- user
     |         |-- endpoint
     |              |-- media
     |

     |-- sidebars-by-ref
     |    |-- entry
     |    |-- entry
     |
     |-- sidebars-by-val
          |-- entry
          |    |-- users
          |         |-- user
          |         |-- user
          |-- entry
               |-- users
                    |-- user
                    |-- user
                    |-- user

   ほとんどの場合、本文書は、情報(カンファレンスドキュメントによってサブ
   スクライバに提示される情報)をフォーカスが取得する方法を必須としない。
   多くの場合、情報は呼のシグナリングから動的に知ることができる。また、
   管理者が手動で作成することもできる。いずれの場合もローカルポリシーに
   従う。本文書は、サブスクライバが適切に解釈できるように、XML要素の意
   味を規定する。情報の一部は自動装置による処理を意図したもので、その他
   は人間の使用のみを意図している。たとえば、要素<conf-uris>、
   <service-uris>、<available-media>、<host-info>、<endpoint>、<media>




Rosenberg, et al.           Standards Track                    [Page 12]

RFC 4575                   Conference Package                August 2006


   の下位要素<display-text>は、人間のサブスクライバに対してのみ表示され
   ることを意図している。

   本文書には、特定の情報をサブスクライバに通信すべき[SHOULD]であると複
   数の箇所で記載しているが、特定のカンファレンスパッケージのサブスクラ
   イバ(たとえば、モデレータ、管理者、またはカスケードされたフォーカス
   など)は、正しく操作するにはこの情報の正確さに頼る。したがって、カン
   ファレンスサーバーは、すべての重要な変化([SHOULD]と記載)は、各サブス
   クライバへ確実に通信しなければならない[MUST]。
   その他の場合、このような変化は、カンファレンス情報に対する全サブスク
   ライバに通信しなければならない[MUST]。

   以降のセクションでは、より詳細なXMLスキーマについて説明する。

5.2.  <conference-info>

   カンファレンス情報ドキュメントは、カンファレンスタイプのルート要素タ
   グ<conference-info>で始まる。

   以下の属性が<conference-info>に定義されている。

   entity: この属性には、カンファレンスURIが含まれる。カンファレンスURI
      は、ドキュメントに記述されているカンファレンスを特定する。これは、
      関連エンティティがカンファレンスパッケージ情報を取得するために
      SUBSCRIBEする必要があるSIP URIである。このURIは、SIPの手法によっ
      て後述のセクション5.3.1に従ってカンファレンスにアクセスするために
      使用される、URIの1つとして列挙することができる点に注意。

   state:  この属性は、ドキュメントに全体のカンファレンス情報が含まれて
      いるか(「full」)、以前のドキュメントから変更された情報のみが含ま
      れているか(「partial」)、カンファレンスの存続が中止されたか
      (「deleted」)を示す。詳細についてはセクション4を参照のこと。

   version:  この属性によって、カンファレンス情報ドキュメントの受信者は
      受信した通知を正しく並べ替えることができる。また、この属性はルー
      トの<conference-info>要素とともに使用しなければならない[MUST]。
      バージョン番号は、サブスクリプションの範囲内で1つずつ増加する32
      ビット整数である。サーバーは、サブスクライバに各通知(full、
      partial、deleted)が送信されるごと、およびカンファレンスドキュメン
      トステートの変化が報告されるごとにバージョン番号をインクリメント
      しなければならない[MUST]。部分的通知ごとに、バージョン番号は1つず
      つ増やさなければならない[MUST]。同じダイアログでの部分的通知と以
      降の完全な通知は、カンファレンスステートの変化が発生していない
      場合、同じバージョン番号を含めてもよい[MAY]。



Rosenberg, et al.           Standards Track                    [Page 13]

RFC 4575                   Conference Package                August 2006


   <conference-info>要素は、<conference- description>、<host-info>、
   <conference-state>、<users>、<sidebars-by-ref>、<sidebars-by-val>の
   各子要素から構成される。「完全な」カンファレンスドキュメントは、1つ
   以上の<conference-description>と<users>子要素を含めなければならな
   い[MUST]。

   以降のセクションでは、これら要素の詳細について説明する。完全なXML
   スキーマはセクション6で提供されている。

5.3.  <conference-description>

   <conference-description>要素は、カンファレンス全体を説明する。

   子要素の<display-text>、<subject>、<free-text>、<keywords>は、カン
   ファレンスコンテンツの説明に使用される。

   <display-text>:  人間の使用にテキスト説明文を含む。たとえば、ディレ
      クトリ内のリストなどである。

   <subject>:  カンファレンスの主題を含む。

   <free-text>:  カンファレンスの補足的でより長い説明を含む。

   <keywords>:  スペースで区切られた文字列トークンリストが含まれる。こ
      れは、カンファレンスをより適切に分類するために検索エンジンが使用
      できる。

   その他の子要素である<conf-uris>と<service-uris> は、カンファレンス関
   連のURIを記述するときに使用される。<maximum-user-count>と
   <available-media>は、全体の特性を説明するために使用される。

   この情報は、一般的にシステムカンファレンスポリシーから派生し、カン
   ファレンスのアクティブ化前に設定され、カンファレンスの継続期間中はほ
   とんど変化しない。

   以降のセクションでは、その他の要素についてより詳細に説明する。将来
   的に、他の下位要素が<conference-description>を拡張する可能性がある。

5.3.1.  <conf-uris>

   この要素には一連の<entry>子要素が含まれる。多様なシグナリング手法に
   よってカンファレンスにアクセスするために、それぞれ使用するURIを含む。
   URIの値は、カンファレンスのコンテキスト内で一意であり、<uri>下位要素
   に含めなければならない[MUST]。





Rosenberg, et al.           Standards Track                    [Page 14]

RFC 4575                   Conference Package                August 2006


   各<entry>には、カンファレンスにアクセスする際に参加者の役に立つ追加
   情報を含めてもよい[MAY]。

   <entry>要素には、人間が使用するための説明文を示す<display-text>下位
   要素を含めてもよい[MAY]。

   各<entry>要素には、URIにアクセスするときに発生した内容を記述する
   <purpose>下位要素を含めるべきである[SHOULD]。<conf-uris>とともに使用
   するように現在定義されている<purpose>値は、以下のとおりである。

   participation:  この<purpose>があるURIにアクセスすると、パーティは
      カンファレンスに参加する。

   streaming:  この<purpose>があるURIにアクセスすると、カンファレンスの
      ストリーミングが開始されるが、アクティブな参加は許可されない。

   適切なURIスキームの例として、sip:とsips: [8]、xmpp: [22]、h323: 
   [20]、tel: [19] URIなどがある。rtsp [18] URIはストリーミングに適して
   いる。

   このスキーマの将来的な拡張が新規の値を定義し、それをIANAに本仕様で確
   立した登録の下位に登録する可能性がある。

5.3.2.  <service-uris>

   この要素は、カンファレンスに使用できる補助サービスについて記述する。
   <conference-uris>と同様に、この要素には一連の<entry>子要素が含まれ
   る。各子要素は、特定のカンファレンスで使用できる多様なサービスにアク
   セスするために使用されるURIを含む。
   URIの値は、カンファレンスのコンテキスト内で一意であり、<uri>下位要素
   に含めなければならない[MUST]。

   <entry>要素には、ユーザーが使用するための説明文を示す<display-text>
   下位要素を含めてもよい[MAY]。

   各<entry>要素には<purpose>下位要素を含めるべきである[SHOULD]。
   <service-uris>とともに使用するように現在定義されている<purpose>値
   は、以下のとおりである。

   web-page:  カンファレンスに関する追加情報を含むWebページを示す。

   recording:  記録済みカンファレンスコンテキストを取得できるリンクを
      示す。

   event:  カンファレンスイベントパッケージに対するサブスクリプションを
      要求できるURIを示す。これは、一般的に、メインのカンファレンスのカ
      ンファレンスURIである。



Rosenberg, et al.           Standards Track                    [Page 15]

RFC 4575                   Conference Package                August 2006


   このスキーマの将来的な拡張が新規の値を定義し、それをIANAに本仕様で確
   立した登録の下位に登録する可能性がある。

5.3.3.  <maximum-user-count>

   この要素の値は、カンファレンスに招待できるユーザー数に関して、カン
   ファレンスドキュメントの受信者に対するヒントになる。一般的に、この値
   は、カンファレンスドキュメントの<conf-uris>で公開されているのとは異
   なる手法で、カンファレンスに参加できる全体のユーザー数を表す。この値
   は管理者が設定し、ネットワーク消費、CPU処理脳裏よく、ライセンス規則
   などローカルポリシーの組み合わせを反映する可能性がある、ということに
   注意。

5.3.4.  <available-media>

   この要素にはconference-medium-typeの一連の<entry>子要素が含まれ、そ
   れぞれに属性「label」でインデックスが付けられている。

   「label」属性は、カンファレンスサーバーが割り当てるメディアストリー
   ム識別子であり、その値は<conference-info>コンテキスト内で一意にな
   る。この属性の値は、一般的に、[17]で定義されているセッション記述プロ
   トコル(SDP)の「label」メディア属性に対応する。

   各<entry>には、カンファレンスの参加者が使用できる単一のメディアス
   トリームを記述し、以下の情報を含める。

   <display-text>:  この要素にはメディアストリームの表示テキストが含ま
      れる。

   <type>:  この要素には、メディアストリームのメディアタイプが含まれる。
      この要素の値は、SDP [3]およびそれ以降の改版の「media」に登録され
      ている値の1つにしなければならない[MUST]。たとえば、「audio」、
      「video」、「text」、「message」などである。

   <status>:  この要素は、カンファレンス参加者が使用できるメディアス
      トリームの使用可能なステータスを示す。たとえば、これは、
      「dial-out」シナリオでフォーカスがオファーするメディアストリーム
      のステータスである。通常のSIPオファー/アンサーメカニズム(RFC 3264
      [9]で定義)をダイヤルインおよびダイヤルアウトのシナリオに使用する
      と、参加者は当然ながら使用できるストリームのサブセットしか確立で
      きない(つまり、双方向が使用できる場合、一方向でのみストリームを要
      求または承認)。有効値は、SDP [3]とそれ以降の改訂の定義に従い、




Rosenberg, et al.           Standards Track                    [Page 16]

RFC 4575                   Conference Package                August 2006


      「sendrecv」、「sendonly」、「recvonly」、「inactive」である。(値
      は参加者の観点からの方向を示すことに注意。)

5.4.  <host-info>

   この要素には、カンファレンスをホストするエンティティに関する情報が含
   まれる。この情報は、カンファレンスのアクティブ化前に設定され、カン
   ファレンスの存続期間中はほとんど変化しない。ただし、他のエンティティ
   がホストするために全体のカンファレンスが移動される場合は除く。
   ホスト情報は以下の要素から構成される。

5.4.1.  <display-text>

   この要素には、カンファレンスをホストするエンティティを説明するテキス
   トが含まれる。

5.4.2.  <web-page>

   この要素には、カンファレンスサービス、またはカンファレンスをホストす
   るユーザーについて説明したWebページのHTTP:またはHTTPS: URIが含まれ
   る。

5.4.3.  <uris>

   この要素には一連の<entry>子要素が含まれ、それぞれにURI値と、オプション
   の説明が含まれる。

5.5.  <conference-state>

   この要素をカンファレンスドキュメントに含めると、サーバーはサブスクラ
   イバに対して全体のカンファレンス情報を通知することができる。
   <conference-state>子要素については後述する。

5.5.1.  <user-count>

   この要素の値によって、カンファレンスドキュメントの受信者は、ある時点
   でカンファレンスに参加しているユーザーの合計数がわかる。一般的に、こ
   の値は、カンファレンスドキュメントの<conf-uris>で公開されているのと
   は異なる手法で、カンファレンスに参加した全体のユーザー数を表す。この
   数は一致する必要はなく、<users>コンテナのエンティティ数を超えてもよ
   い[MAY]。たとえば、講義のシナリオで、大きなカンファレンス通知の
   <users>要素には全参加者が含まれなくても、代わりにパネリストまたは話
   者のみを報告することができる。






Rosenberg, et al.           Standards Track                    [Page 17]

RFC 4575                   Conference Package                August 2006


5.5.2.  <active>

   このブール型要素は、カンファレンスが現在アクティブかどうかを示す。認
   可済みクライアントが<conf-uris>のいずれかを呼び出した結果、クライア
   ントとフォーカス間のシグナリングセッションが正常に確立し、カンファレ
   ンスに正常に参加できた場合、カンファレンスはアクティブである。

5.5.3.  <locked>

   このブール型要素は、カンファレンスが現在ロックされているかどうかを
   示す。この文脈では、「ロックされている」とは、カンファレンス登録者を
   登録できないことを示す(ただし、参加者はカンファレンスから退席したり
   参加者を削除したりすることはできる)。

5.6.  <users>とその<user>下位要素

   <users>要素は、複数の<user>子要素のコンテナであり、それぞれカンファ
   レンスの単一の参加者について説明している。

   以下の属性が<user>要素に定義されている。

   entity:  この属性には、カンファレンスのユーザーのURIが含まれる。これ
      は論理的識別子であり、コールシグナリングの参加者の認証済みアイデ
      ンティティに対応する。「entity」値は、そのカンファレンスの全参加
      者内で一意でなければならない[MUST]。一部の参加者について、情報を
      公開しないことをフォーカスが決定した場合(たとえば、ローカルポリ
      シーまたはセキュリティ上の理由から)、ユーザーURIのホスト部分は、
      RFC 2606 [5]の定義に従って.invalidトップレベルドメインを使用しな
      ければならない[MUST]。
      また、フォーカスは、URIが同じドメインの全参加者内で一意になるよ
      うに、URIのユーザー部分を構築しなければならない[MUST]。たとえば、
      以下の規約

          "AnonymousX" <sip:anonymousX@anonymous.invalid>

      は、RFC 3323 [11]の匿名URIを生成するガイドラインに従って、プライ
      バシを要求する参加者向けに使用すべきである[SHOULD]。
      異なるケースでは、たとえばEnhancements for Authenticated Identity
      Management in SIP [25]と連携して使用する場合などは、以下の規約を
      使用できる。

          "AnonymousX" <sip:anonymousX@example.com>

   state:  この属性は、ドキュメントに全体のユーザー情報が含まれている
      か(「full」)、以前のドキュメントから変更された情報のみが含まれて
      いるか(「partial」)、カンファレンスからユーザーが削除されたか
      (「deleted」)を示す。



Rosenberg, et al.           Standards Track                    [Page 18]

RFC 4575                   Conference Package                August 2006


   以下の子要素が<user>要素に定義されている。

5.6.1.  <display-text>

   この要素は、カンファレンスのユーザーがわかりやすい名前を表示するとき
   に使用する。

5.6.2.  <associated-aors>

   この要素には、<user>に関連付けられた追加の(「entity」に対する)URIが
   含まれる。一般的に、シグナリングエンティティ間の論理的関連付け、また
   は独立していることを示すこの情報は、管理者が手動で提示する。たとえ
   ば、<user>の「entity」にGlobally Routable User URI (GRUU) [24]また
   はtel: URI RFC 3966 [19]が含まれる場合、各デバイスを使用する個人の
   Addresses-of-Record (AOR)を使用してこのフィールドを作成するのが便利
   である。この各デバイスは個々の<user>として表現される。

5.6.3.  <roles>

   この要素には、カンファレンスのユーザーの役割を説明する、人間が読み取
   り可能な文字列を含めてもよい[MAY]。この情報は、人間の使用にのみ適用
   できることに注意。本仕様は、使用できるカンファレンスの役割またはそれ
   ぞれに関連付けられたセマンティクスを定義しない。将来的なカンファレン
   ス仕様で、そのような役割と対応するスキーマ拡張が適切に定義されること
   が予想される。

5.6.4.  <languages>

   この要素には、複数のトークンがスペースで区切られたリストが含まれる。
   各トークンにはユーザーが理解できる言語が含まれる。この情報は、コール
   シグナリングで自動的に認識できる場合と、参加者が手動で設定する場合が
   ある。

5.6.5.  <cascaded-focus>

   この要素には、フォーカスのカスケードの結果、メインのカンファレンスに
   接続されたユーザーのカンファレンスURI(メインのカンファレンスURIとは
   異なる)が含まれる。SIPのカンファレンスフレームワーク[16]に従って、こ
   のパッケージでピアツーピア(つまり「フラットな」)のフォーカスのカス
   ケーディングのみを表現することができるようになる。実際のカスケーディ
   ンググラフは、パッケージ単体で提供される情報から推定される。高度なア
   プリケーションであれば、このパッケージとカスケードされた各フォーカス
   のダイアログパッケージ[23]の両方にサブスクライブし、関連情報を対応付
   けることによって、図を構築することができる。





Rosenberg, et al.           Standards Track                    [Page 19]

RFC 4575                   Conference Package                August 2006


5.6.6.  <endpoint>

   親の<user>要素以下に1つまたは複数の<endpoint>要素を含めることで、
   サーバーは、ユーザーのデバイスとシグナリングセッション関する目的のレ
   ベルの詳細情報(ステート、メディアストリーム、アクセス情報など)を、カ
   ンファレンスに取り入れて提供することができる。

   認証が(ユーザーごとではなく)エンドポイントごとに実行されるカンファレ
   ンスシステムの場合、フォーカスは共通のユーザーに属する複数エンドポイ
   ントの論理的関連付けを意識していない可能性がある。この場合、エンドポ
   イントは、カンファレンスドキュメントに独自の<endpoint>下位要素を持つ
   個別の<user>として出現する。

   また別の場合では、フォーカスは、参加者の複数あるエンドポイントとシグ
   ナリングセッションを他のサブスクライバから隠すことを選択する可能性も
   ある(プライバシポリシーなどの理由から)。
   この場合、フォーカスは、単一の<endpoint>要素に属する複数のシグナリン
   グセッションの情報を集約してもよい[MAY]。この場合、(<call-info>下位
   要素で表現される)詳細なコールシグナリング情報は含まれない。

5.7.  <endpoint>

   このセクションでは、<endpoint>要素の詳細について説明する。

   以下の属性が<endpoint>に定義されている。

   entity:  サーバーは、親の<user>に属する各<endpoint>要素に、ユーザー
      コンテキスト内で値が一意になるように「entity」キーを生成しなけれ
      ばならない[MUST]。SIP用語では、これはContact URI、GRUUなどになる
      可能性がある。

   state:  この属性は、要素に全体のエンドポイント情報が含まれている
      か(「full」)、以前のドキュメントから変更された情報のみが含まれて
      いるか(「partial」)、カンファレンスからエンドポイントが削除された
      か(「deleted」)を示す。

   以下の呼要素が<endpoint>要素に定義されている。

5.7.1.  <display-text>

   この要素にはエンドポイントの表示テキストが含まれる。








Rosenberg, et al.           Standards Track                    [Page 20]

RFC 4575                   Conference Package                August 2006


5.7.2.  <referred>

   この要素には、このエンドポイントが結果的にカンファレンスに参加する行
   動を取るユーザーに関する情報が含まれる(REFERをフォーカスに送信したこ
   のURIで識別されるSIPユーザーなど)。この要素には以下の下位要素を含め
   てもよい[MAY]。

   when:  XMLのdateTimeの要素には、エンドポイントがカンファレンスに参加
      した日時が含まれる。これはCoordinated Universal Time (UTC)形式で
      表現すべきである[SHOULD]。たとえば、以下の通り。

        <when>2005-03-04T20:00:00Z</when>

   reason:  この要素にはエンドポイントがカンファレンスに参加した理由が
      含まれる。RFC 3326 [12]で定義されている形式で情報を含めることが推
      奨される[RECOMMENDED]。たとえば、以下の通り。

   <reason>Reason: SIP;text="Ad-hoc Invitation"</reason>

   by:  この要素には、エンドポイントをカンファレンスに参加させたエン
      ティティのURIが含まれる。SIPの場合、このURIはRFC 3892 [15]で定義
      されているReferred-Byヘッダーフィールドから作成される。

5.7.3.  <status>

   この要素には、エンドポイントのステータスが含まれ、以下の値が想定で
   きる。

   connected: エンドポイントはカンファレンスの参加者である。
      メディアポリシーに従って、ユーザーは、他の参加者との間でメディア
      を送受信できる。

   disconnected: エンドポイントはカンファレンスの参加者ではなく、エンド
      ポイントとフォーカス間にアクティブなダイアログは存在しない。

   on-hold: アクティブなシグナリングダイアログがエンドポイントとフォー
      カス間に存在するが、エンドポイントはカンファレンスを「保留中
      (on-hold)」にしている。つまり、エンドポイントはカンファレンスの
      ミックス音声が「聞こえて(hearing)」いないし、エンドポイントのメ
      ディアはカンファレンスにミックスされていない。一例は、エンドポイ
      ントはSIPを使用してカンファレンスへの参加を要求したが、その参加
      は、議長の承認に基づいて保留されている場合である。その間、その
      ユーザーには、保留音など、関連するコンテンツが聞こえている。

   muted-via-focus: アクティブなシグナリングダイアログがエンドポイント
      とフォーカス間に存在し、そのエンドポイントはカンファレンスを「聴
      く(listen)」ことができるが、エンドポイントのメディアはカンファレ



Rosenberg, et al.           Standards Track                    [Page 21]

RFC 4575                   Conference Package                August 2006


      ンスにミックスされていない。場合によっては、他(音声やIMなど)がア
      クティブでも、エンドポイントのメディアストリームのサブセットは、
      フォーカスによって消音される可能性があることに注意(低品質のビデオ
      など)。この場合、「集約した」エンドポイントの接続性<status>は、最
      もアクティブなメディアのステータスを反映することが推奨される
      [RECOMMENDED]。

   pending:  エンドポイントはまだセッションに参加していないが、近いうち
      に参加することが予想される。

   alerting:  公衆交換電話網(PSTN)のALERTINGまたはSIP 180 Ringingが、発
      信に対して返された。エンドポイントにはアラートされている。

   dialing-in:  エンドポイントはカンファレンスにダイヤルインしているが、
      まだ登録者になっていない(恐らく認証中である)。

   dialing-out:  フォーカスはエンドポイントをカンファレンスに接続するた
      めにダイヤルアウトしたが、エンドポイントはまだ登録者になっていな
      い(恐らく認証中である)。

   disconnecting:  フォーカスはエンドポイントの接続解除処理中である(た
      とえば、SIPでDISCONNECTまたはBYEがエンドポイントに送信された)。

   定義済みの一時的ステータス(接続解除中、アラート中など)は、大量のトラ
      フィックを生成する可能性がある。したがって、実装時には、このよう
      なステータスに関する通知を特定の参加者に対してのみ生成するか、
      まったく生成しないかをローカルポリシーに従って選択してもよい
      [MAY]。

5.7.4.  <joining-method>

   この要素には、エンドポイントがカンファレンスに参加した方法が含まれ、
   以下の値が想定できる。

   dialed-in: エンドポイントはカンファレンスにダイヤルし(たとえば、
      フォーカスにINVITEを送信し)、その結果、ダイアログが正常に確立さ
      れた。

   dialed-out: フォーカスは、エンドポイントをカンファレンスに参加させ
      た(たとえば、SIPでは、フォーカスがエンドポイントにINVITEを正常に
      送信した)。

   focus-owner: エンドポイントはこのカンファレンスのフォーカスである。
      このステータスは、参加者のUAがカンファレンスフォーカスとして動作
      する場合にのみ使用される。






Rosenberg, et al.           Standards Track                    [Page 22]

RFC 4575                   Conference Package                August 2006


5.7.5.  <joining-info>

   この要素には、エンドポイントが参加する方法に関する情報が含まれる。
   また、以下の下位要素を含めてもよい[MAY]。

   when:  XMLのdateTimeの要素には、エンドポイントがカンファレンスに参加
      した日時が含まれる。これはCoordinated Universal Time (UTC)で表現す
      べきである[SHOULD]。

   reason:  この要素にはエンドポイントがカンファレンスに参加した理由が
      含まれる。RFC 3326 [12]で定義されている形式で情報を含めることが推
      奨される[RECOMMENDED]。たとえば、以下の通り。

   <reason>Reason: SIP;text="Ad-hoc Invitation"</reason>

   by:  この要素には、エンドポイントをカンファレンスに参加させたエン
      ティティのURIが含まれる。

5.7.6.  <disconnection-method>

   この要素には、エンドポイントがカンファレンスを退席した方法が含まれ、
   以下の値が想定できる。

   departed: SIPでは、エンドポイントはBYEを送信し、その結果、カンファレ
      ンスから退席した。

   booted: SIPでは、エンドポイントにフォーカスからBYEを送信され、カン
      ファレンスから退席させられた。または、エンドポイントがカンファレ
      ンスにダイヤルインしようとしたが、ローカルポリシーによってフォー
      カスが拒否した。

   failed: SIPでは、サーバーはエンドポイントをカンファレンスに参加させ
      ようとしたが、そのエンドポイントへの接続試行は、非200クラスの最終
      応答という結果になった。あるいは、エンドポイントは、技術的な理由
      からカンファレンスへのダイヤルに成功しなかった。

   busy: SIPでは、サーバーはエンドポイントをカンファレンスに参加させよ
      うとしたが、そのエンドポイントへの接続試行は、486 "Busy Here"最終
      応答という結果になった。または、エンドポイントはカンファレンスに
      ダイヤルインしようとしたが、フォーカスは486応答で応答した。

5.7.7.  <disconnection-info>

   この要素には、エンドポイントがカンファレンスから退席した方法に関する
   情報が含まれる。また、以下の下位要素を含めてもよい[MAY]。




Rosenberg, et al.           Standards Track                    [Page 23]

RFC 4575                   Conference Package                August 2006


   when:  XMLのdateTimeの要素には、エンドポイントがカンファレンスから退
      席した日時が含まれる。これはCoordinated Universal Time (UTC)で表
      現すべきである[SHOULD]。

   reason:  この要素にはエンドポイントがカンファレンスから退席した理由
      が含まれる。既知で意味がある場合、コールシグナリングで伝達/報告さ
      れた情報をRFC 3326 [12]で定義されている形式で含めることが推奨され
      る[RECOMMENDED]。たとえば、以下の通り。

   <reason>Reason: SIP;cause=415;text="Unsupported Media Type"</reason>

   by:  この要素には、エンドポイントをカンファレンスから退席させたエン
      ティティのURIが含まれる。

5.7.8.  <media>

   この要素には、単一のメディアストリームに関する情報が含まれ、フォーカ
   スと<endpoint>間で確立されているメディアストリームごとに含まれる。メ
   ディアストリームの定義はSDP [3]を参照のこと。

   サーバーがエンドポイントの<call-info>下位要素をドキュメントに含めな
   い場合、共通の<endpoint>以下に列挙されたメディアストリームは個別のシ
   グナリングセッションごとに確立された可能性があることに注意。

5.7.9.  <call-info>

   <call-info>要素は、参加者とフォーカス間で維持される詳細なコールシグ
   ナリング情報を提供する。
   この情報を他の参加者に公開する前に、プライバシポリシーを確認しなけれ
   ばならない[MUST]。

   <sip>下位要素には、エンドポイントのフォーカスとのダイアログのSIPダイ
   アログ識別子が含まれる。この要素には下位要素の<display-text>、
   <call-id>、<to-tag>、<from-tag>が含まれる。

   将来的に、<call-info>要素は、SIP以外のプロトコルに関するコールシグナ
   リングプロトコル情報を含む範囲まで拡張される可能性がある。

5.8.  <media>

   このセクションでは、<media>要素の詳細について説明する。

   単一の「id」属性がこの要素に定義されている。これは、値がエンドポイン
   トのコンテキスト内で一意になるようにサーバーが生成した、メディアス




Rosenberg, et al.           Standards Track                    [Page 24]

RFC 4575                   Conference Package                August 2006


   トリーム識別子である。この属性は、特定のメディアストリームをカンファ
   レンスドキュメントに参加させるキーである。

   以下の子要素が<media>要素に定義されている。

5.8.1.  <display-text>

   この要素にはメディアストリームの表示テキストが含まれる。この要素の
   値は、SDP [3]に定義されているSDP記述のmedia属性(「i」)に対応する。

5.8.2.  <type>

   この要素には、メディアストリームのメディアタイプが含まれる。この要素
   の値は、SDP [3]およびそれ以降の改版の「media」に登録されている値の1
   つにしなければならない[MUST]。

5.8.3.  <label>

   <label>要素では、カンファレンスの全ストリームの中でこのストリームの
   一意な識別子が伝達される。また、この要素はフォーカスが割り当てる。こ
   の要素の値は、一般的に[17]に定義されているSDPの「label」media属性に
   対応する。また、参加者とフォーカスの間で双方のシグナリング接続上で交
   換される。

   <available-media>情報(セクション5.3.4参照)がカンファレンスドキュメン
   トに含まれる場合、この要素の値は、<available-media>コンテナの対応す
   るメディアストリーム<entry>の「label」値と同一にしなければならな
   い[MUST]。

5.8.4.  <src-id>

   <src-id>要素では、適用できる場合、実際のメディアソースに関する情報が
   伝達される。たとえば、Real-time Transport Protocol (RTP) / RTP 
   Control Protocol (RTCP) [13]メディアストリームの場合、値には、送信す
   るストリームに関してエンドポイントが生成した同期ソース
   (synchronization source/SSRC)識別子を含めなければならない[MUST]。

   RTP/RTCP[13]に従ってRTPミキサーが貢献ソース(contributing source/
   CSRC)識別子のリストを生成するとき、特定パケットの生成に貢献したソー
   スのSSRC識別子のリストを、パケットのRTPヘッダーに挿入する。RFC 3550
   [13]の説明を引用する。「例のアプリケーションは、通話音が結合されて送
   信されるパケットが作成される、すべての通話者をミキサーが示す音声カン
   ファレンスである。また、受信側は、すべての音声パケットに同じSSRC識別
   子(ミキサーのもの)が含まれている場合でも、現在の通話者を示すことが
   できるようになる。」




Rosenberg, et al.           Standards Track                    [Page 25]

RFC 4575                   Conference Package                August 2006


   上記に準拠するRTPミキサーを使用する場合、参加者はSSRCをユーザーのマッ
   ピングに実行し、「現在の話者」を識別する。

5.8.5.  <status>

   要素<status>は、両方向のメディアストリームに含まれるステータスを示
   し、SDP [3]と以降の改版の定義に従って、「sendrecv」、「sendonly」、
   「recvonly」、「inactive」という値がある。値は参加者の観点からの方向
   を示すことに注意。たとえば、消音された参加者のストリームは、
   「recvonly」という値になる。

5.9.  サイドバー

   メインのカンファレンスの参加者がサイドバーに参加すると、そのユーザー
   を表す新規の<user>要素は、<sidebars-by-ref>要素から参照されるか、ま
   たは後述する<sidebars-by-val>の1つに所属する、個別の下位カンファレン
   スの一部として作成される。

   メイン登録者の<user>は削除されていないが、サイドバーへの参加によって
   生じる影響を反映して、メディアステータスが更新される可能性がある。こ
   の情報の表示は、サイドバーでもメインのカンファレンスでも、ローカルポ
   リシーやサブスクライバの役割に従って、同じカンファレンス情報に対する
   サブスクライバの中で変わる可能性がある。

5.9.1.  <sidebars-by-ref>

   この要素には<entry>子要素群が含まれ、それぞれにサイドバーのカンファ
   レンスURIが含まれる。この情報の受信者は、メインカンファレンスのパッ
   ケージサブスクリプションとは別に、サイドバー情報にサブスクライブする
   ことができる。

5.9.2.  <sidebars-by-val>

   この要素には<entry>子要素群が含まれ、それぞれに単一のサイドバーに関
   する情報が含まれる。このconference-typeの要素を使用することで、サー
   バーは、(下位カンファレンスとして)各サイドバーの完全または部分的な説
   明をメインカンファレンスドキュメントのボディに含めることができる。

6.  XMLスキーマ

   <?xml version="1.0" encoding="UTF-8" ?>
   <xs:schema
   targetNamespace="urn:ietf:params:xml:ns:conference-info"
   xmlns:tns="urn:ietf:params:xml:ns:conference-info"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"



Rosenberg, et al.           Standards Track                    [Page 26]

RFC 4575                   Conference Package                August 2006


   xmlns="urn:ietf:params:xml:ns:conference-info"
   elementFormDefault="qualified"
   attributeFormDefault="unqualified">
   <!--
     This imports the xml:language definition
   -->
      <xs:import namespace="http://www.w3.org/XML/1998/namespace"
       schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
   <!--
     CONFERENCE ELEMENT
   -->
      <xs:element name="conference-info" type="conference-type"/>
      <!--
         CONFERENCE TYPE
      -->
      <xs:complexType name="conference-type">
       <xs:sequence>
        <xs:element name="conference-description"
         type="conference-description-type" minOccurs="0"/>
        <xs:element name="host-info"
         type="host-type" minOccurs="0"/>
        <xs:element name="conference-state"
         type="conference-state-type" minOccurs="0"/>
        <xs:element name="users"
         type="users-type" minOccurs="0"/>
        <xs:element name="sidebars-by-ref"
         type="uris-type" minOccurs="0"/>
        <xs:element name="sidebars-by-val"
         type="sidebars-by-val-type" minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
         minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:attribute name="entity"
        type="xs:anyURI" use="required"/>
       <xs:attribute name="state"
        type="state-type" use="optional" default="full"/>
       <xs:attribute name="version"
        type="xs:unsignedInt" use="optional"/>
       <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:complexType>
      <!--
         STATE TYPE
      -->
      <xs:simpleType name="state-type">
       <xs:restriction base="xs:string">
        <xs:enumeration value="full"/>
        <xs:enumeration value="partial"/>
        <xs:enumeration value="deleted"/>



Rosenberg, et al.           Standards Track                    [Page 27]

RFC 4575                   Conference Package                August 2006


       </xs:restriction>
      </xs:simpleType>
      <!--
         CONFERENCE DESCRIPTION TYPE
      -->
      <xs:complexType name="conference-description-type">
       <xs:sequence>
        <xs:element name="display-text"
         type="xs:string" minOccurs="0"/>
        <xs:element name="subject"
         type="xs:string" minOccurs="0"/>
        <xs:element name="free-text"
         type="xs:string" minOccurs="0"/>
        <xs:element name="keywords"
         type="keywords-type" minOccurs="0"/>
        <xs:element name="conf-uris"
         type="uris-type" minOccurs="0"/>
        <xs:element name="service-uris"
         type="uris-type" minOccurs="0"/>
        <xs:element name="maximum-user-count"
         type="xs:unsignedInt" minOccurs="0"/>
        <xs:element name="available-media"
         type="conference-media-type" minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
         minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:complexType>
      <!--
         HOST TYPE
      -->
      <xs:complexType name="host-type">
       <xs:sequence>
        <xs:element name="display-text" type="xs:string"
         minOccurs="0"/>
        <xs:element name="web-page" type="xs:anyURI"
         minOccurs="0"/>
        <xs:element name="uris" type="uris-type"
         minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
         minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:complexType>
      <!--
         CONFERENCE STATE TYPE
      -->
      <xs:complexType name="conference-state-type">



Rosenberg, et al.           Standards Track                    [Page 28]

RFC 4575                   Conference Package                August 2006


       <xs:sequence>
        <xs:element name="user-count" type="xs:unsignedInt"
         minOccurs="0"/>
        <xs:element name="active" type="xs:boolean"
         minOccurs="0"/>
        <xs:element name="locked" type="xs:boolean"
         minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
         minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:complexType>
      <!--
         CONFERENCE MEDIA TYPE
      -->
      <xs:complexType name="conference-media-type">
       <xs:sequence>
        <xs:element name="entry" type="conference-medium-type"
         maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:complexType>
      <!--
         CONFERENCE MEDIUM TYPE
      -->
      <xs:complexType name="conference-medium-type">
       <xs:sequence>
        <xs:element name="display-text" type="xs:string"
         minOccurs="0"/>
        <xs:element name="type" type="xs:string"/>
        <xs:element name="status" type="media-status-type"
         minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
         minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:attribute name="label" type="xs:string"
        use="required"/>
       <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:complexType>
      <!--
         URIs TYPE
      -->
      <xs:complexType name="uris-type">
       <xs:sequence>
        <xs:element name="entry" type="uri-type"
         maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:attribute name="state" type="state-type"



Rosenberg, et al.           Standards Track                    [Page 29]

RFC 4575                   Conference Package                August 2006


        use="optional" default="full"/>
       <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:complexType>
      <!--
         URI TYPE
      -->
      <xs:complexType name="uri-type">
       <xs:sequence>
        <xs:element name="uri" type="xs:anyURI"/>
        <xs:element name="display-text" type="xs:string"
         minOccurs="0"/>
        <xs:element name="purpose" type="xs:string"
         minOccurs="0"/>
        <xs:element name="modified" type="execution-type"
         minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
         minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:complexType>
      <!--
         KEYWORDS TYPE
      -->
      <xs:simpleType name="keywords-type">
       <xs:list itemType="xs:string"/>
      </xs:simpleType>
      <!--
         USERS TYPE
      -->
      <xs:complexType name="users-type">
       <xs:sequence>
        <xs:element name="user" type="user-type"
         minOccurs="0" maxOccurs="unbounded"/>
        <xs:any namespace="##other" processContents="lax"
         minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:attribute name="state" type="state-type"
        use="optional" default="full"/>
       <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:complexType>
      <!--
         USER TYPE
      -->
      <xs:complexType name="user-type">
       <xs:sequence>
        <xs:element name="display-text" type="xs:string"
         minOccurs="0"/>
        <xs:element name="associated-aors" type="uris-type"



Rosenberg, et al.           Standards Track                    [Page 30]

RFC 4575                   Conference Package                August 2006


         minOccurs="0"/>
        <xs:element name="roles" type="user-roles-type"
         minOccurs="0"/>
        <xs:element name="languages" type="user-languages-type"
         minOccurs="0"/>
        <xs:element name="cascaded-focus" type="xs:anyURI"
         minOccurs="0"/>
        <xs:element name="endpoint" type="endpoint-type"
         minOccurs="0" maxOccurs="unbounded"/>
        <xs:any namespace="##other" processContents="lax"
         minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:attribute name="entity" type="xs:anyURI"/>
       <xs:attribute name="state" type="state-type"
        use="optional" default="full"/>
       <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:complexType>
      <!--
         USER ROLES TYPE
      -->
      <xs:complexType name="user-roles-type">
       <xs:sequence>
        <xs:element name="entry" type="xs:string"
         maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:complexType>
      <!--
         USER LANGUAGES TYPE
      -->
      <xs:simpleType name="user-languages-type">
       <xs:list itemType="xs:language"/>
      </xs:simpleType>
      <!--
         ENDPOINT TYPE
      -->
      <xs:complexType name="endpoint-type">
       <xs:sequence>
        <xs:element name="display-text" type="xs:string"
         minOccurs="0"/>
        <xs:element name="referred" type="execution-type"
         minOccurs="0"/>
        <xs:element name="status" type="endpoint-status-type"
         minOccurs="0"/>
        <xs:element name="joining-method" type="joining-type"
         minOccurs="0"/>
        <xs:element name="joining-info"
         type="execution-type"



Rosenberg, et al.           Standards Track                    [Page 31]

RFC 4575                   Conference Package                August 2006


         minOccurs="0"/>
        <xs:element name="disconnection-method"
         type="disconnection-type"
         minOccurs="0"/>
        <xs:element name="disconnection-info"
         type="execution-type"
         minOccurs="0"/>
        <xs:element name="media" type="media-type"
         minOccurs="0" maxOccurs="unbounded"/>
        <xs:element name="call-info" type="call-type"
         minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
         minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:attribute name="entity" type="xs:string"/>
       <xs:attribute name="state" type="state-type"
        use="optional" default="full"/>
       <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:complexType>
      <!--
         ENDPOINT STATUS TYPE
      -->
      <xs:simpleType name="endpoint-status-type">
       <xs:restriction base="xs:string">
        <xs:enumeration value="pending"/>
        <xs:enumeration value="dialing-out"/>
        <xs:enumeration value="dialing-in"/>
        <xs:enumeration value="alerting"/>
        <xs:enumeration value="on-hold"/>
        <xs:enumeration value="connected"/>
        <xs:enumeration value="muted-via-focus"/>
        <xs:enumeration value="disconnecting"/>
        <xs:enumeration value="disconnected"/>
       </xs:restriction>
      </xs:simpleType>
      <!--
         JOINING TYPE
      -->
      <xs:simpleType name="joining-type">
       <xs:restriction base="xs:string">
        <xs:enumeration value="dialed-in"/>
        <xs:enumeration value="dialed-out"/>
        <xs:enumeration value="focus-owner"/>
       </xs:restriction>
      </xs:simpleType>
      <!--
         DISCONNECTION TYPE
      -->



Rosenberg, et al.           Standards Track                    [Page 32]

RFC 4575                   Conference Package                August 2006


      <xs:simpleType name="disconnection-type">
       <xs:restriction base="xs:string">
        <xs:enumeration value="departed"/>
        <xs:enumeration value="booted"/>
        <xs:enumeration value="failed"/>
        <xs:enumeration value="busy"/>
       </xs:restriction>
      </xs:simpleType>
      <!--
         EXECUTION TYPE
      -->
      <xs:complexType name="execution-type">
       <xs:sequence>
        <xs:element name="when" type="xs:dateTime"
         minOccurs="0"/>
        <xs:element name="reason" type="xs:string"
         minOccurs="0"/>
        <xs:element name="by" type="xs:anyURI"
         minOccurs="0"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:complexType>
     <!--
         CALL TYPE
      -->
      <xs:complexType name="call-type">
       <xs:choice>
        <xs:element name="sip" type="sip-dialog-id-type"/>
        <xs:any namespace="##other" processContents="lax"
         minOccurs="0" maxOccurs="unbounded"/>
       </xs:choice>
       <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:complexType>
      <!--
         SIP DIALOG ID TYPE
      -->
      <xs:complexType name="sip-dialog-id-type">
       <xs:sequence>
        <xs:element name="display-text" type="xs:string"
         minOccurs="0"/>
        <xs:element name="call-id" type="xs:string"/>
        <xs:element name="from-tag" type="xs:string"/>
        <xs:element name="to-tag" type="xs:string"/>
        <xs:any namespace="##other" processContents="lax"
         minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:complexType>



Rosenberg, et al.           Standards Track                    [Page 33]

RFC 4575                   Conference Package                August 2006


      <!--
         MEDIA TYPE
      -->
      <xs:complexType name="media-type">
       <xs:sequence>
        <xs:element name="display-text" type="xs:string"
         minOccurs="0"/>
        <xs:element name="type" type="xs:string"
         minOccurs="0"/>
        <xs:element name="label" type="xs:string"
         minOccurs="0"/>
        <xs:element name="src-id" type="xs:string"
         minOccurs="0"/>
        <xs:element name="status" type="media-status-type"
         minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
         minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:attribute name="id" type="xs:string"
        use="required"/>
       <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:complexType>
      <!--
         MEDIA STATUS TYPE
      -->
      <xs:simpleType name="media-status-type">
       <xs:restriction base="xs:string">
        <xs:enumeration value="recvonly"/>
        <xs:enumeration value="sendonly"/>
        <xs:enumeration value="sendrecv"/>
        <xs:enumeration value="inactive"/>
       </xs:restriction>
      </xs:simpleType>
       <!--
         SIDEBARS BY VAL TYPE
       -->
       <xs:complexType name="sidebars-by-val-type">
        <xs:sequence>
         <xs:element name="entry" type="conference-type"
          minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="state" type="state-type"
         use="optional" default="full"/>
        <xs:anyAttribute namespace="##other" processContents="lax"/>
       </xs:complexType>
      </xs:schema>





Rosenberg, et al.           Standards Track                    [Page 34]

RFC 4575                   Conference Package                August 2006


7.  例

7.1.  基本的な例

   完全なカンファレンス情報ドキュメントの例を以下に示す。

   <?xml version="1.0" encoding="UTF-8"?>
   <conference-info
    xmlns="urn:ietf:params:xml:ns:conference-info"
    entity="sips:conf233@example.com"
    state="full" version="1">
   <!--
     CONFERENCE INFO
   -->
    <conference-description>
     <subject>Agenda: This month's goals</subject>
      <service-uris>
       <entry>
        <uri>http://sharepoint/salesgroup/</uri>
        <purpose>web-page</purpose>
       </entry>
      </service-uris>
     </conference-description>
   <!--
      CONFERENCE STATE
   -->
    <conference-state>
     <user-count>33</user-count>
    </conference-state>
   <!--
     USERS
   -->
    <users>
     <user entity="sip:bob@example.com" state="full">
      <display-text>Bob Hoskins</display-text>
   <!--
     ENDPOINTS
   -->
      <endpoint entity="sip:bob@pc33.example.com">
       <display-text>Bob's Laptop</display-text>
       <status>disconnected</status>
       <disconnection-method>departed</disconnection-method>
       <disconnection-info>
        <when>2005-03-04T20:00:00Z</when>
        <reason>bad voice quality</reason>
        <by>sip:mike@example.com</by>
       </disconnection-info>



Rosenberg, et al.           Standards Track                    [Page 35]

RFC 4575                   Conference Package                August 2006


   <!--
     MEDIA
   -->
       <media id="1">
        <display-text>main audio</display-text>
        <type>audio</type>
        <label>34567</label>
        <src-id>432424</src-id>
        <status>sendrecv</status>
       </media>
      </endpoint>
     </user>
   <!--
     USER
   -->
     <user entity="sip:alice@example.com" state="full">
      <display-text>Alice</display-text>
   <!--
     ENDPOINTS
   -->
      <endpoint entity="sip:4kfk4j392jsu@example.com;grid=433kj4j3u">
       <status>connected</status>
       <joining-method>dialed-out</joining-method>
       <joining-info>
        <when>2005-03-04T20:00:00Z</when>
        <by>sip:mike@example.com</by>
       </joining-info>
   <!--
     MEDIA
   -->
       <media id="1">
        <display-text>main audio</display-text>
        <type>audio</type>
        <label>34567</label>
        <src-id>534232</src-id>
        <status>sendrecv</status>
       </media>
      </endpoint>
     </user>
    </users>
   </conference-info>

7.2.  高度な例

   部分的なカンファレンス情報ドキュメントの例を以下に示す。この例では、
   音声カンファレンスに32名の参加者がいる。ユーザーBobは音声品質が悪い
   ため、Mikeによるカンファレンスから退席した。カンファレンスには3つの
   サイドバーがあることに注意。2つはサイドバーURIからのみ参照され、3つ
   目のサイドバーに関する情報はこの通知に含まれる。
   また、このカンファレンスは音声機能とビデオ機能の両方を提供するが、現
   在は音声のみが使用されていることにも注意すること。



Rosenberg, et al.           Standards Track                    [Page 36]

RFC 4575                   Conference Package                August 2006


   the conference; two are referenced just by their sidebar URIs, and
   information about the third sidebar is included in this notification.
   Also note that while this conference offers both audio and video
   capabilities, only audio is currently in use.

   <?xml version="1.0" encoding="UTF-8"?>
   <conference-info
    xmlns="urn:ietf:params:xml:ns:conference-info"
    entity="sips:conf233@example.com"
    state="partial" version="5">
   <!--
     CONFERENCE INFO
   -->
    <conference-description>
     <display-text>Weekly Sales Meeting</display-text>
     <subject>Agenda: This month's goals</subject>
     <free-text>We will start strict on time</free-text>
     <keywords>sales meeting weekly</keywords>
     <conf-uris>
      <entry>
       <uri>tel:+18005671234</uri>
       <display-text>TTI Bridge</display-text>
       <purpose>participation</purpose>
      </entry>
      <entry>
       <uri>h323:conf545@h323.example.com</uri>
       <purpose>participation</purpose>
      </entry>
      <entry>
       <uri>http://real.streaming.com/54634/live.ram</uri>
       <purpose>streaming</purpose>
      </entry>
     </conf-uris>
     <service-uris>
      <entry>
       <uri>http://sharepoint/salesgroup/</uri>
       <purpose>web-page</purpose>
      </entry>
      <entry>
       <uri>http://quicktime.com/54634/recording.mov</uri>
       <display-text>Quicktime</display-text>
       <purpose>recording</purpose>
      </entry>
     </service-uris>
     <maximum-user-count>100</maximum-user-count>
     <available-media>
      <entry label="34567">
       <display-text>main audio</display-text>



Rosenberg, et al.           Standards Track                    [Page 37]

RFC 4575                   Conference Package                August 2006


       <type>audio</type>
       <status>sendrecv</status>
      </entry>
      <entry label="34569">
       <display-text>main video</display-text>
       <type>video</type>
       <status>inactive</status>
      </entry>
     </available-media>
    </conference-description>
   <!--
     HOST INFO
   -->
    <host-info>
     <display-text>Sales Host</display-text>
     <web-page>http://sharepoint/salesgroup/hosts/</web-page>
     <uris>
      <entry>
       <uri>sip:sales@example.com</uri>
      </entry>
     </uris>
    </host-info>
   <!--
     CONFERENCE STATE
   -->
    <conference-state>
     <user-count>32</user-count>
     <active>true</active>
     <locked>false</locked>
    </conference-state>
   <!--
     USERS
   -->
    <users>
     <user entity="sip:bob@example.com">
      <display-text>Bob Hoskins</display-text>
      <associated-aors>
       <entry>
        <uri>mailto:bob@example.com</uri>
        <display-text>email</display-text>
       </entry>
      </associated-aors>
      <roles>
      <entry>participant</entry>
      </roles>
      <languages>en</languages>
   <!--
     ENDPOINTS



Rosenberg, et al.           Standards Track                    [Page 38]

RFC 4575                   Conference Package                August 2006


   -->
      <endpoint entity="sip:bob@pc33.example.com">
       <display-text>Bob's Laptop</display-text>
       <referred>
        <when>2005-03-04T20:00:00Z</when>
        <reason>expert required</reason>
        <by>sip:mike@example.com</by>
       </referred>
       <status>disconnecting</status>
       <joining-method>dialed-out</joining-method>
       <joining-info>
        <when>2005-03-04T20:00:00Z</when>
        <reason>invitation</reason>
        <by>sip:mike@example.com</by>
       </joining-info>
       <disconnection-method>booted</disconnection-method>
       <disconnection-info>

        <when>2005-03-04T20:00:00Z</when>
        <reason>bad voice quality</reason>
        <by>sip:mike@example.com</by>
       </disconnection-info>
   <!--
     MEDIA
   -->
       <media id="1">
        <display-text>main audio</display-text>
        <type>audio</type>
        <label>34567</label>
        <src-id>432424</src-id>
        <status>sendrecv</status>
       </media>
   <!--
     CALL INFO
   -->
       <call-info>
        <sip>
         <display-text>full info</display-text>
           <call-id>hsjh8980vhsb78</call-id>
           <from-tag>vav738dvbs</from-tag>
           <to-tag>8954jgjg8432</to-tag>
        </sip>
       </call-info>
      </endpoint>
     </user>
    </users>
   <!--
     SIDEBARS BY REFERENCE



Rosenberg, et al.           Standards Track                    [Page 39]

RFC 4575                   Conference Package                August 2006


   -->
    <sidebars-by-ref state="partial">
     <entry>
      <uri>sips:conf233@example.com;grid=45</uri>
      <display-text>sidebar with Carol</display-text>
     </entry>
     <entry>
      <uri>sips:conf233@example.com;grid=21</uri>
      <display-text>private with Peter</display-text>
     </entry>
    </sidebars-by-ref>
   <!--
     SIDEBARS BY VALUE
   -->
    <sidebars-by-val state="partial">
     <entry entity="sips:conf233@example.com;grid=77"

      state="partial">
      <users>
       <user entity="sip:bob@example.com"/>
       <user entity="sip:mark@example.com"/>
       <user entity="sip:dan@example.com"/>
      </users>
     </entry>
    </sidebars-by-val>
   </conference-info>

8.  セキュリティの考慮事項

   カンファレンスステート情報へのサブスクリプションによって、機密性の高
   い情報が明かされる可能性がある。この理由から、本文書で定義されたカン
   ファレンス通知メカニズムを使用する場合、フォーカスは認証とカンファレ
   ンス情報の保護に強力な手段を使用し、一貫した認可規則を適用することが
   推奨される[RECOMMENDED]。以降のセクションでは、このような各側面につ
   いて詳細に論じる。

8.1.  接続のセキュリティ

   RFC 3261 [8]のセクション22の定義に従って、ダイジェスト認証など通常
   のSIP認証メカニズムを使用して、フォーカスがカンファレンスパッケージ
   のサブスクライバを認証することが推奨される[RECOMMENDED]。

   カンファレンス情報の伝達に使用されるメカニズムは、完全性を確保しなけ
   ればならない[MUST]。また、情報の信頼性を確保すべきである[SHOULD]。
   これを達成するために、RFC 3261 [8]のセクション26.2.4に記載されている





Rosenberg, et al.           Standards Track                    [Page 40]

RFC 4575                   Conference Package                August 2006


   S/MIMEなど、エンドツーエンドのSIP暗号化メカニズムを使用すべきであ
   る[SHOULD]。

   (前述のような)強力なエンドツーエンドのセキュリティ手法を使用できない
   場合、フォーカスは、RFC 3261のセクション26.2.2「SIPS URI Scheme」と
   セクション26.3.2.2「Interdomain Requests」に記載されている、ホップご
   とのTransport Layer Security (TLS)認証と暗号化メカニズムを双方向で使
   用することが推奨される[RECOMMENDED]。

8.2.  認可の考慮事項

   一般的に、カンファレンスアプリケーションは、認可の決定に大きく関与し
   ている。このような認可規則を確立および強制するメカニズムは、SIPのカ
   ンファレンスフレームワーク[16]全体の中心的な概念である。カンファレン
   スに関するほとんどの情報はカンファレンスパッケージを使用して提示され
   るため、認可規則の多くは本仕様に直接適用される。結果として、通知サー
   バーは、カンファレンスにおけるサブスクライバの役割、個人のアクセス権
   などに従って、異なるサブスクライバに対して個別のカンファレンス情報
   ビューを生成する機能を持たなければならない[MUST]。いずれもローカルの
   認可ポリシーと規則に従う。

   フォーカスはこのイベントパッケージを使用して参加者のアイデンティティ
   情報を提供するため、参加者のプライバシを考慮する必要がある。フォーカ
   スはプライバシに関して参加者からのリクエストに対応しなければならな
   い[MUST]。プライバシは、全参加者または特定の参加者に関するカンファレ
   ンスポリシーによって示すことができる。また、セッションシグナリングで
   示すこともできる。SIPでは、RFC 3323 [11]に記載されているPrivacyヘッ
   ダーフィールドを使用してこの処理を実行できる。参加者がプライバシを要
   求している場合、フォーカスは作成するURI (Addresses-of-Record、
   Contact、GRUUなど)でアイデンティティ情報を公開すべきではない。このよ
   うな場合、本文書のセクション5.6で概説している匿名URIの生成方法に従わ
   なければならない[MUST]。

9.  IANA条項

   本文書は、SIPイベントパッケージ、新規のMIMEタイプ
   application/conference-info+xml、新規のXML名前空間、および新規のXML
   スキーマを登録する。また、既存の登録
   http://www.iana.org/assignments/sip-parameters以下に下位登録の
   「URI purposes (URIの目的)」を作成する。

9.1.  カンファレンスイベントパッケージ登録

   本仕様では、RFC 3265[10]で定義されている登録手順に基づいて、イベント
   パッケージを登録する。登録に必要とされる情報は以下の通り。





Rosenberg, et al.           Standards Track                    [Page 41]

RFC 4575                   Conference Package                August 2006


   パッケージ名: conference

   パッケージまたはテンプレートパッケージ: これはパッケージである。

   公開されている文書: RFC 4575

   連絡先: IESG <iesg@ietf.org>の指定に従い、IETF SIPPING Working Group
      <sipping@ietf.org>

9.2.  application/conference-info+xml MIME登録

   MIMEメディアタイプ名:  application

   MIMEサブタイプ名: conference-info+xml

   必須パラメータ: なし

   オプションのパラメータ: RFC 3023 [7]の規定に従い、application/xml
      のcharsetパラメータと同じ。

   エンコーディングの考慮事項: RFC 3023[7]の規定に従い、application/xml
      のエンコーディングの考慮事項と同じ。

   セキュリティの考慮事項: RFC 3023[7]のセクション10と、本仕様のセク
      ション8を参照のこと。

   相互運用性の考慮: なし

   公開された仕様: 本文書

   このメディアタイプを使用するアプリケーション: このドキュメントタイ
      プは、SIPカンファレンスアプリケーションに対応するために使用され
      る。

   補足情報:

      マジックナンバー: なし

      ファイルの拡張子: .xml

      Macintoshファイルタイプコード: "TEXT"

   詳細情報に関する連絡先: IESG <iesg@ietf.org>の指定に従い、IETF 
      SIPPING Working Group <sipping@ietf.org>

   用途:  汎用(COMMON)





Rosenberg, et al.           Standards Track                    [Page 42]

RFC 4575                   Conference Package                August 2006


   著者/改版管理者: IESG <iesg@ietf.org>の指定に従い、IETF SIPPING
      Working Group <sipping@ietf.org>

9.3.  urn:ietf:params:xml:ns:conference-infoのためのURNの
     下位名前空間登録

   このセクションでは、RFC 3688[21]のガイドラインに従って、新規のXML名
   前空間を登録する。

   URI: この名前空間のURIは、urn:ietf:params:xml:ns:conference-infoで
      ある。

   登録者の連絡先: IESG <iesg@ietf.org>の指定に従い、IETF SIPPING 
      Working Group <sipping@ietf.org>

   XML:

   BEGIN
   <?xml version="1.0"?>
   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
             "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
   <html xmlns="http://www.w3.org/1999/xhtml">
   <head>
     <meta http-equiv="content-type"
        content="text/html;charset=iso-8859-1"/>
     <title>Conference Information Namespace</title>

   </head
   <body>
     <h1>Namespace for Conference Information</h1>
     <h2>urn:ietf:params:xml:ns:conference-info</h2>
     <p>See <a href="http://www.rfc-editor.org/rfc/rfc4575.txt">
        RFC4575</a>.</p>
   </body>
   </html>
   END

9.4.  XMLスキーマ登録

   RFC 3688 [21]のガイドラインに沿って、本仕様はスキーマを登録する。

      URI: 割り当てを依頼する

      登録者の連絡先: IESG <iesg@ietf.org>の指定に従い、IETF SIPPING
         Working Group <sipping@ietf.org>

      XML: XMLは、セクション6に記載されている。



Rosenberg, et al.           Standards Track                    [Page 43]

RFC 4575                   Conference Package                August 2006


9.5.  URI Purposesの下位登録の確立

   IANAは、以下に示す既存の登録以下に、新規の下位登録「URI purposes」を
   作成した。
   http://www.iana.org/assignments/sip-parameters

   URIの目的はXML要素であり、カンファレンスイベントパッケージのRFC 4575
   でエンコードされる。<purpose>要素の値は、カンファレンスイベントパッ
   ケージのコンテキストで意図されるURIの用法を示し、本仕様のセクション
   5.3.1と5.3.2で定義される。

   この下位登録は、以下の3列を含む表として定義される。

   値:  登録に属するトークン

   説明: URIの用途を定義した説明文

   文書: 登録を定義する文書の参照

   IANAは、以下の定義に従う初期コンテンツで表を作成した。

   値            説明                                文書
   -------       ----------------------------------  ----------

   participation このURIはカンファレンスに参加する   [RFC 4575]
                 ために使用できる

   streaming     このURIはストリームされたカンファ   [RFC 4575]
                 レンスデータにアクセスするために
                 使用できる

   event         このURIはカンファレンスイベント     [RFC 4575]
                 パッケージにサブスクライブする
                 ために使用できる

   recording     このURIは記録されたカンファレンス   [RFC 4575]
                 データにアクセスするために使用で
                 きる

   web-page      このURIはカンファレンスの追加情報   [RFC 4575]
                 を含むWebページにアクセスするため
                 に使用できる

   「URI purposes」の新しい値はIANAが登録する。また、RFC 2434 [4]の定義
   に従う仕様が必要である。
   仕様のIANA条項には、以下の情報を含めなければならない[MUST]。



Rosenberg, et al.           Standards Track                    [Page 44]

RFC 4575                   Conference Package                August 2006


   Value (値):  登録する<purpose>要素の値

   Description (説明): URIの用途の短い説明

10.  謝辞

   著者は、Dan Petrie、Sean Olson、Alan Johnston、Rohan Mahy、Cullen
   Jennings、Brian Rosen、Roni Even、Miguel Garciaのコメントとアドバイ
   スについて感謝を述べたい。

11.  参考文献

11.1.  規範となる参考文献

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Moats, R., "URN Syntax", RFC 2141, May 1997.

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

   [4]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 2434, October
         1998.

   [5]   Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names",
         BCP 32, RFC 2606, June 1999.

   [6]   Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
         August 1999.

   [7]   Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
         RFC 3023, January 2001.

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

   [9]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
         Session Description Protocol (SDP)", RFC 3264, June 2002.

   [10]  Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
         Notification", RFC 3265, June 2002.

   [11]  Peterson, J., "A Privacy Mechanism for the Session Initiation
         Protocol (SIP)", RFC 3323, November 2002.




Rosenberg, et al.           Standards Track                    [Page 45]

RFC 4575                   Conference Package                August 2006


   [12]  Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header
         Field for the Session Initiation Protocol (SIP)", RFC 3326,
         December 2002.

   [13]  Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
         "RTP: A Transport Protocol for Real-Time Applications", STD 64,
         RFC 3550, July 2003.

   [14]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
         63, RFC 3629, November 2003.

   [15]  Sparks, R., "The Session Initiation Protocol (SIP) Referred-By
         Mechanism", RFC 3892, September 2004.

   [16]  Rosenberg, J., "A Framework for Conferencing with the Session
         Initiation Protocol (SIP)", RFC 4353, February 2006.

   [17]  Levin, O. and G. Camarillo, "The Session Description Protocol
         (SDP) Label Attribute", RFC 4574, August 2006.

11.2.  Informative References

   [18]  Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
         Protocol (RTSP)", RFC 2326, April 1998.

   [19]  Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
         December 2004.

   [20]  Levin, O., "H.323 Uniform Resource Locator (URL) Scheme
         Registration", RFC 3508, April 2003.

   [21]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
         January 2004.

   [22]  Saint-Andre, P., "A Uniform Resource Identifier (URI) Scheme
         for the Extensible Messaging and Presence Protocol (XMPP)",
         Work in Progress, December 2004.

   [23]  Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
         Initiated Dialog Event Package for the Session Initiation
         Protocol (SIP)", RFC 4235, November 2005.

   [24]  Rosenberg, J., "Obtaining and Using Globally Routable User
         Agent (UA) URIs (GRUU) in the Session Initiation Protocol
         (SIP)", Work in Progress, May 2006.






Rosenberg, et al.           Standards Track                    [Page 46]

RFC 4575                   Conference Package                August 2006


   [25]  Peterson, J. and C. Jennings, "Enhancements for Authenticated
         Identity Management in the Session Initiation Protocol (SIP)",
         RFC 4474, August 2006.

著者の連絡先

   Jonathan Rosenberg
   Cisco Systems
   600 Lanidex Plaza
   Parsippany, NJ  07054
   US

   Phone: +1 973 952-5000
   EMail: jdrosen@cisco.com
   URI:   http://www.jdrosen.net


   Henning Schulzrinne
   Columbia University
   M/S 0401
   1214 Amsterdam Ave.
   New York, NY  10027
   US

   EMail: schulzrinne@cs.columbia.edu
   URI:   http://www.cs.columbia.edu/~hgs


   Orit Levin (editor)
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   US

   EMail: oritl@microsoft.com
















Rosenberg, et al.           Standards Track                    [Page 47]

RFC 4575                   Conference Package                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年
-----------------------------------------------------------------------
Rosenberg, et al.           Standards Track                    [Page 48]