Network Working Group M. Barnes, Ed. Request for Comments: 4244 Nortel Category: Standards Track November 2005 リクエスト履歴情報のためのセッション開始プロトコル(SIP)拡張 An Extension to the Session Initiation Protocol (SIP) for Request History Information 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準ト ラックプロトコルを規定するものであり、改善のための議論や提案を依頼す るものである。標準化の段階や、プロトコルの位置付けについては、最新版 の"Internet Official Protocol Standards" (STD 1)を参照されたい。この 文書の配信は無制限である。 著作権表記 Copyright (C) The Internet Society (2005). 概要 本文書は、セッション開始プロトコル(Session Initiation Protocol/SIP) リクエストに関する履歴情報を収集する標準的な仕組みを定義する。この機 能によって、特定のアプリケーションまたはユーザーに呼が到達した方法や 理由に関する情報が提供されるため、多くの強化サービスが可能になる。本 文書は新たにオプションのSIPヘッダーであるHistory-Infoを定義する。こ のヘッダーはリクエストの履歴情報を収集する。 目次 1. はじめに ........................................................2 1.1. 概要 ..........................................................2 1.2. 本文書で使用される規約 ........................................3 1.3. 背景: 汎用的な「リクエスト履歴」機能を定義する理由 ............3 2. 「リクエスト履歴」の要件 ........................................4 2.1. セキュリティの要件 ............................................6 2.2. プライバシー要件 ..............................................7 3. リクエスト履歴情報の説明 ........................................7 3.1. History-Infoの選択性 ..........................................8 3.2. History-Infoの保護 ............................................8 3.3. History-Infoのプライバシ確保 ..................................9 4. リクエスト履歴情報プロトコルの詳細 ..............................9 4.1. History-Infoのプロトコル構造 .................................10 4.2. プロトコルの例 ...............................................11 4.3. プロトコルの用法 .............................................12 4.3.1. ユーザーエージェントクライアント(UAC)の動作:................12 4.3.2. ユーザーエージェントサーバー(UAS)の動作 ....................13 4.3.3. プロキシの動作 .............................................13 4.3.4. リダイレクトサーバーの動作 .................................18 4.4. History-Infoのセキュリティ ...................................18 4.5. History-Infoを使用するアプリケーション例 .....................19 4.5.1. Proxy2におけるリクエスト全体のPrivacy...................... ヘッダーフィールドの例 .....................................21 4.5.2. Proxy2における特定URI (UA4)のPrivacy...................... ヘッダーフィールドの例 .....................................22 5. アプリケーションの考慮事項 .....................................24 6. セキュリティの考慮事項 .........................................25 7. IANA条項 .......................................................25 7.1. 新規のSIP History-Infoヘッダーフィールドの登録 ...............25 7.2. SIP Privacyヘッダーフィールドの「history」の登録 .............26 8. 規範となる参考文献 .............................................26 9. 有益な参考文献 .................................................26 10. 謝辞 ..........................................................26 11. 寄稿者の連絡先 ................................................27 付録 シナリオ例 ..................................................28 付録A. シーケンシャルなフォーク(応答におけるHistory-Info).......28 付録B. 音声メール ..............................................34 付録C. 自動通話分散の例 ........................................39 付録D. リダイレクトサーバーとプロキシサーバー経由のセッション ..41 1. はじめに 1.1. 概要 SIPがサポートすることを期待されている多くのサービスでは、特定のアプ リケーションに呼が到達した理由と方法を判断する機能が必要である。 このようなサービスには、たとえば、Webページでクリックすると通話できる SIP URL (Uniform Resource Locators)経由でコールセンターに発信するセッ ション、SIPユーザーエージェント(UA)の「通話管理」インテリジェントソ フトウェア内で「通話履歴/ログ」形式のサービス、音声メールサーバーへ の発呼などがある。SIPは、呼を指定したアプリケーションにルートすると いうリダイレクト/リターゲットの機能を暗黙的に備えているが、このよう なリクエストの履歴を通信する標準的な仕組みは、現在のところSIP内には ない。この「リクエスト履歴」情報によって、受信側アプリケーションは、 呼がアプリケーション/ユーザーに到達した方法と理由に関するヒントを判 断することができる。 本文書では、新しいSIPヘッダーであるHistory-Infoを定義する。 History-Infoは、リクエスト履歴情報を収集する標準的な仕組みを備える。 History-Infoを使用することで、ネットワークやエンドユーザー向けの多様 なサービスが可能になる。History-Infoヘッダーを利用することで、新しい サービスを開発する際の基礎を構築することができる。 Barnes Standards Track [Page 2] RFC 4244 SIP Request History Information November 2005 セクション1.3では、リクエスト履歴機能の背景にある理由についてさらに詳 しく説明する。セクション2ではソリューションの要件を特定し、セクション 3ではソリューションの概要を説明する。 セクション4では、SIPプロトコルへの追加事項の詳細を説明する。 セクション4と5で新しいヘッダーの使用例を説明する。その他のシナリオに ついては付録で紹介する。 セクション5では、前の各セクションで挙げられたアプリケーションの考慮 事項をまとめる。セクション6では、セキュリティのソリューションをまと める。 1.2. 本文書で使用される規約 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、 「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、 「OPTIONAL」はRFC 2119 [RFC2119]に記載されるとおりに解釈されるべきで ある。 1.3. 背景: 汎用的な「リクエスト履歴」機能を定義する理由 SIPには、特定のアプリケーションに呼をルーティングすることができる、暗 黙的なリダイレクト/リターゲット(redirect/retarget)機能がある([RFC3261 ]で定義)。以降、本文書では「リターゲット」という用語を、リクエストで URI(Uniform Resource Identifier)を変更し、それによってリクエストをリ ターゲットするプロキシサーバー/ユーザーエージェントクライアント(UAC) の処理を指すときに使用する。リターゲットという用語を選択した理由は、 元のリクエストの送信先を代替URIに変更することを要求したUACに対して、 応答を返信するという、特定のSIPリダイレクトサーバー機能のみにこのリ クエスト履歴を関連付けることを防ぐためである。リクエスト対象を決定す る規則([RFC3261]のセクション16.5参照)は、本文書で使用する用語「リター ゲット」の用法と一致する。 リクエスト履歴が作成された理由は、リターゲットの処理で、古いルーティ ング情報が永久に失われる可能性があるためである。この損失情報は、呼の リターゲット先である要素が、ローカル定義のアプリケーション固有の方法 で呼を処理できるようにする重要な履歴だった可能性もある。本文書の提案 は、リクエスト履歴を送信する仕組みを実現することである。プロキシまた はUAが情報の受信時に取るアプリケーション固有の動作を提案するものでは ない。実際のところ、このような動作は受信アプリケーションのローカルで 判断すべき事柄である。 現在のネットワークアプリケーションには、呼が特定の送信先にルーティン グされた方法と理由に関する追加情報を呼に関与する要素が交換する機能が ある。このようなアプリケーションの例を次に示す。 Barnes Standards Track [Page 3] RFC 4244 SIP Request History Information November 2005 1. Webサーバー内にあるアプリケーションであるWeb「照会(referral)」アプ リケーションは、Webサイトの訪問者が「関連」サイト経由でアクセスし たことを判断し、そのトラフィック発生について何らかの「照会」手数 料を関連サイトに渡す。 2. 電子メールの転送によって、転送を受けたユーザーは、誰が誰宛てにいつ 電子メールを送信したかという「履歴」を受信する。 3. 従来の電話サービスには、音声メール、コールセンターの「自動通話分 散」、「ガイダンス」形式のサービスなどがある。 上記のアプリケーションの一部は、必要な履歴情報を取得可能なアプリケー ション固有の仕組みを定義している。 さらに、リクエスト履歴情報を使用し、次のような機能によって基本的なSIP 機能を強化するアプリケーションもある。 o SIPリクエストをデバッグする一部の診断情報(この仕組みの診断ユーティ リティは、リターゲットを実行するエンティティがそのユーティリティを 使用することはオプションなので、制限があるということに注意)。 o SIPのセキュリティソリューションの強化。副作用として、「リクエスト 履歴」情報を安全な方法で取得する各プロキシは、(署名済みキーがなく ても)元のリクエスト送信者がリクエストのリターゲットが正常に実行さ れたことを確認できる、という追加の手段を実現する。 2. 「リクエスト履歴」の要件 次に、「リクエスト履歴」機能の要件を構成する一覧を示す。 1) 機能(CAPABILITY)要件: 「リクエスト履歴」機能には、リクエストの処 理に関与するプロキシとUAに対して、そのリクエストの履歴/進行につい て通知する機能がある。リターゲットがSIPリダイレクトへの応答に対す るものである場合にはこの機能は本質的に備わっているが、リダイレク トではないリターゲットのシナリオでも有効と考えられる。 2) 選択性(OPTIONALITY)要件: 「リクエスト履歴」情報はオプションである。 2.1) 多くの場合、履歴がリクエストに追加されたかどうかは、特定のア プリケーションが実行するローカルポリシーの判断による。そのた め、特定のプロトコル要素は必要ない。 Barnes Standards Track [Page 4] RFC 4244 SIP Request History Information November 2005 2.2) SIPプロトコルの観点からこの機能は「オプション」であるため、 「リクエスト履歴」を持っていないアプリケーションに対する影響 を説明する必要がある。この機能を使用するアプリケーションは、 以下の要件を満たす解決策の一部として適用性の指針を用意する必 要がある。 3) 生成(GENERATION)要件: 「リクエスト履歴」情報は、リクエストのリター ゲットが実行されたときに生成される。 3.1) 状況によっては、同じプロキシ内でリターゲットする複数のインス タンスが複数発生する可能性がある。また、プロキシは、「内部の リターゲット」についてリクエスト履歴情報を生成すべきである。 3.2) リダイレクトまたはREFERに対する応答としてリターゲットを実行 するエンティティ(UAまたはプロキシ)は、リダイレクト/REFERによ るリクエスト履歴を新しいリクエストに含めるべきである。 4) 発行者(ISSUER)要件: 「リクエスト履歴」情報は、UAまたはプロキシが 生成することができる。またリクエスト履歴情報はリクエストと応答の 両方で渡すことができる。 5) コンテンツ(CONTENT)要件: リターゲットが発生する度に、「リクエス ト履歴」情報には次の情報を含める必要がある。 5.1) このリターゲット処理におけるリクエストの新しい送信先URIまた はアドレス 5.2) リクエストをリターゲットした送信元URIまたはアドレス 5.3) Request-URIまたはアドレスの変更理由 5.4) リクエスト履歴情報の発生順序 6) リクエスト妥当性(REQUEST-VALIDITY)要件: リクエスト履歴は、確立済 みダイアログ内で送信されないリクエスト(INVITE、REGISTER、MESSAGE、 OPTIONSなど)にも適用可能である。 7) 後方転送(BACKWARDS)要件: リクエスト履歴情報は、生成エンティティか らUACに戻すことができる。このような処理は、ダイアログ確立の試行に 関する情報を発呼側パーティに通知するサービスを有効にするために必要 である。 8) 転送(FORWARDS)要件: リクエスト履歴情報を生成するエンティティは、 以降の転送時に、リクエスト履歴情報をリクエストに含めることもでき る。 Barnes Standards Track [Page 5] RFC 4244 SIP Request History Information November 2005 2.1. セキュリティの要件 リクエスト履歴情報は、リクエストをリターゲットするネットワーク要素が 挿入している。結果として、基本のSIPヘッダーの問題とはやや異なる問題 が発生するため、固有の考慮が必要になる。これらのセキュリティ要件は、 プロキシが挿入する情報を保護できる基本要件に一般化することが可能であ ると考えられている。 次のようなセキュリティ問題が考えられる。 1) 不正アプリケーションが、リターゲットの結果として新規エントリを追 加するか、または無効な情報を入力することで、偽のリクエスト履歴エ ントリを挿入する可能性がある。 2) 不正アプリケーションは、リクエスト履歴情報を修正して、終端アプリ ケーションの特性を変更したり、情報の受信者を誤った方向に導く可能 性がある。 3) 不正アプリケーションは、リクエスト履歴情報の一部またはすべてを削 除する可能性がある。 したがって、「リクエスト履歴」のセキュリティソリューションは次の要件 を満たす必要がある。 1) セキュリティ(SEC)要件1: リクエスト履歴を受信するエンティティには、 以前に追加されたリクエスト履歴コンテンツのどこかが変更されたかど うかを判断する機能が必要である。 2) セキュリティ要件2: リターゲットの各インスタンスにおいて、リクエス ト履歴情報の順序は保存する必要がある。 3) セキュリティ要件3: リクエスト履歴で伝達される情報を受信するエン ティティには、リクエストを提示するエンティティを認証できる機能が 必要である。 4) セキュリティ要件4: リクエスト履歴情報の機密性を確保するために、リ クエストを処理するエンティティのみが情報を表示できるようにすべき である。 これらのセキュリティ要件は、情報のリターゲットと取得によって、または リクエスト/応答で受信した情報を利用するアプリケーションとして、リク エスト履歴情報を利用するすべてのエンティティに適用される、ということ に注意すること。 Barnes Standards Track [Page 6] RFC 4244 SIP Request History Information November 2005 2.2. プライバシー要件 取得されるRequest-URIによって、意図しなくても発信元の情報がわかって しまうことがあるため、準拠が必要な一般的なプライバシ要件がある[MUST]。 1) プライバシ(PRIV)要件1: リクエストをリターゲットするエンティティ は、リクエストをリターゲット時に、そのリクエストと関連付けられた ネットワーク提供のプライバシ([RFC3323]参照)を維持しなければならな い。 2) プライバシ要件2: リクエスト履歴を受信するエンティティは、リクエス ト履歴情報と関連付けられたプライバシを維持しなければならない。 さらに、プロキシのローカルポリシーによって、リクエスト履歴情報で 取得されているRequest-URIと関連付けられたプライバシ要件を特定する こともできる。 3) プライバシ要件3: プライバシ要件に従うリクエスト履歴情報は、 [RFC3323]に記載されている方法で保護されていない場合、送出メッセー ジに含めてはならない。 3. リクエスト履歴情報の説明 リクエスト履歴情報によって実現する基礎機能は、リクエストの処理に関わ るプロキシとUAに対して、そのリクエストの履歴または進行について通知す る機能である(機能要件)。解決策は、History-InfoというSIPメッセージの 新しいヘッダーフィールドでリクエストを転送するときに、Request-URIを 取得することである(コンテンツ要件)。これによって、以降のリクエスト転 送に関わる通常のSIP処理では失われてしまうリクエストの履歴取得を考慮 に入れることができるようになる。この解決策は、SIPプロトコル仕様 [RFC3261]のセクション16.5と16.6で定義されている、リクエスト対象の基 本的な決定方法またはリクエスト転送方法を変更するものではない。 History-Infoヘッダーフィールドは、確立済みダイアログと関連付けられて いないリクエスト(INVITE、REGISTER、MESSAGE、REFER and OPTIONS、 PUBLISH、SUBSCRIBE)、およびそのリクエストに対する有効な応答に指定す ることができる(発行者要件)。 History-Infoヘッダーフィールドは、UACが新しいリクエストを作成する とき、プロキシがリクエストを転送するとき、またはリクエストの対象を変 更するときに追加される。「リターゲット」という用語が導入された理由 は、このリクエスト対象の変更と、そのリクエストの以降の転送を指すため である。注意が必要なのは、Request-URIの示す先が、処理を実行するエン ティティが責任を持つドメインである場合にのみ、リターゲットが発生する という点である。SIPプロトコルの観点では、リターゲットに関する処理は [RFC3261]のセクション16.5と16.6に記載されている。[RFC3261]のセクショ ン16.5に記載されているように、リクエスト転送の開始後に、プロキシは対 象セットに対象を追加してもよい[MAY]ため、同じプロキシがリクエストの 対象を複数回変更することができる(セクション2で「内部的なリターゲッ ト」と呼んでいる)。[RFC3261]のセクション16.6にはリクエストの転送につ いて記載されている。オプションの新規ヘッダーフィールドとして履歴情報 を取得するのは、このリクエスト転送の処理時である。したがって、 History-Infoヘッダーフィールドの追加は、基礎のSIPリクエスト転送に影 響を与えない。リダイレクトまたはREFERへの応答として、リクエストの対 象を変更するエンティティ(UAまたはプロキシ)は、最初のリクエストの History-Infoヘッダーフィールドも新しいリクエストに伝播すべきである(生 成要件、転送要件)。 3.1. History-Infoの選択性 History-Infoヘッダーフィールドは、UAとプロキシのどちらもサポートする 必要がないオプションである。新規のSupportedヘッダーフィール ド「histinfo」は、History-Infoヘッダーフィールドが応答で返されたかど うかを示すリクエストに含まれる(後方転送要件)。「histinfo」Supported ヘッダーフィールドとは別に、ローカルポリシーによってヘッダーフィール ドを任意のリクエストに追加するか、リターゲットされる特定の Request-URIについて追加するかが決定される。これによって、リクエスト 履歴情報を利用したサービスの適用性が制限される可能性がある。具体的 には、同じローカルポリシーによって制御されるドメイン内、特定のポリ シーをサポートするために他のドメインとポリシーをネゴシエートするドメ イン間、またはサービスを提供する上で完全なHistory-Infoが必要ではな いサービス間にリターゲット先が制限される(選択性要件)。History-Infoヘ ッダーフィールドを利用するすべてのアプリケーションは、利用できる情報 の影響を明確に定義し、そのリクエストの処理方法を指定しなければならな い[MUST]。 3.2. History-Infoの保護 本仕様はSIPの新規ヘッダーフィールドを定義する。トランスポート層セキュ リティ(Transport Layer Security/TLS)[RFC2246]を必須のメカニズムとし て使用することで、History-Infoヘッダーフィールド全体の機密性を確保す る(セキュリティ要件4)ことが強く推奨される[RECOMMENDED]。この結果、 History-Infoは、仲介エンティティが挿入したSIPの他のヘッダーフィール ドと同じレベル以上のセキュリティを持つことになる。リクエストを転送す る接続にTLSを利用できない場合、リクエストにはHistory-Infoを含めては ならない[MUST NOT]。または、このリクエストは、History-Infoヘッダー フィールドを含め、クライアントにリダイレクトしなければならない[MUST]。 これはクライアントがリクエストをリターゲットできるようにするためで ある。 TLSによって実現するセキュリティレベルがあれば(セキュリティ要件3)、 History-Infoヘッダーフィールドの情報を評価し、インデックス間の差異を 評価することで情報を削除するかどうかを判断することができる。エントリ が見つからない場合に情報を利用できるかどうかを定義するのは、アプリ ケーションに委ねられる。 SIPSスキームを使用することで、SIPメッセージパスの外部にいる任意のパー ティの場合はHistory-Infoを改ざんできないように保護できるが、パス上の すべての仲介エンティティは暗黙的に信頼される、ということに注意。悪意 のある仲介エンティティは、History-Infoを任意に削除、書き換え、または 修正する可能性がある。本仕様には、悪意のある仲介エンティティによる攻 撃を回避または検出する意図はない。 3.3. History-Infoのプライバシ確保 [RFC3323]に記載されているように、History-Infoヘッダーフィールドによっ て不注意でリクエスト送信者の情報がわかる可能性があるため、Privacyヘ ッダーフィールドを使用して、仲介エンティティが受信および転送するリク エスト(プライバシ要件2)またはリターゲットするリクエスト(プライバシ要 件1)に、History-Infoヘッダーフィールドを追加できるかどうかを決定すべ きである[SHOULD]。したがって、リクエスト送信者がセッションレベルのプ ライバシまたはヘッダーレベルのプライバシのpriv-valueを示したリクエス トには、History-Infoヘッダーフィールドを含めるべきではない [SHOULD NOT]。 さらに、History-Infoヘッダーフィールドによって一般的なルーティング情 報がわかる可能性がある。たとえば、特定の仲介エンティティまたはネッ トワークから参照できる可能性がある。そのため、プライバシ制限の対象に なる。したがって、ローカルポリシーを使用して、History-Infoヘッダー フィールド自体を含めるかどうか、特定のRequest-URIをヘッダーフィール ドに取得するかどうか、または特定のドメイン内でリターゲットされている ときにリクエストにのみ含めるかどうかを決定してもよい[MAY]。最後のケ ースでは、任意または特定のHistory-Infoヘッダーフィールドを転送すべ き[SHOULD]であることを示す、新しいpriv-valueのhistoryをPrivacyヘッ ダーフィールド[RFC3323]に追加することで実現することができる。 プライバシ要件を満たすことで情報を生成するリクエストを上書きするた め、この解決策の機能に影響があると認識されている。選択性やセキュリ ティ要件と同様に、History-Infoを利用するアプリケーションは、可能性が ある影響に対処すべきである[SHOULD]。または、アプリケーションに影響を 与えない理由を説明しなければならない[MUST]。 4. リクエスト履歴情報プロトコルの詳細 ここでは、提案する新規SIPプロトコル要素の詳細と用法について説明する。 また、解決策のセキュリティ上の側面についても論ずる。 Barnes Standards Track [Page 9] RFC 4244 SIP Request History Information November 2005 4.1. History-Infoのプロトコル構造 History-Infoは[RFC3261]で定義されているヘッダーフィールドである。オプ ションのヘッダーフィールドであり、リクエストと応答のどちらにも使用す ることができ、ダイアログと関連付けられていないリクエスト/応答の場合 でもダイアログを開始したリクエストであっても使用してもよい[MAY]。た とえば、History-InfoはINVITE、REGISTER、MESSAGE、REFER、OPTIONS、 SUBSCRIBE、PUBLISHと有効な応答だけでなく、ダイアログを開始したNOTIFY リクエストに指定してもよい[MAY]。 本文書では、[RFC3261]の表2に以下のエントリを追加する。この表への追加 は、本文書の発行時点の拡張メソッドにも反映される。これは読者のために 提供されているものであり、規範とはならない。 ヘッダー 場所 プロキシ ACK BYE CAN INV OPT REG MSG フィールド ------------ ----- ----- --- --- --- --- --- --- --- History-Info amdr - - - o o o o SUB NOT REF INF UPD PRA PUB --- --- --- --- --- --- --- History-Info amdr o o o - - - o History-Infoヘッダーフィールドは、ヘッダーフィールドをリクエストまた は応答に含めるときに必要な必須パラメータと共に、次の情報を伝達する。 o Targeted-to-URI (hi-targeted-to-uri): 必須パラメータ。特定のリク エストを転送するときに、Request-URIを取得する。 o Index (hi-index): History-Infoの必須パラメータ。情報の発生順序を 反映し、リクエストのフォークとネストも反映したインデックスを付け られる。このパラメータのフォーマットは数値の文字列がドットで区切 られ、転送のホップ数とリターゲット数を示す。この結果、リクエスト 履歴のツリー表記になり、ツリーのブランチを反映した最低レベルのイ ンデックスが含まれる。インデックスを含めてヘッダーを保護し、新し いエントリを順番に(つまり既存のエントリに続けて(詳細はセクション 4.3.3.1を参照))追加することで、リクエストのHistory-Infoヘッダー フィールドの順序が守られる(セキュリティ要件2)。さらに、アプリケー ションは、インデックス値に基づいて多様なメトリック(リターゲット の総数、特定のブランチからのリターゲットの総数など)を抽出するこ とができる。 o Reason: History-Infoのオプションのパラメータ。hi-targeted-to-uri でエスケープされるReasonヘッダーフィールド[RFC3326]を含めること で、History-Infoヘッダーフィールドに反映される。初めて Barnes Standards Track [Page 10] RFC 4244 SIP Request History Information November 2005 History-Infoヘッダーフィールドに追加される場合、理由は hi-targeted-to-uriに含まれないが、リターゲットが実際に発生したと きに追加される。これはセキュリティ問題を複雑にしているように見え るという点に注意。ただし、Request-URIの示す先が、処理を実行する エンティティが責任を持つドメインである場合にのみ、リターゲットは 発生する。したがって、Reason付きで更新するヘッダーフィールドに、 最初にhi-targeted-to-URIを追加したのと同じ処理エンティティになる。 o Privacy: History-Infoのオプションのパラメータ。hi- targeted-to-uri にエスケープしたpriv-value「history」を指定したPrivacyヘッダー フィールド[RFC3323]を含めることで、またはpriv-value「history」 を指定したPrivacyヘッダーフィールドをリクエストに追加することで 、History-Infoヘッダーフィールド値に反映される。priv-value 「history」を指定したPrivacyヘッダーフィールドを使用することは、 History-Infoヘッダーフィールドの一部または前部を転送すべきでは ないことを示す。 o Extension (hi-extension): オプションのパラメータ。将来的なオプ ションの拡張を見込んでいる。[RFC3261]に従い、拡張を理解しない実 装は、拡張を無視すべきである。 以下に、標準のSIP構文[RFC3261]に基づいて、History-Infoヘッダーフィー ルドの構文の概要を示す。 History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) hi-entry = hi-targeted-to-uri *( SEMI hi-param ) hi-targeted-to-uri= name-addr hi-param = hi-index / hi-extension hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT) hi-extension = generic-param 4.2. プロトコルの例 次に、History-Infoヘッダーフィールドの例をいくつか示す。 この例では、読みやすくするためだけに、フィールド間のバックスラッシュ とCRLFを使用している。 History-Info:;index=1;foo=bar History-Info: ; index=1.1, Barnes Standards Track [Page 11] RFC 4244 SIP Request History Information November 2005 ;index=1.2, ;index=1.3 4.3. プロトコルの用法 このセクションでは、History-Infoヘッダーフィールド、「histinfo」オプ ションタグ、および「history」のpriv-valueに関するUAとプロキシに固有 の処理について説明する。セクション1.3で論じたように、このプロトコル の基本的な目的は、リクエストの転送時に対象のRequest-URIを取得するこ とである。こうすることで、以降の対象指定(またはリターゲット)および転 送によって失われたリクエスト履歴を取得することができる。 これをリクエストの履歴全体で実現するには、UACが最初ののリクエスト でHistory-InfoヘッダーフィールドのRequest-URIを取得するか、プロキ シが、リクエストの転送時に、最初のリクエストのRequest-URI用のhi-entry と対象のRequest-URI用のhi-entryの両方を指定したHistory-Infoヘッダー フィールドを追加する必要がある。基本の処理は、リクエストを転送する各 エンティティが対象のRequest-URI用にhi-entryを追加し、インデックスを 更新し、リターゲットされたRequest-URIに適したReasonを追加することで ある。 4.3.1. ユーザーエージェントクライアント(UAC)の動作: UACは、応答でHistory-Infoヘッダーフィールドを受信したい、確立済みダ イアログと関連付けられていないすべてのリクエストに、「histinfo」オプ ションタグをSupportedヘッダーフィールドに含めるべきである[SHOULD]。 さらに、UACは、History-Infoヘッダーフィールドを追加し、リクエストの Request-URIを hi-target-to-uriとして使用し、hi-entryのインデックスを 推奨[RECOMMENDED]値の1に初期化することで、リクエストの診断ユーティリ ティを改善してもよい[MAY]。結果として、仲介エンティティとUASは少なく とも、元のRequest-URIと、Request-URIが1つ前のホップで修正されたかど うかを知ることができる。 リクエストがリダイレクトサーバーにルーティングされ、UACがContactヘッ ダーフィールドで3xx応答を受信する場合、UACはリクエストに含まれる前の hi-entry(複数も可)を維持してもよい[MAY]。この場合、セクション 4.3.3.1.2の説明どおりに、Reasonヘッダーフィールドは、前の(最後の) hi-entryに含まれるhi-targeted-to-uriと関連付けるべきである。次に、新 しいhi-entryをContactヘッダーフィールドのURIに追加してもよい[MAY](こ れが新しいRequest-URIになる)。この場合、前のhi-entryからインデックス 値を読み取ってインクリメントすることでインデックスが作成される。その ため、リターゲット時のプロキシに規定されている規則(セクション 4.3.3.1.3.参照)と同じ規則に従う。このシナリオの例は、付録Dを参照の こと。 UACがプライバシを考慮してHistory-Infoヘッダーフィールドを追加したく ない場合、リクエストに「session」、「header」、または「history」の priv-value(複数も可)を指定したPrivacyヘッダーフィールドを含めるべき である[SHOULD]。 Barnes Standards Track [Page 12] RFC 4244 SIP Request History Information November 2005 前述した3xx応答の処理は例外だが、応答で受信したHistory-Infoヘッダー フィールドの処理方法はアプリケーション固有のものであり、本文書の範囲 外である。ただし、アプリケーション用法の前に、情報の妥当性を確保すべ きである[SHOULD]。たとえば、エントリを評価してインデックス間の差異を 判断してもよい[MAY]。差異によって、エントリが不正に削除されたか、プ ライバシの理由から削除されたかがわかる可能性がある。どちらの方法で も、アプリケーションは損失した可能性がある情報を意識してもよい[MAY]。 4.3.2. ユーザーエージェントサーバー(UAS)の動作 リクエストにおけるUASによるHistory-Infoヘッダーフィールドの処理方 法は、その情報を利用する可能性があるUASのローカルポリシーと特定アプ リケーションによって変わる。情報をアプリケーションが使用する前に、妥 当性を確認すべきである[SHOULD]。たとえば、エントリを評価してインデッ クス間の差異を判断してもよい[MAY]。差異によって、エントリが不正に削 除されたか、プライバシの理由から削除されたかがわかる可能性がある。ど ちらの方法でも、アプリケーションは損失した可能性がある情報を意識して もよい[MAY]。 UASは、「histinfo」オプションタグをリクエストで受信した場合、リクエ ストで受信したHistory-Infoを以降の応答に含めるべきである[SHOULD]。 4.3.3. プロキシの動作 リクエストにHistory-Infoヘッダーフィールドを含めても、リクエストの対 象を決定するプロキシの基本的な処理方法([RFC3261]のセクション16.5で 定義)は変わらない。プロキシがリクエストの転送時にHistory-Infoを追加 するか、新規のhi-entryを追加するかは、次の点を考慮して決まる。 1. リクエストのSupportedヘッダーフィールドに「histinfo」オプション タグが含まれているかどうか。 2. プロキシがHistory-Infoヘッダーフィールドをサポートしているかど うか。 3. リクエストに「session」、「header」、「history」のpriv-valueが 指定されたPrivacyヘッダーフィールドが含まれるかどうか。 4. プロキシまたはドメインが追加されたHistory-Infoヘッダーフィール ドを、そのドメイン外に送信すべきかどうか。例として、リターゲッ トする特定のドメイン内でHistory-Infoヘッダーフィールドを使用す るが、ポリシー(プライバシ、ユーザーセキュリティとネットワークセ キュリティなど)によって、ドメイン外にその情報が公開されることを 禁止する場合を挙げる。このような状況に合わせるために、プロキシ は同じドメイン内でリクエストを転送するときに、priv-value 「history」を指定したPrivacyヘッダーフィールドを挿入してもよ い[MAY]。このようなアプリケーションの例は付録Cに示す。 5. 特定のRequest-URIにhi-eytryを追加するかどうかは、ローカルプライ バシポリシーを考慮することで変わる。プロキシは、特定の hi-targeted-to-uriと関連付けられたpriv-value「history」を指定し たPrivacyヘッダーフィールドを追加してもよい[MAY]。 たとえば、「histinfo」オプションタグがSupportedヘッダーフィールドに含 まれる場合にのみ、プロキシはHistory-Infoヘッダーフィールドを追加する というポリシーがあるとする。また、他のプロキシは、常にHistory-Info ヘッダーフィールドを追加するが、特定のドメイン外には転送しないという ポリシーを持っているとする(このポリシーは、priv-value「history」が指 定されたPrivacyヘッダーフィールドを各hi-entryに追加し、内部的なリター ゲットの場合にのみ情報を収集できるようにすることで実現する)。 History-Infoヘッダーフィールドを利用する各アプリケーションは、特定の アプリケーションに与えるローカルポリシーの影響に対処すべきである [SHOULD](たとえば、特定のアプリケーションにできれば必要なローカルポ リシーの指定や、ローカルポリシーの決定で課せられる可能性がある制限)。 オプションヘッダーフィールドの基本的なSIP処理と矛盾しないように、プロ キシは、ローカルポリシーでHistory-Infoをサポートしているかどうかには 関係なく、転送されたメッセージで受信したHistory-Infoヘッダーフィール ドを維持すべきである[SHOULD]。 上記の考慮事項に対処するために、プロキシがHistory-Infoヘッダーフィー ルドをリクエストと応答に追加する具体的な処理については、以降のセクシ ョンで詳細に説明する。 4.3.3.1. History-Infoヘッダーフィールドをリクエストに追加 History-Infoヘッダーフィールドをリクエストに含める際の考慮事項 (Privacyヘッダーフィールドの上書きを含めない、ローカルポリシーのサ ポートなど、詳細は4.3.3を参照)を評価して、プロキシはhi-entryをリクエ ストの転送時に追加すべきである[SHOULD]。[RFC3261]のセクション16.6 には、プロキシがリクエストを転送するときに従うべき手順が定義されて いる。手順5は、オプションのヘッダーフィールドを追加する場合について 規定している。これはHistory-Infoヘッダーフィールドを追加する場合に適 した手順のように見えるが、手順6でのやり取り「後処理のルーティング情 報(Postprocess routing information)」とRouteヘッダーフィールドのスト リクトルーティングの影響で、結果としてRequest-URIが変更される可能性 がある。したがって、手順8(Viaヘッダーフィールドの追加)と9 (Content-Length)の間にHistory-Infoヘッダーフィールドを追加することが 推奨される[RECOMMENDED]。ルースルーティングの場合、リクエストの転送 時にRequest-URIは変化しないという点に注意。したがって、この場合にリ クエストのHistory-Infoを取得すると、インデックスが異なるRequest-URI が重複する結果になる。転送されたリクエストで受信したhi-eytryの次に、 hi-entryを追加しなければならない[MUST]。さらに、History-Infoヘッ Barnes Standards Track [Page 14] RFC 4244 SIP Request History Information November 2005 ダーフィールドを含まないリクエストを受信した場合、プロキシは、転送さ れた現在のリクエストに追加される前に、hi-entryを指定したHistory-Info ヘッダーフィールドを追加してもよい[MAY]。このhi-entryのインデックスは 1から開始することが推奨される[RECOMMENDED]。以降のサブセクションで は、各hi-entryに関連付けられた情報を作成する際の詳細について定義して いる。 4.3.3.1.1. History-InfoヘッダーフィールドのPrivacy リクエストに「session」、「header」、「history」のpriv-valueが指定さ れたPrivacyヘッダーフィールドがある場合、処理エンティティが責任を持 つドメインに関連付けられたRequest-URIに、リクエストが転送されていれ ば(またローカルポリシーがHistory-Infoヘッダーフィールドをサポートし ているなどの条件があれば)、hi-entryを追加してもよい[MAY]。プロキシが 責任を持たないドメインと関連付けられたRequest-URIにリクエストが転送 されている場合、およびリクエストに「session」、「header」、「history」 のpriv-valueが指定されたPrivacyヘッダーフィールドがある場合、プロキ シは、転送前にhi-entryを削除すべきである[SHOULD]。このとき、ローカル ポリシーと、プロキシが要求されたプライバシを適用するためにダウンス トリームのプライバシサービスに依存できることを推測的に知っているかど うかによって処理が変わる。 リクエストにPrivacyヘッダーフィールドがなく、このエンティティが責任 を持つドメインと関連付けられたRequest-URIにリクエストを転送する場合、 その他にも考慮事項がある。 o プライバシと関連付けられたローカルポリシーがない場合、hi-entryを リクエストに追加してもよい[MAY]。 o プロキシのローカルポリシー(セクション4.3.3の考慮事項4に従う)が、 このプロキシが責任を持つドメイン以外にHistory-Infoを転送すべきで はないと示している場合、「history」のpriv-valueを指定したPrivacy ヘッダーフィールドは、このシナリオでプロキシが追加した各hi-entry と関連付けるべきである[SHOULD]。 o プロキシのポリシー(セクション4.3.3の考慮事項5に従う)が、このプロ キシが責任を持つドメイン以外に特定のRequest-URIのHistory-Infoを 転送すべきではないと示している場合、「history」のpriv-valueを指 定したPrivacyヘッダーフィールドは、このシナリオでプロキシが追加 した特定hi-targeted-to-uriの特定hi-entryと関連付けるべきであ る[SHOULD]。 プロキシが責任を持たないドメインにリクエストがRequest-URIに転送され、 ローカルポリシーで、プライバシを追加したすべてのhi-entryまたは特定の Barnes Standards Track [Page 15] RFC 4244 SIP Request History Information November 2005 hi-entryと関連付ける必要がある場合、「history」のpriv-valueが指定さ れたhi-entryはすべて転送前に削除すべきである[SHOULD]。 4.3.3.1.2. History-InfoヘッダーフィールドのReason 明示的なSIP応答の結果としてリターゲットする場合、Reasonは hi-targeted-to-uriと関連付けなければならない[MUST]。SIP応答にReason ヘッダーフィールドが含まれない場合、リターゲットのトリガになったSIP 応答コードは、リターゲットされたhi-targeted-to-uriと関連付けられた Reasonとして含めなければならない[MUST]。応答にSIP以外のReasonヘッダー フィールド(Q.850など)が含まれる場合、SIP応答コードと共に、リターゲッ トされるhi-targeted-to-uriと関連付けられた追加のReasonとして取得しな ければならない[MUST]。ReasonヘッダーがSIPの理由の場合、SIP応答コード とは異なるhi-targeted-to-uriと関連付けられたReasonとして使用しなけれ ばならない[MUST]。 タイムアウトや内部的なイベントの結果としてリターゲットする場合、 Reasonはリターゲットされたhi-targeted-to-uriと関連付けてもよい[MAY]。 特定のURIに対するリクエストが成功しなかった理由を反映するため、リター ゲットされたhi-targeted-to-uriと関連付けられるときで、リクエスト(新規 のhi-targeted-to-uriで新規のhi-entryを追加するなどのリクエスト)の転送 前に、Reasonの追加は発生すべきである。 4.3.3.1.3. History-Infoヘッダーフィールドのインデックス 順序を維持し、リクエストのネストとリターゲットを正確に反映するため、 取得したTargeted-to-URIと共にインデックスを含めなければならない [MUST]。セクション4.1の構文に従って、インデックスはドット区切りの数字 列で構成される(たとえば、1.1.2)。各ドットは、ホップまたはネストのレベ ルを反映している。つまり、ホップ数はドットの総数で判断できる。各レベ ル内では、整数は、リクエストがルーティングされる相手側エンティティの 数を反映する。したがって、インデックス処理の結果として、リクエスト履 歴の論理ツリー表記になる。インデックスのレベルごとに、インデックスを 1で開始することが推奨される。新しいブランチに進む場合、1のインクリメ ントを使用することが推奨される。 インデックスを追加する基本規則は、次のようにまとめられる。 1. 基本転送: 転送されているリクエストの場合、ブランチの深さ/長さ は増えているため、別レベルのインデックスを追加することでインデッ クスが決定される。これを実現するために、プロキシは可能であれば 受信したリクエストのHistory-Infoヘッダーフィールドから値を読み Barnes Standards Track [Page 16] RFC 4244 SIP Request History Information November 2005 取り、ドット区切り文字を付加して、最初のインデックスを続けるこ とで(新しいレベルは1にすることが推奨される[RECOMMENDED])、別レ ベルのインデックスを追加する。たとえば、受信リクエストの最後 のHistory-Infoヘッダーフィールドのインデックスが1.1の場合、この プロキシはインデックスを1.1.1に初期化し、リクエストを転送する。 2. プロキシ内のリターゲット - 最初のインスタンス: プロキシ内でリ ターゲットの最初のインスタンスの場合、インデックスの計算は、基 本転送で規定された計算に従う。 3. プロキシ内のリターゲット - 後続のインスタンス: 同じプロキシによ るリクエストの後続リターゲットごとに、新しいブランチが追加され る。現在のレベルで最後/最小の桁をインクリメントして新規ブランチ ごとにインデックスを計算し、その同じプロキシが転送する次のリク エスト(前述の例に従う)に含まれるインデックスは、1.1.2になる。 4. 応答に基づくリターゲット: 特定の応答(302など)によるリターゲット の場合、インデックスは規則3に従って計算される。つまり、インデッ クスの最小/最後の桁がインクリメントされる(つまり、新しいブラン チが作成される)。このとき、インクリメントは1にすることが推奨さ れる。たとえば、受信リクエストのHistory-Infoヘッダーフィールド に含まれるインデックスが1.2の場合、新しいhi-targeted-to-uriの History-Infoヘッダーフィールドのインデックスは1.3である。 5. 平行(フォーク)したリクエストのリターゲット: リクエストの転送が 同時に実行される場合、上記の規則に従ってフォークしたリクエスト ごとに、インデックスを取得しなければならない[MUST]。このとき、 各新しいリクエストは一意のインデックスを持つ。このシナリオのメッ セージ処理と、規則2と3の基本的なプロキシのリターゲットに従って 作成されるメッセージ処理との唯一の違いは、規則2と3で転送される リクエストは、その相手側とHistory-Infoエントリが関連付けられて いないということです。プロキシは、各リクエストに関連付けられた 収集情報を使用し、インデックスで示される順序でヘッダーエントリ を含めて、後続の応答(またはリクエスト)を構築する。応答は、 [RFC3261]のセクション16.7に記載されているとおりに処理され、手順 7「認証ヘッダーフィールド値の総計」と同様に総計History-Infoエン トリが処理される。セクション4.5には、このインデックスメカニズム を強調した並行するリクエストシナリオの例を示す。 Barnes Standards Track [Page 17] RFC 4244 SIP Request History Information November 2005 4.3.3.2. 応答のHistory-Infoの処理 プロキシがSupportedヘッダーフィールドに「histinfo」オプションタグを含 むリクエストを受信し、History-Infoの取得をサポートするローカルポリ シーに依存している場合、リクエストに対する後続の暫定応答と最終応答で 取得したHistory-Infoを返すべきである[SHOULD]。このとき、次のプライバ シの考慮条件に従う。 o 応答が、プロキシが責任を持たないドメインと関連付けられたRequest- URIに転送され、プロキシが受信したリクエストに「session」、 「header」、または「history」のpriv-valueが指定されたPrivacyヘッ ダーフィールドがある場合、プロキシは転送前にHistory-Infoヘッダー フィールド(つまりすべてのhi-entries)を削除しなければならな い[MUST]。 o プロキシが責任を持たないドメインと関連付けられているRequest-URIに リクエストが転送され、ローカルポリシーで、追加した任意またはすべ てのhi-entryと関連付けられたプライバシが必要な場合、「history」 のpriv-valueが指定されたhi-entryは転送前にすべて削除しなければな らない[MUST]。 o プロキシが、責任を持つドメインと関連付けられた別の仲介エンティ ティから応答を受信し、hi-entryをPrivacyヘッダーフィールドに含め、 責任を持たないドメインに応答を転送する場合、これらのhi-entryを削 除しなければならない[MUST]。 応答のHistory-Infoの処理は、[RFC3261]のセクション16.7に記載された方 法に従う。このとき、手順9「応答の転送」の直前に新規の手順を追加して、 History-Infoヘッダーフィールドを処理する。 4.3.4. リダイレクトサーバーの動作 リダイレクトサーバーは、3xx応答を受信するエンティティが実行する場合 と同様に、新規のHistory-Infoを追加すべきではない[SHOULD NOT]。ただ し、リダイレクトサーバーは、後続の応答に対するリクエストに、受信した History-Infoヘッダーフィールドを追加することで、応答にHistory-Infoを 含めてもよい[MAY]。 4.4. History-Infoのセキュリティ セクション3で論じたように、セキュリティ要件を満たすには、ホップバイ ホップのセキュリティのために、TLSの使用([RFC3261]に従う基本のSIP要件) が推奨される。History-Infoヘッダーフィールドを含むリクエストを転送す る接続でTLSが使用できない場合、以下の2つの選択肢のいずれかを実装しな ければならない[MUST]。 Barnes Standards Track [Page 18] RFC 4244 SIP Request History Information November 2005 o History-Infoヘッダーフィールドは、リクエストを転送する前に削除し なければならない[MUST]。 o 応答でHistory-Infoヘッダーフィールドを含めてリクエストをリダイレ クトすることで、History-Infoヘッダーフィールドなど、UACが安全に リクエストを発行できるようにしなければならない[MUST]。 4.5. History-Infoを使用するアプリケーション例 このシナリオでは、別のプロキシが既に試行したルーティングを再試行しな い場合に、応答のHistory-Infoが使用する場合の例を強調する。これは単な る例であり、プロキシがルーティングを再試行する理由には有効な理由が存 在する可能性もあり、ローカルポリシーやユーザー固有のポリシーの可能性 もある、ということに注意。 UA1はBobに発呼し、呼がProxy 1に到達する。proxy 1はリクエストをProxy 2 へ転送するProxy 2はリクエストを同時に送信し、複数箇所(UA2、UA3、UA4) を試行してから、すべての場所がビジー状態であるとProxy 1に応答を送信 する。Proxy 1は、UA5で完了する前に、Bobの登録済み連絡先の基づいて History-Infoなしで同じ場所(UA3など)を何度か試行する。ただし、 History-Infoがあれば、Proxy 1はUA3が既にINVITEを受信済みであると判断 するため、INVITEは直接UA5に送信される。 セクション4.5.1は、プライバシメカニズムの1つを使用して、これと同じシ ナリオを説明している。4.5.1では、Proxy 2(P2)が、History-InfoをP2のド メイン外に伝播しないと指定したPrivacyヘッダーフィールドを追加する。 このシナリオでは、Privacyヘッダーフィールドの「history」のプライバシ をリクエスト全体に使用して機能が失われた可能性と、History-Infoのプラ イバシの使用時に慎重に考慮が必要な点について強調している。 また、セクション4.5.2でも、プライバシメカニズムの1つを使用して同じシ ナリオについて説明している。異なる点は、Proxy2のローカルポリシーに よって、History-Infoに含まれるRequest-URIの1つにのみ(UA4)、priv-value が含まれているため、リクエストのルーティング処理で一部の機能が最適化 されているが、特定のURIに関するプライバシは維持していることである。 これらのシナリオは、見やすくするためにフォーマットされている。そのた め、読みやすさのためバックスラッシュとCRLFがフィールド間に使用され、 URIのヘッダーはエスケープのため正しく表示されない。 正しいフォーマットについてはセクション4.2の例を参照のこと。付録には その他の詳細なシナリオもある。 Barnes Standards Track [Page 19] RFC 4244 SIP Request History Information November 2005 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 | | | | | | | |--INVITE -->| | | | | | | |-INVITE->| | | | | Supported: histinfo History-Info: ;index=1, ; index=1.1 | | | | | | | | | |-INVITE>| | | | History-Info: ;index=1, ;index=1.1, ;index=1.1.1 | | | | | | | | | |-----INVITE ---->| | | History-Info:;index=1, ; index=1.1, ;index=1.1.2 | | | | | | | | | |-------INVITE------------>| | History-Info:;index=1, ;index=1.1, ;index=1.1.3 /* INVITEによるすべての応答は、不成功/使用不可を示す*/ | | | | | | | | |<-480 ---| | | | | History-Info: ;index=1, ; index=1.1, ;index=1.1.1, ; index=1.1.2, ; index=1.1.3 | | | | | | | /* 応答の受信時に、P1はINVITEの別のルーティングを決定するが、試行済み のルーティング(UA3など)に一致することがわかったため、INVITEはUA5にの み転送される。UA5でセッションは正常に確立する。 */ | | | | | | | | |----------------INVITE --------------------->| History-Info: ;index=1, ; index=1.1, ;index=1.1.1, ; index=1.1.2, ; index=1.1.3 ;index=1.2 | | | | | | | | |<-----200 OK---------------------------------| |<--200 OK---| | | | | | | | | | | | | |--ACK --------------------------------------------------->| 4.5.1. プロキシ2におけるリクエスト全体のPrivacyヘッダーフィールドの例 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 | | | | | | | |--INVITE -->| | | | | | | |-INVITE->| | | | | Supported: histinfo History-Info: ;index=1, ;index=1.1 | | | | | | | | | |-INVITE>| | | | Privacy: history History-Info:;index=1, ;index=1.1, ;index=1.1.1 | | | | | | | | | |-----INVITE ---->| | | Privacy: history History-Info:;index=1, ; index=1.1, ;index=1.1.2 | | | | | | | | | |-------INVITE------------>| | Privacy: history History-Info:;index=1, ;index=1.1, ;index=1.1.3 /* INVITEからのすべての応答は不成功/使用不可を示し、最初に受信した History-InfoエントリのみがPrivacyヘッダーフィールド値のためにP1に 返されなかった。 */ | | | | | | | | |<-480 ---| | | | | History-Info: ;index=1, ; index=1.1 | | | | | | | /* 応答を受信して、P1はUA3を含めたINVITEの別のルーティングを決定す る。UA3はP2が試行済みだが、PrivacyのためにP1は試行済みであること が認識できない。そのため、UA5へINVITEを転送する前にUA3が再試行 され、セッションが正常に確立する。 */ | | | | | | | | |--------------INVITE ----->| | | History-Info: ;index=1, ; index=1.1, ; index=1.2 | | | | | | | | |<-- 486 -------------------| | | History-Info: ;index=1, ; index=1.1, ; index=1.2 | | | | | | | | |----------------INVITE --------------------->| History-Info: ;index=1, ; index=1.1, ;index=1.2, ;index=1.3 | | | | | | | | |<-----200 OK---------------------------------| |<--200 OK---| | | | | | | | | | | | | |--ACK --------------------------------------------------->| 4.5.2. プロキシ2における特定URI (UA4)のPrivacyヘッダーフィールドの例 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 | | | | | | | |--INVITE -->| | | | | | | |-INVITE->| | | | | Supported: histinfo History-Info: ;index=1, ; index=1.1 | | | | | | | | | |-INVITE>| | | | History-Info:;index=1, ;index=1.1, ;index=1.1.1 | | | | | | | | | |-----INVITE ---->| | | History-Info:;index=1, ;index=1.1, ;index=1.1.2 | | | | | | | Barnes Standards Track [Page 22] RFC 4244 SIP Request History Information November 2005 | | |-------INVITE------------>| | History-Info: ;index=1, ;index=1.1, ; index=1.1.3 /* INVITEによるすべての応答は、不成功/使用不可を示す。UA4に関連付けら れたHistory-Infoは、そのURIに関連付けられたPrivacyヘッダーフィール ドのために応答では返されない。 */ | | | | | | | | |<-480 ---| | | | | History-Info: ;index=1, ; index=1.1, ;index=1.1.1, ; index=1.1.2, | | | | | | | /* 応答の受信時に、P1はINVITEの別のルーティングを決定するが、試行済み のルーティング(UA3など)に一致することがわかったため、INVITEはUA5に のみ転送される。UA5でセッションは正常に確立する。 */ | | | | | | | | |----------------INVITE --------------------->| History-Info: ;index=1, ; index=1.1, ;index=1.1.1, ; index=1.1.2, ;index=1.2 | | | | | | | | |<-----200 OK---------------------------------| |<--200 OK---| | | | | | | | | | | | | |--ACK --------------------------------------------------->| Barnes Standards Track [Page 23] RFC 4244 SIP Request History Information November 2005 5. アプリケーションの考慮事項 付録の例でわかるように、History-Infoは、さまざまなサービスの仲介エン ティティとUAが使用できる非常に柔軟性が高い基礎を構築することができ る。そのため、History-Infoを利用するサービスは、次の点を考慮して設計 する必要がある。 1) History-Infoはオプションである。したがってサービスは、リクエスト と応答にHistory-Infoヘッダーフィールドが含まれない場合のデフォル ト動作を定義しなければならない[MUST]。 2) プライバシを考慮してHistory-Infoに影響が及ぶ場合がある。 History-Infoを必要とするアプリケーションは、ヘッダーレベル、セッ ションレベル、または履歴レベルのプライバシがUAから要求された場合 に、History-Infoをリクエストまたは応答に使用できない場合がある、 という点に注意する必要がある。この問題には、前項の考慮事項と同じ 方法でアプリケーションが対処する。つまり、情報を利用すべきではな いことを適切なデフォルト動作で指定する。 3) ローカルポリシーがHistory-Infoに影響を及ぼす場合がある。 History-Infoヘッダーフィールドを利用する各アプリケーションは、特 定のアプリケーションに与えるローカルポリシーの影響に対処すべきで ある[SHOULD](たとえば、特定のアプリケーションにできれば必要な ローカルポリシーの指定や、ローカルポリシーの決定で課せられる可能 性がある制限)。これは前述した1と2で示した選択性とプライバシの考 慮事項に関連するが、それ以外の点もあるということに注意。たとえ ば、選択性とプライバシの考慮事項のために、エンティティは部分的 なHistory-Infoエントリのみを受信する可能性があるが、これだけで十 分だろうか。これはデバッグ目的の制限だが、特定の仲介エンティティ からの情報のみを必要とする一部のモデルでは十分な可能性もある。 4) History-Infoヘッダーフィールドに関連付けられたセキュリティではTLS を使用する必要がある。リクエストが転送されている接続にTLSを使用 できない場合、History-Infoヘッダーフィールドはリクエストから削除 することができる。履歴情報がない影響は、特定のアプリケーションの 性質によって変わる(たとえば、情報はディスプレイに表示されるもの か、以降のリクエスト処理に悪影響を及ぼす可能性がある自動装置に よって処理されたものか、など)。セキュリティの推奨事項をサポート していない仲介エンティティの影響は、アプリケーションが評価するこ とが推奨される。これによって、アプリケーションが適切に影響に対処 することができる。 Barnes Standards Track [Page 24] RFC 4244 SIP Request History Information November 2005 6. セキュリティの考慮事項 History-Infoの脅威モデルとそれに関連するセキュリティとプライバシの要 件は、本文書のセクション2.1と2.2で説明している。セクション3.2、3.3、 4.4には、これらの要件を満たすセキュリティとプライバシに関連する規範 的な推奨事項を記載している。TLSの使用は、History-Infoヘッダーフィー ルドを使用するエンティティ(UACからプロキシ、プロキシからプロキシ、お よびプロキシからUAS)間では必須である。特定の接続でTLSが使用できない 場合の適切なリクエスト処理については、セクション5で説明している。 TLSを使用すると、History-Infoヘッダーは、一般的にSIPセッションの以降 の処理にHistory-Infoよりも大きな影響がある他のSIPヘッダーとまったく 同程度に安全になる。 7. IANA条項 7.1. 新規のSIP History-Infoヘッダーフィールドの登録 本文書は、新規のヘッダーフィールド名History-Infoと新しいオプションタ グhistinfoを定義する。 http:///www.iana.org/assignments/sip-parametersに以下の変更が加えら れた。 次の行がヘッダーフィールドセクションに追加された。 ヘッダー名 短縮形 参考文献 ----------- ------------ --------- History-Info none [RFC4244] 次の行がオプションタグセクションに追加された。 名前 説明 参考文献 ---- ----------- --------- histinfo このオプションタグをSupportedヘッ [RFC4244] ダーフィールドと共に使用すると、 リクエストで履歴情報を取得し、以降 の応答で返す処理をサポートしている ことを示す。histinfoタグはProxy-Require またはRequireヘッダーフィールドには 使用されない。これは、History-Infoの サポートがオプションであるためである。 Barnes Standards Track [Page 25] RFC 4244 SIP Request History Information November 2005 7.2. SIP Privacyヘッダーフィールドの「history」の登録 本文書は、SIP Privacyヘッダーフィールドの新しいpriv-value「history」 を定義する。 http://www.iana.org/assignments/sip-priv-valuesに以下の変更が加え られた。 次の情報がSIP Privacyヘッダーフィールドの登録に追加された。 名前 説明 登録者 参考文献 ---- ----------- ---------- --------- history History-Infoヘッダー Mary Barnes [RFC4244] フィールド用に要求される mary.barnes@nortel.com プライバシ 8. 規範となる参考文献 [RFC3261] 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. [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002. [RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. 9. 有益な参考文献 [RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, December 2003. 10. 謝辞 Robert Sparks、Paul Kyzivat、Scott Orton、John Elwell、Nir Chen、 Francois Audet、Palash Jain、Brian Stucker、Norma Ng、Anthony Brown、 Jayshree Bharatia、Jonathan Rosenberg、Eric Burger、Martin Dolly、 Roland Jesske、Takuya Sawada、Sebastien Prouvost、Sebastien Garcinの 各氏からいただいた建設的なフィードバックについて感謝を述べたい。 また、ABNFの規範的な側面の一部、特にインデックスとセキュリティ上の側 面に関する必要性と形式についてRohan Mahyから多大な貢献をいただいたこ とに感謝を述べたい。 11. 寄稿者の連絡先 Cullen、Mark、Jonは、初期の要件の開発に貢献した。 CullenとMarkは、初期バージョンの各解決策の開発において電子メール形式 の議論に多大な貢献をいただいた。 Cullen Jennings Cisco Systems 170 West Tasman Dr MS: SJC-21/3 Phone: +1 408 421 9990 EMail: fluffy@cisco.com Jon Peterson NeuStar, Inc. 1800 Sutter Street, Suite 570 Concord, CA 94520 USA Phone: +1 925-363-8720 EMail: Jon.Peterson@NeuStar.biz Mark Watson Digital Fountain 39141 Civic Center Drive Suite 300 Fremont, CA 94538 U.S.A. EMail: mark@digitalfountain.com Barnes Standards Track [Page 27] RFC 4244 SIP Request History Information November 2005 付録. シナリオ例 付録A〜DのシナリオはHistory-Infoヘッダーフィールドの使用例を示した が、参考情報としてのみ利用するための例である。これらの例は規範にする 意図はなく、見やすくするためにフォーマットしている。したがって、URI のヘッダーフィールドは、エスケープのために正しくフォーマットされてい ない。正しいフォーマットについてはセクション4.2の例を参照のこと。 付録A. シーケンシャルなフォーク(応答におけるHistory-Info) このシナリオでは、Requireを開始したアプリケーションまたはユーザーに 対して応答のHistory-Infoが有効な場合の例について強調している。 UA1のAliceは、Proxy1経由でBobに発呼する。Proxy1は、応答をAliceに送信 する前に、いくつかの試行を連続して行い、一部(UA2、UA3、UA4)が失敗 する。 このシナリオは、History-InfoをUA1に提示することで、UA1のエンドユー ザーまたアプリケーションは、Bobを見つける最適な試行方法を決定する処 理を示す。この仕組みを使用しなかった場合、UA1はUA3(とUA4)も試行し、 Bobに到達する3度目の手動の試行で、UA4を再試行する。この仕組みを使用 した場合、両端のエンドユーザーまたはアプリケーションは、Bobの自宅電 話はビジー状態であり、またオフィスにBobはいない、ということがわかる。 このエンドユーザーまたはアプリケーションが知っているBobの代替アドレ スがあり、まだ試行されていない場合、アプリケーションまたはエンドユー ザーはそのアドレスを試行することができる。この意図は、このメカニズム の柔軟性の例を強調することである。この柔軟性によって、詳細なアプリ ケーションを規定するために、SIPそのままよりもまた本文書の範囲よりも 優れたアプリケーションを実現することができる。 このシナリオでは、UA1が元のRequest-URIをINVITEに含めなかったため、プ ロキシはhi-entryを追加して元のRequest-URIを取得し、完全な情報を実現 する(セクション4.3.3.1参照)。 Barnes Standards Track [Page 28] RFC 4244 SIP Request History Information November 2005 UA1 Proxy1 UA2 UA3 UA4 | | | | | |-INVITE F1->| | | | | | | | | | |--INVITE F2------>| | | |<--100 F3---| | | | | |<-302 F4----------| | | | | | | | | |-------INVITE F5 --------->| | | | | | | | |<-------180 F6 ------------| | |<---180 F7--| | | | | . . |---retransmit INVITE ----->| | | | | | | | | ( timeout ) | | | | | | | | | |------INVITE F8 ------------------->| |<--100 F9 --| | | | | | | | | | |<-486 F10 --------------------------| | | | | | | |-- ACK F11------------------------->| |<--486 F12--| | | | | | | | | |--ACK F13-->| | | | | | | | | メッセージ詳細 F1 INVITE UA1 ->Proxy1 INVITE sip:UserA@example.com SIP/2.0 Via: SIP/2.0/UDP example.net:5060 From: Alice To: Bob Call-Id: 12345600@example.net CSeq: 1 INVITE Contact: Alice Content-Type: application/sdp Content-Length: v=0 o=UserA 2890844526 2890844526 IN IP4 client.example.net s=Session SDP c=IN IP4 192.0.2.3 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Barnes Standards Track [Page 29] RFC 4244 SIP Request History Information November 2005 /* UA1のクライアントは、ネットワークからポート49170上でデータを受信す るために準備する。 */ F2 INVITE Proxy1 ->UA2 INVITE sip:UserA@ims.example.com SIP/2.0 Via: SIP/2.0/UDP ims.example.com:5060;branch=1 Via: SIP/2.0/UDP example.net:5060 Record-Route: From: Alice To: Bob Call-Id: 12345600@example.net CSeq: 1 INVITE History-Info: ; index=1, ; index=1.1 Contact: Alice Content-Type: application/sdp Content-Length: v=0 o=UserA 2890844526 2890844526 IN IP4 client.example.net s=Session SDP c=IN IP4 192.0.2.3 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F3 100 Trying Proxy1 ->UA1 SIP/2.0 100 Trying Via: SIP/2.0/UDP example.net:5060 From: Alice To: Bob Call-Id: 12345600@example.net CSeq: 1 INVITE Content-Length: 0 F4 302 Moved Temporarily UA2 ->Proxy1 SIP/2.0 302 Moved Temporarily Via: SIP/2.0/UDP ims.example.com:5060;branch=1 Via: SIP/2.0/UDP example.net:5060 From: Alice To: Bob ;tag=3 Call-Id: 12345600@example.net CSeq: 1 INVITE Contact: Content-Length: 0 Barnes Standards Track [Page 30] RFC 4244 SIP Request History Information November 2005 F5 INVITE Proxy1 -> UA3 INVITE sip:UserB@example.com SIP/2.0 Via: SIP/2.0/UDP ims.example.com:5060;branch=2 Via: SIP/2.0/UDP example.net:5060 From: Alice To: Bob Call-Id: 12345600@example.net History-Info: ; index=1, ; index=1.1, ;index=1.2 CSeq: 1 INVITE Contact: Alice Content-Type: application/sdp Content-Length: v=0 o=User1 2890844526 2890844526 IN IP4 client.example.net s=Session SDP c=IN IP4 192.0.2.3 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F6 180 Ringing UA3 ->Proxy1 SIP/2.0 180 Ringing Via: SIP/2.0/UDP example.net:5060 From: Alice To: Bob ;tag=5 Call-ID: 12345600@example.net CSeq: 1 INVITE Content-Length: 0 F7 180 Ringing Proxy1 -> UA1 SIP/2.0 180 Ringing SIP/2.0/UDP example.net:5060 From: Alice To: Bob Call-Id: 12345600@example.net CSeq: 1 INVITE Content-Length: 0 /* User Bにはアクセスできない。INVITEはタイムアウトするまで複数解送信 される。 */ Barnes Standards Track [Page 31] RFC 4244 SIP Request History Information November 2005 /* プロキシは、新規の履歴情報エントリを追加した後に、INVITEをUA4に転 送する。 */ F8 INVITE Proxy1 -> UA4 INVITE sip:UserC@example.com SIP/2.0 Via: SIP/2.0/UDP ims.example.com:5060;branch=3 Via: SIP/2.0/UDP example.net:5060 From: Alice To: Bob Call-Id: 12345600@example.net History-Info: ; index=1, ;index=1.1, ;index=1.2, ;index=1.3 CSeq: 1 INVITE Contact: Alice Content-Type: application/sdp Content-Length: v=0 o=User1 2890844526 2890844526 IN IP4 client.example.net s=Session SDP c=IN IP4 192.0.2.3 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F9 100 Trying Proxy1 ->UA1 SIP/2.0 100 Trying Via: SIP/2.0/UDP example.net:5060 From: Alice To: Bob Call-Id: 12345600@example.net CSeq: 1 INVITE Content-Length: 0 F10 486 Busy Here UA4 -> Proxy1 SIP/2.0 486 Busy Here Via: SIP/2.0/UDP ims.example.com:5060;branch=3 Via: SIP/2.0/UDP example.net:5060 From: Alice To: Bob Call-Id: 12345600@example.net Barnes Standards Track [Page 32] RFC 4244 SIP Request History Information November 2005 CSeq: 1 INVITE Content-Length: 0 F11 ACK Proxy1 -> UA4 ACK sip:UserC@example.com SIP/2.0 Via: SIP/2.0/UDP example.net:5060 From: Alice To: Bob Call-Id: 12345600@example.net CSeq: 1 ACK Content-Length: 0 /* プロキシは、一連のINVITEから関連する履歴情報エントリを追加した 後で、Aliceに486を転送する。 */ F12 486 Busy Here Proxy1 -> UA1 SIP/2.0 486 Busy Here Via: SIP/2.0/UDP example.net:5060 From: Alice To: Bob Call-Id: 12345600@example.net History-Info: ; index=1, ;index=1.1, ;index=1.2, ;index=1.3 CSeq: 1 INVITE Content-Length: 0 F13 ACK Alice -> Proxy 1 ACK sip:UserA@example.com SIP/2.0 Via: SIP/2.0/UDP example.net:5060 From: Alice To: Bob Call-Id: 12345600@example.net CSeq: 1 ACK Content-Length: 0 Barnes Standards Track [Page 33] RFC 4244 SIP Request History Information November 2005 付録B. 音声メール このシナリオでは、リクエストのHistory-Infoがエッジサービス(音声メール サーバーなど)によって主に使用されている場合の例について強調している。 注意が必要なのは、追加の情報をエッジサービスが必要としている可能性が 高いため、この例は特定のエッジサービスに適した完全な仕様にする意図は ない、という点である。History-Infoは、このサービスが利用する基礎の1 つに過ぎない。 UA1はUAに発呼し、その呼はUA Bに転送され、さらにUA VM(音声メールサー バー)に転送される。INVITEでリターゲットされたURIとReason(およびその 他の情報)に基づいて、VMサーバーは使用するメールボックス、再生する挨 拶などについてポリシーの決定を行う。 UA1 Proxy UA-A UA-B UA-VM | | | | | |--INVITE F1-->| | | | | | | | | | |--INVITE F2-->| | | |<--100 F3-----| | | | | |<-302 F4------| | | | | | | | | |--------INVITE F5---------->| | | | | | | | |<--------180 F6-------------| | |<---180 F7----| | | | | . . . | | | | | |------retransmit INVITE---->| | | . . . | | | | | | (timeout) | | | | | | | | |-------INVITE F8---------------------->| | | | | | | |<-200 F9-------------------------------| | | | | | |<-200 F10-----| | | | | | | | | |--ACK F11-------------------------------------------->| Barnes Standards Track [Page 34] RFC 4244 SIP Request History Information November 2005 メッセージ詳細 INVITE F1 UA1->Proxy INVITE sip:UserA@example.com SIP/2.0 Via: SIP/2.0/UDP example.net:5060 From: BigGuy To: LittleGuy Call-Id: 12345600@example.net CSeq: 1 INVITE Contact: BigGuy Content-Type: application/sdp Content-Length: v=0 o=UserA 2890844526 2890844526 IN IP4 client.example.net s=Session SDP c=IN IP4 192.0.2.3 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 /* UA1のクライアントは、ネットワークからポート49170上でデータを受信す るために準備する。 */ INVITE F2 Proxy->UA-A INVITE sip:UserA@ims.example.com SIP/2.0 Via: SIP/2.0/UDPims.example.com:5060;branch=1 Via: SIP/2.0/UDP example.net:5060 Record-Route: From: BigGuy To: LittleGuy Call-Id: 12345600@example.net CSeq: 1 INVITE History-Info: ; index=1 Contact: BigGuy Content-Type: application/sdp Content-Length: v=0 o=UserA 2890844526 2890844526 IN IP4 client.example.net s=Session SDP c=IN IP4 192.0.2.3 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 100 Trying F3 Proxy->UA1 Barnes Standards Track [Page 35] RFC 4244 SIP Request History Information November 2005 SIP/2.0 100 Trying Via: SIP/2.0/UDP example.net:5060 From: BigGuy To: LittleGuy Call-Id: 12345600@example.net CSeq: 1 INVITE Content-Length: 0 302 Moved Temporarily F4 UserA->Proxy SIP/2.0 302 Moved Temporarily Via: SIP/2.0/UDP ims.example.com:5060;branch=1 Via: SIP/2.0/UDP example.net:5060 From: BigGuy To: LittleGuy;tag=3 Call-Id: 12345600@example.net CSeq: 1 INVITE Contact: Content-Length: 0 INVITE F5 Proxy-> UA-B INVITE sip:UserB@example.com SIP/2.0 Via: SIP/2.0/UDP ims.example.com:5060;branch=2 Via: SIP/2.0/UDP example.net:5060 From: BigGuy To: LittleGuy Call-Id: 12345600@example.net History-Info: ; index=1, ;index=2 CSeq: 1 INVITE Contact: BigGuy Content-Type: application/sdp Content-Length: v=0 o=User1 2890844526 2890844526 IN IP4 client.example.net s=Session SDP c=IN IP4 192.0.2.3 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 180 Ringing F6 UA-B ->Proxy SIP/2.0 180 Ringing Via: SIP/2.0/UDP example.net:5060 From: BigGuy Barnes Standards Track [Page 36] RFC 4244 SIP Request History Information November 2005 To: LittleGuy ;tag=5 Call-ID: 12345600@example.net CSeq: 1 INVITE Content-Length: 0 180 Ringing F7 Proxy-> UA1 SIP/2.0 180 Ringing SIP/2.0/UDP example.net:5060 From: BigGuy To: LittleGuy Call-Id: 12345600@example.net CSeq: 1 INVITE Content-Length: 0 /* User Bにはアクセスできない。INVITEはタイムアウトするまで複数解送信 される。 */ /* プロキシは、新規の履歴情報エントリを追加した後に、INVITEをUA-VMに 転送する。 */ INVITE F8 Proxy-> UA-VM INVITE sip:VM@example.com SIP/2.0 Via: SIP/2.0/UDP ims.example.com:5060;branch=3 Via: SIP/2.0/UDP example.net:5060 From: BigGuy To: LittleGuy Call-Id: 12345600@example.net History-Info:;index=1, ;index=2, ;index=3 CSeq: 1 INVITE Contact: BigGuy Content-Type: application/sdp Content-Length: v=0 o=User1 2890844526 2890844526 IN IP4 client.example.net s=Session SDP c=IN IP4 192.0.2.3 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 200 OK F9 Barnes Standards Track [Page 37] RFC 4244 SIP Request History Information November 2005 SIP/2.0 200 OK UA-VM->Proxy Via: SIP/2.0/UDP ims.example.com:5060;branch=3 Via: SIP/2.0/UDP example.net:5060 From: BigGuy To: LittleGuy ;tag=3 Call-Id: 12345600@example.net CSeq: 1 INVITE Contact: TheVoiceMail Content-Type: application/sdp Content-Length: v=0 o=UserA 2890844527 2890844527 IN IP4 vm.example.com s=Session SDP c=IN IP4 192.0.2.4 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 200 OK F10 Proxy->UA1 SIP/2.0 200 OK Via: SIP/2.0/UDP ims.example.com:5060;branch=3 Via: SIP/2.0/UDP example.net:5060 From: BigGuy To: LittleGuy ;tag=3 Call-Id: 12345600@example.net CSeq: 1 INVITE Contact: TheVoiceMail Content-Type: application/sdp Content-Length: v=0 o=UserA 2890844527 2890844527 IN IP4 vm.example.com s=Session SDP c=IN IP4 192.0.2.4 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ACK F11 UA1-> UA-VM ACK sip:VM@example.com SIP/2.0 Via: SIP/2.0/UDP example.net:5060 From: BigGuy To: LittleGuy;tag=3 Call-Id: 12345600@example.net Barnes Standards Track [Page 38] RFC 4244 SIP Request History Information November 2005 CSeq: 1 ACK Content-Length: 0 /* UA1とUA-VM間でRTPストリームが確立される。UA-VMはUA1に関するアナウ ンスを開始する。 */ 付録C. 自動通話分散の例 このシナリオは、自動通話分散サービスの例について強調している。この例 の場合、エージェントは、対応する顧客の種類に応じてグループに区分され ている。この例で、Goldの顧客には、Silverの顧客よりも高い優先度が指定 されているため、Goldグループ(ACDGRP1)のサービスを担当する全エージェ ントがビジー状態の場合でも、リクエストをSilverグループにリターゲット することで、Goldの顧客からの呼はサービスを受けられる。受信通話の処理 に割り当てられたエージェントで通話の受信時に、メッセージ内の History-Infoヘッダーフィールドに基づいて、エージェントのアプリケー ションはそれがGold顧客の通話であることを示すことができる。エージェン トに到達する前にオーバーフローする可能性がある多くのグループから、 エージェントが適切に処理する処理することができる。 通話がSilverからGoldにオーバーフローする可能性があるシナリオの場合、 呼を処理する代替グループの表示、内部ルーティング、または実際のエー ジェントは、明らかにUA1に送信すべきではない[SHOULD]。 したがって、このシナリオでは、発呼側UAがリクエストしている場合でも、 プロキシはHistory-Infoの送信を応答でサポートしないと想定される。 この例は、他の例と同様にこの種のサービスを処理する方法を規定するもの ではないが、このようなサービスと関連付けられる処理のサブセット例では ある。さらに、この例では、エージェントの可用性の側面には対処してい ない。可用性については、SIPインターフェイスによって実行することもで きる。 UA1 Proxy ACDGRP1 Svr ACDGRP2 Svr UA2-ACDGRP2 | | | | | |--INVITE F1-->| | | | Supported:histinfo | | | | | | |--INVITE F2-->| | | Supported:histinfo History-Info: ; index=1 History-Info: ; index=1.1 | | | | | | |<-302 F3------| | | Contact: | | | | | | |--------INVITE F4---------->| | History-Info: ; index=1 History-Info: ; index=1.1 History-Info: ; index=1.2 | | | | | | | | | | | | | |INVITE F5>| History-Info: ; index=1 History-Info: ; index=1.1 History-Info: ; index=1.2 | | | | | | | | |<-200 F6--| | | | | | | |<-200 F7--------------------| | History-Info: ; index=1 History-Info: ; index=1.1 History-Info: ; index=1.2 |<-200 F8------| | | | < No History-Info included in the response due to Local Policy> | | | | | |--ACK F9--------------------------------------------->| 付録D. リダイレクトサーバーとプロキシサーバー経由のセッション このシナリオでは、Aliceは最初にリダイレクトサーバーを使用し、次にプ ロキシサーバーを使用して、Bobに発呼する。INVITEメッセージは、リダイ レクトサーバーにまず送信される。サーバーは、Bobの現在のSIPアドレスが 指定されたContactヘッダーフィールドを含む302 Moved Temporarily応答を 返す(F2)。次にAliceは、Bobの現在のSIPアドレスを別のHistory-Infoエント リに含めた新規のINVITEを生成する。INVITEはプロキシサーバー経由でBob に送信される。その結果、Bobは完全な履歴情報を受信し、呼は通常どおり に進行する。このシナリオの完全なコールフローは、History-Infoは使用し ていないが、[RFC3665]のセクション3.6の「SIPの基本コールフロー例」に 記載されている。 Alice Redirect Server Proxy 3 Bob | | | | | INVITE F1 | | | |--------------->| | | | 302 F2 | | | |<---------------| | | | ACK F3 | | | |--------------->| | | | INVITE F4 | | |-------------------------------->| INVITE F5 | | 100 F6 |--------------->| メッセージ詳細 F1 INVITE Alice -> Redirect Server INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 INVITE History-Info: ; index=1 Contact: Content-Length: 0 F2 302 Moved Temporarily Redirect Proxy -> Alice SIP/2.0 302 Moved Temporarily Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44 ;received=192.0.2.1 From: Alice ;tag=9fxced76sl To: Bob ;tag=53fHlqlQ2 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com Barnes Standards Track [Page 41] RFC 4244 SIP Request History Information November 2005 CSeq: 1 INVITE History-Info: ; index=1 Contact: Content-Length: 0 F3 ACK Alice -> Redirect Server ACK sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob ;tag=53fHlqlQ2 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 ACK Content-Length: 0 F4 INVITE Alice -> Proxy 3 INVITE sip:bob@chicago.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 2 INVITE History-Info: \ text="Moved Temporarily">; index=1, ; index=2 Contact: Content-Length: 0 F5 INVITE Proxy 3 -> Bob INVITE sip:bob@client.chicago.example.com SIP/2.0 Via: SIP/2.0/TCP ss3.chicago.example.com:5060;branch=z9hG4bK721e.1 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.1 Max-Forwards: 69 Record-Route: From: Alice ;tag=9fxced76sl To: Bob Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 2 INVITE History-Info: \ text="Moved Temporarily">; index=1, ; index=2, ; index=2.1 Contact: Barnes Standards Track [Page 42] RFC 4244 SIP Request History Information November 2005 Content-Length: 0 詳細なコールフローは[RFC3665]のセクション6.3に従って続く。 編集者の連絡先 Mary Barnes Nortel 2201 Lakeside Blvd Richardson, TX USA Phone: 1-972-684-5432 EMail: mary.barnes@nortel.com Barnes Standards Track [Page 43] RFC 4244 SIP Request History Information November 2005 完全な著作権表示 Copyright (C) The Internet Society (2005). 本文書は、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編集職務のための資金は、現在、インターネット協会によって提供され ている。 ------------------------------------------------------------------------ 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2006年 ------------------------------------------------------------------------ Barnes Standards Track [Page 44]