Network Working Group R. Sparks Request for Comments: 3515 dynamicsoft Category: Standards Track April 2003 セッション開始プロトコル(SIP) Referメソッド The Session Initiation Protocol (SIP) Refer Method 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準 トラックプロトコルを規定するものであり、改善のための議論や提案を 依頼するものである。標準化の段階や、プロトコルの位置付けについては、 最新版の"Internet Official Protocol Standards" (STD 1)を参照されたい。 この文書の配布は無制限である。 著作権表記 Copyright (C) The Internet Society (2003). All Rights Reserved. 概要 本文書では、REFERメソッドを定義する。このセッション開始プロトコル (Session Initiation Protocol / SIP)拡張は、リクエストの受信者が、リク エスト中で提供されたリソースを参照(REFER)することを要求する。これは、 REFERを送信するパーティが、参照リクエストの結果を通知されることを可能に する。これは呼の転送(call transfer)を含む多くのアプリケーションを可能に するために使用できる。 本文書はREFERメソッドのほかに、referイベントパッケージとRefer-Toリク エストヘッダーを定義する。 目次 1. 概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. REFERメソッド . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Refer-Toヘッダーフィールド . . . . . . . . . . . . . . 3 2.2 REFERメソッドのためのヘッダーフィールドサポート . . . . 4 2.3 メッセージボディの包含 . . . . . . . . . . . . . . . . 5 2.4 SIPユーザーエージェントの挙動 . . . . . . . . . . . . . 6 2.4.1 REFERリクエストの形成 . . . . . . . . . . . . . . 6 2.4.2 REFERリクエストの処理 . . . . . . . . . . . . . . 6 2.4.3 Referred-toリソースへのアクセス . . . . . . . . . 6 2.4.4 SIPイベントを使用して参照の結果を報告する . . . . 7 2.4.5 NOTIFYのボディ . . . . . . . . . . . . . . . . . 8 2.4.6 ダイアログ中の複数REFERリクエスト . . . . . . . . 9 2.4.7 イベントreferとあわせたSubscription-Stateヘッダー フィールドの使用 . . . . . . . . . . . . . . . . 9 Sparks Standards Track [Page 1] RFC 3515 The SIP Refer Method April 2003 2.5 SIPレジストラとリダイレクトサーバーの挙動 . . . . . . . 9 2.6 SIPプロキシの挙動 . . . . . . . . . . . . . . . . . . . 10 3. パッケージの詳細: イベントrefer . . . . . . . . . . . . . . 10 3.1 イベントパッケージ名 . . . . . . . . . . . . . . . . . 10 3.2 イベントパッケージのパラメータ . . . . . . . . . . . . 10 3.3 SUBSCRIBEのボディ . . . . . . . . . . . . . . . . . . . 10 3.4 サブスクリプションの継続時間 . . . . . . . . . . . . . 10 3.5 NOTIFYのボディ . . . . . . . . . . . . . . . . . . . . 11 3.6 通知者(Notifier)のSUBSCRIBEリクエスト処理 . . . . . . . 11 3.7 通知者(Notifier)のNOTIFYリクエスト生成 . . . . . . . . 11 3.8 サブスクライバーのNOTIFYリクエスト処理 . . . . . . . . 11 3.9 フォークされたリクエストのハンドリング . . . . . . . . 11 3.10 通知レート . . . . . . . . . . . . . . . . . . . . . . 11 3.11 ステートエージェント . . . . . . . . . . . . . . . . . 11 4. 例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1 原型的なREFERコールフロー . . . . . . . . . . . . . . . 12 4.2 Mダイアログ中の複数REFER . . . . . . . . . . . . . . . 14 5. セキュリティの考慮 . . . . . . . . . . . . . . . . . . . . . 16 5.1 Refer-To URIの構築 . . . . . . . . . . . . . . . . . . 16 5.2 REFERに対する認可の考慮. . . . . . . . . . . . . . . . 17 5.3 message/sipfrag利用についての考慮 . . . . . . . . . . . 18 5.3.1 プライバシーの迂回 . . . . . . . . . . . . . . . 18 5.3.2 機密性の迂回 . . . . . . . . . . . . . . . . . . 19 5.3.3 違反の抑制 . . . . . . . . . . . . . . . . . . . 19 5.3.4 カット、ペースト、再生の考慮 . . . . . . . . . . 19 6. これまでの経緯 . . . . . . . . . . . . . . . . . . . . . . 20 7. IANA条項 . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1 規範的な参考文献 . . . . . . . . . . . . . . . . . . . 21 9.2 有益な参考文献 . . . . . . . . . . . . . . . . . . . . 21 10. 知的所有権表記 . . . . . . . . . . . . . . . . . . . . . . . 21 11. 著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . 22 12. 完全な著作権表記 . . . . . . . . . . . . . . . . . . . . . . 23 1. 概要 本文書では、REFERメソッドを定義する。このSIP(参考文献[1])拡張は、リクエ ストの受信者が、リクエスト中で提供されたリソースを参照(REFER)することを 要求する。 これは呼の転送(Call Transfer)を含む多くのアプリケーションを可能にするた めに使用できる。例えば、AliceがBobと話し中で、BobがCarolと話す必要があ ると決めた場合、Aliceは、彼女のSIPユーザーエージェント(UA)へ、BobのUAに CarolのSIPのコンタクト情報を提供して、SIPのREFFERリクエストを送信するよ うに指示することができる。Bobが許可を与えたと仮定して、BobのUAは、その コンタクトを利用して、Carolと通話しようと試みる。BobのUAは、そのコンタ クトへ到達するのに成功したかどうかをAliceのUAへ報告するだろう。 Sparks Standards Track [Page 2] RFC 3515 The SIP Refer Method April 2003 2. REFERメソッド REFERはRFC3261(参考文献[1])で定義されたSIPメソッドの一つである。REFER メソッドは、受信者(Request-URIで識別される)が、リクエストで提供された コンタクト情報を使用して、第三者にコンタクトをとるべきであることを示 す。 特に別記されることがなければ、REFERリクエストの発行とそれに対する応答 のプロトコルは、参考文献[1]におけるBYEリクエストのプロトコルとまった く同じである。REFER(またはその他の未知の)メソッドが実装されていないSIP エンティティの挙動は、参考文献[1]で明示的に定義されている。 REFERリクエストは、referイベントに対するサブスクリプションを暗黙的に 確立する。イベントのサブスクリプションは参考文献[2]で定義されている。 REFERリクエストは、INVITEで生成されたダイアログのスコープ外で発行しても よい[MAY]。REFERはダイアログを生成するので、Record-Routeされてもよく [MAY]、したがって、単一のContactヘッダー値を含まなければならない [MUST]。既存のダイアログ内で発生したREFERは、そのダイアログの Route/Record-Routeのロジックに従わなければならない[MUST]。 2.1 Refer-Toヘッダーフィールド Refer-Toは参考文献[1]で定義されているリクエストヘッダーフィールド (request-header)である。Refer-Toは、REFERリクエストにのみ出現する。こ れは、参照のためのURLを提示する。 Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) * (SEMI generic-param) 以下は、RFC3261の表3に記載されているものとして解釈するべきである。 Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________________ Refer-To R - - - - - - Refer-Toヘッダーフィールドは、エンドツーエンドの暗号化の一部として暗 号化されてもよい[MAY]。 ContactヘッダーフィールドはRoute/Record-Routeメカニズムの重要な部分で あり、参照のターゲットを示すためには利用できない。 Sparks Standards Track [Page 3] RFC 3515 The SIP Refer Method April 2003 例 Refer-To: sip:alice@atlanta.example.com Refer-To: Refer-To: Refer-To: Refer-To: http://www.ietf.org ここでは、わかりやすくするために、長いヘッダーフィールド値の行を折り返 して記述している。 2.2. REFERメソッドのためのヘッダーフィールドサポート この表は、参考文献[1]の表2と表3に列を追加するものであり、REFERメソッ ドに存在するヘッダーフィールドを記述する。使用されている記号について は、参考文献[1]を参照のこと。Refer-Toリクエストヘッダーの行は、推測で きるように、REFERに必須である。Refer-Toは、他のいかなるメソッドにも適 用されない。参考文献[1]のproxy列が、修正なしでREFERメソッドに適用さ れる。 Header Where REFER Accept R o Accept 2xx - Accept 415 c Accept-Encoding R o Accept-Encoding 2xx - Accept-Encoding 415 c Accept-Language R o Accept-Language 2xx - Accept-Language 415 c Alert-Info - Allow Rr o Allow 405 m Authentication-Info 2xx o Authorization R o Call-ID c m Call-Info - Contact R m Contact 1xx - Contact 2xx m Contact 3-6xx o Content-Disposition o Content-Encoding o Sparks Standards Track [Page 4] RFC 3515 The SIP Refer Method April 2003 Content-Language o Content-Length o Content-Type * CSeq c m Date o Error-Info 3-6xx o Expires R o From c m In-Reply-To - Max-Forwards R m Min-Expires - MIME-Version o Organization o Priority R - Proxy-Authenticate 401 o Proxy-Authenticate 407 m Proxy-Authorization R o Proxy-Require R o Record-Route R o Record-Route 2xx,18x o Reply-To - Require c Retry-After 404,413,480,486 o Retry-After 500,503 o Retry-After 600,603 o Route R c Server r o Subject R - Supported R,2xx o Timestamp o To c(1) m Unsupported 420 o User-Agent o Via c(2) m Warning r o WWW-Authenticate 401 m WWW-Authenticate 407 o 表1: ヘッダーフィールドサポート 2.3 メッセージボディの包含 REFERメソッドは、ボディを含んでもよい[MAY]。本仕様では、そのようなボ ディに対して何ら意味を割り当てていない。受信エージェントは、そのボディ を、そのContent-Typeに応じて処理することにしてもよい。 Sparks Standards Track [Page 5] RFC 3515 The SIP Refer Method April 2003 2.4 SIPユーザーエージェントの挙動 2.4.1 REFERリクエストの形成 REFERはSIPリクエストであり、参考文献[1]で定義されているように構築され る。REFERリクエストは、厳密に一つのRefer-Toヘッダーフィールド値を含ま なければならない[MUST]。 2.4.2 REFERリクエストの処理 整形式REFERリクエストを受信したUAは、次の段階へ進むことに対するユー ザーからの承認を要求すべきである[SHOULD](この要求はインタラクティブで 満たされてもよいし、設定によって満たされてもよい)。承認を得ると、UAは セクション2.4.3で論じられている方法で、Refer-Toヘッダーフィールド値中 のURIで指定されたリソースにコンタクトしなければならない[MUST]。 整形式REFERリクエストに対して上記で要求した承認が即座に拒否された場 合、UAはそのリクエストを辞退してもよい[MAY]。 REFERメソッドに応答するエージェントは、そのリクエストにRefer-Toヘッダー フィールド値がないか、もしくは2つ以上含まれている場合には、400(Bad Request)を返さなければならない[MUST]。 エージェント(ローカルな応答を生成するプロキシを含む)は、100(Trying)や、 参考文献[1]で規定されている適切な4xx-6xxクラスの応答を返してもよ い[MAY]。 REFERリクエストを受け入れるか否かを決定するロジックを実装する際には注 意を要するべきである。非SIP URIにアクセスできないUAは、それに対する REFERリクエストを受け入れるべきではない[SHOULD NOT]。 上記のルールにより最終応答が生成されない場合、UAはREFERトランザクショ ンが期限切れになる前に、202 Accepted応答を返さなければならない[MUST]。 REFERリクエストが受け入れられる場合(すなわち、2xxクラス応答が返される)、 受信者は、サブスクリプションを生成して、セクション2.4.4に述べられてい るように、参照のステータスの通知を送信しなければならない[MUST]。 2.4.3 Referred-toリソースへのアクセス Refer-ToのURIで特定されるリソースは、そのURIのタイプに対する通常の仕組 みを使用してコンタクトされる。例えば、URIがINVITEを表すSIP URI(例えば method=INVITEというURIパラメータを使用して)である場合、UAは、参考文献 [1]で定義されているすべての通常のINVITE送出ルールを使用して、新規 INVITEを発行する。 Sparks Standards Track [Page 6] RFC 3515 The SIP Refer Method April 2003 2.4.4 SIPイベントを使用して参照の結果を報告する REFERを送信するエージェントに参照のステータスを知らせるために、参考文 献[2]で定義されているNOTIFYの仕組みを使用しなければならない[MUST]。 各NOTIFYのダイアログID(To、From、Call-ID)は、REFERがSUBSCRIBEリクエス トだった場合にもそうであるように、REFERのダイアログIDに合致しなければ ならない。 各NOTIFYは、referという値およびできるならidパラメータ(セクション2.4.6 参照)を持つ、Eventヘッダーフィールドを含まなければならない[MUST] 各々のNOTIFYは、タイプが「message/sipfrag」(参考文献[3])のボディを含 まなければならない[MUST]。 参考文献[2]で定義されているように、サブスクリプションの生成は、いつも 直ちにNOTIFYを返すことになる。その文章で記述されているSUBSCRIBEの場合 に類似して、REFERを発行したエージェントは、REFERトランザクションが完 了する前にNOTIFYを受信する用意がなければならない[MUST]。 REFERによって生成される暗黙的なサブスクリプションは、SUBSCRIBEリクエ ストで生成されるサブスクリプションと同じである。REFERを発行するエージェ ントは、参考文献[2]で述べられているメカニズムを使用してアンサブスクラ イブすることにより、このサブスクリプションを早期(prematurely)に終了 できる。明示的にアンサブスクライブするかNOTIFYを拒否するなどしてサブス クリプションを終了することは、参照リクエストが取り消されるべきあるい は中止されるべきであることを示すものではない。特に、REFERリクエストに 従って動作しているエージェントは、参照リクエストが完了する前にREFERを 送信するエージェントがreferイベントに対するサブスクリプションを停止し たからといって、参照されるどのSIPリクエストに対してもCANCELを発行する べきではない[SHOULD NOT]。 REFERを発行するエージェントは、参考文献[2]で述べられているサブスクリ プションのリフレッシュメカニズムを使用して、サブスクリプションを延長 してもよい。 REFERは、イベントreferに対してサブスクリプションを生成できる唯一のメ カニズムである。イベントreferのためのSUBSCRIBEリクエストを、まだ存在 しないサブスクリプションに対して受信する場合、それは403で拒否されなけ ればならない[MUST]。 SUBSCRIBEとは違いREFERトランザクションは、リクエスト中にも応答中にも サブスクリプションの期間を含まない、ということに注意すること。サブス クライブされるステートの生存時間は、参照リクエストの進行状態によって 決定される。サブスクリプションの継続時間は、REFERを受け入れるエージェ ントによって選択され、サブスクリプションの最初のNOTIFYで(Subscription-State のexpiresヘッダーパラメータを使用して)REFERを送信したエージェントに伝 えられる。REFERを受け入れて、サブスクリプションステートの保持を望まな いエージェントは、この最初のNOTIFYでサブスクリプションを終了できる、 ということに注意すること。 Sparks Standards Track [Page 7] RFC 3515 The SIP Refer Method April 2003 2.4.5 NOTIFYのボディ 各々のNOTIFYは、タイプが「message/sipfrag」(参考文献[3])のボディを含 まなければならない[MUST]。NOTIFYのボディは、参考文献[1]で定義されてい るような「SIP Response Status-Line」で始まらなければならない[MUST]。 このステータス行の応答クラスは、参照された動作のステータスを示す。ボ ディは、参照動作の結果に関する情報を提供するために、他のSIPヘッダーフ ィールドを含んでもよい[MAY]。このボディは、参照された動作のステータス の完全な説明を提示する。referイベントパッケージはステートの差分(state delta)をサポートしない。 サブスクリプションのステートがペンディング(pending)のときにNOTIFYが生 成される場合、それのボディは、応答コード100を含むステータス行だけから 成るべきである。 最小だが完全な実装では、以下のいずれかのボディを含む1つのNOTIFYで応答 できる。 SIP/2.0 100 Trying サブスクリプションがペンディングの場合のボディは上記であり、 SIP/2.0 200 OK 参照が成功した場合のボディは上記であり、 SIP/2.0 503 Service Unavailable 参照が失敗した場合のボディは上記であり、 SIP/2.0 603 Declined あるいは、参照にしたがうことへの承認が取得できる前にREFERリクエストが 受け入れられ、引き続いてその承認が拒否された場合(セクション2.4.7参照) のボディは上記である。 実装では、そのボディに、より多くの情報を持たせるため、より多くのSIPメ ッセージを含めてもよい[MAY]。参照された動作に対する応答中で受信した Warningヘッダーフィールドは、(訳注:追加情報を持たせるのに使用するた めの)よい候補である。実際、参照がSIP URIに対するものであった場合、そ の参照動作に対する応答の全体が返されることがあり得る(おそらくデバッグ を補助するために)。しかし、そのようにすることは、セキュリティに重大な 影響をもたらす(セクション5参照)。実装者は、何を含めるかを慎重に考慮し なければならない。 参照が非SIP URIに対するものであった場合、参照指示端末(referrer)に対す るいかなるNOTIFYのステータスも、SIP Response Status-Lineの形式でなけ ればならない。上で述べた最小の実装でも、成功か失敗かについて基本的な Sparks Standards Track [Page 8] RFC 3515 The SIP Refer Method April 2003 表示を行うのに十分である。例えば、クライアントがHTTP URLに対するREFER を受信し、そのリソースに対するアクセスが成功した場合、参照指示端末に 対するNOTIFYに、「SIP/2.0 200 OK」のmessage/sipfragボディを含めること ができる。通知者(notifier)が、リクエストの状態に関する、非SIPプロトコル に固有の付加的な情報を返したければ、それをsipfragメッセージのボディに置 いてもよい。 2.4.6 ダイアログ中の複数REFERリクエスト REFERは、REFERリクエスト中でダイアログIDを共有する暗黙的なサブスクリ プションを生成する。2つ以上のREFERが同一ダイアログ内で発行された場合 (例えば、呼を転送するための2度目の試行で)、ダイアログIDは、生成される NOTIFYを適切なREFERに関連付ける十分な情報を提供しない。 したがって、UAが特定のダイアログ内で受信する、2つめおよびそれ以降のREFER リクエストに対して、UAは、各NOTIFYのEventヘッダーフィールドに、このNOTIFY が関連付けられるREFERのシーケンス番号(CSeqヘッダーフィールド値からの 数値)を含むidパラメータ(参考文献[2])を含めなければならない[MUST]。こ のidパラメータは、特定のダイアログ内でUAが受信する最初のREFERに対する NOTIFYに含めてもよい[MAY]。このサブスクリプションをリフレッシュするた め、あるいは終了するために送信されたSUBSCRIBEは、このidパラメータを含 まなければならない[MUST]。 2.4.7 イベントreferとあわせたSubscription-Stateヘッダーフィールドの使用 各々のNOTIFYは、参考文献[2]で定義されているようにSubscription-Stateヘ ッダーフィールドを含まなければならない。REFERに対する応答で送信される 最後のNOTIFYは、「noresource」という理由で、サブスクリプションが終了 された(terminated)ことを示さなければならない[MUST]。(サブスクライブさ れるリソースは、参照リクエストのステートである)。 NOTIFYが、参考文献[2]にしたがってre-subscribeすることが適切であること を示唆するreasonを示す場合、REFERを送信したエージェントはre-subscribe する義務はない[NOT]。 REFERが202で受け入れられたが、それに続いて、参照にしたがうことへの承 認が拒否された場合、Subscription-Stateヘッダーフィールドのreasonと retry-afterエレメントを、REFERを再試行できるかどうか、再試行できると すればそれはいつかを示すために使用できる(参考文献[2]でSUBSCRIBEに対し て述べられているように)。 2.5 SIPレジストラとリダイレクトサーバーの挙動 REFERメソッド定義を理解しないレジストラは、おそらく参考文献[1]で定義 されている501応答を返す。REFERメソッド定義を理解するレジストラは、405 応答を返すべきである[SHOULD]。 Sparks Standards Track [Page 9] RFC 3515 The SIP Refer Method April 2003 本仕様では、リダイレクトサーバーの挙動に関する要求を、参考文献[1]で定 義されている以外には何ら課さない。したがって、REFERリクエストがリダイ レクトされることもあり得る。 2.6 SIPプロキシの挙動 SIPプロキシは、REFERメソッドをサポートするための変更を必要としない。 具体的には、参考文献[1]で要求されているように、プロキシはREFERリクエ ストを、OPTIONSリクエストを処理するのと同じ方法で処理するべきである。 3. パッケージの詳細: イベントrefer 本文書は、参考文献[2]で定義されているように、イベントパッケージを定義 する。 3.1 イベントパッケージ名 このイベントパッケージの名称は「refer」である。 3.2 イベントパッケージのパラメータ このパッケージは、参考文献[2]で定義されている「id」パラメータを使用す る。パッケージ内でのそれの用法はセクション2.4.6で述べている。 3.3 SUBSCRIBEのボディ SUBSCRIBEのボディはこのイベントパッケージに対してなんら特別な意味を持 たない。 3.4 サブスクリプションの継続時間 REFERリクエストによって生成された暗黙的なサブスクリプションの継続時間 は、REFERを受け入れるエージェントによって最初に確定され、サブスクリプ ションにおいて最初に送信されるNOTIFY中のSubscription-Stateヘッダーフ ィールドのexpireパラメータで、サブスクライブしたエージェントに伝えら れる。この最初の継続時間の理にかなった選択は、Refer-To URI中で示され るリクエストのタイプに依存する。継続時間は、参照リクエストが完了する ための時間よりも長くなるように選択されるべきである[SHOULD]。例えば、 Refer-To URIがSIP INVITE URIの場合、サブスクリプション間隔はINVITE中 のExpire値よりも長くなるべきである。サブスクリプションを認可するため に必要とされる時間を考慮するために、更なる時間を含めてもよい[MAY]。 サブスクライブするエージェントは、サブスクリプションをリフレッシュす ることによってそれを延長するか、あるいはアンサブスクライブしてそれを 終了してもよい[MAY]。セクション2.4.7で述べられているように、REFERを受 け入れるエージェントは、参照の最終結果を報告するときに、Subscription-State ヘッダーフィールド中で終了を示して、サブスクリプションを終了する。 Sparks Standards Track [Page 10] RFC 3515 The SIP Refer Method April 2003 3.5 NOTIFYのボディ イベントreferに対するNOTIFYリクエストのボディは、セクション2.4.5で論 じられている。 3.6 通知者(Notifier)のSUBSCRIBEリクエスト処理 通知者(notifier)のSUBSCRIBEリクエスト処理はセクション2.4.4で論じられ ている。 3.7 通知者(Notifier)のNOTIFYリクエスト生成 通知者(notifier)のNOTIFYリクエスト生成はセクション2.4.4で論じられてい る。 3.8 サブスクライバーのNOTIFYリクエスト処理 サブスクライバーのNOTIFYリクエスト処理はセクション2.4.4で論じられてい る。 3.9 フォークされたリクエストのハンドリング 既存のダイアログのスコープ内で送信されたREFERはフォークしない。ダイア ログのコンテキスト外で送信されたREFERはフォークしてもよく[MAY]、それ が複数のエージェントに受け入れられた場合は、複数のサブスクリプション を生成してもよい[MAY]。これらのサブスクリプションは、REFERがSUBSCRIBE であったかのように、参考文献[2]の「フォークされたリクエストのハンドリ ング(Handling of Forked Requests)」によって生成され、管理される。REFER を送信するエージェントは、各サブスクリプションに関連付けられるステー トを別々に管理する。それは、別々のサブスクリプションのステートをマー ジしない[NOT]。ステートとは、それぞれの受け入れエージェントにおける、 参照リクエストのステータスである。 3.10 通知レート イベントreferのNOTIFYは、参照リクエストのステータスに関する新しい知識 が利用可能になるたびに、生成されるかもしれない。例えば、REFERがSIP INVITE に対するものだった場合、INVITEに対する各暫定応答および各最終応答で NOTIFYが生成されるかもしれない。その代わり、サブスクリプションは、即 時のNOTIFYと参照の最終結果を伝えるNOTIFYの、ただ2つのNOTIFYリクエスト を生成するだけかもしれない。イベントreferに対するNOTIFYは、1秒に1回よ りも多い頻度で送信されるべきではない[SHOULD NOT]。 3.11 ステートエージェント イベントreferのための分離ステートエージェント(separate state agent)は 定義されていない。 Sparks Standards Track [Page 11] RFC 3515 The SIP Refer Method April 2003 4. 例 4.1 原型的なREFERコールフロー Agent A Agent B | | | F1 REFER | |----------------------->| | F2 202 Accepted | |<-----------------------| | F3 NOTIFY | |<-----------------------| | F4 200 OK | |----------------------->| | | | | | |-------> | | (whatever) | |<------ | | | F5 NOTIFY | |<-----------------------| | F6 200 OK | |----------------------->| | | | | これは、エージェントBが発生させた、(何か[whatever])への参照が成功した 場合、エージェントAとエージェントBとの間の4つのメッセージがどのように 見えるかという例である。このフローの詳細は、このREFERはセッションの外 部で発生することを示す(REFERリクエストにToタグがない)。REFERがセッシ ョンの内部で発生する場合、リクエストのToタグは空ではない。 Message One (F1) REFER sip:b@atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK2293940223 To: From: ;tag=193402342 Call-ID: 898234234@agenta.atlanta.example.com CSeq: 93809823 REFER Max-Forwards: 70 Refer-To: (whatever URI) Contact: sip:a@atlanta.example.com Content-Length: 0 Sparks Standards Track [Page 12] RFC 3515 The SIP Refer Method April 2003 Message Two (F2) SIP/2.0 202 Accepted Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK2293940223 To: ;tag=4992881234 From: ;tag=193402342 Call-ID: 898234234@agenta.atlanta.example.com CSeq: 93809823 REFER Contact: sip:b@atlanta.example.com Content-Length: 0 Message Three (F3) NOTIFY sip:a@atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9922ef992-25 To: ;tag=193402342 From: ;tag=4992881234 Call-ID: 898234234@agenta.atlanta.example.com CSeq: 1993402 NOTIFY Max-Forwards: 70 Event: refer Subscription-State: active;expires=(depends on Refer-To URI) Contact: sip:b@atlanta.example.com Content-Type: message/sipfrag;version=2.0 Content-Length: 20 SIP/2.0 100 Trying Message Four (F4) SIP/2.0 200 OK Via: SIP/2.0/UDP agentb.agentland;branch=z9hG4bK9922ef992-25 To: ;tag=193402342 From: ;tag=4992881234 Call-ID: 898234234@agenta.agentland CSeq: 1993402 NOTIFY Contact: sip:a@agentland Content-Length: 0 Message Five (F5) NOTIFY sip:a@agentland SIP/2.0 Via: SIP/2.0/UDP agentb.agentland;branch=z9hG4bK9323394234 To: ;tag=193402342 From: ;tag=4992881234 Call-ID: 898234234@agenta.agentland CSeq: 1993403 NOTIFY Max-Forwards: 70 Sparks Standards Track [Page 13] RFC 3515 The SIP Refer Method April 2003 Event: refer Subscription-State: terminated;reason=noresource Contact: sip:b@agentland Content-Type: message/sipfrag;version=2.0 Content-Length: 16 SIP/2.0 200 OK Message Six (F6) SIP/2.0 200 OK Via: SIP/2.0/UDP agentb.agentland;branch=z9hG4bK9323394234 To: ;tag=193402342 From: ;tag=4992881234 Call-ID: 898234234@agenta.agentland CSeq: 1993403 NOTIFY Contact: sip:a@agentland Content-Length: 0 4.2 ダイアログ中の複数REFER 上記Message Oneは、暗黙的なサブスクリプションのダイアログを生み出す。 エージェントAがそのダイアログ内で2つめのREFERを発行したと仮定すると、 以下のようなフローになる。 Agent A Agent B | | | F7 REFER | |----------------------->| | F8 202 Accepted | |<-----------------------| | F9 NOTIFY | |<-----------------------| | F10 200 OK | |----------------------->| | |-------> | | (something different) | |<------ | | | F11 NOTIFY | |<-----------------------| | F12 200 OK | |----------------------->| | | | | Sparks Standards Track [Page 14] RFC 3515 The SIP Refer Method April 2003 Message Seven (F7) REFER sip:b@atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK9390399231 To: ;tag=4992881234 From: ;tag=193402342 Call-ID: 898234234@agenta.atlanta.example.com CSeq: 93809824 REFER Max-Forwards: 70 Refer-To: (some different URI) Contact: sip:a@atlanta.example.com Content-Length: 0 Message Eight (F8) SIP/2.0 202 Accepted Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK9390399231 To: ;tag=4992881234 From: ;tag=193402342 Call-ID: 898234234@agenta.atlanta.example.com CSeq: 93809824 REFER Contact: sip:b@atlanta.example.com Content-Length: 0 Message Nine (F9) NOTIFY sip:a@atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9320394238995 To: ;tag=193402342 From: ;tag=4992881234 Call-ID: 898234234@agenta.atlanta.example.com CSeq: 1993404 NOTIFY Max-Forwards: 70 Event: refer Subscription-State: active;expires=(depends on Refer-To URI) Contact: sip:b@atlanta.example.com Content-Type: message/sipfrag;version=2.0 Content-Length: 20 SIP/2.0 100 Trying Message Ten (F10) SIP/2.0 200 OK Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9320394238995 To: ;tag=193402342 From: ;tag=4992881234 Call-ID: 898234234@agenta.atlanta.example.com Sparks Standards Track [Page 15] RFC 3515 The SIP Refer Method April 2003 CSeq: 1993404 NOTIFY Contact: sip:a@atlanta.example.com Content-Length: 0 Message Eleven (F11) NOTIFY sip:a@atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK2994a93eb-fe To: ;tag=193402342 From: ;tag=4992881234 Call-ID: 898234234@agenta.atlanta.example.com CSeq: 1993405 NOTIFY Max-Forwards: 70 Event: refer;id=93809824 Subscription-State: terminated;reason=noresource Contact: sip:b@atlanta.example.com Content-Type: message/sipfrag;version=2.0 Content-Length: 16 SIP/2.0 200 OK Message Twelve (F12) SIP/2.0 200 OK Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK2994a93eb-fe To: ;tag=193402342 From: ;tag=4992881234 Call-ID: 898234234@agenta.atlanta.example.com CSeq: 1993405 NOTIFY Contact: sip:a@atlanta.example.com Content-Length: 0 5. セキュリティの考慮 参考文献[1]のセクション26に記載されるセキュリティの考慮が、REFERのトラ ンザクションに適用される。特に、実装レベルとセクション26.3は、通常のSIP トランザクションを安全にするためのものである。参照されたリクエスト結果 を配信するために、REFERリクエストの認可(authorization)ポリシーと、と message/sipfragの利用について、特別な考慮が保証される。 5.1 Refer-To URIの構築 このメカニズムは、参照されるパーティへreferred-toのリソースについての コンタクト情報提供に依存している。referred-toのリソースが保護されるべき ならば、適切に制限されたURIを提供するために気を付けるべきである。 Sparks Standards Track [Page 16] RFC 3515 The SIP Refer Method April 2003 5.2 REFERに対する認可の考慮 セクション2.4.2に記載されるとおり、実装は、任意のスキームを含むRefer-To URIを持つREFERリクエストを受信できる。例えば、ユーザーは、telnet URIを 使用するMUDのようなオンラインサービスに参照されることができる。カスタ マーサービスはカスタマーにHTTP URIを使用した注文追跡のWebページを参照 させることもできる。セクション2.4.2によって、ユーザーエージェントは、 参照されたスキームを処理できない場合、REFERリクエストを拒否することがで きるようになる。また、それによって、ユーザーエージェントは、そのURIを使 用しようと試みる前に、ユーザーから認可を取得する必要もある。一般的に、 これは、完全なURIと「このリソースにアクセスしたいですか (Y/N)」のような 質問をプロンプトすることで達成することができるだろう。もちろん、 URIは任意の長さの可能性があるし、時には、悪意ある形で構築されるため、 URI自体を表示する際でも、予期せぬ驚きを防ぐように気を付けるべきである (例えば、部分的にしか表示されない、または表示が壊れているなど)。 さらに、ユーザーが危険な決定へ誤って導かれるリスクを軽減できるように、 できるだけ多くの参照に関する情報を明かすように気を付けるべきである。 例えば、Refer-ToヘッダーはURIを持つ表示名を含む可能性がある。その表示名 で指定されるプロパティのいずれについても、URIによって共有されるというこ とは確かではない。例えば、表示名は"secure"または"president"を含み、 URIは sip:agent59@telemarketing.example.com を示す場合。このように、 表示名のみをユーザーにプロンプトするのは十分とは言えない。 ある場合では、ユーザーエージェントにポリシーを提供する時点の前に、 ユーザーはあるREFERリクエストに認可を提供できる。 これは、例えば、参考文献[4]で議論されている呼の転送(call transfer) の場合、適切である。この場合、既存のSIPダイアログ内のsip:、または sips:、tel: URIへの正しく承認されたREFERリクエストは、ユーザー相互の認 可取得なしに、そのポリシーを通して受け入れられてもよい。同様に、参照指 示端末が、承認済み参照指示端末のリストに明示的に示される場合、HTTP URI へ正しく認可されたREFERを受け入れるのは、適切であると言える。このような 前もって提供される認可がないばあい、ユーザーは、指定されたリソースを参 照するために、相互に認可を提供しなければならない。 HTTP URIをやみくもに受け入れたり、実行するポリシーの危険性を理解する には、例えば、小さな組織のファイアウォールに隠れたクライアントからの リクエストのみを受け入れるように設定されたWebサーバーを考慮されたい。 小さな組織がメンバーすべてを信頼し、内部セキュリティをほとんど持たない ような、このソフトでクリーミーで中程度な環境にいると、Webサーバーは、 メンテナンスの目の行き届かないところで、悪意のある構成のURIを通した攻撃 に対して脆弱な状態に置かれることになる(URIで提供される任意のコードを実 行するような結果になるかもしれない)。このファイアウォールの内部にあるSIP UAが、任意のHTTP URIへの参照をやみくもに受け入れると、ファイアウォール 外部の攻撃者がWebサーバーを危うくするかもしれない。一方で、UAのユーザー Sparks Standards Track [Page 17] RFC 3515 The SIP Refer Method April 2003 が、このURIを実行する前に積極的な行動を取らなければならない場合(例えば プロンプトに応答するなど)、リスクは、Webブラウザやemailメッセージ中のURI をユーザーがクリックするのと同じレベルまで下がる 上記の段落の結論は、任意のスキームを持つURIへも一般化される。特定のス キームを持つURIへアクセスする自動的なアクションをとるエージェントは、間 接的に、そのスキームに関連する何らかのセキュリティの欠陥に対して脆弱で ある別のホストを攻撃するのに使用されるリスクを持つ。ホストとエージェン トがファイアウォールのような共通のポリシー実施ポイントに隠れている場合、 このリスクと他のホストを害する可能性は高くなる。さらに、このエージェン トは、特に各自動的なアクションが新規の接続を開始する指定の場合、DoS攻撃 に晒され、リソースを消耗するような度合いが高くなる。 例えば、今のオペレーティングシステムによって提供されるようなサードパー ティのサービスへ、任意のURIを処理する場合、特に、ユーザーエージェントが そのスキームや、それが示すプロトコルを使用する可能性のある派生する問題 を意識していない場合、ユーザーエージェントは気を付けるべきである。 「驚き最小限の原則(principle of least surprise)」に違反する可能性は非常 に高い。 5.3 message/sipfrag利用の考慮 進行度とREFERリクエストの結果を返すためにmessage/sipfragボディを使用す ることは、非常に強力である。その能力を不注意に利用することによって、 機密性やプライバシーを危険にさらす可能性がある。ここでは、害の可能性を 示すために、1組のシンプルでやや不自然な例を挙げよう。 5.3.1 プライバシーの迂回 Aliceが、SIP INVITE URIに対するREFERリクエストを受諾し、参照指示端末に 対してNOTIFYのボディ中にINVITEへの各応答をコピーすることにより、INVITEの 進捗状況を通知するユーザエージェントを持っていると仮定する。 そのうえ、Carolに、Malloryを避ける理由があり、Carolがいつ在席している か、またはCarolが実際にどのようなユーザーエージェントを使用しているか をMalloryが知ることができないように、自分のプロキシのシステムを、(Alice を含む)自分が信用するある特定の人たちからの呼のみを受諾するように設定 していたと仮定する。 MalloryはAliceに対し、Carolを示すRefer-To URIを持つREFERを送ることが できる。AliceからCarolへ到達可能であれば、Carolが送る200 OKは、Mallory に対してNOTIFY中で返され、彼に、Carolが在席しているということだけでな く、彼女が使用しているエージェントのIPアドレスをも知らせてしまうこと になる。 Sparks Standards Track [Page 18] RFC 3515 The SIP Refer Method April 2003 5.3.2 機密性の迂回 Aliceが、上記と同じユーザーエージェントを使用し、SIP FOOといういまだ かつて発明されていないすばらしいSIPデバイスを開発している会社で働いて いると仮定する。その会社は、そのSIPデバイス開発とマーケティング資料に 数ヶ月かけており、そのアイディアと、その名称さえも秘密にしている(FOO は、そのアイディアを最初に得たものが誰でも実現できるという類のもので あるため)。FOOは完成し、稼動しており、会社の誰でも使用できるが、会社 のファイアウォールの外側では使用できない。 Malloryは、Aliceの会社が何か大きなことをやっているという噂を聞き、何 とかしてそれで何かできそうなURIを得た。彼は、その秘密のURIをもった REFERをAliceに送り、AliceがFOOに接続したので、Malloryは以下のボディを 含むNOTIFYを得た。 Server: FOO/v0.9.7 5.3.3 違反の抑制 これらの場合のそれぞれについて、また一般的に、NOTIFYを介した参照の進 捗状況に関して利用可能な情報の、注意深く選択されたサブセットを返すこ とは、リスクを軽減する。セクション2.4.5で記述した最小の実装では、REFER リクエストを処理するエージェントが何をしたかということに関する最低限 の情報のみを開示しており、悪意を持つユーザーにとって有用なツールには なりえないであろう。 5.3.4 カット、ペースト、再生の考慮 この仕様で定義されるメカニズムは、NOTIFYリクエストから全部または部分的 にmessage/sipfragボディをコピーしたり、同じまたは異なるREFERに対応する NOTIFYリクエストに後の挿入することによって、直接的に侵害の影響を受ける ことはない。この仕様では、REFERリクエストに応答するエージェントは、送信 するNOTIFYのボディの内容の完全な制御下にある。このエージェントに、他の 参照されたパーティーからのすべての情報を忠実に転送(forward)することを要 求するメカニズムは、ここでは定義されない。つまり、後の応答のためにボディ を保存することは、エージェントに、ピアにおいて、このドキュメントで定義 されるメカニズムへ影響を及ぼす能力を、ボディなしで持つ能力以上にはない ということである。同様に、盗聴者がmessage/sipfragボディを取得しても、そ れがない場合以上に、このメカニズムに影響する能力はないだろう。 「あなたが私を参照したパーティに私は接続しました。ここに暗号証明 (cryptographic proof)があります。」といった主張をするNOTIFYにおけ るmessage/sipfragのボディ部を使用するのを許可するために、将来の拡張 が、REFERに応答するエージェントに対して、新規の制約を作るかもしれない。 これらの主張は、受信側のUAの動作に影響を与えるように使用される可能性 Sparks Standards Track [Page 19] RFC 3515 The SIP Refer Method April 2003 がある。この類の拡張は、コピーベースの攻撃に自身を保護する新規のメカニ ズムを定義する必要があるだろう。 6. これまでの経緯 このメソッドは当初、呼の転送用アプリケーションによって考え出された。 TRANSFERとして始まり、後にREFERとして一般化されたこのメソッドは、転送 をBYEの処理から切り離して、期限切れとなったdraft-ietf-sip-cc-01のBYE/ Alsoコンセプトを改良したものである。これらの変更は、失敗した転送のリカ バリを容易にし、参加しているエンティティにおけるステート管理を明確に する。 これの初期のバージョンでは、REFERに応答するエージェントが、REFERに対 する最終応答を送信する前に、参照動作が完了するのを待つことが必要とさ れた。この最終応答は、参照動作の成功または失敗を反映していた。これは、 参考文献[1]において非INVITEリクエストに対して定義されたトランザクショ ンタイムアウトのルールのために、実現不可能だった。REFERは常に、即時 (非INVITEトランザクションの生存時間内に)最終応答を受信しなければならな い。 7. IANA条項 本文書は、新規SIPメソッド名(REFER)、新規SIPヘッダーフィールド名とその コンパクトフォーム(それぞれRefer-To、r)、およびイベントパッケージ(refer) を定義する。 以下が、http://www.iana.org/assignments/sip-parameters下のメソッドの 下位レジストリに追加された。 REFER [RFC3515] 以下の情報が、http://www.iana.org/assignments/sip-parameters 以下の ヘッダーの下位レジストリに追加された。 ヘッダー名: Refer-To 省略形: r 参照: RFC 3515 本仕様は、参考文献[2]で定義されている登録手順に基づいて、イベントパッ ケージを登録する。以下は、この登録に必要とされる情報である。 パッケージ名: refer パッケージまたはパッケージテンプレート: 本仕様がパッケージである。 Sparks Standards Track [Page 20] RFC 3515 The SIP Refer Method April 2003 発行された仕様: RFC 3515 連絡先: Robert Sparks, rsparks@dynamicsoft.com 8. 謝辞 本文書はSIPワーキンググループの共同成果物である。 9. 参考文献 9.1 規範的な参考文献 [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] Roach, A. B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [3] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002. 9.2 有益な参考文献 [4] Sparks, R. and A. Johnston, "Session Initiation Protocol Call Control - Transfer", Work in Progress. 10. 知的所有権表記 IETFは、知的所有権、あるいは本文書に記載される技術の実装または仕様に 関して主張される可能性のある他のいかなる権利についても、有効期間また は範囲に関して、あるいはこのような権利下でどのようなライセンスの範囲 までが利用可能か否かに関して、何ら見解を持たない。また、このような権 利を特定しようともしていない。標準化過程および標準化に関連する文書化 に関するIETFの手順に関する情報は、BCP-11に記載されている。こうした所 有権について、本仕様の実装者あるいはユーザーが公開のために利用可能と された権利請求の複写、および、利用可能とされたライセンスの保証、ある いは、一般的なライセンスまたは許可を取得しようと試みた結果は、IETF事 務局から入手できる。 IETFは、この規格を実行するために必要とされる技術の範囲にある可能性が ある、すべての著作権、特許または特許アプリケーション、あるいは他の所 有権について、すべての関連団体に対して配慮するよう依頼している。これ らの情報については、IETFの事務局長への連絡を請う。 Sparks Standards Track [Page 21] RFC 3515 The SIP Refer Method April 2003 11. 著者の連絡先 Robert J. Sparks dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 EMail: rsparks@dynamicsoft.com Sparks Standards Track [Page 22] RFC 3515 The SIP Refer Method April 2003 12. 完全な著作権表記 Copyright (C) The Internet Society (2003). All Rights Reserved. 本記述とその翻訳は複写し他に提供することができる。また論評を加えた派 生的製品や、この文書を説明したり、その実装を補助するもので、上記の著 作権表示およびこの節を付加するものはすべて、全体であってもその一部で あっても、いっさいの制約を課されること無く、準備、複製、発表、配布す ることができる。しかし、この文書自体にはいかなる方法にせよ、著作権表 示やインターネットソサエティもしくは他のインターネット関連団体への参 照を取り除くなどの変更を加えてはならない。 インターネット標準を開発す るために必要な場合は例外とされるが、その場合はインターネット標準化過 程で定義されている著作権のための手続きに従わなければならない。 またRFC を英語以外の言語に翻訳する必要がある場合も例外である。 以上に述べられた制限は永久的なものであり、インターネットソサエティも しくはその継承者および譲渡者によって破棄されることはない。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、インターネッ トソサエティおよびIETFは、この情報がいかなる権利も侵害していないとい う保証、商用利用および特定目的への適合性への保証を含め、また、これら だけに限らずすべての保証について、明示的もしくは暗黙的の保証は行われ ない。 謝辞 RFCエディターの活動のための資金は、現在インターネットソサエティによっ て提供されている。 --------------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただし、 この権利の設定は原文から新たな翻訳を作成し公開することを妨げるものではあり ません。本翻訳物は、本著作権表示を含めて改変しないことを条件に再配布を許可 します。翻訳の正確さについては一切保証しません。原文とあわせてご利用くだ さい。 2003年 --------------------------------------------------------------------------- Sparks Standards Track [Page 23]