Network Working Group H. Schulzrinne Request for Comments: 3326 Columbia University Category: Standards Track D. Oran Cisco G. Camarillo Ericsson December 2002 セッション開始プロトコル(SIP)のためのReasonヘッダーフィールド The Reason Header Field for the Session Initiation Protocol (SIP) 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準 トラックプロトコルを規定するものであり、改善のための議論や提案を 依頼するものである。標準化の段階や、プロトコルの位置付けについては、 最新版の"Internet Official Protocol Standards" (STD 1)を参照されたい。 この文書の配布は無制限である。 著作権表記 Copyright (C) The Internet Society (2002). All Rights Reserved. 概要 サービスを生成するために、あるセッション開始プロトコル(Session Initiation Protocol/SIP)のリクエストがなぜ発行されたのかを知ることは しばしば有益なことである。本文書では、この情報を提供するヘッダーフィー ルドReasonを定義する。Reasonヘッダーフィールドはまた、暫定応答内の最終 ステータスコードをカプセル化するための利用も目的としている。この機能 は、「不均一エラー応答のフォーク問題(Heterogeneous Error Response Forking Problem/HERFP)」を解決するためにも必要である。 Schulzrinne, et. al. Standards Track [Page 1] RFC 3326 The Reason Header Field for SIP December 2002 目次 1. はじめに ..................................................... 2 1.1 述語規則 .................................................... 3 2. Reasonヘッダーフィールド ..................................... 3 3. 例 ........................................................... 4 3.1 Call Completed Elsewhere .................................... 4 3.2 応答に出てくるオファーの拒否 ................................ 4 3.3 サードパーティの呼制御 ...................................... 5 3.4 ISUPの相互作用 .............................................. 5 4. IANA条項 ..................................................... 6 5. セキュリティの考慮 ........................................... 6 6. 謝辞 ......................................................... 7 8. 規範的な参考文献 ............................................. 7 7. 著者の連絡先 ................................................. 7 9. 完全な著作権表記 ............................................ 8 1. はじめに 同一のSIP(参考文献[1])リクエストでも、様々な理由で発行される可能性が ある。例えば、SIP CANCELリクエストは、呼が別の分岐(branch)で完了した り、応答前に中止された場合に発行される可能性がある。プロトコルとシステ ムの動作はその両方の場合において同じである(つまり、アラートは中止される) が、ユーザーインターフェースはかなり異なるかもしれない。2番目の場合、 呼は失敗した呼としてログされるかもしれないが、このことは、その呼が別の 場所で受け取られた場合には適切ではないだろう。 サードパーティのコールコントローラは、別ダイアログからのSIP応答の受信 時に、しばしばSIPリクエストを生成する。ゲートウェイは、SIPとは異なる プロトコルからメッセージを受信した後に、SIPリクエストを生成する。 いずれの場合でも、クライアントは何がSIPリクエストのトリガーとなったのか を知りたがるかもしれない。 SIP応答はすでに、ユーザーへ何故リクエストが失敗したかを知らせる手段を 提供している。本文書の単純な仕組みによって、リクエストに対しても同様の ことを達成する。 INVITEは、時には、セッションの開始が断られた(decline)のではなく、 リクエストの側面の何かが受け入れられないために拒否(reject)される ことがある。INVITEがフォークし、拒否という結果になった場合、他の分岐 すべてもまたそのリクエストを拒否しないかぎり、エラー応答はクライアント へ転送(forward)されない可能性がある。この問題は「不均一エラー応答の フォーク問題(Heterogeneous Error Response Forking Problem/HERFP)」と して知られている。この問題へのソリューションは、暫定応答における最終 エラー応答のカプセル化を伴うかもしれないと予測されている。Reasonヘッ ダーフィールドはこのようなカプセル化に使用されるものの候補のひとつで ある。 Schulzrinne, et. al. Standards Track [Page 2] RFC 3326 The Reason Header Field for SIP December 2002 ここで定義されるReasonヘッダーフィールドは、まずはBYEとCANCELリクエスト に最も役に立つように見えるが、ダイアログ内のすべてのリクエストや、すべ てのCANCELリクエスト、ステータスコードがこのヘッダーフィールドの提示を 明示的に許容しているすべての応答においても、示される可能性がある。 ステータスコードと理由フレーズがすでに十分な情報を提供しているので、 Reasonヘッダーフィールドは、通常、応答において必要ではないということに 注意。 クライアントとサーバーはこのヘッダーフィールドをまったく無視しても構わ ない。プロトコル処理には何も影響を与えない。 1.1 述語規則 本文書では、次のキーワードはBCP 14、RFC2119(参考文献[2])に記述されてい るとおりに解釈され、SIPに準拠した実装のための要求レベルを示す。 「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、 「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、 「MAY」、および「OPTIONAL」 2. Reasonヘッダーフィールド Reasonヘッダーフィールドは、ダイアログ内のすべてのリクエストや、すべて のCANCELリクエスト、ステータスコードがこのヘッダーフィールドの提示を明 示的に許容しているすべての応答においても、示されてもよい[MAY]。ヘッダー フィールドの構文は標準的なSIPパラメータ構文に従う。 Reason = "Reason" コロン reason-value *(カンマ reason-value) reason-value = protocol *(セミコロン reason-params) protocol = "SIP" / "Q.850" / トークン reason-params = protocol-cause / reason-text / reason-extension protocol-cause = "cause" EQUAL 理由(cause) cause = 1*DIGIT reason-text = "text" EQUAL 引用符で囲まれた文字列(quoted-string) reason-extension = 一般的なパラメータ protocolフィールドについては以下の値が定義されている。 SIP: causeパラメータはSIPステータスコードを含む。 Q.850: causeパラメータはITU-T Q.850のcause値を10進表記で含む。 Schulzrinne, et. al. Standards Track [Page 3] RFC 3326 The Reason Header Field for SIP December 2002 例は以下の通り。 Reason: SIP ;cause=200 ;text="Call completed elsewhere" Reason: Q.850 ;cause=16 ;text="Terminated" Reason: SIP ;cause=600 ;text="Busy Everywhere" Reason: SIP ;cause=580 ;text="Precondition Failure" Reasonヘッダーフィールドを含む前のホップからCANCELリクエストを受信した 際に、CANCELリクエストを生成するプロキシは、それを新たなCANCELリクエス トにコピーすべきである[SHOULD]。 通常のSIP操作では、応答内のSIPのステータスコードは、応答やセッション パラメータ、ユーザーをトリガーしたリクエストに関する情報を、クライアン トに提供する。例えば、405(メソッドが許可されていない)応答は、リクエスト が非対応のメソッドを含んでいたことを示す。488(ここでは受け入れ不能)は セッションパラメータが受け入れできないことを示し、486(ここはビジー)は ユーザーのステータスに関する情報を提供する。 SIPステータスコードはリクエストのReasonヘッダーフィールドに示されても よい[MAY]。ただ、リクエストに関するエラーを報告する意図のあるステータ スコードがたいていデバッグ用途に有用であるのに対し、ユーザーとセッショ ンパラメータに関する情報を提示するステータスコードは、たいていサービス の実装について有用である。 SIPメッセージは、1個以上のReason値(つまり複数のReason行)を含んでも よい[MAY]が、それらすべては異なるprotocol値(例えば、1個はSIP、もう1個は Q.850)を持たなければならない[MUST]。実装は理解できないReason値をまった く無視しても構わない。 3. 例 このセクションは、Reasonヘッダーフィールドの用法を説明する多くの例を 含む。 3.1 Call Completed Elsewhere プロキシはINVITEリクエストをフォークし、分岐のひとつが200(OK)を返す。 フォークするプロキシは、このステータスコードを、残りの分岐に送るCANCEL リクエスト内のReasonヘッダーフィールドに含める。 3.2 応答に出てくるオファーの拒否 クライアントは空のINVITEを送信し、200(OK)応答に受け入れできないオファー を受信する。クライアントは正しく整形された応答とともにACKを送信し、セッ Schulzrinne, et. al. Standards Track [Page 4] RFC 3326 The Reason Header Field for SIP December 2002 ションを停止するために速やかにBYEを送信する。クライアントは488(ここでは 受け入れ不能)のステータスコードをReasonヘッダーフィールドに含める。 3.3 サードパーティの呼制御 図1のサードパーティのコールコントローラは、AとB間のセッションを確立しよ うとしている。だが、ユーザーBはビジーである。コントローラは、Reasonヘッ ダーフィールドにステータスコード 486(ここはビジー)とともにBYEを送信す る。 A Controller B | INV no SDP | | |<------------------| | | | | | 200 SDP A1 | | |-----------------> | | | | | | ACK SDP held | | |<------------------| | | | | | | INV no SDP | | |----------------->| | | | | | 486 Busy Here | | |<-----------------| | | | | | ACK | | |----------------->| | BYE (486) | | |<------------------| | | | | | 200 OK | | |-----------------> | | | | | 図1: サードパーティの呼制御 3.4 ISUPの相互作用 図2のPSTNゲートウェイは、REL(release)メッセージがISUP側から受信されたと きにCANCELされなければならない1個のINVITEを生成する。CANCELリクエスト は、RELメッセージのQ.850 cause値(16 Normal Call Clearing)を含む。 Schulzrinne, et. al. Standards Track [Page 5] RFC 3326 The Reason Header Field for SIP December 2002 A Gateway B | IAM | | |-----------------> | | | | INVITE | | |----------------->| | | | | | 100 Trying | | |<-----------------| | REL (16) | | |-----------------> | | | | CANCEL (Q.850 16)| | |----------------->| | | 200 OK | | |<-----------------| 図2: ISUPの相互作用 4. IANA条項 本文書は、RFC3261のセクション27に沿って、新規のSIPヘッダーフィール ド「Reason」を定義する。 このヘッダーフィールドとともに使用されるprotocol value(およびそれに対応 するprotocol cause)は、IANAによって、 http://www.iana.org/assignments/sip-parameters 以下の新規サブ登録へ登録 されており、「Reason Protocols」と名付けられている。Reasonプロトコルは ITU-TのRFCの番号また、IETFプロトコル名、他の標準化組織から認識されるプ ロトコル識別子のいずれかを参照しなければならない。protocol causeは Reasonヘッダーフィールド内の「cause」フィールドのソースを記述する。 現在のところ、登録中のエンティティは以下のみ。 Protocol Value Protocol Cause 参照 -------------- --------------- ----------- SIP ステータスコード RFC 3261 Q.850 10進表記のCause値 ITU-T Q.850 5. セキュリティの考慮 HERFPにおいて、スプーフィングや応答からのReasonヘッダーフィールド削除に Schulzrinne, et. al. Standards Track [Page 6] RFC 3326 The Reason Header Field for SIP December 2002 よって、クライアントはその前のリクエストを正しく更新できず、そのために セッション確立が不可能になる可能性がある。そのため、このヘッダーフィー ルドを適切な統合的仕組みによって保護することが推奨される[RECOMMENDED]。 6. 謝辞 Jonathan Rosenberg、Rohan Mahy、Vijay K. Gurbaniから有益なコメントと提案 をいただいた。 8. 規範的な参考文献 [1] 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. [2] Bradner, S., "Key words for use in RFCs to indicate requirement levels," BCP 14, RFC 2119, March 1997. 7. 著者の連絡先 Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA EMail: schulzrinne@cs.columbia.edu David R. Oran Cisco Systems, Inc. Acton, MA USA EMail: oran@cisco.com Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland EMail: Gonzalo.Camarillo@ericsson.com Schulzrinne, et. al. Standards Track [Page 7] RFC 3326 The Reason Header Field for SIP December 2002 9. 完全な著作権表記 Copyright (C) The Internet Society (2002). All Rights Reserved. 本記述とその翻訳は複写し他に提供することができる。また論評を加えた派 生的製品や、この文書を説明したり、その実装を補助するもので、上記の著 作権表示およびこの節を付加するものはすべて、全体であってもその一部で あっても、いっさいの制約を課されること無く、準備、複製、発表、配布す ることができる。しかし、この文書自体にはいかなる方法にせよ、著作権表 示やインターネットソサエティもしくは他のインターネット関連団体への参 照を取り除くなどの変更を加えてはならない。インターネット標準を開発す るために必要な場合は例外とされるが、その場合はインターネット標準化過 程で定義されている著作権のための手続きに従わなければならない。またRFC を英語以外の言語に翻訳する必要がある場合も例外である。 以上に述べられた制限は永久的なものであり、インターネットソサエティも しくはその継承者および譲渡者によって破棄されることはない。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、インターネッ トソサエティおよびIETFは、この情報がいかなる権利も侵害していないとい う保証、商用利用および特定目的への適合性への保証を含め、また、これら だけに限らずすべての保証について、明示的もしくは暗黙的の保証は行われ ない。 謝辞 RFC編集者の職務のための資金は、現在、インターネットソサエティによって 提供されている。 --------------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただし、 この権利の設定は原文から新たな翻訳を作成し公開することを妨げるものではあり ません。本翻訳物は、本著作権表示を含めて改変しないことを条件に再配布を許可 します。翻訳の正確さについては一切保証しません。原文とあわせてご利用くだ さい。 2003年 --------------------------------------------------------------------------- Schulzrinne, et. al. Standards Track [Page 8]