Network Working Group J. Rosenberg Request for Comments: 4538 Cisco Systems Category: Standards Track June 2006 セッション開始プロトコル(SIP)におけるダイアログ識別による リクエストの認可 Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP) 本文書の位置付け 本文書は、インターネットコミュニティのためのインターネット標準化過程 プロトコルを規定し、改善のための議論や提案を依頼するものである。標準 化の段階や、プロトコルの位置付けについては、最新版の"Internet Official Protocol Standards" (STD 1)を参照されたい。本文書の配信は無制限であ る。 著作権表記 Copyright (C) The Internet Society (2006). 概要 この仕様は、セッション開始プロトコル(Session Initiation Protocol/SIP) のTarget-Dialogヘッダーフィールドと対応するオプションタグtdialogを定義 する。このヘッダーフィールドは、SIPダイアログを作成するリクエストで使 用される。このヘッダーフィールドは、送信者が受信者との既存のダイアログ を認識していることを、受信者に示す。認識している理由は、送信者がそのダ イアログの相手側にいるため、またはダイアログ識別子にアクセス権があるた めである。受信者は、その認識に基づいて、リクエストを認可することができ る。 Rosenberg Standards Track [Page 1] RFC 4538 Target Dialog June 2006 目次 1. はじめに ..................................................... 3 1.1. 用語 ..................................................... 4 2. 操作の概要 ................................................... 4 3. ユーザーエージェントクライアント(UAC)の動作 ................... 5 4. ユーザーエージェントサーバーの動作 ........................... 7 5. プロキシの動作 ............................................... 8 6. 拡張性の考慮事項 ............................................. 8 7. ヘッダーフィールドの定義 ..................................... 9 8. セキュリティの考慮事項 ....................................... 9 9. In-Reply-Toとの関係 .......................................... 10 10. コールフロー例 .............................................. 10 11. IANA条項 .................................................... 13 11.1. ヘッダーフィールド .................................... 13 11.2. ヘッダーフィールドパラメータ .......................... 13 11.2.1. local-tag ............................................ 13 11.2.2. remote-tag .......................................... 13 11.3. SIPオプションタグ ...................................... 14 12. 謝辞 ........................................................ 14 13. 参考文献 .................................................... 14 13.1. 規範となる参考文献 .................................... 14 13.2. 有益な参考文献 ........................................ 15 Rosenberg Standards Track [Page 2] RFC 4538 Target Dialog June 2006 1. はじめに セッション開始プロトコル(Session Initiation Protocol/SIP) [2]は、ダイ アログの概念を、1組のユーザーエージェント感の継続的な関係と定義してい る。ダイアログは、シーケンス番号、プロキシのルート、ダイアログ識別子な どの状況を示す。ダイアログは、特定のメソッドを使用したSIPリクエストの 送信によって確立される。特に、INVITE、REFER [8]、SUBSCRIBE [3] リクエ ストはいずれもダイアログを作成する。 ユーザーエージェントは、ダイアログを作成するリクエストを受信した場合、 そのリクエストを認可するかどうかを判断する必要がある。一部のリクエスト の場合、認可は、送信者のID、リクエストメソッドなどの機能である。ただ し、多くの場合、ユーザーエージェントによる認可の判断は、リクエストの送 信者がそのユーザーエージェントとの間で現在ダイアログを使用中かどうか、 またはリクエストの送信者が、他のエンティティとの間で使用しているダイア ログを認識しているかどうかによって決定されてきた。 たとえば、REFERで実現する呼転送がある。ユーザーエージェントAとBはINVITE ダイアログを使用中で、ユーザーエージェントAはユーザーエージェントB をユーザーエージェントCに転送したいと考えている。この場合、ユーザー エージェントAはREFERリクエストをユーザーエージェントBに送信し、ユー ザーエージェントCにINVITEリクエストを送信することをユーザーエージェン トBに尋ねる。ユーザーエージェントBはこのREFERを認可する必要がある。適 切な認可の判断は、ユーザーエージェントBが現在INVITEダイアログで関係を 持っているユーザーからリクエストが送られた場合、Bはそのリクエストを受 け入れる、というものである。現在の実装は、ユーザーエージェントAとBの間 に確立しているダイアログと同じダイアログで、REFERを送信するという対処 方法である。ただし、このアプローチには多くの問題がある[12]。たとえば、 ダイアログのライフサイクルと用法を判断することや、各アプリケーションの 用法と関連があるメッセージを判断することが難しいという問題がある。この 方法よりも優れたアプローチは、ユーザーエージェントAがそのダイアログ外 でREFERリクエストをユーザーエージェントBに送信する方法である。この場 合、ユーザーエージェントBがREFERを認可する手段が必要である。 もう1つの例は、アプリケーション対話フレームワーク(application interaction framework) [14]である。このフレームワークでは、SIP INVITE リクエストのパス上にあるプロキシサーバーが、リクエストを生成または受信 したユーザーエージェントに、ユーザーインターフェースコンポーネントを配 置することができる。このために、プロキシサーバーは、ユーザーエージェン トのGlobally Routable User Agent URI (GRUU) [13]宛てに、REFERリクエス トを送信する必要がある。このユーザーエージェントに対するリクエストで は、ユーザーインターフェースコンポーネントを含むHTTPリソースを取得する ように要求される。この場合、ユーザーエージェントBがREFERを認可する手段 が必要である。アプリケーション対話フレームワークでは、元のダイアログの パス上にあるエンティティから送信された場合、そのリクエストを認可するこ とが推奨されている。これは、REFERにダイアログ識別子を含めることで実行 できる。これによって、REFERを送信したユーザーエージェントが、そのダイ アログ識別子を認識していることが証明される(当然ながら、sipsメカニズム によって盗聴者から保護する必要がある)。 もう1つの例は、2つのユーザーエージェントがINVITEダイアログを共有し、 INVITEリクエストのパス上の要素がINVITEの状態を追跡することを望んでいる 場合である。この場合、SUBSCRIBEリクエストをユーザーエージェントのGRUU に送信し、ダイアログイベントパッケージへのサブスクリプションを求める。 SUBSCRIBEリクエストがINVITEリクエストパス上の要素から送信されている場 合、そのリクエストは認可すべきである。 1.1. 用語 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「MAY」、「OPTIONAL」はRFC 2119[1]の記載に従って解釈 されるべきである。 2. 操作の概要 +--------+ +--------+ | | INVITE | | | Server |----------->| Server | | A | | B | | |...........>| | +--------+ +--------+ ^ REFER . \ / . \ / . \ / . \ / . \ / V V +--------+ +--------+ | | | | | User | | User | | Agent | | Agent | | A | | B | +--------+ +--------+ 図1 図1は、操作の基本モデルを示す。ユーザーエージェントAは、サーバーAと サーバーBという2つのサーバーを経由して、INVITEをユーザーエージェントB に送信する。このトランザクションでは、どちらのサーバーもプロキシとして 動作する。ユーザーBは200 OK応答をINVITEに対して送信する。200 OKには、 本仕様のサポートを示すSupportedヘッダーフィールドが含まれる(tdialogオ プションタグの指定による)。200 OK応答によって、2つのユーザーエージェン ト間でダイアログが確立する。 Rosenberg Standards Track [Page 4] RFC 4538 Target Dialog June 2006 次に、リクエストパス上にあるエンティティ(サーバーAなど)は、ダイアログ を構成するリクエスト(REFERなど)をユーザーAまたはB(ユーザーBなど)に送信 する。そのエンティティはユーザーエージェントとして動作し、リクエストを ユーザーBに送信する。このリクエストはユーザーBのURI宛てであり、そのURI は、サーバーAがINVITEリクエストの200 OKに含まれるContactヘッダーフィー ルドを調べて取得した。このURIにGRUU [11]プロパティがある場合(GRUUは、 サーバーAなどのインターネット上の要素が、特定のユーザーエージェントイ ンスタンスに到達し、INVITEに対して200 OKを生成するために使用できる)、 このメカニズムはNATの境界を越えて機能する。 サーバーAが生成したリクエストには、Target-Dialogヘッダーフィールドが含 まれる。このヘッダーフィールドには、ユーザーエージェントAとB間のINVITE ダイアログのダイアログ識別子が含まれ、Call-ID、ローカルタグ、リモート タグで構成される。サーバーAは、ユーザーエージェントBがTarget-Dialogヘ ッダーフィールドをサポートしていることを知っているため、REFERリクエス トにTarget-Dialogが含まれることも知っていた。 リクエストがユーザーエージェントBに到達すると、認可の判断を行う必要が ある。INVITEダイアログはsips URIを使用して確立されたため、またこのダイ アログ識別子は暗号的にランダム[2]なため、ユーザーAおよび最初のINVITEリ クエストのパス上にあるプロキシ以外のエンティティは、ダイアログ識別子を 知ることができない。リクエストにはダイアログ識別子が含まれるため、ユー ザーエージェントBは、ユーザーエージェントA、2つのプロキシ、またはユー ザーエージェントAかプロキシがダイアログ識別子を与えたエンティティから リクエストが来たことを確信することができる。したがって、ユーザーエージ ェントBはリクエストを認可し、要求された動作を実行する。 3. ユーザーエージェントクライアント(UAC)の動作 UACは、以下の条件がすべて真の場合、リクエストにTarget-Dialogヘッダーフ ィールドを含めるべきである[SHOULD]。 1. リクエストが既存のダイアログ外で送信されている。 2. ユーザーエージェントクライアントが、他のダイアログのダイアログ識別 子を認識していることを証明できない限り、ユーザーエージェントサー バーから認可されないと確信している。このダイアログをターゲットダイ アログと呼ぶ。 3. Target-Dialog以外に、UACがそのダイアログ識別子を認識していることを 示す情報がリクエストに含まれていない。 Rosenberg Standards Track [Page 5] RFC 4538 Target Dialog June 2006 4. ユーザーエージェントクライアントは、ユーザーエージェントサーバーが Target-Dialogヘッダーフィールドをサポートしていることを知ってい る。この情報は、ターゲットダイアログ内のユーザーエージェントサー バーからのリクエストまたは応答のSupportedヘッダーフィールドに、 tdialogオプションタグが含まれていたことから知ることができる。 4つ目の条件に適合しない場合、UACは本仕様を使用すべきではない[SHOULD NOT]。このとき、ユーザーエージェントサーバー(UAS)とのダイアログ内にあ る場合、既存のターゲットダイアログ内でリクエストの送信を試行すべきで ある[SHOULD]。 以下は、これらの条件に適合する場合の使用例である。 o REFERリクエストは[14]の原則に従って送信される。 このREFERはダイアログ外で送信され、ターゲットダイアログを認識して いることを示す他の情報は含まれない。 [14]では、UAがターゲットダイアログ仕様のサポートを示している場合に のみ、REFERを送信することも必須としている。 o ユーザーAは、ユーザーBとCに個別に通話中である。ユーザーAは三者間通 話を開始することを決定し、フォーカス[17]に変化する。ユーザーBはカン ファレンスの他の参加者について知りたい。そのため、カンファレンスイ ベントパッケージ[18]について、SUBSCRIBEリクエストをユーザーA (フォーカスとして動作)に送信する。これはユーザーBとフォーカス間の既 存のダイアログ外で送信される。また、ユーザーBが、フォーカスとの既存 のダイアログのダイアログ識別子を知っていることを証明でる場合、Aが認 可する。その結果、Target-DialogヘッダーフィールドはSUBSCRIBEに含ま れる。 以下は、これらの条件に適合しない場合の使用例である。 o プロキシとして動作するサーバーは、セッションを確立するINVITEダイア ログに参加している。サーバーは、Keypad Markup Language (KPML)イベン トパッケージ[18]を使用して、発信元ユーザーエージェントのキー押下に 関して検出したい。このために、サーバーはSUBSCRIBEリクエストを送信す る。ただし、SUBSCRIBEのEventヘッダーフィールドには、サブスクリプシ ョンのターゲットダイアログを示すイベントパラメータが含まれる。その ため、リクエストはその他の情報なしで認可することができる。 o プロキシとして動作するサーバーは、セッションを確立するINVITEダイア ログに参加している。サーバーは、ダイアログイベントパッケージ[15]を 使用して、発信元ユーザーエージェントでダイアログに関して検出した い。このために、サーバーはSUBSCRIBEリクエストを送信する。 ただし、SUBSCRIBEのEventヘッダーフィールドには、サブスクリプション のターゲットダイアログを示すイベントパラメータが含まれる。 Rosenberg Standards Track [Page 6] RFC 4538 Target Dialog June 2006 そのため、リクエストはその他の情報なしで認可することができる。 Target-Dialogヘッダーフィールドを利用する意図を持つ仕様では、含める べき具体的な条件について議論すべきである[SHOULD]。 その条件が含まれているという前提で、Target-Dialogヘッダーフィールドの callidの生成値は、ターゲットダイアログのCall-IDと一致しなければならな い[MUST]。「remote-tag」ヘッダーフィールドパラメータは指定しなければな らない[MUST]。また、新しいリクエストの受信者の観点から、リモートタグと して見られるタグを含めなければならない[MUST]。「local-tag」ヘッダーフ ィールドパラメータは指定しなければならない[MUST]。また、新しいリクエス トの受信者の観点から、ローカルタグとして見られるタグを含めなければなら ない[MUST]。 UACから送信されるリクエストには、tdialogオプションタグが指定された Requireヘッダーフィールドを含めるべきである[SHOULD]。原則として、この リクエストは420 (Bad Extension)応答で失敗することはない。これは、UAS がこの拡張をサポートするとUACが確信していない限り、UACはリクエストを 送信しないためである。Requireヘッダーフィールドが含まれず、UASがこの 拡張をサポートとしていない場合、認可されないため、リクエストは通常ど おり恐らく403で拒否される。 ただし、Requireヘッダーフィールドがない場合、UACは以下を区別できない。 o UASはTarget-Dialogヘッダーフィールドを理解していなかったために届い た403 (この場合、クライアントはできるだけターゲットダイアログ内でリ クエストを送信すべきである)。 o UASはTarget-Dialogヘッダーフィールドを理解しているが、UACがターゲッ トダイアログの認識を証明しているという事実にもかかわらず、リクエス トを認可しないように指定されているために届いた403 (この場合、クライ アントは可能な場合でもターゲットダイアログ内でリクエストを再送信す べきではない)。 4. ユーザーエージェントサーバーの動作 ユーザーエージェントサーバーがダイアログを作成するリクエストを受信し、 リクエストを認可したい場合、および送信者がUASとの既存のダイアログにつ いて認識しているかどうかに応じて認可が行われ、Target-Dialogヘッダーフ ィールド以外の情報ではこの認識を証明できない場合、UASは、Target-Dialog ヘッダーフィールドがリクエストに存在するかどうかを確認すべきである [SHOULD]。このヘッダーフィールドが存在しない場合でも、UASは他の手段を 使用してリクエストを認可してもよい[MAY]。 Rosenberg Standards Track [Page 7] RFC 4538 Target Dialog June 2006 ヘッダーフィールドが存在し、callid作成の値、「remote-tag」値、 「local-tag」値が、既存のダイアログのCall-ID、remote-tag、local-tagと 一致し、一致するダイアログがsips URIを使用して確立された場合、そのダイ アログを作成したリクエストのパス上にあるエンティティ、またはそのダイア ログを作成したリクエストのパス上にあるエンティティが信頼している任意の エンティティをUASが認可するのであれば、UASはそのリクエストを認可すべき である[SHOULD]。 ダイアログ識別子は一致しても、sips URIで作成されていないダイアログと一 致する場合、そのダイアログを作成したリクエストのパス上にあるエンティテ ィ、またはそのダイアログを作成したリクエストのパス上にあるエンティティ が信頼する任意のエンティティを認可するのであれば、UASはそのリクエスト を認可してもよい[MAY]。ただし、この場合、元のダイアログパス上に盗聴者 がいると、ダイアログ識別子にアクセスできるため、認可はオプションであ る。 ダイアログ識別子が一致しない場合、または「remote-tag」と「local-tag」 の両パラメータが含まれない場合、ヘッダーフィールドは無視しなければなら ない[MUST]。また認可は他の手段で判断してもよい[MAY]。 5. プロキシの動作 プロキシの動作は本仕様の影響を受けない。 6. 拡張性の考慮事項 本仕様は、ユーザーエージェントクライアントがユーザーエージェントサー バーにリクエストを送信する前に、UASがTarget-Dialogヘッダーフィールドを サポートするかどうかをUACが認識することに依存している。セクション3で論 じたように、UACが認識できるのは、ターゲットダイアログ内でUASから送信さ れるリクエストまたは応答に、tdialogオプションタグが指定されたSupported ヘッダーフィールドが含まれているためである。 この要件があるため、本仕様に準拠するユーザーエージェントが、ダイアログ を作成するリクエストおよび応答のすべてにSupportedヘッダーフィールドを 含めることは特に重要である。リクエストにSupportedヘッダーフィールドを 含めることは、RFC 3261に従って[SHOULD]の強さである。本仕様はこの要件を 変更しない。ただし、実装では、tdialogオプションタグがリクエストおよび 応答のSupportedヘッダーフィールドに配置されない限り、この拡張を使用す る可能性は低く、既存のターゲットダイアログ内でリクエストを再送信する可 能性が高い、ということを認識すべきである(送信者がターゲットダイアログ の外部にあるUAであるという前提で)。[SHOULD]を付けない条件は、UAがこの 拡張の使用を有効にしたくないというまれな場合である。 Rosenberg Standards Track [Page 8] RFC 4538 Target Dialog June 2006 7. ヘッダーフィールドの定義 Target-Dialogヘッダーフィールドの文法は以下のように定義される。 Target-Dialog = "Target-Dialog" HCOLON callid *(SEMI td-param) ;callid from RFC 3261 td-param = remote-param / local-param / generic-param remote-param = "remote-tag" EQUAL token local-param = "local-tag" EQUAL token ;RFC 3261のtokenとgeneric-param 図3と4は、RFC 3261 [2]の表2と3のTarget-Dialogヘッダーフィールドに関す る拡張である。「INF」列はINFOメソッド[4]、「PRA」はPRACKメソッド[5]、 「UPD」はUPDATEメソッド[6]、「SUB」はSUBSCRIBEメソッド[3]、「NOT」は NOTIFYメソッド[3]、「MSG」はMESSAGEメソッド[7]、「REF」はREFERメソッド [8]、「PUB」はPUBLISHメソッド[9]を示す。 Header field where proxy ACK BYE CAN INV OPT REG PUB Target-Dialog R - - - - o - - - 図3: Target-Dialogが許容されるメソッド Header field where proxy PRA UPD SUB NOT INF MSG REF Target-Dialog R - - - o - - - o 図4: Target-Dialogが許容されるメソッド 8. セキュリティの考慮事項 Target-Dialogヘッダーフィールドは、特定のエンティティのみがアクセス権 を持つ情報に対してリクエストの送信者がアクセス権を持つという事実に基づ いて、リクエストを認可するために使用される。このような認可の決定を保護 するために、2つの条件に適合する必要がある。 第1に、盗聴者はこの情報にアクセスできないこと。このために、元のSIPダイ アログをsips URIを使用して確立し、各ホップ上でTLSを提供する必要があ る。sips URIを使用すると、ユーザーエージェントとリクエストパス上のプロ キシのみが、ダイアログ識別子を認識できるようになる。第2の条件は、推測 できない程度にダイアログ識別子を暗号的にランダムにすることである。RFC 3261は、Call-IDのグローバルな一意性と、各タグの32ビットの暗号的なラン ダム性を必須としている(ダイアログには2つのタグがある)。一般的なダイア ログの短い継続期間(たとえば1日)であれば、推測する攻撃を回避するため Rosenberg Standards Track [Page 9] RFC 4538 Target Dialog June 2006 に、この程度のランダム性が適切と考えられる。ただし、本仕様は、RFC 4086 [11]に記載されている本当に暗号的なランダム性を必須としていることに注意 する点が重要である。疑似ランダム識別子を弱くすると衝突の可能性は減る が、推測可能なため、攻撃者が識別子の連続性を観察し、次の識別子を推測 し、本仕様を使用して攻撃を仕掛けることを回避するには十分ではない。 9. In-Reply-Toとの関係 RFC 3261はIn-Reply-Toヘッダーフィールドを定義している。このヘッダーフ ィールドは、現在のリクエストが参照する、または返す、通話のCall-IDリス トを提供する。 このヘッダーフィールドは、電子メールのRefer-Toと似た目的で機能し、ユー ザーインターフェースで対話のスレッド構築を容易にすることを意図して作成 された。Target-Dialogも、前のセッションを参照するという点で似ている。 この類似性があるため、これら2つのヘッダーフィールドを相互の代替とする ことの難しさを理解する点が重要である。 第1に、In-Reply-Toは、人間またはユーザーインターフェース機器(通話の内 容やユーザーが通話すべきかどうかについて決定できる情報を人間に提供する 機器)が使用するためのヘッダーフィールドである。 一方は、Target-Dialogは、認可がユーザーの機能ではなく基礎となるプロト コルの機能である場合に、ユーザーエージェント自体が使用してセッションリ クエストを容易に認可できるようになることを意図している。UAは、正しい値 のTarget-Dialogヘッダーフィールドに基づいて、Target-Dialogを含む通話を 認可する。 第2に、Target-Dialogは、現在進行中の特定のダイアログを参照する。 In-Reply-Toは、以前の通話試行を参照する。ほとんどの場合、ダイアログが 確立しなかった試行である。これは、In-Reply-ToはCall-IDを使用し、 Target-Dialogはダイアログ識別子のセットを使用する理由である。 最後に、In-Reply-Toは原因と結果を暗示する。In-Reply-Toが存在する場合、 配信された前のリクエストがあるため、そのリクエストが送信されたことを意 味する。Target-Dialogは原因と結果を暗示しない。単に、認可の目的につい て意識しているだけである。 10. コールフロー例 この例では、ユーザーエージェントAとユーザーエージェントBが、INVITEによ って開始されたダイアログをサーバーAとサーバーB経由で確立する。各サー バーはINVITEのプロキシとして動作する。サーバーBは、アプリケーション対 話フレームワーク[14]を使用して、ユーザーAがHTMLユーザーインターフェー スコンポーネントを取得することを要求したい。このために、ユーザーBはAの URIに対してREFERリクエストを送信する。このフローを図5に示す。長いメッ Rosenberg Standards Track [Page 10] RFC 4538 Target Dialog June 2006 セージ行の表記については、[19]の規約が使用される。 A Server-A Server-B B |(1) INVITE | | | |----------->| | | | |(2) INVITE | | | |----------->| | | | |(3) INVITE | | | |----------->| | | |(4) 200 OK | | | |<-----------| | |(5) 200 OK | | | |<-----------| | |(6) 200 OK | | | |<-----------| | | |(7) ACK | | | |------------------------------------->| | |(8) REFER | | | |<-----------| | |(9) REFER | | | |<-----------| | | |(10) 200 OK | | | |----------->| | | | |(11) 200 OK | | | |----------->| | 図5 まず、送信者はメッセージ1のようにINVITEを送信する。 INVITE sips:B@example.com SIP/2.0 Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8 From: Caller ;tag=kkaz- To: Callee Call-ID: fa77as7dad8-sd98ajzz@host.example.com CSeq: 1 INVITE Max-Forwards: 70 Supported: tdialog Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, REFER Accept: application/sdp, text/html Contact: ;schemes="http,sip,sips" Content-Length: ... Content-Type: application/sdp Rosenberg Standards Track [Page 11] RFC 4538 Target Dialog June 2006 --SDPは示さない-- INVITEは、送信者がGRUU (INVITEのContactヘッダーフィールドに指定される) とTarget-Dialogヘッダーフィールドをサポートすることを示している。この INVITEは受信者に転送され(メッセージ2〜3)、結果として200 OK応答が生成さ れ、送信者に返される(メッセージ4〜5)。メッセージ5は以下のようになる。 SIP/2.0 200 OK Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8 From: Caller ;tag=kkaz- To: Callee ;tag=6544 Call-ID: fa77as7dad8-sd98ajzz@host.example.com CSeq: 1 INVITE Contact: Content-Length: ... Content-Type: application/sdp --SDPは示さない-- この場合、受信側はGRUUまたはTarget-Dialogヘッダーフィールドをサポート していない。送信者はACKを生成する(メッセージ7)。 サーバーBは以下のREFERをユーザーAに送信する。 REFER sips:A@example.com;gruu;opaque=urn:uuid:f81d4f ae-7dec-11d0-a765-00a0c91e6bf6;grid=99a SIP/2.0 Via: SIP/2.0/TLS serverB.example.org;branch=z9hG4bK9zz10 From: Server B ;tag=mreysh To: Caller Target-Dialog: fa77as7dad8-sd98ajzz@host.example.com ;local-tag=kkaz- ;remote-tag=6544 Refer-To: http://serverB.example.org/ui-component.html Call-ID: 86d65asfklzll8f7asdr@host.example.com CSeq: 1 REFER Max-Forwards: 70 Require: tdialog Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, NOTIFY Contact: Content-Length: 0 Rosenberg Standards Track [Page 12] RFC 4538 Target Dialog June 2006 このREFERはGRUU宛てではないため、サーバーAに配信される。サーバーAから ユーザーエージェントAに転送され(メッセージ9)、Target-Dialogヘッダーフ ィールドが存在するため認可される。 11. IANA条項 本仕様は、RFC 3261 [2]の処理に従って新規のSIPヘッダーフィールドと新規 のオプションタグ、RFC 3968 [10]の処理に従って新規のヘッダーフィールド パラメータを登録する。 11.1. ヘッダーフィールド RFC番号: RFC 4538 ヘッダーフィールド名: Target-Dialog 短縮形: なし 11.2. ヘッダーフィールドパラメータ このセクションでは、RFC 3968 [10]の処理に従って2つのヘッダーフィールド パラメータを登録する。 11.2.1. local-tag ヘッダーフィールド: Target-Dialog ヘッダーフィールドパラメータ: local-tag 定義済みの値: なし RFC: RFC 4538 11.2.2. remote-tag ヘッダーフィールド: Target-Dialog ヘッダーフィールドパラメータ: remote-tag 定義済みの値: なし RFC: RFC 4538 Rosenberg Standards Track [Page 13] RFC 4538 Target Dialog June 2006 11.3. SIPオプションタグ 本仕様は、RFC 3261のセクション27.1の指針に従って、新規のSIPオプション タグを登録する。 名前: tdialog 説明: このオプションタグは、Target-Dialogヘッダーフィールド拡張を識別 するために使用される。Requireヘッダーフィールドで使用される場合、受 信者がTarget-Dialogヘッダーフィールドをサポートする必要があることを 示す。Supportedヘッダーフィールドで使用される場合、メッセージの送信 者がサポートしていることを示す。 12. 謝辞 本仕様は、ダイアログ用法のドラフト[12]でRobert Sparksが最初に提案した ヘッダーフィールドに基づいている。John Elwellからは有益なコメントをい ただいた。 13. 参考文献 13.1. 規範となる参考文献 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [4] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [5] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002. [6] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [7] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [8] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. Rosenberg Standards Track [Page 14] RFC 4538 Target Dialog June 2006 [9] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004. [10] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004. 13.2. 有益な参考文献 [11] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [12] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", Work in Progress, March 2006. [13] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Work in Progress, May 2006. [14] Rosenberg, J., "A Framework for Application Interaction in the Session Initiation Protocol (SIP)", Work in Progress, July 2005. [15] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005. [16] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Conference State", Work in Progress, July 2005. [17] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006. [18] Burger, E., "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", Work in Progress, December 2004. [19] Sparks, R., Ed., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006. Rosenberg Standards Track [Page 15] RFC 4538 Target Dialog June 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 Rosenberg Standards Track [Page 16] RFC 4538 Target Dialog June 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 Standards Track [Page 17]