Network Working Group S. Donovan Request for Comments: 2976 dynamicsoft Category: 標準化過程 October 2000 Standards Track SIP INFOメソッド The SIP INFO Method このメモのステータス このドキュメントはインターネットコミュニティのためのインターネット 標準化過程のプロトコルを定義し、改良のための議論と提案を求めるもの である。このプロトコルの標準化の段階と状態については「Internet Official Protocol Standard」(STD 1)の最新版を参照してほしい。この文書の配布は 制限されない。 著作権 Copyright (C) The Internet Society (2000). All Rights Reserved. 概要 このドキュメントはSession Initiation Protocol(SIP)の拡張を提案する ものである。この拡張はSIPプロトコルにINFOメソッドを追加する。INFO メソッドを使用することで、セッション中に生成される制御情報に関連 するセッションを伝達できるようになる。このようなセッション制御情報の 一例として、ISUPやISDNのテレフォニーコールサービスを制御するのに使用 されるシグナリングメッセージが挙げられる。 このドキュメントとINFOメソッドを使用する例は、将来的に標準化される かもしれない。 [訳注: 以下のドキュメントで、大文字で書かれた次のキーワードは訳に併記 します。 また、訳す際は、次のように表現します。訳の分類はRFC2119を 参照しました。 MUST/SHALL/REQUIRED 〜しなければならない/〜する必要がある MUST NOT/SHALLNOT 〜してはならない SHOULD/RECOMMENDED 〜する方がよい SHOULD NOT 〜しない方がよい MAY/OPTIONAL 〜してもよい/〜は任意である ] 目次 1 はじめに....................................................2 1.1 使用例......................................................2 2 INFOメソッド................................................3 2.1 INFOメソッドに対応するヘッダフィールド......................3 2.2 INFO要求メソッドに対する応答................................4 2.3 メッセージ本文の包括........................................5 2.4 SIPユーザーエージェントの動作...............................6 2.5 SIPプロキシとリダイレクトサーバーの動作.....................6 2.5.1 プロキシサーバー............................................6 2.5.2 プロキシサーバーの分岐......................................6 2.5.3 リダイレクト(リダイレクション)サーバー......................6 3. INFOメッセージ本文..........................................6 4. INFOを利用する拡張へのガイドライン..........................7 5. セキュリティの考慮..........................................7 6. 参考文献....................................................8 Donovan Standards Track [Page 1] RFC 2976 SIP INFO Method October 2000 7. 謝辞........................................................8 8. 著者の連絡先................................................8 完全な著作権表記............................................9 1. はじめに [1]で記載されているSIPプロトコルは、SIPが制御するセッションの開始・ 破棄段階のセッション制御メッセージを定義している。 また、SIPのre-INVITEはセッション中にセッションの特性を変更するため にも使用される。re-INVITEは通常、セッションに関わるメディアフローの 特徴を変更したり、SIPセッションタイマーを更新するためのものである。 だが、セッション中のSIPシグナリングパスに従った、セッション制御情報を 伝達するための「通常の目的」の仕組みというものはない。 INFOメッセージの目的は、SIPのシグナリングパスに従った、アプリケー ションレベルの情報を伝達することである。 INFOメソッドは、SIPコールの状態やSIPが開始するセッションのパラメータ を変更するためには使用しない。INFOメソッドは、単に任意のアプリケー ションレベルの情報、通常はセッションに関連する情報を、送信するだけで ある。 セッション中のシグナリング情報は、SIPシグナリングパスを確立する次の セッション(post session)を越える(traverse)必要がある。このパスとは、 個々のセッションに拘束されるSIPのre-INVITE、BYEや他のSIP要求がとる パスのことである。このパスによって、SIPプロキシサーバーがセッション中 のシグナリング情報を受信し、潜在的に影響を与えることができるように なる。 このドキュメントは、新たにINFOメソッドを定義するSIPの拡張を提案する。 INFOメソッドは、セッションシグナリングパスに従った、コール中のシグナ リング情報を伝達するするために使用されるだろう。 1.1 使用例 以下に挙げるのは、INFOメッセージの潜在的な使用方法である。: - PSTNゲートウェイ間で行われるコール中のPSTNシグナリングメッセージ の伝達 - SIPセッション中に生成されるDTMF音の伝達 - ワイヤレスで移動性のあるアプリケーションに対応するための ワイヤレスシグナルの強度情報の伝達 - アカウントバランス情報の伝達 Donovan Standards Track [Page 2] RFC 2976 SIP INFO Method October 2000 - セッションの参加者間で行われる画像や他の非ストリーミング情報の伝達 これらは単に潜在的な使い方であり、このドキュメントではこのような 用法に限定したり、必ずしも薦めるものではない。 テレフォニー向け、非テレフォニー向けの別のINFOメソッドの用法がある と想定することもできる。 2. INFOメソッド INFOメソッドは、コールに対するシグナリングパスに従ったセッション中の シグナリング情報をやりとりするために使われる。 INFOメソッドはSIPコールの状態を変更したり、SIPによって開始される セッションの状態を変更するためには使用されない。どちらかというと、 SIPを使用するアプリケーションをさらに強化できる任意の情報を新たに 提供する。 INFOメソッドのシグナリングパスは、コールが開始された結果として確立する シグナリングパスである。コールの開始は、発信側と受信側のユーザー エージェント間の直接のシグナリングである可能性がある。または、コール の開始時に関わり、最初のINVITEメッセージのRecord-Routeヘッダに自分 自身を追加するSIPプロキシサーバーに関するシグナリングパスである 可能性がある。 セッション中の情報はINFOメッセージヘッダまたはメッセージ本文の一部の いずれかの方法でやり取りできる。セッション中の情報を伝達するために 使われるメッセージ本文の定義かつ/または(and/or)メッセージヘッダに ついては、このドキュメントの範囲外である。 INFOに関連する特定のセマンティックスはない。セマンティックスは本文 またはINFOの用法で定義される新たなヘッダから派生する。 2.1 INFOメソッドに対応するヘッダフィールド 表1と表2は、[1]の表4、表5に1列を追加したものである。表の内容の解説 については、[1]のセクション6を参照されたい。表1と表5内のenc.と e-e列で定義されている規則は、INFO要求とINFO要求に対する応答に あるヘッダの用法にも適用されるということに注意。 Donovan Standards Track [Page 3] RFC 2976 SIP INFO Method October 2000 2.2 INFO要求メソッドに対する応答 サーバーがINFO要求を受信した場合、サーバーは最終応答を送信しなけれ ばならない(MUST)。 既存の呼に対してINFO要求を正常に受信した場合は、UASは、メッセージ ボディを持たないINFOリクエストに対して200 OK応答を送信しなければな らない[MUST]。それとは別に、別の操作も必要である。 Header Where INFO ------ ----- ---- Accept R o Accept-Encoding R o Accept-Language R o Allow 200 - Allow 405 o Authorization R o Call-ID gc m Contact R o Contact 1xx - Contact 2xx - Contact 3xx - Contact 485 - Content-Encoding e o Content-Length e o Content-Type e * CSeq gc m Date g o Encryption g o Expires g o From gc m Hide R o Max-Forwards R o Organization g o 表1 ヘッダフィールド A-0 の概要 メッセージ本文を含むINFOメッセージを操作することは、このドキュ メントの範囲外である。メッセージ本文を定義するドキュメントは、また、 これらのメッセージ本文に関するSIPプロトコルの規則を定義する必要が あるだろう。 INFO要求が既存のどのコールレグにも合致しない場合は、UASは 481 Call Leg/Transaction Does Not Existメッセージを送信しなければ ならない(MUST)。 Donovan Standards Track [Page 4] RFC 2976 SIP INFO Method October 2000 サーバーが本文にとともにINFO要求を受信した場合、サーバーはその要求 を理解し、サーバーは本文の処理規則に関するINFOの知識を持たないが、 サーバーは本文をユーザーに提供・表示してもよい(MAY)。INFOは200 OK で応答される。 INFO要求がサーバーの理解していない本文を含み、本文の処理規則に関連 するINFOがない場合は、サーバーは415 Unsupported Media Typeメッセージ で応答しなければならない(MUST)。 Header Where INFO ------ ----- ---- Priority R o Proxy-Authenticate 407 o Proxy-Authorization R o Proxy-Require R o Require R o Retry-After R - Retry-After 404,480,486 o Retry-After 503 o Retry-After 600,603 o Response-Key R o Record-Route R o Record-Route 2xx o Route R o Server r o Subject R o Timestamp g o To gc(1) m Unsupported 420 o User-Agent g o Via gc(2) m Warning r o WWW-Authenticate 401 o 表2 ヘッダフィールド P-Z の概要 SIPのコール状態やSIPによって開始されたセッションの変更を暗示する 本文はINFOメッセージで送信してはいけない(MUST NOT)。 別の要求エラー(4xx)、サーバーエラー(5xx)、全体的なエラー(6xx)の 応答は、INFO要求に対して送信してもよい(MAY)。 2.3 メッセージ本文の包括 INFO要求はメッセージ本文を含んでもよい(MAY)。 Donovan Standards Track [Page 5] RFC 2976 SIP INFO Method October 2000 2.4 SIPユーザーエージェントの動作 別に宣言されていない限り、タグ・Route・Record-Routeの用法、再送信 と信頼性、CSeqのインクリメント、メッセージ書式を管理するINFO要求に ついてのプロトコルの規則は、[1]で規定されているBYE要求の規則と一致 する。 INFO要求はキャンセルされるかもしれない(MAY)。INFOに対して最終応答 が送信されていなくても、INFO要求に対してCANCELを受信したUASは、 INFOに対して"487 Request Cancelled"で 応答し、そして、要求を受信 しなかったかのように動作する方が良い(SHOULD)。 だが、INFOメッセージはSIPコールの状態やSIPによって開始されたセッ ションを変更してはならない(MUST NOT)。 2.5 SIPプロキシとリダイレクトサーバーの動作 2.5.1 プロキシサーバー 別に宣言されていない限り、プロキシにおけるINFO要求についての プロトコルの規則は、[1]で規定されているBYE要求の規則と一致する。 2.5.2 プロキシサーバーの分岐 別に宣言されていない限り、プロキシにおけるINFO要求についての プロトコルの規則は、[1]で規定されているBYE要求の規則と一致する。 2.5.3 リダイレクトサーバー 別に宣言されていない限り、プロキシにおけるINFO要求についての プロトコルの規則は、[1]で規定されているBYE要求の規則と一致する。 [訳注: 2.5.1〜2.5.3の本文は、原文も同一。] 3. INFOメッセージ本文 INFOメッセージの目的は、SIPユーザーエージェント間のセッション中の情報 を伝達することである。この情報は通常、メッセージ本文で伝達されるだろ うが、INFOメッセージのヘッダで伝達される可能性もある。 メッセージ本文やINFOメソッドのために作られる新たなヘッダの定義につい ては、この文書の範囲外である。これらのエンティティの定義を宣言する ために別のドキュメントが作られるだろう。 Donovan Standards Track [Page 6] RFC 2976 SIP INFO Method October 2000 また、INFOメソッドは、正しい順序での配信(in-order delivery)を保証する 新たな仕組みを定義しない。CSeqヘッダは新たなINFOメッセージの送信で インクリメントされるだろうが、これはINFO情報の順序を決定するために 使わない方が良い。これは、ユーザーエージェントの送信するre-INVITESや 他のSIPメッセージによってINFOメッセージのCSeqカウントのずれが生じる かもしれないという事実のためである。 4. INFOを利用する拡張へのガイドライン 以下に述べるのは、INFOメソッドを利用するSIP拡張を定義する際に考慮に 入れる方がよい項目である。 - INFOメッセージが伝達するメッセージ本文のサイズについての考慮。 UDP経由で伝達されるメッセージの可能性や、より大量のメッセージの 分割(fragmentation)の可能性も考慮して、メッセージ本文は少量に 保つ方がよい。 - INFOメッセージはSIPプロキシサーバーによって分岐される可能性がある。 INFOメッセージの情報の分岐を実装することは、考慮に入れておく必要が ある。 - マルチパートメッセージの本文を利用することは、INFOメッセージによって 伝達されるメッセージ本文を定義するときに役に立つかもしれない。 - INFOメッセージを使用する拡張は、SIPのコール状態やセッションに関わる 状態に、INFOメッセージが何らかの影響を与えることを頼ってはならない (MUST NOT)。 - このドキュメントで定義されているINFO拡張は、RequireやProxy-Require ヘッダの利用に依存しない。INFOメッセージを利用する拡張は、これらの 仕組みを使用する必要があるかもしれない。だが、もし可能なら、SIP エンティティ間の相互運用性を向上させるために、RequireとProxy-Require の利用は避ける方が良い。 5. セキュリティの考慮 メッセージ本文の内容がプライベートな場合、内容に対する認証されていない アクセスを防ぐために、メッセージ本文の端末間(end-to-end)の暗号化を 利用できるだろう。 他に、INFOメソッドに特化したセキュリティの論点はない。SIPの仕様で指定 されているセキュリティの必要条件が、INFOメソッドに適用される。 Donovan Standards Track [Page 7] RFC 2976 SIP INFO Method October 2000 6. 参考文献 [1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. 7. 謝辞 著者は、このドキュメントに対するMatthew Cannonの貢献に感謝を述べたい。 また、 MMUSICとSIPワーキンググループのメンバー、特にドキュメントを 改善する方法についてコメントと提案をいただいたJonathan Rosenbergに 感謝を述べたい。 8. 著者の連絡先 Steve Donovan dynamicsoft 5100 Tennyson Parkway, Suite 200 Plano, Texas 75024 Email: sdonovan@dynamicsoft.com Donovan Standards Track [Page 8] RFC 2976 SIP INFO Method October 2000 9. 完全な著作権表記 Copyright (C) The Internet Society (2000). All Rights Reserved. [訳注: この項目9の訳は、以下のJPNIC RFC-JPから引用した。 http://rfc-jp.nic.ad.jp/ ] 本記述とその翻訳は複写し他に提供することができる。また論評を加えた 派生的製品や、この文書を説明したり、その実装を補助するもので、上記 の著作権表示およびこの節を付加するものはすべて、全体であってもその 一部であっても、いっさいの制約を課されること無く、準備、複製、発表、 配布することができる。しかし、この文書自体にはいかなる方法にせよ、 著作権表示やインターネットソサエティもしくは他のインターネット関連 団体への参照を取り除くなどの変更を加えてはならない。インターネット 標準を開発するために必要な場合は例外とされるが、その場合はインター ネット標準化過程で定義されている著作権のための手続きに従わなければ ならない。またRFCを英語以外の言語に翻訳する必要がある場合も例外であ る。 以上に述べられた制限は永久的なものであり、インターネットソサエティ もしくはその継承者および譲渡者によって破棄されることはない。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、インターネッ トソサエティおよびIETFは、この情報がいかなる権利も侵害していないと いう保証、商用利用および特定目的への適合性への保証を含め、また、こ れらだけに限らずすべての保証について、明示的もしくは暗黙的の保証は 行われない。 謝辞 RFCエディターの職務に関する財政援助は現在インターネットソサエティに よって提供されている。 --------------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただし、 この権利の設定は原文から新たな翻訳を作成し公開することを妨げるものではあり ません。本翻訳物は、本著作権表示を含めて改変しないことを条件に再配布を許可 します。翻訳の正確さについては一切保証しません。原文とあわせてご利用くだ さい。 2005年 --------------------------------------------------------------------------- Donovan Standards Track [Page 9]