Network Working Group J. Rosenberg Request for Comments: 4235 Cisco Systems Category: Standards Track H. Schulzrinne Columbia University R. Mahy, Ed. SIP Edge LLC November 2005 INVITEによって開始されるダイアログに関する セッション開始プロトコル(SIP)用イベントパッケージ An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP) 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準ト ラックプロトコルを規定するものであり、改善のための議論や提案を依頼す るものである。標準化の段階や、プロトコルの位置付けについては、最新版 の"Internet Official Protocol Standards" (STD 01)を参照されたい。こ の文書の配信は無制限である。 著作権表記 Copyright (C) The Internet Society (2005). 概要 本文書は、SIPイベントアーキテクチャのためのダイアログイベントパッケー ジを、このパッケージに対する通知で使用されるデータフォーマットととも に定義する。ダイアログパッケージを使用すると、他のユーザにサブスクラ イブし、サブスクライブ対象ユーザーが関与しているINVITE開始ダイアログ (INVITE-initiated dialog)の使用ステートが変化したときに通知を受信す ることができるようになる。 目次 1. はじめに ....................................................... 3 2. 用語 ........................................................... 4 3. ダイアログイベントパッケージ ................................... 4 3.1. イベントパッケージ名 ..................................... 4 3.2. イベントパッケージパラメータ ............................. 4 3.3. SUBSCRIBEのボディ ....................................... 5 3.4. サブスクリプションの有効期間 ............................. 6 3.5. NOTIFYのボディ ........................................... 6 3.6. SUBSCRIBEリクエストのノーティファイア処理 ............... 7 3.7. NOTIFYリクエストのノーティファイア生成 ................... 8 3.7.1. 登録ステートマシン ............................... 8 3.7.2. ステートマシンの適用 ............................ 11 Rosenberg, et al. Standards Track [Page 1] RFC 4235 Dialog Package November 2005 3.8. NOTIFYリクエストのサブスクライバ処理 .................... 12 3.9. フォークしたリクエストの処理 ............................ 12 3.10. 通知の頻度 ............................................ 13 3.11. ステートエージェント .................................. 13 4. ダイアログ情報フォーマット .................................... 13 4.1. ダイアログ情報の構成 .................................... 13 4.1.1. ダイアログ要素 .................................. 14 4.1.2. state要素 ...................................... 15 4.1.3. duration要素 .................................... 15 4.1.4. replaces要素 .................................... 15 4.1.5. referred-by要素 ................................ 16 4.1.6. local要素とremote要素 .......................... 16 4.2. 通知のボディ例 .......................................... 17 4.3. 一貫したステートの構築 .................................. 18 4.4. スキーマ ................................................ 19 5. 新しいメディアフィーチャーパラメータの定義 .................... 22 5.1. 「sip.byeless」パラメータ .............................. 22 5.2. 「sip.rendering」パラメータ ............................ 23 6. 例 ............................................................ 24 6.1. 基本的な例 .............................................. 24 6.2. 共有回線電話システムの模倣 .............................. 26 6.3. プライバシを保持する最小ダイアログ情報 .................. 31 7. セキュリティの考慮事項 ........................................ 32 8. IANA条項 ...................................................... 32 8.1. application/dialog-info+xml MIME登録 .................... 33 8.2. urn:ietf:params:xml:ns:dialog-infoのための URNの下位名前空間登録 ...................................... 34 8.3. スキーマ登録 ............................................ 34 8.4. MIMEフィーチャーパラメータ登録 .......................... 34 8.4.1. sip.byeless .................................... 35 8.4.2. sip.rendering .................................. 35 9. 謝辞 .......................................................... 36 10. 参考文献 .................................................... 36 10.1. 規範となる参考文献 .................................... 36 10.2. 有益な参考文献 ........................................ 37 Rosenberg, et al. Standards Track [Page 2] RFC 4235 Dialog Package November 2005 1. はじめに SIPのイベントフレームワーク[1]には、SIPネットワークにおけるイベント へのサブスクリプションとイベント通知の一般的な仕組みが定義されてい る。また、パッケージとは、定義済みイベント群のためのイベントメカニズ ム独自の「インスタンス化」である、という概念が紹介されている。たとえ ば、ユーザープレゼンス[16]、ウォッチャー情報[17]、および、メッセージ 待ちインジケータ[18]などのパッケージが定義されてきた。本文書では、 INVITE開始ダイアログの使用に関するイベントパッケージを定義する。ダイ アログとは、2つのSIPピア間で確立されたSIP関係を指す[2]。ダイアログは 様々なメソッドで作成することができるが、RFC 3261で定義されているのは INVITEメソッドのみである。RFC 3265 [1]ではSUBSCRIBEとNOTIFYメソッド が定義され、新しいダイアログ用法も作成されている。ただし、このパッ ケージを使用して非セッションダイアログの使用ステートをモデリングする ことは、本仕様の範囲外である。 INVITEダイアログの使用ステートを知ることによって、多様な応用が可能に なる。一部の例を以下に示す。 自動コールバック: この基本的な公衆電話交換回線網(Public SwitchedTelephone Network/PSTN)の応用例では、ユーザーAがユー ザーBへ発呼するが、Bは通話中である。ユーザーAは、ユーザーBが電 話を切った後にコールバックしてほしい。Bが電話を切ると、ユーザー Aの電話が鳴る。Aが電話を取ると、発着信音が両側で鳴り、Bへ接続 される。これをSIPで実装するには、Bでダイアログが完了したときに Aが通知を受け取るための仕組みが必要となる。 プレゼンスが有効なカンファレンス： このアプリケーションで、ユー ザーAは、ユーザーBおよびCとのカンファレンスコールの開始したいと 考えている。カンファレンスコールはスケジュールされるのではな く、A、B、Cの全員が電話に出られる時点で自動的に生成される。これ を実行するために、アプリケーションを提供するサーバーは、A、B、C が「オンライン」かどうか、アイドルではないか、また、通話中では ないかを認知しようとする。A、B、Cが通話中かどうかは、2つの方式 で判断できる。第1の方法では、サーバーは、A、B、Cのコールステー トフルプロキシとして動作する方法である。そのため、サーバーは ユーザーのコールステートを認識する。 これは常に可能とは限らないが、スケーラビリティ、信頼性が向上 し、複雑な操作が可能になる。その他に、サーバーがユーザー達の ダイアログステートにサブスクライブし、そのステートが変化した ときに通知を受信する方法もある。この場合、分散方式でアプリケー ションに通知することができる。つまり、サーバーは、ユーザーと同 じドメインに所属する必要はない。 IMカンファレンスアラート： この応用例では、ユーザーは電話でカン ファレンスに参加している場合、そのカンファレンスに他のユーザー が参加するたびに、その電話でインスタントメッセージ(IM)を受信す ることができる。このIMアラートは、カンファレンスサーバーとは別 のアプリケーションによって生成される。 Rosenberg, et al. Standards Track [Page 3] RFC 4235 Dialog Package November 2005 通常、ダイアログパッケージは、分散型アプリケーションの構築を許容す る。この分散型アプリケーションは、ダイアログステートに関する情報を必 要とするが、ステートが格納されているエンドユーザー環境とは同居してい ない。 本文書は、2つの新しい着呼側機能[10]フィーチャーパラメータも定義する。 o 「sip.byeless」。SIPユーザーエージェント(UA)にセッションを終了 する機能がないことを示す(たとえば、何らかの告知サービス、記録 サービス、コールセンターなどの場合)。これ以降、UAはセッションに 参加する意志がない。 o 「sip.rendering」。ユーザーエージェントが受信中の任意メディアを レンダリングするかどうかを明確に記述する。ダイアログパッケージ が作成される理由となった応用方法のうち、多数にこれらのフィー チャーパラメータを適用できる。たとえば、カンファレンス、プレゼ ンス、および共有回線(セクション6.2で説明)などである。 2. 用語 本文書では、以下のキーワードはRFC 2119 [9]に記述されている通りに解釈 されるべきであり、準拠する実装に対する要求レベルを示すものである。 「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、 「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」 3. ダイアログイベントパッケージ このセクションには、[1]で規定されるように、SIPイベントパッケージ定義 の詳細を記載する。 3.1. イベントパッケージ名 このイベントパッケージ名は「dialog」である。このパッケージ名は、[1] で定義されるように、EventおよびAllow-Eventsヘッダーフィールドで伝達 される。 3.2. イベントパッケージパラメータ このパッケージでは、call-id、to-tag、from-tag、 include-session-descriptionという4つのイベントパッケージパラメータを 定義する。特定ダイアログへのサブスクリプションがリクエストされている 場合、サブスクライブ先のダイアログを識別するために、call-id、to-tag、 from-tagを指定しなければならない[MUST]。to-tagはローカルタグに、 from-tagはリモートタグに、call-idはCall-IDに対応する。 include-session-descriptionパラメータは、サブスクライブした1つまたは 複数のダイアログ用法に関連するセッション記述をサブスクライバが受け取 りたいかどうかを示す。 Rosenberg, et al. Standards Track [Page 4] RFC 4235 Dialog Package November 2005 また、UAC(ユーザーエージェントクライアント)が送信する1個のINVITEの結 果として作成される複数ダイアログに、サブスクライブすることもできる。 この場合、call-idとto-tagを提示しなければならない[MUST]。to-tagは ローカルタグに対応し、call-idはCall-IDに対応する。 これらパラメータのABNFは以下の通り。RFC 3261のABNFから、EQUAL、 DQUOTE、およびトークンなど、多くの構文が参考にされている。 call-id = "call-id" EQUAL ( token / DQUOTE callid DQUOTE ) ;; 注意: callid内のDQUOTEはエスケープしなければなら ない[MUST]。 from-tag = "from-tag" EQUAL token to-tag = "to-tag" EQUAL token with-sessd = "include-session-description" 二重引用符を含むcall-idの場合、バックスラッシュ引用(backslash- quoting)の仕組みを使用して、その二重引用符をエスケープしなければなら ない[MUST]。call-idパラメータは、場合によっては、引用符付き文字列と して示す必要がある、ということに注意。この理由は、callid作成とcallid が使用する単語作成のABNF(どちらもRFC 3261 [1]に記載されている)で、 トークン内で許容されていない文字(「@」、「[」、「:」など)を許容する ためである。 3.3. SUBSCRIBEのボディ ダイアログパッケージのSUBSCRIBEリクエストには、ボディを含めてもよ い[MAY]。このボディでは、サブスクリプションに適用されるフィルタを定 義する。フィルタドキュメントについては本文書では規定されないが、現時 点では、将来の標準化過程において主題となることが予想される。 ダイアログパッケージのSUBSCRIBEは、ボディなしで送信してもよい[MAY]。 これは、サブスクリプションフィルタのデフォルトポリシーを示す。デフォ ルトポリシーを以下に示す。 o Eventヘッダーフィールドにダイアログ識別子が含まれる場合、SUBSCRIBE のリクエストURIで特定されるユーザーにマッチする任意ダイアログのス テートが変更されるたびに、通知が生成される。 o Eventヘッダーフィールドにダイアログ識別子が含まれない場合でも、 SUBSCRIBEのリクエストURIで特定されるユーザーの任意ダイアログの ステートが変更されるたびに、通知が生成される。ただし、以下のよう に例外がある。サブスクライバのターゲット(Contact)URIが、特定ダイ アログのリモートターゲットURIと同一の場合、そのダイアログのdialog 要素は、サブスクライバによって削除される。(サブスクライバは、すで にダイアログに直接参加するパーティであるため、このような通知は不 Rosenberg, et al. Standards Track [Page 5] RFC 4235 Dialog Package November 2005 要である。)ダイアログの削除後にダイアログが残らない場合、そのサブ スクライバに対する通知自体も削除され、そのサブスクライバに関する dialog-info要素のバージョン番号はインクリメントされない。あるサブ スクライバ用の暗黙的フィルタは、他のサブスクライバへの通知には影 響を与えない。 o 通常、通知には完全なステートを含めない。正確に言うと、通知には、 ステートが変わったダイアログのステートのみを指定する。 例外は、SUBSCRIBEに対する応答で送信されるNOTIFYと、dialog要素を含 まないNOTIFYである。これらのNOTIFYには、ダイアログステートの完全 な一覧が含まれる。 o 通知には、ダイアログに参加するユーザーのID、ターゲットURI、および ダイアログ識別子を含む。明示的に要求されるか、明示的に認可される 場合を除き、セッション記述は含まない。 3.4. サブスクリプションの有効期間 ダイアログステートはすぐに変化する。電話での通話は、通常、1度確立する と数分続く(当然ながら、他のセッションタイプの場合は異なる)。一方で、 新規通話が始まるまでの間隔は、通常は長期である。クライアントは、明示 的な有効期間を指定すべきである[SHOULD]。 ダイアログステートには、2つの異なる利用事例がある。1つ目の事例は、 サブスクライバが、特定ダイアログまたは複数ダイアログのステートに関心 がある場合(また、このようなダイアログのステートについてのみ、情報の 取得が認可されている場合)である。この場合、ダイアログが終了すると、 サブスクリプションも終了する。このような場合、サブスクリプション有効 期間値の大部分は無関係なので、通常のダイアログ有効期間よりも長くすべ きである[SHOULD]。デフォルトの有効期間は2時間にすることが推奨される。 これで、ほとんどのダイアログが対象になる可能性が高くなる。 2つ目の事例では、サブスクライバは、特定ユーザーの全ダイアログのステー トに関心がある。この場合、より短時間の間隔の方が適している。この場合 のサブスクリプションでは、デフォルトは1時間である。 3.5. NOTIFYのボディ RFC 3265[1]に記述されているように、NOTIFYメッセージには、サブスクラ イブされたリソースのステートが記述されているボディを含める。この ボディは、SUBSCRIBEのAcceptヘッダーフィールドに列挙された形式か、 AcceptヘッダーフィールドがSUBSCRIBEから省略された場合は、パッケージ 独自のデフォルト形式である。 本イベントパッケージでは、通知のボディにはダイアログ情報ドキュメント を含める。このドキュメントには、サブスクライブされたリソースと関連付 けられる1個以上のダイアログのステートが記述されている。サブスクライ Rosenberg, et al. Standards Track [Page 6] RFC 4235 Dialog Package November 2005 バとノーティファイアはすべて、セクション4に記載される「application/ dialog-info+xml」データ書式に対応しなければならない[MUST]。SUBSCRIBE リクエストには、Acceptヘッダーフィールドを含めてもよい[MAY]。Accept ヘッダーフィールドがない場合、初期値は「application/dialog-info+xml」 である。Acceptヘッダーフィールドを提示する場合、 「application/dialog-info+xml」を含めなければならず[MUST]、また、他に ダイアログステートを表現可能なタイプを含めてもよい[MAY]。 当然ながら、サーバーにより生成される通知は、SUBSCRIBEリクエスト内の Acceptヘッダーフィールドで指定される形式のいずれかに則っていなければ ならない[MUST]。 3.6. SUBSCRIBEリクエストのノーティファイア処理 ユーザーのダイアログ情報には、機密情報が含まれる。 そのため、すべてのサブスクリプションは、承認(approval)の前に、認証 (authenticated)および認可(authorized)されるべきである[SHOULD]。本 パッケージを実装する場合、基本機能として、ダイジェスト認証の仕組みに 対応しなければならない[MUST]。認可ポリシーは、通例通り、管理者の裁量 にある。ただし、いくつかの推奨はできる。 ユーザーBのポリシーで、ユーザーAからユーザーBへの発呼を許可している場 合、ユーザーAからのダイアログサブスクリプションも許可することが推奨 される[RECOMMENDED]。ただし、通知で提示する情報には、ダイアログ識別 情報を含めない。含むのは、そのユーザーが通話中かどうかを示す情報のみ である。具体的には、INVITEを送信したかどうか以上の情報を、ユーザーに 知らせるべきではない。(「仮想(virtual)」ダイアログの概念がセクション 3.7.2に記載されている。このような通知のボディ例を以下に示す。) confirmed Addresses-of-Record「X」で登録したユーザーエージェントは、自身をXと 認証することができるエンティティからのサブスクリプションを認可すべき である[SHOULD]。この場合、ダイアログステートに関する完全な情報が送信 されるべきである[SHOULD]。この認可の動作によって、1ユーザーに対応す る複数デバイスが、互いのステートを認識できるようになる。これは、単一 回線拡張(single-line-extension) (共有回線(shared lines)とも呼ばれる) のようなアプリケーションの場合に有効である。 Rosenberg, et al. Standards Track [Page 7] RFC 4235 Dialog Package November 2005 多くの「共有回線(shared-lines)」の実装には、共有のAddresses-of- Recordに関する通話の詳細を非公開(private)にする機能があることに 注意。この認可ポリシーは、共有回線の非公開が要求された場合には、 dialog要素のid属性とstate要素のみを通知に含み、共有回線の非公開が 要求されない場合には、完全な情報を通知に含む、という結果にするこ とが可能であり、適切である。 3.7. NOTIFYリクエストのノーティファイア生成 通知がダイアログパッケージに対して生成されるのは、INVITEリクエストが 送信される場合、あるUAで新規のダイアログが発生した場合、または既存 ダイアログのステートまたは特性が変わった場合である。したがって、通知 をいつ送信するか、また、どのような通知内容にすべきか、を正確に判断す るには、ダイアログステートのモデルが必要である。SIP仕様には、適度に 定義されたダイアログのライフサイクルがある。ただし、明確にはモデルさ れていない。本仕様では、有限ステートマシン(finite state machine/FSM) によって、ダイアログステートの明確なモデルを提示する。 NOTIFYリクエストには、ステートまたは参加の情報が変わったダイアログに 関する情報のみを含めることを推奨する[RECOMMENDED]。ただし、ノーティ ファイアがSUBSCRIBEリクエストを受け取る場合、トリガされるNOTIFYには、 サブスクライバが参照を認可されている全ダイアログのステートを含めるべ きである[SHOULD]。 3.7.1. 登録ステートマシン ダイアログステートのモデルは、2つの要因から複雑になる。第1にフォーク である。これは、1つのINVITEによって、多くのダイアログがUACで生成され る原因となる。2つめは、UAC(ユーザーエージェントクライアント)とUAS (ユーザーエージェントサーバー)で、ステートのビューが異なることであ る。第1の問題への対処として、ダイアログの有限ステートマシン(Finite State Machine/FSM)を拡張して、INVITEの伝送と、1xxおよび2xx応答の受信 による実際のダイアログ作成との間のステートを含めることを選択した。結 果的に、本仕様では、完全にインスタンス化される前は、ダイアログ向けの ダイアログステートの概念に対応する。 また、UACとUASの双方用に1つのFSMを使用することも選択した。 Rosenberg, et al. Standards Track [Page 8] RFC 4235 Dialog Package November 2005 +----------+ +----------+ | | 1xx-notag | | | |----------->| | | Trying | |Proceeding|-----+ | |---+ +-----| | | | | | | | | | +----------+ | | +----------+ | | | | | | | | | | | | | +<--C-----C--+ |1xx-tag | | | | | | cancelled| | | V | rejected| | |1xx-tag +----------+ | | | +------->| | |2xx | | | | | +<--C--------------| Early |-----C---+ 新規タグ | | replaced | | | | 付きの | | | |<----C---+ 1xx-tag | | +----------+ | (新規FSM | | 2xx | | インスタンス | +----------------+ | | の作成) | | |2xx | | | | | V V V | +----------+ +----------+ | | | | | | | | | | | |Terminated|<-----------| Confirmed|<----+ | | error | | | | timeout | | +----------+ replaced +----------+ local-bye | ^ remote-bye | | | | +------+ 新規タグ付きの2xx (新規FSMインスタンス の作成) 図3 ダイアログステート用FSMを図3に示す。FSMは、UACの場合とUASの場合を分け て考えると、理解しやすい。 Rosenberg, et al. Standards Track [Page 9] RFC 4235 Dialog Package November 2005 FSMは、UACがINVITEリクエストを送信するときのTrying (試行中)ステートで 作成される。タグなしの1xxを受信すると、FSMはProceeding (進行中)ステー トへ遷移する。SIP仕様で定義されるように、まだ実際のダイアログは存在し ていない点に注意。ただし、3コンポーネント中2つのダイアログID (呼識別 子およびローカルタグ)が知られているという意味では、「半ダイアログ (half-dialog)」は存在する。タグ付きの1xxを受信すると、FSMはEarly (初 期)ステートへ遷移する。この時点で、完全なダイアログ識別子が定義され る。2xxを受信した場合、FSMはConfirmed (確認済み)ステートへ遷移する。 EarlyまたはConfirmedステートへの遷移後に、UACが異なるタグの付いた1xx (Earlyの場合)または2xx(Confirmedの場合)を新たに受信すると、FSMのイン スタンスがもう1つ作成され、それぞれEarlyまたはConfirmedステートに初 期化される。この手法の長所は、フォークしない通常の処理時に、招待と結 果として生じるダイアログの全体のステートを示すFSMが1つしかない、とい う点である。 UACが万一CANCELを送信し、続けて自身のINVITEトランザクションに対し487 を受信すると、このINVITEから生じたすべてのFSMは、「canceled」イベン トを伴ってTerminated (終了済み)ステートへ遷移する。UACが、現在の EearlyダイアログまたはConfirmedダイアログを置換する新規の招待を (Replaces[13]ヘッダーで)受け取った場合、置換される招待から生じたすべ てのINVITEトランザクションは、「replaced」イベントを伴ってTerminated ステートへ遷移する。INVITEトランザクションが何らかの理由で非2xx応答 で終了する場合、そのINVITEから生じたすべてのFSMは、「rejected」イベ ントを伴ってTerminatedステートへ遷移する。 Confirmedステートへ遷移すると、呼はアクティブになる。Terminatedステー トへ遷移する可能性があるのは、UACがBYEを送信または受信する場合(必要に 応じて「local-bye」イベントと「remote-bye」イベントに対応)、ダイアロ グ内リクエスト(mid-dialog request)によって481または408応答が生成され る場合(「error」イベントに対応)、またはダイアログ内リクエストによっ て応答が生成されない場合(「timeout」イベントに対応)である。 UASの立場から見ると、INVITEを受信すると、TryingステートでFSMが作成さ れる。タグなしの1xxを送信すると、FSMはProceedingステートへ遷移する。 タグ付きの1xxを送信すると、FSMはEarlyステートへ遷移し、2xxを送信する と、Confirmedステートへ遷移する。UASが万が一CANCELリクエストを受信し た後に、INVITEに対して487応答を生成する場合(これはProceedingとEarly ステートのときに発生する可能性がある)、FSMは、「cancelled」イベント を伴ってTerminatedステートへ遷移する。万が一UASがINVITEリクエストに 対して他の非2xx最終応答を生成する場合、FSMは「rejected」イベントを 伴ってTerminatedステートに遷移する。UASが、現在のConfirmedダイアログ を置換する新規の招待を(Replaces[13]ヘッダーフィールドで)受け取った 場合、置換される招待は、「replaced」イベントを伴ってTerminatedステー Rosenberg, et al. Standards Track [Page 10] RFC 4235 Dialog Package November 2005 トへ遷移する。Confirmedステートに遷移すると、UACの場合と同様の理由 で、他のTerminatedステートへの遷移も発生する。 Tryingステートから、「cancelled」を伴ったTerminatedステートへ遷移 することはない。これは、SIPの仕様では、暫定応答を受け取る前に CANCELを伝送することは禁止されているためである。ただし、FSMでは、 Trying、Proceeding、およびEarlyステートから、Terminatedステートへ の遷移を統一するためだけに、この遷移が定義される。 3.7.2. ステートマシンの適用 FSMのどのイベント遷移時でも、ノーティファイアはNOTIFYリクエストを生成 してよい[MAY]。これを実行するかどうかは、ポリシー次第である。ただし、 一定の一般的なガイドラインが提示される。 サブスクライバが認証されていない場合、あるいは、認証されているが特定 の認可ポリシーを持たないサードパーティである場合、個々のダイアログへ のサブスクリプション、または特定の複数ダイアログに対するサブスクリプ ションを禁じることが推奨される[RECOMMENDED]。全ダイアログ(つまり、 Eventヘッダーフィールドにダイアログ識別子がないもの)に対するサブスク リプションのみが許可される。この場合、すべてのダイアログに渡る実際の ダイアログステートは、伝達されない。その代わり、1個の「仮想 (virtual)」ダイアログFSMが使用され、イベント遷移はそのFSM上で伝達さ れる。 UAにConfirmedステートのダイアログがある場合、仮想FSMはConfirmedステー トである。UAにConfirmedステートのダイアログはないが、Earlyステートの ダイアログが1つでも存在する場合、仮想FSMはEarlyまたはConfirmedステー トである。ConfirmedまたはEarlyステートのダイアログはないが、 Proceedingステートのダイアログが1つでも存在する場合、仮想FSMは Proceeding、Early、またはConfirmedステートである。Confirmed、Early、 Proceedingステートのダイアログはないが、Tryingステートのダイアログが 1つでも存在する場合、仮想FSMはTrying、Proceeding、Early、または Confirmedステートである。アクティブな呼の場合とは対照的に、どのステー トを使用すべきかについての選択は、未知のユーザーに対して電話をかけて いることを、UAが知らせたいかどうかによる。 優先度が指定されていない場合は、どのような場合でもConfirmedを使用す ることが推奨される(セクション3.3の例を参照)[RECOMMENDED]。 さらに、仮想FSMの変化を通知する場合、FSMのステートとイベント遷移(ダイ アログ識別子はなし)以外の情報を伝達しないことが推奨される [RECOMMENDED](このモデルでは、いかなる場合でもダイアログ識別子は明確 に定義されていない)。この仮想FSMを使用することで、伝達される情報が最 小限になる。サブスクライバは、進行中の呼の数または相手は認知できず、 呼の存在のみを認知する。ユーザーにINVITEを送信しただけの場合に、受け Rosenberg, et al. Standards Track [Page 11] RFC 4235 Dialog Package November 2005 取る情報と同じである。この場合、486 (Busy Here)応答では通話中と示さ れる。 サブスクライバを認証するとき、およびサブスクライバ自身をUAが使用する 同じAddresses-of-Recordで認証するとき、明示的な認可ポリシーが定義され ていない場合、レポートするように登録しているダイアログに関して、完全 なダイアログIDとともにすべてのステートを遷移することが推奨される [RECOMMENDED]。つまり、ダイアログ識別子がEventヘッダーフィールドにな い場合はすべてのダイアログ、それ以外の場合はEventヘッダーフィールド で識別される特定のダイアログ群を示す。 ダイアログに関連する特性が変更された場合、ノーティファイアはNOTIFYリ クエストを生成すべきである[SHOULD]。この特性には、Contact URI、 Contactパラメータ、セッション記述が含まれるため、この情報を修正する re-INVITEおよびUPDATEリクエスト[3]を受信した場合は、通知のトリガとし てもよい[MAY]。 3.8. NOTIFYリクエストのサブスクライバ処理 SIP Eventフレームワークは、サブスクライバがNOTIFYリクエストを独自に 処理する方法をパッケージが規定することを期待している。特に、パッケー ジは、NOTIFYリクエストを使用して、サブスクライブしたリソースの一貫し たステートビューを構築する方法を規定すべきである。 一般に、ダイアログパッケージのNOTIFYには、ステートが変わったダイアロ グに関する情報のみが含まれる。全ダイアログのステート全体の一貫した ビューを構築するには、ダイアログパッケージに対するサブスクライバは、 長い時間に渡って受け取ったNOTIFYを合成する必要がある。 このパッケージ内の通知では、部分的な情報を伝達できる。つまり、サブス クリプションに関連付けられたステートのサブセットに関する情報を示すこ とができる。これは、一貫性があり矛盾のないステートを構築するには、明 確なアルゴリズムを定義する必要があるということを意味する。この仕組み の詳細は、個々のドキュメントタイプ固有のものである。 application/dialog-info+xmlドキュメントから一貫した情報を構築するこ とについては、セクション4.3を参照のこと。 3.9. フォークしたリクエストの処理 ダイアログステートは、UAを通して特定ユーザーに配信されるため、ダイア ログ ステートに対するSUBSCRIBEリクエストがフォークし、複数のUAに到達 することは、合理的であり、または有益である。 結果として、ダイアログステートに対するフォークされたSUBSCRIBEリクエ ストは、複数のサブスクリプションを組み込む可能性がある。このパッケー Rosenberg, et al. Standards Track [Page 12] RFC 4235 Dialog Package November 2005 ジに対するサブスクライバは、1個のSUBSCRIBEの結果として生成された各 NOTIFYに対して、サブスクリプションステートを組み込むように備えなけれ ばならない[MUST]。 3.10. 通知の頻度 輻輳制御(congestion control)の理由から、通知頻度が過度にならないよう にすることが重要である。サーバーは、1人のサブスクライバについて、1秒 に1度よりも短い頻度で通知を生成しないことが推奨される[RECOMMENDED]。 3.11. ステートエージェント ダイアログステートは、理想的にはダイアログが存在するユーザーエージェ ント内で保持される。そのため、ダイアログを保持する要素が、ダイアログ に対するサブスクリプションを処理するのが最適である。ただし、場合に よっては、ユーザーが保持するダイアログのステートは、ネットワークエー ジェントも知っている可能性がある。このようなステートエージェントを本 パッケージに使用してもよい[MAY]。 4. ダイアログ情報フォーマット ダイアログ情報は、整形済みのXMLドキュメントでなければならない[MUST]。 また有効なXMLドキュメントであるべき[SHOULD]である。ダイアログ情報ド キュメントはXML 1.0に基づかなければならない[MUST]。また、UTF-8を使用 してエンコードされなければならない[MUST]。本仕様では、ダイアログ情報 ドキュメントとドキュメントの断片を特定するために、XML名前空間を利用 する。本仕様で定義される要素に対する名前空間URIは、URN[5]であり、[6] で定義され、[7]で拡張される名前空間識別子「ietf」を使用している。こ のURNを以下に示す。 urn:ietf:params:xml:ns:dialog-info ダイアログ情報ドキュメントは、ルート要素タグ「dialog-info」で開始さ れる。 4.1. ダイアログ情報の構成 ダイアログ情報ドキュメントは、dialog-info要素で開始される。 この要素は以下の3つの必須属性を持つ。 o version: この属性によって、受信者は、ダイアログ情報ドキュメントを 適切に順序付けできる。versionは0で始まり、サブスクライバへ送信さ れる新規ドキュメントごとに1ずつインクリメントする。 versionは1サブスクリプション内を範囲とする。versionは、負ではない 32ビット整数を使って表現可能でなければならない[MUST]。 o state: この属性は、ドキュメントに完全なダイアログ情報が含まれる か、または、前のドキュメント以降にステートが変わったダイアログに 関する情報のみが含まれる(部分的)かを示す。 Rosenberg, et al. Standards Track [Page 13] RFC 4235 Dialog Package November 2005 o entity: この属性には、ダイアログ情報がドキュメントの他の部分で伝 達されるユーザーについて、特定するURIが含まれる。このユーザーは、 「観察ユーザー(observed user)」と呼ばれる。 「dialog-info」要素には、一連のダイアログのサブ要素が0個以上含まれ る。サブ要素のそのそれぞれが特定のダイアログを示す。以下に例を示す。 4.1.1. dialog要素 dialog要素は、特定のダイアログまたは「half-dialog」に関する情報を伝達 する。必須属性はidのみである。id属性には、このダイアログまたは 「half-dialog」の識別子として使用可能な1個の文字列を指定する。このid 属性は、RFC 3261[2]で定義されているダイアログIDとは異なる識別子だが、 関連はある。 発呼側では、idはINVITEリクエストが送信される際に作成される。タグ付き の1xx応答、または2xx応答を受信した場合、ダイアログは正式に作成され る。idはそのまま変更されない。ただし、新規の1xxや2xxを受信した場合、 別のダイアログが(また結果的にFSMも)作成される結果となり、ダイアログ は新しいidを割り当てられる。 着呼側では、既存のダイアログ外のINVITEを受信するときにidが作成され る。2xxまたはタグ付きの1xxが送信されると、ダイアログは作成されるが、 idはそのまま変更されない。 idは、1つのUAにおけるすべてのカレントダイアログの中で一意でなければ ならない[MUST]。 以下のように、ダイアログに関する識別情報を提供するオプション属性がい くつかある。 o call-id: この属性は、ダイアログ識別子のcall-idコンポーネントを 示す文字列である。(call-id内の一重引用符および二重引用符は、 「"」は「"e;」に、「'」は「'」にエスケープする必要が ある。) o local-tag: この属性は、ダイアログ識別子のlocal-tagコンポーネン トを示す文字列である。 o remote-tag: この属性は、ダイアログ識別子のremote-tagコンポーネ ントを示す文字列である。INVITE生成されて最終応答またはタグ付き Rosenberg, et al. Standards Track [Page 14] RFC 4235 Dialog Package November 2005 の暫定応答が受信されず、結果として「half-dialog」しか存在しな い場合、remote-tag属性は提示されない。 o direction: この属性は、イニシエータまたは受信側のいずれかを 示す。また、観察ユーザーが、ダイアログのイニシエータか、または ダイアログを作成したINVITEの受信側かを示す。 ... dialog要素のサブ要素では、ダイアログに関する補足情報が提示される。 localサブ要素およびremoteサブ要素にはダイアログに関連する参加者の特 性が記述されるが、ダイアログ自体の詳細情報を提示するサブ要素もある。 唯一の必須のサブ要素は、state要素である。 4.1.2. state要素 「state」要素はダイアログのステートを示す。要素値は、上述のFSMでス テータスの1つを記述する列挙型である。state要素には、オプションのevent 属性がある。event属性を使用して、「terminated」ステートへの遷移の原 因となったイベントを示すことができる。また、オプションのcode属性も ある。code属性を使用して、元のINVITEに対する応答が原因で発生した遷移 に関連付けられる応答コードを示す。 terminated 4.1.3. duration要素 「duration」要素には、FSM作成後の総時間が、秒単位で含まれる。 145 4.1.4. replaces要素 「replaces」要素は、Replacesヘッダーフィールドが含まれる招待の結果と して、新規のダイアログを置換されるダイアログと関連付けるために使用さ れる。replaces要素は、置換側ダイアログ(新規ダイアログの方)にのみ存在 する。また、この要素には、被置換側ダイアログのcall-id、local-tag、お よびremote-tagを指定した属性が含まれる。 Rosenberg, et al. Standards Track [Page 15] RFC 4235 Dialog Package November 2005 4.1.5. referred-by要素 「referred-by」要素は、新規のダイアログを、そのダイアログのトリガと なったREFER[12]リクエスト新規ダイアログ関連付けるために使用される。 referred-by要素は、Referred-By[11]ヘッダーフィールドを含むREFERリクエ ストによって、トリガされたダイアログで提示される。また、この要素に は、(オプションで)display属性と、値としてReferred-By URIが含まれる。 sip:bob@example.com 4.1.6. local要素とremote要素 「local」要素と「remote」要素は、それぞれローカルの参加者とリモート の参加者に関する情報を含むdialog要素のサブ要素である。いずれも、オプ ションのサブ要素をいくつか持っている。サブ要素では、参加者から伝達さ れる、参加者のアイデンティティ、ターゲットURI、ターゲットのフィー チャータグ、およびセッション記述が指定される。 4.1.6.1. indentity要素 「identity」要素は、[2]で定義されるように、必要に応じてローカルURIま たはリモートURIを示す。identity要素には、displayというオプションの属 性がある。display属性には、該当するURIの表示名が含まれる。 複数のアイデンティティ(たとえば、sip: URI、tel: URIなど)がすべて 1人の参加者に関連付けられる場合は、複数のアイデンティティが含まれ る可能性がある、ということに注意。 リクエストごとに識別情報が繰り返されるのを回避するために、対応す るlocal要素またはremote要素にidentity要素が提示されていない場合、 サブスクライバは識別URIが前の通知と同一であると見なすことができ る。identity要素が、通知のlocal部またはremote部に存在する場合、 identityタグの新規一覧は、対応する部分の旧一覧を完全に置換する。 sip:anonymous@anonymous.invalid 4.1.6.2. target要素 「target」要素には、ローカルまたはリモートのターゲットURIが含まれる。 このターゲットURIは、「uri」属性についてRFC 3261[2]で定義されるよう に、このダイアログのユーザーエージェントによって構築される。 Rosenberg, et al. Standards Track [Page 16] RFC 4235 Dialog Package November 2005 この要素は、paramサブ要素に([10]で定義されているものなど)、Contact ヘッダーパラメータの一覧を含む。param要素には、2つの必須属性pnameと pvalが含まれるブール型パラメータは、明示的なpval値「true」と「false」 によって表される(フィーチャーパラメータが明示的に否定される場合 など)。まったく値が指定されていないパラメータは、明示的なpval値 「true」で表される。param要素自体には、コンテンツがない。リクエスト ごとにContact情報が繰り返されるのを回避するために、対応するlocal要素 またはremote要素にtarget要素が提示されていない場合、サブスクライバ はターゲットURIおよびパラメータが前の通知と同一であると見なすことが できる。target要素が、通知のlocal部またはremote部に存在する場合、新 規のtargetタグと、パラメータタグ一覧は、対応する部分の旧targetとパラ メータ一覧を完全に置換する。引用符([10]で文字列値を引用符で囲むとき に使用する角かっこの引用符も含む)やバックスラッシュを使用するエス ケープ処理は、pval属性に指定する前に削除しなければならない[MUST]こと に注意。残っている一重引用符、二重引用符、&記号は適宜XMLのエスケープ 処理を実行しなければならない[MUST]。 4.1.6.3. セッション記述要素 session-description要素には、ダイアログの末尾に観察ユーザーが使用する セッション記述が含まれる。サブスクライバにより明示的に要求されない限 り、この要素は通常は通知内に含まれるべきではない[should NOT]。 session-description要素には「type」という1個の属性があり、セッション 記述のMIMEメディアタイプを示す。リクエストごとにセッション記述が繰り 返されるのを回避するために、対応するlocal要素またはremote要素に session-description要素が提示されていない場合、サブスクライバはセッ ション記述が前の通知と同一であると見なすことができる。 4.2. 通知のボディ例 confirmed 274 Rosenberg, et al. Standards Track [Page 17] RFC 4235 Dialog Package November 2005 sip:alice@example.com sip:bob@example.org 4.3. 一貫したステートの構築 ダイアログ情報のサブスクライバは、1ダイアログに1行というダイアログを 列挙した表を維持する。各行は、「dialog」要素の「id」属性で提示される IDでインデックスされる。各行には、ドキュメント内で伝達された、そのダ イアログのステートを含む。 また、この表は、バージョン番号にも関連付けられる。バージョン番号は、 最初に受信したドキュメント内の「dialog-info」要素にある「version」属 性の値で初期化されなければならない[MUST]。新規ドキュメントを受信する たびに、ローカルのバージョン番号値と、新規ドキュメント内の「version」 値が比較される。新規ドキュメントの値がローカルのバージョン番号より1大 きい場合、ローカルのバージョン番号は1増加され、ドキュメントが処理さ れる。新規ドキュメントの値が、ローカルのバージョン番号よりも2以上高 い場合、ローカルのバージョン番号は新規ドキュメントの値に設定され、 ドキュメントを処理する。このとき、新規ドキュメントに完全なステートが 含まれていない場合には、サブスクライバは、完全なステート通知をトリガ する更新リクエスト(SUBSCRIBE)を生成すべきである[SHOULD]。ドキュメン トの値がローカルのバージョン番号未満の場合、そのドキュメントは破棄 され、処理は行われない。 ダイアログ情報ドキュメントの処理は、そのドキュメントに含まれているの が完全なステートか、部分的なステートかによって異なる。ドキュメントに 完全なステートが含まれる場合(「dialog-info」要素の「state」属性値で 示される)、表のコンテンツは消去され(flushed)、ドキュメントから再作成 される。個々の「dialog」要素ごとに、新しい行が表に作成される。ドキュ メントに部分的なステートが含まれる場合(「dialog-info」要素の「state」 属性値で指定される)、ドキュメントは表を更新するために使用される。サブ スクライバは、ドキュメント内の各「dialog」要素ごとに、そのダイアログ に対応する行が存在するかどうかを確認する。この確認では、「dialog」要 素の「id」属性にあるIDと、行に関連付けられているIDとを比較する。ダイ Rosenberg, et al. Standards Track [Page 18] RFC 4235 Dialog Package November 2005 アログが表に存在しない場合、行が追加され、ステートとして「dialog」要 素の情報に設定される。ダイアログが存在する場合、そのステートは、 「dialog」要素の情報に更新される。行が更新または作成されると、ステー トはterminatedになるので、そのエントリは、いつでも表から削除してよ い[MAY]。 4.4. スキーマ 以下は、application/dialog-info+xmlタイプのスキーマである。 Rosenberg, et al. Standards Track [Page 19] RFC 4235 Dialog Package November 2005 Rosenberg, et al. Standards Track [Page 20] RFC 4235 Dialog Package November 2005 Rosenberg, et al. Standards Track [Page 21] RFC 4235 Dialog Package November 2005 5. 新しいメディアフィーチャーパラメータの定義 ここでは、カンファレンスアプリケーション、および共有回線のようなアプ リケーション(セクション6.2で例を説明)で、ユーザープレゼンスに対する 入力として有益な、新しいメディアフィーチャーパラメータを2つ定義する。 このフィーチャーパラメータは、ダイアログパッケージと組み合わせて使用 すると、特に有益である。認可済みのサードパーティが、その特性を認識で きるようになるためである。 5.1. 「sip.byeless」パラメータ 「sip.byeless」メディアフィーチャーパラメータは、本文書で定義する新規 のブール型パラメータである。このパラメータを設定するユーザーエージェ ントは、(たとえばBYEリクエストを使用して)自身でセッションを終了でき ないことを明確に示すことができる。たとえば、継続的なアナウンスサービ Rosenberg, et al. Standards Track [Page 22] RFC 4235 Dialog Package November 2005 スやある種の録音サービスは、適切なセッション終了のタイミングを判断で きないため、セッションを終了する機能がまったくない。また、多くのコー ルセンターも、担当者からセッションを終了できないように設定されている (これは、コールセンターの担当者が、誤って電話を切らないようにするた めである)。([10]に従って、SIPのContactヘッダーフィールドで使用する 場合、パラメータ名の前には「+」文字を付ける必要がある)。 Contact: ;automaton;+sip.byeless 5.2. 「sip.rendering」パラメータ 「sip.rendering」メディアフィーチャーパラメータは、本文書で定義する 新規の文字列型パラメータである。このパラメータを設定するユーザーエー ジェントは、特定のセッション内で受信中のメディアを現在レンダリングし ているかどうかを明確に示すことができる。このパラメータは、INVITEリク エストを使用して作成されたダイアログのContactヘッダーフィールドでの み使用しなければならない[MUST] このパラメータには、「yes」、「no」、「unknown」という3つの正規の値 がある。値「yes」は、ユーザーエージェントが1つ以上の受信メディアスト リームをレンダリングしているという、明確な認識を示す。 値「no」は、ユーザーエージェントがレンダリングしている受信メディアス トリームはないという、明確な認識を示す。値「unknown」は、セッション に関連付けられたメディアがレンダリングされているかどうかをユーザー エージェントが知らないことを示す(たとえば、ユーザーエージェントが3pcc (Third Party Call Control) [19]コントローラとして動作している場合な どにあり得る)。 「sip.rendering」パラメータは、共有のアピアランス、カンファレンス ステータス、監視、ユーザープレゼンスへの入力などの用途で有効である。 Contact: ;automaton;+sip.rendering="no" Rosenberg, et al. Standards Track [Page 23] RFC 4235 Dialog Package November 2005 6. 例 6.1. 基本的な例 たとえば、UACが、以下のようなINVITEを送信したとする(以下は一部)。 INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8 Max-Forwards: 70 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 142 [SDPは非表示] Aliceからの通知に含まれるXMLドキュメントは、以下のようになる。 trying 続いて、以下のように180応答を受信したとする。 SIP/2.0 180 Ringing Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8 To: Bob ;tag=456887766 From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: Rosenberg, et al. Standards Track [Page 24] RFC 4235 Dialog Package November 2005 通知内のXMLドキュメントは以下のようになる。 early 以下のように、2つ目の180を異なるタグ付きで受信したとする。 SIP/2.0 180 Ringing Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8 To: Bob ;tag=hh76a From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: This results in the creation of a second dialog: early early Rosenberg, et al. Standards Track [Page 25] RFC 4235 Dialog Package November 2005 200 OK応答が2つ目のダイアログ上で受信された場合、ダイアログは以下の ようにconfirmedへ遷移する。 confirmed 32秒後、他のearlyダイアログは、2xx応答を受信しなかったために終了す る。これは、正常にキャンセルされ、したがって以下の通知が送信される、 ということを意味する。 terminated 6.2. 共有回線電話システムの模倣 以下の例では、SIP電話ユーザーエージェントで詳細なステート情報を提供 し、また共有回線電話システムも模倣する(電話がオフフックになっている だけの場合でも、ダイアログの存在について「うそをつく」)方法を示す。 アイドル(Idle): Rosenberg, et al. Standards Track [Page 26] RFC 4235 Dialog Package November 2005 受話器を持ち上げた状態(Seized): trying ダイヤル中(Dialing): trying sip:alice@example.com sip:bob@example.net 呼び出し中(Ringing): early Rosenberg, et al. Standards Track [Page 27] RFC 4235 Dialog Package November 2005 ボイスメールによる応答(Answered (by voicemail)): terminated confirmed Rosenberg, et al. Standards Track [Page 28] RFC 4235 Dialog Package November 2005 AliceはBobの音声メールよりも、Bobのアシスタント(Cathy Jones)に話した いと考えている。Aliceはその意向を示すためにキーを押す(おそらく北米で は「0」、ヨーロッパでは「9」)。Bobの音声メールシステムは、このキー入 力に応答して、Aliceの発呼をCathyのAddresses-of-Recordに転送する[20]。 terminated confirmed sip:bob-is-not-here@vm.example.net sip:cjones@example.net Rosenberg, et al. Standards Track [Page 29] RFC 4235 Dialog Package November 2005 AliceとCathyは通話し、CathyはローカルのカンファレンスにAliceを追加 する。 confirmed AliceはCathyを保留にする。 confirmed Rosenberg, et al. Standards Track [Page 30] RFC 4235 Dialog Package November 2005 Cathyが電話を切る: terminated trying Aliceが電話を切る: 6.3. プライバシを保持する最小ダイアログ情報 以下の例では、自動コールバックのようなサービス向けに、プライバシを維 持するために最小限情報を提示する、同じユーザーエージェントを示する。 オンフック(Onhook): Rosenberg, et al. Standards Track [Page 31] RFC 4235 Dialog Package November 2005 オフフック(Offhook): (「受話器を持ち上げた」とき、Trying時、 Proceeding時、またはConfirmed時の、この「state」への遷移については、 Aliceの実装またはポリシー上の選択である。) confirmed オンフック(Onhook): (terminate時、または、もう「受話器を持ち上げた」 状態ではないとき、この「ステート」への遷移については、Aliceの実装ま たはポリシー上の選択である。) 7. セキュリティの考慮事項 ダイアログステートへのサブスクリプションは、機密情報を漏らす可能性が ある。この理由から、セクション3.6では、サブスクリプションの認証および 認可について説明し、常識的な認可ポリシーに関するガイドラインを提示し ている。本パッケージの実装はすべて、ダイジェスト認証の仕組みに対応し なければならない[MUST]。 通知内のデータにも同様に機密性があるので、S/MIMEを利用したエンドツー エンドのSIP暗号化の仕組みによって、保護してもよい[MAY]。ダイアログ パッケージを実装するユーザーエージェントは、TLS[15]とsips:スキーム上 でSIPを実装すべきである[SHOULD]。 8. IANA条項 本文書は、新規のMIMEタイプapplication/dialog-info+xml、新規のXML名前 空間、2つの新規メディアフィーチャーパラメータをSIPツリーに登録する。 Rosenberg, et al. Standards Track [Page 32] RFC 4235 Dialog Package November 2005 8.1. application/dialog-info+xml MIMEタイプの登録 MIMEメディアタイプ名: application MIMEサブタイプ名: dialog-info+xml 必須パラメータ: なし オプションのパラメータ: RFC 3023 [8]で規定されているとおり、 application/xmlのcharsetパラメータと同様。 エンコーディングの考慮事項: RFC 3023[8]で規定されているとおり、 application/xmlのエンコーディングの考慮事項と同様。 セキュリティ条項： RFC 3023[8]のセクション10、ならびに本仕様のセク ション7を参照のこと。 相互運用性の考慮事項: なし 公開された仕様: 本文書。 このメディアタイプを使用するアプリケーション: このドキュメントタイプ は、コールリターンやオートカンファレンスなどのSIPアプリケーション に対応するために使用されてきた。 補足情報: マジックナンバー: なし ファイルの拡張子: .xml Macintoshファイルタイプコード: "TEXT" 詳細情報についての個人のemailアドレス: Jonathan Rosenberg 用途: 汎用(COMMON) 著者/改版 管理者: IETF Rosenberg, et al. Standards Track [Page 33] RFC 4235 Dialog Package November 2005 8.2. urn:ietf:params:xml:ns:dialog-infoのためのURNの下位名前空間登録 このセクションでは、[7]のガイドラインに従って、新規のXML名前空間を登 録する。 URI: この名前空間のURIは、urn:ietf:params:xml:ns:dialog-info である。 登録者の連絡先: IESG XML: BEGIN Dialog Information Namespace

Namespace for Dialog Information

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

See RFC4235.

END 8.3. スキーマ登録 [7]のガイドラインに沿って、本仕様はスキーマを登録する。 URI: urn:ietf:params:xml:schema:dialog-info 登録者の連絡先: IESG XML: XMLは、セクション4.4に書かれている。 8.4. MIMEフィーチャーパラメータ登録 このセクションでは、RFC 2506[14]で定義された手順に従って、2つの新規 メディアフィーチャータグを登録する。このタグは、[10]で定義されてい る、sipツリーに配置される。 Rosenberg, et al. Standards Track [Page 34] RFC 4235 Dialog Package November 2005 8.4.1. メディアフィーチャータグsip.byeless メディアフィーチャータグ名: sip.byeless ASN.1識別子: 19 このタグで示されるメディアフィーチャーの概要: このフィーチャータグは ブール型のフラグである。送信される場合、このデバイスはセッションを自 身で終了できないことを示す。 このフィーチャータグの使用に適切な値: ブール型 このフィーチャータグの主な用途であるアプリケーション、プロトコル、 サービス、ネゴシエーションのメカニズム: このフィーチャータグは、通信 アプリケーションでアプリケーションの能力を記述する場合に最も有効で ある。たとえば、アナウンスサービス、録音サービス、カンファレンス、 コールセンターなど。 一般的な使用例: コールセンターとメディアサービス。 関連する規定またはドキュメント: RFC 4235 セキュリティの考慮: このメディアフィーチャータグは、アプリケーション の動作に影響を及ぼす方法で使用されたり、プライベート情報を公開する可 能性がある。たとえば、カンファレンスなどのアプリケーションでは、この メディアフィーチャータグが設定されると、早期に呼を終了する判断を下す 場合がある。したがって、攻撃者がこのタグの値を変更できる場合、アプリ ケーションの動作に影響を与えられる可能性がある。このため、このメディ アフィーチャータグを使用するアプリケーションは、完全性を保証する手段 を提供すべきである[SHOULD]。同様に、このフィーチャータグは、タグで記 述されたユーザーまたはユーザーエージェントからきたもののみを、有効で あると信頼すべきである。結果として、このフィーチャータグを伝達するプ ロトコルは、信頼性を保証するメカニズムを提供すべきである[SHOULD]。 8.4.2. メディアフィーチャータグsip.rendering メディアフィーチャータグ名: sip.rendering ASN.1識別子: 20 このタグで示されるメディアフィーチャーの概要: このフィーチャータグに は、デバイスが現セッションのメディアをレンダリングしている (「yes」)か、現セッションでレンダリングしているメディアはない (「no」)か、またはステータスをデバイスで認知していない (「unknown」)かを示す3つの文字列値のいずれかが含まれる。 このフィーチャータグの使用に適切な値: 文字列型 Rosenberg, et al. Standards Track [Page 35] RFC 4235 Dialog Package November 2005 このフィーチャータグの主な用途であるアプリケーション、プロトコル、 サービス、ネゴシエーションのメカニズム: このフィーチャータグは、 マルチメディアセッション中の通信アプリケーションで、デバイス(電話 やPDAなど)の状態を記述する場合に最も有効である。 一般的な使用例: カンファレンス、電話の共有回線エミュレーション、プレ ゼンスアプリケーション。 関連する規定またはドキュメント: RFC 4235 セキュリティの考慮: このメディアフィーチャータグは、アプリケーション の動作に影響を及ぼす方法で使用されたり、プライベート情報を公開す る可能性がある。たとえば、カンファレンスなどのアプリケーションで は、このメディアフィーチャータグが「no」に設定されると、早期に呼 を終了する判断を下す場合がある。したがって、攻撃者がこのタグの値 を変更できる場合、アプリケーションの動作に影響を与えられる可能性 がある。このため、このメディアフィーチャータグを使用するアプリ ケーションは、完全性を保証する手段を提供すべきである[SHOULD]。同 様に、このフィーチャータグは、タグで記述されたユーザーまたはユー ザーエージェントからきたもののみを、有効であると信頼すべきである。 結果として、このフィーチャータグを伝達するプロトコルは、信頼性を 保証するメカニズムを提供すべきである[SHOULD]。 9. 謝辞 Sean Olsonのコメントに感謝を表したい。 10. 参考文献 10.1. 規範となる参考文献 [1] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [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] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [4] Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C FirstEdition REC-xml-20001006, October 2000. [5] Moats, R., "URN Syntax", RFC 2141, May 1997. Rosenberg, et al. Standards Track [Page 36] RFC 4235 Dialog Package November 2005 [6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999. [7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [8] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [10] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. [11] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004. [12] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [13] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. [14] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999. [15] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. 10.2. 有益な参考文献 [16] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004. [17] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004. [18] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004. [19] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004. Rosenberg, et al. Standards Track [Page 37] RFC 4235 Dialog Package November 2005 [20] Sparks, R., "Session Initiation Protocol Call Control - Transfer", Work in Progress, July 2005. 著者の連絡先 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 Rohan Mahy (editor) SIP Edge LLC EMail: rohan@ekabal.com Rosenberg, et al. Standards Track [Page 38] RFC 4235 Dialog Package November 2005 完全な著作権表示 Copyright (C) The Internet Society (2005). 本文書は、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編集職務のための資金は、現在、インターネット協会によって提供され ている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2005年 ----------------------------------------------------------------------- Rosenberg, et al. Standards Track [Page 39]