Network Working Group J. Elwell Request for Comments: 4916 Siemens Enterprise Communications Limited Updates: 3261 June 2007 Category: Standards Track セッション開始プロトコル(SIP)における接続ID Connected Identity in the Session Initiation Protocol (SIP) 本文書の位置付け 本文書は、インターネットコミュニティのためのインターネット標準化過程 プロトコルを規定し、改善のための議論や提案を依頼するものである。標準 化の段階や、プロトコルの位置付けについては、最新版の"Internet Official Protocol Standards" (STD 1)を参照されたい。本文書の配信は無 制限である。 著作権表記 Copyright (C) The IETF Trust (2007). 概要 本文書は、セッション開始プロトコル(Session Initiation Protocol/SIP)の ユーザーエージェント(User Agent/UA)が、ダイアログ構成リクエスト (dialog-forming request)を受信し、反対方向のリクエストを利用して自分 のIDを相手側のUAに提示する手段を提供する。また、認証サービスによって そのIDに署名する手段も提供する。ダイアログ構成リクエストのターゲット 変更のため(Request-URI値の変更)、そのリクエストを受信するUA (ユーザー エージェントサーバー、User Agent Server/UAS)は、Toヘッダーフィールド とは異なるIDを持つ可能性がある。(たとえば、ゲートウェイの背後にある 公衆電話交換回線網(Public SwitchedTelephone Network/PSTN)における何 らかの動作などによる)ダイアログ中のID変更を示すために、同じ仕組みを 使用できる。本文書は、RFC 3261 (SIP)の規範に関して更新している。 Elwell Standards Track [Page 1] RFC 4916 SIP Connected ID June 2007 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. 用語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. ソリューションの概要 . . . . . . . . . . . . . . . . . . . . . 4 4. 動作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. 既存のダイアログのコンテキスト外でINVITE リクエストを発行するUAの動作 . . . . . . . . . . . . . . 6 4.2. 既存のダイアログのコンテキスト外でINVITE リクエストを受信するUAの動作 . . . . . . . . . . . . . . 6 4.3. 確立済みINVITEが開始したダイアログ中にIDが 変化したUAの動作 . . . . . . . . . . . . . . . . . . . . 7 4.4. 一般的なUAの動作 . . . . . . . . . . . . . . . . . . . . 7 4.4.1. ダイアログ中のリクエスト送信 . . . . . . . . . . . . 7 4.4.2. ダイアログ中のリクエスト受信 . . . . . . . . . . . . 8 4.5. 認証サービスの動作 . . . . . . . . . . . . . . . . . . . 8 4.6. ベリファイアの動作 . . . . . . . . . . . . . . . . . . . 9 4.7. プロキシの動作 . . . . . . . . . . . . . . . . . . . . . 9 5. 例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. 呼に応答後の接続IDの送信 . . . . . . . . . . . . . . . . 10 5.2. 通話中に変更された接続IDの送信 . . . . . . . . . . . . . 16 6. IANA条項 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. セキュリティの考慮事項 . . . . . . . . . . . . . . . . . . . . 21 8. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9.1. 規範となる参考文献 . . . . . . . . . . . . . . . . . . . 23 9.2. 有益な参考文献 . . . . . . . . . . . . . . . . . . . . . 23 Elwell Standards Track [Page 2] RFC 4916 SIP Connected ID June 2007 1. はじめに セッション開始プロトコル(Session Initiation Protocol/SIP) (RFC 3261 [1])は、セッションを開始するだけでなく、セッションの両端にいるパー ティのIDに関する情報も提供する。ユーザーは、SIPが開始した通信の扱い 方法を判断する上で、この情報が必要である。 呼に応答するパーティのIDは、さまざまな理由(呼の転送、呼の分散、呼の ピックアップなど)から、最初に着呼したパーティのIDと異なる可能性があ る。さらに、あるパーティが呼に応答した後、呼の転送、コールパーク、呼 の取得などの理由から、別のIDを持つ異なるパーティで置き換えられる可能 性がある。場合によっては、このようなIDを公開しない理由もあるが、こう した情報を提供する仕組みが存在する方が望ましい。 本文書は、Fromヘッダーフィールドの用法を拡張して、一般的に「接続ID」 情報(接続ユーザーのID)と呼ばれる情報を、既存のINVITEが開始したダイア ログのコンテキスト内で両方向に伝達できるようにする。以下の情報を伝達 するときに使用できるようになる。 o 呼に応答するときの発呼側に対する着呼側ID、 o 応答前の潜在的着呼側のID、または o 呼の再配置(たとえば、PSTN内や、サードパーティ呼制御技術を使用して B2BUA (back-to-back user agent)内で実行された呼の転送など)に続い て、発呼側または着呼側を置換するユーザーのID。 REFERメソッドを使用する標準的なSIPの呼転送技術の使用によって、新 しいダイアログが確立されるため、発呼側と着呼側のIDに関する通常の 仕組みが適用される。 応答の応答側ID (一般的に「応答ID(response identity)」と呼ばれる)の提 示は、本文書の範囲外である。 IDが何らかの方法で応答で伝達された場合でも、一般的に、そのUASを認 証することは困難である。別のリクエストでIDを提示することで、通常 の認証技術を使用できるようになる。 Elwell Standards Track [Page 3] RFC 4916 SIP Connected ID June 2007 2. 用語 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「MAY」、「OPTIONAL」はRFC 2119[2]の記載に従って解 釈されるべきである。 本仕様では、さらに以下の用語を定義する。 発呼側(caller): 呼を開始するINVITEリクエストを発行するUAのユーザー。 発呼側ID (caller identity): 発呼側のID (Addresses of Record)。 着呼側(callee): INVITEリクエストに対して2xx応答を発行して、呼に応答 するUAのユーザー。 着呼側ID (callee identity): 着呼側のID (Addresses of Record)。 潜在的着呼側(potential callee): 初期ダイアログを構成した結果、INVITE リクエストのターゲットとなったUAのユーザー。ただし、リクエストの パラレル分岐またはシリアル分岐のために、必ずしも呼に応答するユー ザーにはならない。 接続ユーザー(connected user): 確立済みの呼に関与するユーザー。発呼 側、着呼側、または、呼の転送といった呼の再配置によって発呼側や着 呼側を置換するユーザーを含む。 接続ID (connected identity): 接続ユーザーのID (Addresses of Record)。 3. ソリューションの概要 ダイアログ中のリクエストは接続IDの提示に使用される。リクエストのユー ザーエージェントクライアント(UAC)は、リクエストのFromヘッダーフィー ルドに自分のIDを挿入する。認証を実行するために、ダイアログ中のリクエ ストのパスで適切な認証サービスがIdentityヘッダーフィールド(RFC 4474 [3])を挿入する。UACで指定されない限り、認証サービスは、Record-Route を行い、UACを認証できるプロキシにあると期待される。 通話の応答前または応答時に、INVITEリクエストとは反対方向のリクエス トで、潜在的着呼側または着呼側のIDをそれぞれ指定することができる。応 答前に、INVITEリクエストと同じ方向のリクエストで、発呼側の変更を指定 することができる。応答後は、どちらの方向のリクエストでも、接続ユー ザーの変更を指定することができる。どの場合でも、ダイアログ(初期また は確立済み)は、このようなリクエストの送信前に確立する必要がある。 Elwell Standards Track [Page 4] RFC 4916 SIP Connected ID June 2007 このソリューションでは、リクエストにUPDATEメソッド(RFC 3311 [4])を使 用するが、場合によっては、re-INVITEメソッドを使用する。着呼側IDを送 信するには、INVITEリクエストのUAが、INVITEリクエストに対する2xx応答 の送信後で、かつACKリクエストの受信後に、UPDATEリクエストを送信する。 潜在的着呼側IDを送信するには、RFC 3262 [5]のサポートが期待される。こ の場合、INVITEリクエストのUASは、PRACKリクエストを受信して応答した後 (INVITEリクエストに対する信頼できる1xx応答を送信した後に発生する)、 UPDATEリクエストを送信する。UPDATEリクエストは、恐らく他の目的にも使 用できる。たとえば、初期ダイアログ中に、初期メディアに関するセッショ ン記述プロトコル(Session Description Protocol/SDP)のオファーと同時 に、潜在的着呼側IDを送信するときにも使用できる。確立済みの通話中に接 続IDの変更を示すには、UPDATEメソッドまたはre-INVITEメソッドを使用で きる。re-INVITEメソッドは、他の用途に必要な場合に使用される(たとえ ば、B2BUAがサードパーティ呼制御(Third Party Call Control/3PCC)技術を 使用して転送を実行する場合、UAからのSDPオファーを求めるには、SDPオ ファーなしでre-INVITEを発行する必要がある)。 このソリューションには、リクエストや応答を構成するダイアログで対応す る値と比較して、ダイアログ中のリクエストでToとFromヘッダーフィールド に含まれる(タグではなく) URIを変更する処理が必要である。ToとFromヘッ ダーフィールドのURIを変更する処理は、RFC 3261 [1]のセクション12.2.1.1 で熟考されている。 「後続のリクエスト内で最初のリクエストのToとFromフィールドのURIを 使用する処理は、RFC 2543 [6]との下位互換性のために実行されている。 RFC 2543ではダイアログ識別のためにURIを使用していた。本仕様では、 ダイアログ識別のためにタグのみを使用する。ダイアログ中のリクエス トで最初のToとFromのURIを必ず反映する処理は、本仕様以降の改版で廃 止されると予想される。」 したがって、本文書は、ダイアログ中のリクエストとその応答で最初のToと FromのURIを必ず反映する処理は廃止する。結果として、RFC 3261 [1]の変更 が制定される。本文書は、URIの変更を許容できないプロキシには備えてい ない。これは、URIの変更が長い間期待されてきたためである。URIの変更を 許容できないUAを考慮するために、Supportedヘッダーフィールドでサポー トの肯定を示す新しいオプションタグ「from-change」を導入する。このオ プションのサポートを示すターゲットに対してのみ、変更したFromヘッダー フィールドのURIを含むリクエストを送信することで、このオプションタグ をRequireヘッダーフィールドで送信する必要はなくなる。 接続IDを反映するために、ダイアログ中にFromヘッダーフィールドのURIを 変更できるようにする他に、本文書では、ダイアログ中のリクエストのFrom ヘッダーフィールドのURIで接続IDを受信したUAが、そのUAが以降に送信す Elwell Standards Track [Page 5] RFC 4916 SIP Connected ID June 2007 るダイアログ中のリクエストのToヘッダーフィールドにそのURIを使用する ことを必須とする。 ダイアログ中のリクエストのパス上に適切な認証サービスがない場合、(対応 するIdentityヘッダーフィールドがない状態で) UASは未認証の接続IDを受信 する。この処理が意味するところについては、セクション7を参照のこと。 4. 動作 4.1. 既存のダイアログのコンテキスト外でINVITEリクエストを発行するUA の動作 INVITEリクエストを発行するときに、本仕様に準拠するUAは、Supported ヘッダーフィールドに「from-change」オプションタグを含めなければなら ない[MUST]。 「from-change」オプションタグを送信しても、接続IDが以降のリクエス トで受信されることは保証されない。 4.2. 既存のダイアログのコンテキスト外でINVITEリクエストを受信するUA の動作 INVITEリクエストの受信後に、本仕様に準拠するUAは、すべてのダイアログ 構成応答のSupportedヘッダーフィールドに「from-change」オプションタグ を含めなければならない[MUST]。 「from-change」オプションタグを送信しても、発呼側が変更されたとき に接続IDが受信されることは保証されない。 初期ダイアログの構成後に、「from-change」オプションタグをSupported ヘッダーフィールドで受信した場合、UAは同じダイアログでUPDATEリクエス トを発行してもよい[MAY](RFC 3311 [4])。ただし、INVITEリクエストに対 する信頼できる暫定応答を送信し、PRACKリクエストを受信して応答したと いう前提に限る。完全なダイアログが構成された後(INVITEリクエストに対 する2xx最終応答が送信された後)、「from-change」オプションタグを Supportedヘッダーフィールドで受信し、UPDATEリクエストが初期ダイアロ グでまだ送信されていない場合、UAは同じダイアログでUPDATEリクエストを 発行しなければならない[MUST]。いずれの場合でも、UPDATEリクエストには 着呼側(または潜在的着呼側)のIDをFromヘッダーフィールドのURI (または、 匿名性が必要な場合は匿名のID)に含めなければならない[MUST]。 URIが、INVITEリクエストのToヘッダーフィールドのURIと同じ場合でも、 認証サービスは、新しいリクエストを送信することで、このIDの認証を Elwell Standards Track [Page 6] RFC 4916 SIP Connected ID June 2007 アサートし、INVITEリクエストのToヘッダーフィールドURIのIDと接続ID が同じであることを相手側のUAに確認する。 4.3. 確立済みINVITEが開始したダイアログ中にIDが変化したUAの動作 INVITEが開始したダイアログ中に「from-change」オプションタグを Supportedヘッダーフィールドで受信した場合で、かつUAに関連付けられた IDが、そのUAから送信されたリクエストのFromヘッダーフィールドに指定さ れた最後のIDと比較して変わっている場合、UAは、Fromヘッダーフィールド のURIに新しいID (または、匿名性が必要な場合、匿名のID)を含む同じダイ アログでリクエストを発行しなければならない[MUST]。この目的のために、 UAは、他の理由からre-INVITEメソッドを同時に使用する場合を除き、UPDATE メソッドを使用しなければならない[MUST]。 4.4. 一般的なUAの動作 4.4.1. ダイアログ中のリクエスト送信 ダイアログ中のリクエストを送信するときに、FromヘッダーフィールドURI を作成する場合、UAは、(匿名性を達成する準備を含め)RFC 4474 [3]の要件 を監視しなければならない[MUST]。 これによって、ダイアログ中のリクエストのパス上にある認証サービス がIdentityヘッダーフィールドを挿入できるようになる。 ダイアログ中のリクエストを送信するときに、UAは、そのダイアログのリ モートURIの現在の値を使用して、ToヘッダーフィールドURIを作成しなけれ ばならない[MUST]。ただし、RFC 3261 [1]に従ってダイアログの開始時に固 定されたURIではなく、本文書のセクション4.4.2の規則に従って更新すると いう前提がある。 修正された(つまり、このダイアログで前のリクエストのFromヘッダー フィールド、またはリクエストが送信されていない場合に受信したダイアロ グ構成INVITEリクエストのToフィールドで送信されたURIと比較して修正さ れた) FromヘッダーフィールドURIを使用してリクエストを送信した後、 UAは、IDの変更が再度発生しない限り、以降のすべてのリクエストのFrom ヘッダーフィールドに同じURIを同じダイアログで送信しなければならな い[MUST]。 また、UAは、以降のダイアログ中のリクエストで、修正したURIを受信でき るように備えなければならない[MUST]。さらに、少なくともToヘッダー フィールドに修正したURIを含むリクエストを受信するまで、古いURIを受信 し続けるように備えなければならない。 ダイアログ中のリクエストは、UASが接続IDを受け入れない場合、RFC 4474 [3]に従って拒否できる。UACが、ダイアログ中のリクエストに対して428、 436、437、または438応答を受信した場合、ダイアログを終了するリクエス トの場合にはそのダイアログを終了済みと見なすべきである[SHOULD]。また Elwell Standards Track [Page 7] RFC 4916 SIP Connected ID June 2007 他のリクエストの場合にはアクションを実行しないべきである[SHOULD]。 リクエストを繰り返す試行、または他のダイアログ中のリクエストを送 信する試行は、同じ応答になる可能性が高い。これは、UAは認証サービ スの動作を制御できないためである。 4.4.2. ダイアログ中のリクエスト受信 UAが相手側のUAからダイアログ中のリクエストを受信した場合、UAはFrom ヘッダーフィールドURIのIDを利用することができる(ユーザーに示すなどの 方法で)。UAは、署名付きIDと署名なしのIDを区別してもよい[MAY]。署名付 きIDの場合、UAは、リクエストのパス上にあるベリファイア(セクション4.6 を参照)の存在を当てにできない場合、ベリファイアを呼び出すべきである [SHOULD]。 UAが相手側のUAからダイアログ中のリクエストを受信し、そのFromヘッダー フィールドURIが、同じダイアログの以前のリクエストで受信したURI、また は最初のINVITEリクエストのToヘッダーフィールドで送信したURIと異なる 場合で、かつUAが2xx応答を送信する場合、UAは、RFC 3261 [1]の定義に 従って、このダイアログのリモートURIを更新しなければならない[MUST]。 この結果、UAが送信する以降のリクエストのToヘッダーフィールドには、セ クション4.4.1の規則に従って、新しい値が使用されるようになる。その他 の最終応答が送信された場合、UAはこのダイアログのリモートURIを更新し てはならない[MUST]。 4.5. 認証サービスの動作 認証サービスは、ダイアログ中のリクエストを処理する場合、RFC 4474 [3] に従って動作しなければならない[MUST]。 RFC 4474は、FromヘッダーフィールドのIDが、UACがアサートできるIDで はない場合の動作は規定していないため、Identityヘッダーフィールド がない場合にリクエストを拒否するか転送するかについてはローカルポ リシーの問題である。 ダイアログ中のリクエストに関するポリシーと他のリクエストに関する ポリシーは別にすることができる。 UAが本仕様に準拠する場合、認証サービスは(通常の認証規則に従って)、 リクエストの送信者をFromヘッダーフィールドで識別されたエンティ ティであると認証することができる。そのため、このIDの署名を提示す ることができる。この点は本仕様をサポートしないUAとは対照的である。 サポートしない場合、ターゲット変更とダイアログ中のID変更によって、 リクエストの送信者を識別する手段としてはFromヘッダーフィールドが 不正確になる可能性がある。 Elwell Standards Track [Page 8] RFC 4916 SIP Connected ID June 2007 4.6. ベリファイアの動作 ダイアログ中のリクエストを処理する際に、認証サービスは、以下のよう にRFC 4474 [3]に従って動作しなければならない[MUST]。 RFC 4474 [3]は、リクエストにIdentityヘッダーフィールドがない場合、428 (Use Identity Header)応答でリクエストを拒否するかどうかはポリシーの問 題であると述べている。UAは、ダイアログ中のリクエストと他のリクエスト に関して異なるポリシーを採用してもよい[MAY]。 4.7. プロキシの動作 ダイアログ中のリクエストを受信するプロキシは、ToヘッダーフィールドURI およびFromヘッダーフィールドURIと、ダイアログ構成リクエストおよび応 答に表示されたURIとを区別できるように備えなければならない[MUST]。 ダイアログ中のリクエスト向けに認証サービスを提供できるプロキシは、UAC からプロキシによって受信されたダイアログ構成リクエストで Supported: from-changeが指定された場合、Record-Routeしなければならな い[MUST]。 5. 例 以下の例では、いくつかのメッセージは72文字を超え、本来は行を折り返さ ないものがある。これらの行はタグで囲んで引用している。(ラインフィー ドやキャリッジリターンを削除して)タグ間に記載されているすべての行を 直接連結することで、1つの折り返しのない行が再構築される。 例では、domain example.comが以下のプライベートキー(PEM形式でレンダリ ング)を持っているという前提である。このプライベートキーは、認証サー ビスがIdentityヘッダーフィールドに署名を生成するときに使用される。 Elwell Standards Track [Page 9] RFC 4916 SIP Connected ID June 2007 -----BEGIN RSA PRIVATE KEY----- MIICXQIBAAKBgQDPPMBtHVoPkXV+Z6jq1LsgfTELVWpy2BVUffJMPH06LL0cJSQO aIeVzIojzWtpauB7IylZKlAjB5f429tRuoUiedCwMLKblWAqZt6eHWpCNZJ7lONc IEwnmh2nAccKk83Lp/VH3tgAS/43DQoX2sndnYh+g8522Pzwg7EGWspzzwIDAQAB AoGBAK0W3tnEFD7AjVQAnJNXDtx59Aa1Vu2JEXe6oi+OrkFysJjbZJwsLmKtrgtt PXOU8t2mZpi0wK4hX4tZhntiwGKkUPC3h9Bjp+GerifP341RMyMO+6fPgjqOzUDw +rPjjMpwD7AkcEcqDgbTrZnWv/QnCSaaF3xkUGfFkLx5OKcRAkEA7UxnsE8XaT30 tP/UUc51gNk2KGKgxQQTHopBcew9yfeCRFhvdL7jpaGatEi5iZwGGQQDVOVHUN1H 0YLpHQjRowJBAN+R2bvA/Nimq464ZgnelEDPqaEAZWaD3kOfhS9+vL7oqES+u5E0 J7kXb7ZkiSVUg9XU/8PxMKx/DAz0dUmOL+UCQH8C9ETUMI2uEbqHbBdVUGNk364C DFcndSxVh+34KqJdjiYSx6VPPv26X9m7S0OydTkSgs3/4ooPxo8HaMqXm80CQB+r xbB3UlpOohcBwFK9mTrlMB6Cs9ql66KgwnlL9ukEhHHYozGatdXeoBCyhUsogdSU 6/aSAFcvWEGtj7/vyJECQQCCS1lKgEXoNQPqONalvYhyyMZRXFLdD4gbwRPK1uXK Ypk3CkfFzOyfjeLcGPxXzq2qzuHzGTDxZ9PAepwX4RSk -----END RSA PRIVATE KEY----- 5.1. 呼に応答後の接続IDの送信 この例では、プロキシにおけるターゲット変更によってCarolのUAに到達し たため、CarolのID (AoR)は、受信したINVITEリクエストのToヘッダーフィー ルドのID (Bob)と一致しない。CarolのUAは、UPDATEリクエストのFromヘッ ダーフィールドでCarolのIdentityを伝達している。また、プロキシは、認 証サービスも提供しているため、IdentityとIdentity-Infoヘッダーフィー ルドをUPDATEリクエストに追加する。 AliceのUA プロキシ+ CarolのUA 認証 サービス INVITE(1) INVITE(2) ----------------> ----------------> 200(4) 200(3) <---------------- <---------------- ACK(5) ACK(6) ----------------> ----------------> UPDATE(8) UPDATE(7) <---------------- <---------------- 200(9) 200(10) ----------------> ----------------> Elwell Standards Track [Page 10] RFC 4916 SIP Connected ID June 2007 INVITE (1): INVITE sip:Bob@example.com SIP/2.0 Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8 To: Bob From: Alice ;tag=13adc987 Call-ID: 12345600@ua1.example.com CSeq: 1 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE Supported: from-change Contact: Content-Type: application/sdp Content-Length: 154 v=0 o=UserA 2890844526 2890844526 IN IP4 ua1.example.com s=Session SDP c=IN IP4 ua1.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Elwell Standards Track [Page 11] RFC 4916 SIP Connected ID June 2007 INVITE (2): INVITE sip:Carol@ua2.example.com SIP/2.0 Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhds Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2. 1 To: Bob From: Alice ;tag=13adc987 Call-ID: 12345600@ua1.example.com CSeq: 1 INVITE Max-Forwards: 69 Date: Thu, 21 Feb 2002 13:02:03 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE Supported: from-change Contact: Record-Route: Identity: "xN6gCHR6KxGM+nyiEM13LcWgAFQD3lkni1DPkwgadxh4BB7G+VwY1 3uRv5hbCI2VSvKuZ4LYN0JNoe7v8VAzruKMyi4Bi4nUghR/fFGBrpBSjztmfffLT p6SFLxo9XQSVrkm1O4c/4UrKn2ejRz+5BULu9n9kWswzKDNjlYlmmc=" Identity-Info: ;alg=rsa-sha1 Content-Type: application/sdp Content-Length: 154 v=0 o=UserA 2890844526 2890844526 IN IP4 ua1.example.com s=Session SDP c=IN IP4 ua1.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Elwell Standards Track [Page 12] RFC 4916 SIP Connected ID June 2007 200 (3): SIP/2.0 200 OK Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhds;received=192. 0.2.2 Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2. 1 To: Bob ;tag=2ge46ab5 From: Alice ;tag=13adc987 Call-ID: 12345600@ua1.example.com CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE Supported: from-change Contact: Record-Route: Content-Type: application/sdp Content-Length: 154 v=0 o=UserB 2890844536 2890844536 IN IP4 ua2.example.com s=Session SDP c=IN IP4 ua2.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 200 (4): SIP/2.0 200 OK Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2. 1 To: Bob ;tag=2ge46ab5 From: Alice ;tag=13adc987 Call-ID: 12345600@ua1.example.com CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE Supported: from-change Contact: Record-Route: Content-Type: application/sdp Content-Length: 154 Elwell Standards Track [Page 13] RFC 4916 SIP Connected ID June 2007 v=0 o=UserB 2890844536 2890844536 IN IP4 ua2.example.com s=Session SDP c=IN IP4 ua2.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ACK (5): ACK sip:carol@ua2.example.com SIP/2.0 Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9 From: Alice ;tag=13adc987 To: Bob ;tag=2ge46ab5 Call-ID: 12345600@ua1.example.com CSeq: 1 ACK Max-Forwards: 70 Route: Content-Length: 0 ACK (6): ACK sip:carol@ua2.example.com SIP/2.0 Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdt Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9;received=192.0.2. 1 From: Alice ;tag=13adc987 To: Bob ;tag=2ge46ab5 Call-ID: 12345600@ua1.example.com CSeq: 1 ACK Max-Forwards: 69 Content-Length: 0 UPDATE (7): UPDATE sip:Alice@ua1.example.com SIP/2.0 Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1 From: Carol ;tag=2ge46ab5 To: Alice ;tag=13adc987 Call-ID: 12345600@ua1.example.com CSeq: 2 UPDATE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:15 GMT Route: Contact: Content-Length: 0 Elwell Standards Track [Page 14] RFC 4916 SIP Connected ID June 2007 Note that the URI in the From header field differs from that in the To header field in the INVITE request/response. However, the tag is the same as that in the INVITE response. UPDATE (8): UPDATE sip:Alice@ua1.example.com SIP/2.0 Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdu Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2. 3 From: Carol ;tag=2ge46ab5 To: Alice ;tag=13adc987 Call-ID: 12345600@ua1.example.com CSeq: 2 UPDATE Max-Forwards: 69 Date: Thu, 21 Feb 2002 13:02:15 GMT Contact: Identity: "g8WJiVEzrbYum+z2lnS3pL+MIhuI439gDiMCHm01fwX5D8Ft5Ib9t ewLfBT9mDOUSn6wkPSWVQfqdMF/QBPkpsIIROIi2sJOYBEMXZpNrhJd8/uboXMl9 KRujDFQefZlmXV8dwD6XsPnMgcH8jAcaZ5aS04NyfWadIwTnGeuxko=" Identity-Info: ;alg=rsa-sha1 Content-Length: 0 200 (9): SIP/2.0 200 OK Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdu;received=192. 0.2.2 Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2. 3 From: Carol ;tag=2ge46ab5 To: Alice ;tag=13adc987 Call-ID: 12345600@ua1.example.com CSeq: 2 UPDATE Contact: Content-Length: 0 Elwell Standards Track [Page 15] RFC 4916 SIP Connected ID June 2007 200 (10): SIP/2.0 200 OK Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2. 3 From: Carol ;tag=2ge46ab5 To: Alice ;tag=13adc987 Call-ID: 12345600@ua1.example.com CSeq: 2 UPDATE Contact: Content-Length: 0 5.2. 通話中に変更された接続IDの送信 この例では、AliceとBob間に呼が確立している。Bob (図には非表示)はB2BUA の背後にいる。BobのIdentityはUPDATEリクエストで伝達される。次に、 B2BUAは、RFC 3725 [7]に従って、サードパーティ呼制御(3PCC)技術を使用し て呼の転送を実行する(たとえば、クリックトゥーダイヤルアプリケーション の制御を受けて)。結果として、AliceはCarol (図には非表示)に接続し、 re-INVITEリクエストが発行されて、セッションの再ネゴシエートが可能に なる。 B2BUAは認証サービスを提供しているため、INVITEリクエストのIdentityヘッ ダーフィールドを生成して、CarolのIDを認証している。 Elwell Standards Track [Page 16] RFC 4916 SIP Connected ID June 2007 AliceのUA B2BUA INVITE(1) ----------------> 200(2) <---------------- ACK(3) ----------------> UPDATE(4) <---------------- 200(5) ----------------> re-INVITE(6) <---------------- 200(7) ----------------> ACK(8) <--------------- INVITE (1): INVITE sip:Bob@example.com SIP/2.0 Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8 To: Bob From: Alice ;tag=13adc987 Call-ID: 12345600@ua1.example.com CSeq: 1 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE Supported: from-change Contact: Content-Type: application/sdp Content-Length: 154 Elwell Standards Track [Page 17] RFC 4916 SIP Connected ID June 2007 v=0 o=UserA 2890844526 2890844526 IN IP4 ua1.example.com s=Session SDP c=IN IP4 ua1.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 200 (2) SIP/2.0 200 OK Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2. 1 To: Bob ;tag=2ge46ab5 From: Alice ;tag=13adc987 Call-ID: 12345600@ua1.example.com CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE Supported: from-change Contact: Content-Type: application/sdp Content-Length: 154 v=0 o=UserB 2890844536 2890844536 IN IP4 ua2.example.com s=Session SDP c=IN IP4 ua2.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ACK (3) ACK sip:xyz@b2bua.example.com SIP/2.0 Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9 From: Alice ;tag=13adc987 To: Bob ;tag=2ge46ab5 Call-ID: 12345600@ua1.example.com CSeq: 1 ACK Max-Forwards: 70 Content-Length: 0 Elwell Standards Track [Page 18] RFC 4916 SIP Connected ID June 2007 UPDATE (4) UPDATE sip:alice@ua1.example.com SIP/2.0 Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdt1 From: Bob ;tag=2ge46ab5 To: Alice ;tag=13adc987 Call-ID: 12345600@ua1.example.com CSeq: 2 UPDATE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:12 GMT Contact: Identity: "AQFLSjCDRhO2eXlWmTajk99612hkJii9giDMWki5uT6qc4BrekywO UuObcwZI3qhJReZCN7ybMBNYFZ5yFXWdyet4j3zLNCONU9ma+rs8ZOv0+z/Q3Z5c D26HrmitU+OCKWPLObaxbkGQry9hQxOmwRmlUgSjkeCEjgnc1iQc3E=" Identity-Info: ;alg=rsa-sha1 Content-Length: 0 200 (5) SIP/2.0 200 OK Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdt1;received=192.0. 2.2 From: Bob ;tag=2ge46ab5 To: Alice ;tag=13adc987 Call-ID: 12345600@ua1.example.com CSeq: 2 UPDATE Contact: Content-Length: 0 Elwell Standards Track [Page 19] RFC 4916 SIP Connected ID June 2007 re-INVITE (6) INVITE sip:alice@ua1.example.com SIP/2.0 Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxy From: Carol ;tag=2ge46ab5 To: Alice ;tag=13adc987 Call-ID: 12345600@ua1.example.com CSeq: 3 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:03:20 GMT Contact: Identity: "KCd3YLQHj51SlCQhFMnpQjmP6wHh7JGRO8LsB4v5SGEr/Mwu7j6Gp al8ckVM2vd1zqH/F4WJXYDlB525uuJm/fN3O1A2xsZ9BxRkh4N4U19TL9I2Tok3U 3kGg8To/6w1mEXpUQjo3OgNYqOBtawHuZI5nrOVaV3IrbQh1b2KgLo=" Identity-Info: ;alg=rsa-sha1 Content-Length: 0 200 (7) SIP/2.0 200 OK Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxy;received=192.0. 2.2 From: Carol ;tag=2ge46ab5 To: Alice ;tag=13adc987 Call-ID: 12345600@ua1.example.com CSeq: 3 INVITE Contact: Content-Length: 154 v=0 o=UserA 2890844526 2890844526 IN IP4 ua1.example.com s=Session SDP c=IN IP4 ua1.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Elwell Standards Track [Page 20] RFC 4916 SIP Connected ID June 2007 ACK (8) ACK sip:alice@ua1.example.com SIP/2.0 Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxz From: Carol ;tag=2ge46ab5 To: Alice ;tag=13adc987 Call-ID: 12345600@ua1.example.com CSeq: 3 ACK Max-Forwards: 70 Content-Length: 154 v=0 o=UserC 2890844546 2890844546 IN IP4 ua3.example.com s=Session SDP c=IN IP4 ua3.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 6. IANA条項 本仕様は、RFC 3261 [1]のセクション27.1の指針に従って、新規のSIPオプ ションタグを登録する。 本文書は、SIPオプションタグ「from-change」を定義する。 以下の行は、「SIP Parameter Registry」の「Option Tags」セクションに 追加された。 +------------+------------------------------------------+-----------+ | 名前 | 説明 | 参考文献 | +------------+------------------------------------------+-----------+ | from-change| このオプションタグは、ダイアログ中のFrom | [RFC4916] | | | およびToヘッダーフィールドに含まれるURI | | | | の変更をUAがサポートすることを示すときに | | | | 使用される。 | | +------------+------------------------------------------+-----------+ 7. セキュリティの考慮事項 RFC 4474 [3]では、Identityヘッダーフィールドに関するセキュリティの考 慮事項が少し詳しく論じられている。ダイアログ中のリクエストのFromヘッ ダーフィールドURIに含まれる接続IDを認証するために、Identityヘッダー フィールドを使用する場合にも、同じ考慮事項が適用される。 このリクエストまたは同じダイアログの初期リクエストで有効なIdentity ヘッダーフィールド(または他の認証手段)を受信していない場合、ダイアロ グ中のリクエストで受信したFromヘッダーフィールドURIは信用できない(た Elwell Standards Track [Page 21] RFC 4916 SIP Connected ID June 2007 だし、非常に閉じた環境の場合を除く)。また、有効なIdentityヘッダー フィールドによって証明されていないダイアログ開始リクエストのFromヘッ ダーフィールドと同様に扱うことが期待される。ただし、Identityヘッダー フィールドが見つからないという根拠で、ダイアログ中のリクエストを拒否 しないことが推奨される(これは、進行中の通話操作を妨げるためである)。 有効なIdentityヘッダーフィールドがないことで、ユーザーに与える情報に 影響が出る可能性がある。ポリシーまたはユーザー設定で指定している場 合、UAは呼をクリアすることができる。 ダイアログ中のリクエストに含まれる署名付きの接続ID (有効なIdentity ヘッダーフィールドも指定されたFromヘッダーフィールドのURI)は、ダイア ログの相手側UAに関する情報を提供する。ダイアログ構成リクエストのUAS だったUAの場合、このIDは、ダイアログ構成リクエストのToヘッダーフィー ルドのIDと必ずしも同じではない。これは、ダイアログ構成リクエストの ルーティング中にターゲット変更が発生したためである。署名付きの接続 IDは、こうしたターゲット変更の正当性に関して何も示さない。ターゲット 変更の結果を単に反映しているだけである。履歴情報(RFC 4244 [8])は、接 続ユーザーに到達する方法について追加のヒントを提供することができる。 同様に、署名付き接続IDがダイアログ中のID変更を示す場合、こうしたIDの 変更や正当性の理由に関する情報は伝達しない。 呼の確立時でも、通話中でも、sips URIスキームを使用することで、不適切 な接続ID情報が送信される可能性を最小限に抑えることができる。 接続UAのユーザーは、匿名性を要求することができる。匿名性については、 UAが、RFC 4474 [3]に従って、ダイアログ中のリクエストのFromヘッダー フィールドにURIを作成することが期待されている。 8. 謝辞 Francois Audet、Frank Derks、Steffen Fries、Vijay Gurbani、Cullen Jennings、Paul Kyzivat、Hans Persson、Jon Peterson、Eric Rescorla、 Jonathan Rosenberg、Shida Schubert、Ya-Ching Tan、Dan Wingの各氏か ら、貴重なコメントをいただいたことに感謝を述べたい。 Elwell Standards Track [Page 22] RFC 4916 SIP Connected ID June 2007 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] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [4] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, September 2002. [5] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in the Session Initiation Protocol (SIP)", RFC 3262, June 2002. 9.2. 有益な参考文献 [6] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [7] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", RFC 3725, June 2002. [8] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005. 著者の連絡先 John Elwell Siemens Enterprise Communications Limited Technology Drive Beeston, Nottingham NG9 1LA UK Phone: +44 115 943 4989 EMail: john.elwell@siemens.com Elwell Standards Track [Page 23] RFC 4916 SIP Connected ID June 2007 完全な著作権表記 Copyright (C) The IETF Trust (2007). 本文書は、BCP 78に含まれる権利、ライセンス、制限の対象となり、BCP 78 に記載されている例外に従い、著者はすべての権利を持つ。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄稿 者が代表となる組織、または寄稿者を後援する組織(存在する場合)、イン ターネット協会、IETF TSUST、およびIETFは、この情報がいかなる権利も侵 害していないという保証、商用利用および特定目的への適合性への保証を 含め、また、これらだけに限らずすべての保証について、明示的もしくは暗 黙的の保証は行われない。 知的所有権 IETFは、本文書で記述される技術の実装または使用に関して要求される、知 的所有権または他の諸権利の有効性または範囲に関して、またはこのような 権利下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何 ら見解を持たない。このような権利を確認する独自の取り組みを行ったこと も示さない。RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79 に記載されている。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセ ンスの保証すべて、またはこのような所有権の使用に関して、本仕様の実装 者またはユーザーが一般的なライセンスまたは許可の取得を試みた結果につ いては、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能 である。 IETFは、この規格を実装するために必要とされる技術の範囲にある可能性が ある、すべての著作権、特許または特許アプリケーション、あるいは他の所 有権について、すべての関連団体に対して配慮するよう依頼している。情 報は、IETF (ietf-ipr@ietf.org)宛てに送信していただきたい。 謝辞 RFC編集職務のための資金は、現在、インターネット協会によって提供され ている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2008年 ----------------------------------------------------------------------- Elwell Standards Track [Page 24]