Network Working Group J. Rosenberg Request for Comments: 3841 dynamicsoft Category: Standards Track H. Schulzrinne Columbia University P. Kyzivat Cisco Systems August 2004 セッション開始プロトコル(SIP)の発呼側プリファレンス Caller Preferences for the Session Initiation Protocol (SIP) 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準トラッ クプロトコルを規定するものであり、改善のための議論や提案を依頼するもの である。標準化の段階や、プロトコルの位置付けについては、最新版の "Internet Official Protocol Standards" (STD 1)を参照されたい。この文書 の配布は無制限である。 著作権表記 Copyright (C) The Internet Society (2004). 概要 本文書は、サーバーのリクエスト処理に関するプリファレンス(preferences: 優先、希望)を発呼側が表すことを可能にする、セッション開始プロトコル (Session Initiation Protocol/SIP)の拡張セットについて説明する。このよ うなプリファレンスには、リクエストのルート先である統一リソース識別子 (Uniform Resource Identifiers/URI)を選択する機能、プロキシサーバーとリ ダイレクトサーバーにおいて、特定のリクエスト処理コマンドを指定する機能 が含まれる。このような機能を実行するために、Accept-Contact、Reject- Contact、Request- Dispositionという3つのリクエストヘッダーフィールドが 新たに定義される。これらによって、発呼側のプリファレンスが規定される。 Rosenberg, et al. Standards Track [Page 1] RFC 3841 Caller Preferences for SIP August 2004 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 用語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. 定義 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. 操作の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. UACの動作 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. リクエスト処理プリファレンス . . . . . . . . . . . . . . 6 5.2. フィーチャーセットプリファレンス . . . . . . . . . . . . 6 6. UASの動作 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. プロキシの動作 . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Request-Dispositionの処理 . . . . . . . . . . . . . . . . 9 7.2. プリファレンスと能力のマッチング . . . . . . . . . . . . 9 7.2.1. 明示的プリファレンスの抽出 . . . . . . . . . . . . 10 7.2.2. 暗示的プリファレンスの抽出 . . . . . . . . . . . . 10 7.2.2.1. メソッド . . . . . . . . . . . . . . . . 10 7.2.2.2. イベントパッケージ . . . . . . . . . . 11 7.2.3. コンタクト述部の構築 . . . . . . . . . . . . . . 11 7.2.4. マッチング . . . . . . . . . . . . . . . . . . . . 12 7.2.5. 例 . . . . . . . . . . . . . . . . . . . . . . . . 16 8. フィーチャーパラメータから述部へのマッピング . . . . . . . . . 17 9. ヘッダーフィールドの定義 . . . . . . . . . . . . . . . . . . 19 9.1. Request Disposition . . . . . . . . . . . . . . . . . . 20 9.2. Accept-Contact and Reject-Contactヘッダーフィールド . . 21 10. Augmented BNF . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. セキュリティの考慮 . . . . . . . . . . . . . . . . . . . . . . 22 12. IANA条項 . . . . . . . . . . . . . . . . . . . . . . . . . . 23 13. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 14. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . 24 14.1. 規範となる参考文献 . . . . . . . . . . . . . . . . . . 24 14.2. 有益な参考文献 . . . . . . . . . . . . . . . . . . . . . 24 15. 著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . . 25 16. 完全な著作権表示 . . . . . . . . . . . . . . . . . . . . . . 26 1. はじめに セッション開始プロトコル(SIP)(参考文献[1])サーバーがリクエストを受信す るとき、リクエストの処理に関して実行可能な判断が多数ある。例を以下に挙 げる。 o リクエストをプロキシするかリダイレクトするか o プロキシまたはリダイレクトするのはどのURIか o フォークするかどうか o 再帰的に検索するかどうか Rosenberg, et al. Standards Track [Page 2] RFC 3841 Caller Preferences for SIP August 2004 o 検索はパラレルかシーケンシャルか サーバーは、任意のローカルポリシーに基づいて、このような判断を下せる。 このポリシーは、静的に構成するか、プログラムの実行またはデータベースア クセスに基づいて構成することができる。 ただし、サーバーの管理者は、リクエスト処理に関与する唯一のエンティティ ではない。関与するパーティは、少なくとも以下の3つがある。(1) サーバー の管理者、(2) リクエストを送信するユーザー、(3) リクエストの送信先ユー ザーである。管理者の命令は、サーバーのポリシーに組み込まれている。リク エストの送信先であるユーザー(リクエストメソッドがINVITEでない場合で も、着呼側(callee)と呼ぶ)のプリファレンスは、CPL(Call Processing Language/呼処理言語/参考文献[11])など、何らかのスクリプト言語でスクリ プトを記述することで、最も容易に表現できる。ただし、リクエストを送信す るユーザー(リクエストメソッドがINVITEでない場合でも、発呼側(caller)と も呼ぶ)のプリファレンスを組み込むためのメカニズムは存在しない。たとえ ば、発呼側は、特定ユーザーと話したいが、仕事上の電話であるため、相手が 職場にいるときにのみ連絡したい場合がある。別の例では、発呼側は、ある ユーザーと連絡を取りたいが、重要な要件で発呼側が着呼側と話す必要がある ため、ボイスメールは使用したくない場合がある。どちらの例でも、発呼側の プリファレンスは、要するに、プロキシで、発呼側のプリファレンスに基づい て特定のルーティングを選択させる、ということになる。 この拡張によって、発呼側は、このようなプリファレンスを実現できるように なる。発呼側が、リクエスト処理ついて、プリファレンスを提示できるメカニ ズムを指定することによって、実現することができる。2種類のプリファレン スがある。1つはリクエスト処理プリファレンスと呼ばれ、 Request-Dispositionヘッダーフィールドでカプセル化される。プリファレン スには、サーバーに対するリクエスト処理命令が含まれる。もう1つはフィー チャープリファレンスと呼ばれ、Accept-ContactとReject- Contactヘッダー フィールドで提示される。これらのヘッダーフィールドによって、発呼側は、 連絡先のUAの特性についてプリファレンスを表現するフィーチャーセット(参 考文献[2])を提示することができる。これらは、UAからレジストラに対して提 示されたフィーチャーセットとマッチングされる(参考文献[3])。この拡張の 用途は非常に一般的であり、特定のサービスに限定されない。言い替えると、 数多くのサービスを開発するときに使用できるツールである。 発呼側プリファレンスによって可能になるサービスとして、たとえば「ワンナ ンバー(one number)」サービスがある。ユーザーは、携帯電話、PDA、職場の 電話、自宅の電話など、使用するすべてのデバイスに、1つのアイデンティ ティ(SIP URI)を指定することができる。相手が職場の電話で受けることを発 呼側が望む場合、相手のURIに発呼するときに、プルダウンメニューのオプ ションから「職場の電話」を選択するだけでよい。ユーザーは、各デバイスご とに異なるアイデンティティを維持したり、分ける必要はなくなる。 Rosenberg, et al. Standards Track [Page 3] RFC 3841 Caller Preferences for SIP August 2004 2. 用語 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「MAY」、「OPTIONAL」はRFC2119のBCP 14(参考文献[4])に 記載されるとおりに解釈されるべきであり、CPL準拠の実装のための実装レベ ルを示すものである。 3. 定義 本仕様で使用する用語の多くは、参考文献[3]に記載されている。本仕様で は、さらに以下の用語を定義する。 発呼側(Caller): 本仕様内では、発呼側とは、UACによって操作を代行される ユーザーを指す。UACでINVITEリクエストを送信するユーザーには限定され ない。 フィーチャープリファレンス(Feature Preferences): リクエストのルート先 であるUAに対して希望する特性(property)を記述する、発呼側プリファレ ンス。フィーチャープリファレンスは、Accept-ContactとReject-Contact ヘッダーフィールドを使用して明示的に指定することができる。 リクエスト処理プリファレンス(Request Handling Preferences:): サーバー に対して希望するリクエストの扱い方について記述する発呼側プリファレ ンス。このプリファレンスは、Request-Dispositionヘッダーフィールドで 伝達される。 ターゲットセット(Target Set): ターゲットセットは、プロキシサーバーまた はリダイレクトサーバーがリクエストを送信またはリダイレクトする先の 候補となる、URIのセットである。ターゲットセットを登録から取得するこ とはよくあるが、そうする必要はない。 明示的プリファレンス(Explicit Preference): Accept-ContactまたはReject- Contactヘッダーフィールドで明示的に指定される発呼側プリファレンス。 暗示的プリファレンス(Implicit Preference): リクエストの他の側面によっ て暗示される発呼側プリファレンス。たとえば、リクエストメソッドが INVITEの場合、INVITEメソッドに対応するUAにリクエストを送信するこ と、という暗示的発呼側プリファレンスを示す。 4. 操作の概要 発呼側がリクエストを送信するときに、サーバーに対して特定の処理を要求す る、新規のヘッダーフィールドをオプションで含めることができる。このよう なプリファレンスは、2つのカテゴリに分類される。1つ目のカテゴリはリクエ スト処理プリファレンスと呼ばれ、Request-Dispositionヘッダーフィールド で伝達される。このヘッダーフィールドでは、サーバーに対して希望する動作 を指定する。リクエスト処理プリファレンスには、発呼側がサーバーに対し Rosenberg, et al. Standards Track [Page 4] RFC 3841 Caller Preferences for SIP August 2004 て、プロキシするかリダイレクトするかという希望、シーケンシャル検索かパ ラレル検索かという希望が含まれる。このプリファレンスは、呼のシグナリン グパスですべてのプロキシサーバーまたはリダイレクトサーバーで適用するこ とができる。 プリファレンスの2つ目のカテゴリはフィーチャープリファレンスと呼ばれ、 Accept-ContactとReject- Contactヘッダーフィールドで伝達される。これら のヘッダーフィールドには、フィーチャーセットが含まれる。フィーチャー セットは、能力(capability/参考文献[3])の指定に使用されるのと同じフィー チャーパラメータによって示される。本書では、フィーチャーパラメータと は、発呼側プリファレンスを示す。Accept-Contactヘッダーフィールドには、 発呼側が連絡したいUAを記述した、フィーチャーセットが含まれる。Reject- Contactヘッダーフィールドには、UAが一致する場合、リクエストをそのUAに ルートするべきではない、ということを意味するフィーチャーセットが含まれ る。 プロキシは、Accept-ContactとReject-Contactヘッダーフィールドの情報を使 用して、ターゲットセットの連絡先から選択する。どちらのヘッダーフィール ドも提示されない場合、プロキシは、リクエストから暗示的プリファレンスを 算出する。暗示的プリファレンスは、リクエストに明示的に指定されていない が、他のメッセージ要素が存在することから推測可能な、発呼側プリファレン スである。たとえば、リクエストメソッドがINVITEの場合、INVITEメソッドに 対応するUAにリクエストをルートすること、という暗示的発呼側プリファレン スということになる。 リクエスト処理プリファレンスとフィーチャープリファレンスのどちらも、 INVITEだけでなく、任意のリクエストに出現する可能性があるるただし、役に 立つのは、リクエストについて、プロキシがリクエスト対象を決定する必要が ある場合のみである。リクエストパス上にあるプロキシが、Request-URIに含 まれるドメインを所有していない場合、そのようなプロキシはロケーション サービスにアクセスすることはないため、発呼側プリファレンスを適用する機 会が存在しない。通常、Request-URIによって、ダイアログ中(mid-dialog)の リクエストを送信するUASを識別するため、これは筋が通っている。このよう な場合、ルーティングの判断は最初のリクエストですでに行われており、同じ ダイアログの後続のリクエストに対して判断を再実行することは意味がない。 5. UACの動作 リクエストのプリファレンスを示すことを希望する発呼側は、自身のプリファ レンスに応じて、Accept-Contact、Reject-Contact、Request-Disposition ヘッダーフィールドをリクエストに含める。リクエストの送信後、別の動作は 不要である。 Accept-Contact、Reject-Contact、Request-Dispositionヘッダーフィールド を、ACKリクエスト(非2xx最終応答に対するもの)またはCANCELリクエストに使 用する場合、承認またはキャンセルされる元のリクエストと同じ値にしなけれ ばならない[MUST]。これは、ステートレスプロキシを使用する場合でも正しく 操作できるようにするためである。 Rosenberg, et al. Standards Track [Page 5] RFC 3841 Caller Preferences for SIP August 2004 本仕様で説明されるヘッダーフィールドを理解するサーバーがパス上に存在す るかどうかについて、UACが判断したい場合、UACは、「pref」の値を指定した Proxy-Requireヘッダーフィールドをリクエストに含める。このリクエストが 420応答コードで失敗した場合、UACは、パス上のプロキシがこの拡張に対応し ていないことを判断できる。この場合、UACは再試行すべきである[SHOULD]。 また、発呼側プリファレンスを使用すべきかどうかを決定してもよい。UAは、 対応しているかどうかを知ることがリクエスト処理に不可欠である場合にの み、Proxy-Requireを使用すべきである。注意が必要なのは、どのような場合 でも、発呼側プリファレンスはあくまでも希望であり、要求したサービスが実 行されるという保証はない、ということである。したがって、Proxy-Require ヘッダーフィールドを含めることは、プリファレンスが実行されることではな く、単にプロキシが発呼側プリファレンス拡張を理解しているということでし かない。 5.1. リクエスト処理プリファレンス Request-Dispositionヘッダーフィールドでは、サーバーがリクエストを処理 する方法について発呼側プリファレンスを指定する。ヘッダーフィールドの値 は、トークンの一覧であり、各トークンで具体的な処理命令を指定する。 このヘッダーフィールドの構文はセクション10を参照のこと。処理命令のセマ ンティクスはセクション9.1を参照のこと。 5.2. フィーチャーセットプリファレンス UACは、SIPリクエストを送信した結果、連絡を希望するUAまたは連絡を希望し ないUAの能力について、発呼側プリファレンスを指定することができる。この 場合、UACは、Accept-ContactとReject-Contactヘッダーフィールド値を1つ以 上追加する。各ヘッダーフィールド値には、フィーチャーセットを定義する フィーチャーパラメータのセットが含まれる。このヘッダーフィールドの構文 はセクション10を参照のこと。使用方法の論議はセクション9.2を参照のこ と。 各フィーチャーセットは、参考文献[3]のセクション5で説明されている通りに 構築される。これらのヘッダーフィールドに指定するフィーチャーセットは、 重複してもよい[MAY]。つまり、UAは、RFC2533(参考文献[2])のマッチングア ルゴリズムに従って一致するフィーチャーセットについて、プリファレンスを 指定してもよい[MAY]。 UACは、あるUAが対応するメソッドとイベントパッケージについて、明示的プ リファレンスを示すことができる。UAは、Accept-Contactフィーチャーセット に「sip.methods」フィーチャータグを指定した項(term)を含めることが推奨 される[RECOMMENDED](ただし、注意が必要なのは、このフィーチャータグの名 前がsip.methodsの場合でも、Accept-Contactヘッダーフィールドでは単に 「methods」とエンコードされるということである)。このフィーチャータグの 値には、リクエストのメソッドを含める。UAがSUBSCRIBEリクエストを送信す る場合、UAは、Accept-Contactフィーチャーセットに「sip.events」フィー チャータグを指定した項を含め、フィーチャータグの値にはリクエストのイベ ントパッケージを含めることが推奨される[RECOMMENDED]。これらの項を新規 Rosenberg, et al. Standards Track [Page 6] RFC 3841 Caller Preferences for SIP August 2004 のフィーチャーセットに指定するかどうか、または各フィーチャーセットに含 めるかどうかについては、実装者の裁量に委ねられる。ほとんどの場合、各 フィーチャーセットに項を含めることで正しい効果が実現する。 たとえば、以下のAccept-Contactヘッダーフィールドは、参考文献[3]の フィーチャーパラメータを使用して、呼をモバイルデバイスにルートする、と いう希望を示す。 Accept-Contact: *;mobility="mobile";methods="INVITE" Reject-Contactヘッダーフィールドを使用すると、UACは、このヘッダー フィールド値のいずれかにUAが一致する場合、そのUAにはコンタクトすべきで はない、と指定することができる。構文をSIP拡張のガイドライン(参考文献 [12])と合わせる目的でのみ、Reject-Contactヘッダーフィールドの各値に 「*」を含める。フィーチャーパラメータに記述されるフィーチャーセットと 一致する能力を持つUAはすべて、この値と一致する。 Accept-Contactヘッダーフィールドを使用すると、UACは、このヘッダー フィールド値の一部またはすべてにUAが一致する場合、そのUAにコンタクトす べきである、と指定することができる。Accept-Contactヘッダーフィールドの 各値は、「*」を含み、フィーチャーパラメータのセットによってパラメータ 化される。フィーチャーパラメータに記述されるフィーチャーセットと一致 する能力を持つUAはすべて、この値と一致する。厳密な動作は、「require」 パラメータと「explicit」パラメータが存在するかどうかによって変わる部分 が大きい。両方が存在する場合、プロキシは、希望のフィーチャーセットに対 応すると明示的に示されたコンタクト先に対してのみ、リクエストを転送 (forward)する。それ以外は破棄される。したがって、UACは、コンタクト先が 確定的に一致しない場合に呼をエラーにしたいときにのみ、「require」と 「explicit」の両方を使用すべきである。UAは希望する機能に対応するが、登 録時にはそのことを示さなかった、という可能性がある。UACが「explicit」 と「require」の両方を使用する場合、このようなコンタクト先には到達しな い。したがって、この組み合わせは、UACが希望するものではないことが多 い。 「require」のみが存在する場合、コンタクト先が一致しない場合は使用され ない、ということを意味する。一致する場合、または完全な一致かどうかが不 明な場合、そのコンタクト先は使用される。一致しないコンタクト先が不要な 場合、UACは「require」のみを使用する。これは、必須の機能がなければ単に リクエストが使用できない、というサービスの場合に一般的である。たとえ ば、特定のメソッドやイベントパッケージへの対応である。また、 「require」のみが存在する場合、プロキシは、「最も」一致するUAに対し て、リクエストを優先的にルートする。この「最も」とは、そのUAが、希望の 機能について、他の全UAよりも多く対応していることを、明示的に示して いる、ということを意味する。ただし、このプリファレンスのルーティング は、着呼側が提供する命令より優先されることはない、ということに注意。プ リファレンスのルーティングは、同じq値を持つコンタクト先の中からのみ、 選択される。 Rosenberg, et al. Standards Track [Page 7] RFC 3841 Caller Preferences for SIP August 2004 「explicit」のみが存在する場合、着呼側が提示したすべてのコンタクト先が 使用される、ということを意味する。ただし、コンタクト先が明確に一致しな い場合、そのコンタクト先は、同じq値を持つ他の全コンタクト先の後に試行 される。したがって、この構成と、「require」と「explicit」を両方使用す る方法の主な違いは、コンタクト先が明確に一致しない場合の代替動作であ る。「explicit」のみの場合、このようなコンタクト先は最後の手段として試 行される。「require」も存在する場合、このようなコンタクト先が試行され ることはない。 最後に、「require」と「explicit」のどちらも存在しない場合、着呼側が提 示したすべてのコンタクト先が使用される、ということを意味する。ただし、 コンタクト先が一致しない場合、そのコンタクト先は、同じq値を持つ他の全 コンタクト先の後に試行される。一致する場合、リクエストは、「最も」一致 するものに対して優先的にルートされる。これは、プリファレンスが順守され ないときでも呼の成功を許容し、一致する部分が多いほど良い場合に一般的な 構成である。 6. UASの動作 本仕様に準拠するUASは、登録済みコンタクト先のいずれかにRequest-URIが相 当するリクエストを受信した場合、そのRequest-URIに含まれるドメインのプ ロキシであるかのように、セクション7.2で説明する動作を適用すべきである [SHOULD]。UASは、そのRequest-URIのリクエスト対象がロケーションデータ ベースに1つ含まれているように動作する。この対象は、フィーチャーセット に関連付けられる。このフィーチャーセットは、Request-URIに含まれるURIの 登録で指定されているものと同一である。UAが、別個の複数Addresses-of- Recordに対して登録し、それぞれに登録されたコンタクト先の能力が異なる場 合、各登録ごとに異なるURIを使用して、使用すべきフィーチャーセットを判 断することができる。 この処理は、クライアントがリクエストを認証(authenticate)および認可 (authorize)した後に実行される。ただし、RFC3261のセクション8.2.1で説明 されている、残りの一般的なUAS処理の前に実行される。 この処理を実行した後に、ターゲットセットにURIが残らない場合、UAは、リ クエストを480応答で拒否すべきである[SHOULD]。URIが残っている場合(開始 可能なURIが1つのみ存在する場合)、UAは、RFC3261に従ってリクエスト処理を 進行する。 プロキシのようにマッチング操作をUASに実行させることによって、プロキシ が本拡張に対応していない場合でも、特定の発呼側プリファレンスを順守する ことができる。 UASは、リクエストのRequest-Dispositionヘッダーフィールドで提示される queue命令を処理すべきである[SHOULD]。その他の命令は、無視しなければな らない[MUST]。 Rosenberg, et al. Standards Track [Page 8] RFC 3841 Caller Preferences for SIP August 2004 7. プロキシの動作 プロキシの動作は、2つの直交規則で構成される。1つは、Request- Dispositionヘッダーフィールドの規則、もう1つはAccept-ContactとReject- ContactヘッダーフィールドのURIとフィーチャーセットのプリファレンスを処 理するための規則である。 このようなヘッダー処理とは別に、プロキシは、UACのように、これらのヘッ ダーフィールドが存在しない場合は追加したり、既存のヘッダーフィールドに 値を追加してもよい[MAY]。これは、プロキシが、ある機能の実装において、 ダウンストリームのプロキシに処理を要求する場合に有効である。ただし、プ ロキシは、既存のヘッダーフィールド値を修正または削除してはならない [MUST NOT]。これは、S/MIMEが使用されている場合に特に重要である。メッ セージシグネチャには、発呼側プリファレンスのヘッダーフィールドを含める ことができる。これによって、プロキシがヘッダーフィールドを追加した場合 でも、元の発呼側プリファレンスが残っていることを、UASが検証できる。 7.1. Request-Dispositionの処理 リクエストにRequest-Dispositionヘッダーフィールドが含まれ、それが Request-URIに含まれるドメインのオーナーである場合、サーバーは、セク ション9.1の説明通りにその命令を実行すべきである[SHOULD]。ただし、それ とは別の命令を実行するように構成されたローカルポリシーがある場合は、例 外である。 7.2. プリファレンスと能力のマッチング 本仕様に準拠するプロキシは、Request-URIに含まれるドメインのオーナーで あり、かつリクエスト対象に関連付けられる能力を持つローカルサービスにア クセスしている場合を除き、本書に記載されているプリファレンスのマッチン グ操作を、リクエストに適用してはならない[MUST NOT]。一方で、プロキシが ドメインのオーナーであり、かつリクエスト対象と関連付けられる能力を持つ ローカルサービスにアクセスしている場合は、このセクションに記載される処 理を適用すべきである[SHOULD]。通常、これは、登録データベースを使用して リクエスト対象を決定するプロキシである。ただし、プロキシが他の方法に よって能力を知ることができる場合、同様に、ここで定義される処理を適用す べきである[SHOULD]。処理を実行する場合、下記の通りに実行しなければなら ない[MUST]。 処理の説明として、本仕様に記載される構文をRFC2533(参考文献[2])構文へ変 換する処理の次に、マッチング操作と、結果となるコンタクト値のソートが続 く。中間手順のRFC2533構文の仕様は、必須ではない。RFC2533構文は、プロキ シに必要な動作を記述する上で有効なツールとして機能する、というだけであ る。ここで説明する処理を使用して達成される結果と同じ結果が得られるので あれば、プロキシは任意の手順を使用することができる。 Rosenberg, et al. Standards Track [Page 9] RFC 3841 Caller Preferences for SIP August 2004 7.2.1. 明示的プリファレンスの抽出 プロキシ処理の最初の手順は、明示的プリファレンスの抽出である。この場 合、プロキシはAccept-ContactとReject-Contactヘッダーフィールドを探す。 プロキシは、これらのヘッダーフィールドの各値について、フィーチャーパラ メータを抽出する。ヘッダーフィールドパラメータの名前は、「audio」、 「automata」、「class」、「duplex」、「data」、「control」、 「mobility」、「description」、「events」、「priority」、「methods」、 「extensions」、「schemes」、「application」、「video」、 「language」、「type」、「isfocus」、「actor」、「text」、または、名前 がプラス記号(+)から始まるパラメータである(参考文献[3])。プロキシは、セ クション8の規則に基づいて、以上のパラメータをすべてRFC2533の構文に変換 する。 結果として、論理積正規形(conjunctive normal form)であるフィーチャー セット述部のセットになり、それぞれが、2つのプリファレンスヘッダー フィールドの1つに関連付けられる。Accept-Contactヘッダーフィールド値に 関連付けられたreqパラメータが存在する場合、そのヘッダーフィールド値か ら派生するフィーチャーセット述部に、requireフラグセットがあると考えら れる。同様に、Accept-Contactヘッダーフィールド値に関連付けられた explicitパラメータが存在する場合、そのヘッダーフィールド値から派生する フィーチャーセット述部に、explicitフラグセットがあると考えられる。 7.2.2. 暗示的プリファレンスの抽出 プロキシがリクエストから明示的プリファレンスを検出できなかった場合 (Accept-ContactまたはReject-Contactヘッダーフィールドがない場合)にの み、プロキシは暗示的プリファレンスを抽出する。暗示的プリファレンスと は、リクエストに存在する他の情報で暗示されるプリファレンスである。 最初に、プロキシは、項のない論理積(conjunction)を作成する。この論理積 は、Accept-Contactヘッダーフィールドが含まれているかのように、Accept- Contactに関連付けられるフィーチャーセットを示す。暗示されるメッセージ の修正はない、ということに注意すること。これは、処理の目的に合わせた関 連付けでしかない。さらに、このフィーチャーセットにrequireフラグセット はあるが、explicitフラグはない、ということにも注意すること。 次に、プロキシは、以下に示す2つの暗示的プリファレンスの項を論理積に追 加する。 7.2.2.1. メソッド 1つ目の暗示的プリファレンスはメソッドである。UACがあるメソッドを含むリ クエストを送信する場合、これは、そのメソッドに対応するUAにのみルートす るように、という要求がある暗示的プリファレンスである。この暗示的プリ Rosenberg, et al. Standards Track [Page 10] RFC 3841 Caller Preferences for SIP August 2004 ファレンスに対応するには、プロキシは、以下の形式で論理積に項を追加す る。 (sip.methods=[リクエストのメソッド]) 7.2.2.2. イベントパッケージ サブスクリプションを確立するリクエスト(参考文献[5])の場合、Eventヘッ ダーフィールドも暗示的プリファレンスを示すものとして使用できる。Event ヘッダーフィールドは、指定したイベントパッケージに対応するサーバーにの みリクエストをルートするように希望を表す。この暗示的プリファレンスに対 応するには、プロキシは、以下の形式で論理積に項を追加する。 (sip.events=[Eventヘッダーフィールドの値]) 7.2.3. コンタクト述部の構築 次に、プロキシは、ターゲットセット(プロキシまたはリダイレクトする予定 のURIのセット)の各URIから、RFC2533形式のフィーチャーセット述部として能 力を取得する。これは、コンタクト述部と呼ばれる。登録によってターゲット URIを取得した場合、プロキシがコンタクト述部を算出するには、Contactヘッ ダーフィールドからフィーチャーパラメータを抽出(参考文献[5])してから、 それをフィーチャー述部に変換する。フィーチャーパラメータを抽出するに は、プロキシは以下の手順を実行する。 1. 最初に、フィーチャーパラメータの空リストを作成する。 2. Contact URIパラメータに、「audio」、「automata」、「class」、 「duplex」、「data」、「control」、「mobility」、「description」、 「events」、「priority」、「methods」、「schemes」、 「application」、「video」、「actor」、「language」、「isfocus」、 「type」、「extensions」、「text」のいずれかが含まれる場合、このリ ストにコピーする。 3. Contact URIパラメータ名が「+」で始まる場合、「+」記号を除いた名前の パラメータがリストに含まれていなければ、リストにコピーする。つま り、「video」フィーチャーパラメータがリストにある場合、「+video」パ ラメータはリストに加えない。クライアントが参考文献[3]に準拠している 場合、このような衝突は発生しない。理由は、ベースセットのフィー チャータグをエンコードする場合、「+」形式を使用するのは規約違反にな るためである。 ターゲットセットのURIにフィーチャーパラメータがない場合、発呼側プリ ファレンス処理を免除されていると考えられる。つまり、URIをターゲット セットから一時的に削除し、以下の発呼側プリファレンス処理を実行してか ら、削除したURIを追加し直す。 Rosenberg, et al. Standards Track [Page 11] RFC 3841 Caller Preferences for SIP August 2004 URIにフィーチャーパラメータがある場合、フィーチャーパラメータは、セク ション8の規則を使用してRFC2533構文に変換される。 結果の述部は、q値に関連付けられる。REGISTERリクエストによってコンタク ト述部を知った場合、q値は、Contactヘッダーフィールドパラメータのq値(指 定されていなければ「1.0」)と同一である。 たとえば、以下の登録済みContactヘッダーフィールドがあるとする。 Contact: ;audio;video;mobility="fixed"; +sip.message="TRUE";other-param=66372; methods="INVITE,OPTIONS,BYE,CANCEL,ACK";schemes="sip,http" これは、以下の述部に変換される。 (& (sip.audio=TRUE) (sip.video=TRUE) (sip.mobility=fixed) (sip.message=TRUE) (| (sip.methods=INVITE) (sip.methods=OPTIONS) (sip.methods=BYE) (sip.methods=CANCEL) (sip.methods=ACK)) (| (sip.schemes=sip) (sip.schemes=http))) この「other-param」は、ベースタグではなく、先頭が「+」でもないため、 フィーチャーパラメータとして扱われなかった、ということに注意。 7.2.4. マッチング 注意が必要なのは、プロキシは、マッチング操作を実行するために比較する フィーチャータグの意味について、何も知る必要がない、ということである。 比較を実行するための規則は、各フィーチャータグの値に存在する構文上のヒ ントによって変わる。たとえば、以下のような述部があるとする。 (foo>=4) これは、フィーチャータグ「foo」は数値であることを暗示する。RFC2533の マッチング規則では、フィーチャータグが、数値、トークン、引用符付き文字 列のどれであるかがわかる実装のみを必要としている(ブールはトークンと扱 われる)。引用符付き文字列は、常に大文字小文字を区別するマッチング操作 を使用して、マッチングされる。トークンは、大文字小文字を区別せずにマッ チングされる。これら2つの場合は、フィーチャータグ値を囲む山かっこが存 在するかどうかで区別される。山かっこが存在する場合(つまり +sip.foo="")、大文字小文字を区別する文字列を意味する。山かっこ Rosenberg, et al. Standards Track [Page 12] RFC 3841 Caller Preferences for SIP August 2004 が存在しない場合(つまり +sip.foo="val")、大文字小文字を区別しないこと を意味する。数値は、通常の数学的な比較を使用してマッチングされる。 最初に、プロキシは、Reject-Contactヘッダーフィールドに関連付けられる述 部を適用する。 各コンタクト述部について、各Reject-Contact述部(つまり、Reject-Contact ヘッダーフィールドと関連付けられる各述部)を検討する。Reject-Contact述 部にフィーチャータグのフィルタが含まれ、そのフィーチャータグがコンタク ト述部のどこにも存在しない場合、そのReject-Contact述部は、コンタクト述 部処理のために破棄される。Reject-Contact述部を破棄しない場合、RFC2533 (参考文献[2])のマッチング操作を使用してコンタクト述部とマッチングされ る。結果が一致の場合、そのコンタクト述部に相当するURIは、ターゲット セットから破棄される。 結果として、Reject-Contactによって、希望しない機能に対応することを明示 的に示したUAの場合にのみ、URIが破棄されることになる。 次に、プロキシは、Accept-Contactヘッダーフィールドに関連付けられる述部 を適用する。ターゲットセットに残っている各コンタクト先ごとに、プロキシ は1つのマッチングセットを構築する(M)。最初に、このセットには、Accept- Contact述部のすべてが含まれる。この各述部が検証される。RFC2533(参考文 献[2])のマッチング操作を使用して、コンタクト述部とマッチングされる。結 果が一致ではなく、Accept-Contactにrequireフラグセットがある場合、その コンタクト述部に相当するURIは、ターゲットセットから破棄される。結果が 一致ではないが、Accept-Contactにrequireフラグセットがない場合、そのコ ンタクトのURIはターゲットセットから破棄されないが、Accept-Contact述部 は、そのコンタクトのマッチングセットから削除される。 ターゲットセットに残っている各コンタクト先について、プロキシは、そのコ ンタクトのマッチングセットに含まれる各述部に対して、コンタクトのスコア を算出する。Accept-Contact述部に含まれる論理積の項の数を、Nとイコール にする。その述部の各項には、1つのフィーチャータグが含まれる。Contact述 部に、同じフィーチャータグを含む項がある場合、スコアは1/Nずつインクリ メントされる。フィーチャータグがコンタクト述部に存在しなかった場合、ス コアはそのまま変化しない。以上の規則に基づくため、スコアの範囲は0〜1に なる。 Rosenberg, et al. Standards Track [Page 13] RFC 3841 Caller Preferences for SIP August 2004 T +----------> DROP Contact | | / \ / \ T / \ F +---->/require\------> Set score=0 | \ / | \ / / \ \ / / \ \/ score<1 / \ +-------> /explicit----> Score unchanged | \ / F | \ / / \ \ / / \ \/ +--------+ / \ -->|Compute |--> /Score \ --------> Score unchanged | Score | \ / score=1 +--------+ \ / \ / \/ 図1: スコアの適用 次にrequireタグとexplicitタグを適用すると、スコアとターゲットセットが 修正される可能性がある。この処理の概要を、図1に示す。そのAccept- Contact述部に対するコンタクト述部のスコアが1未満であり、Accept-Contact 述部にexplicitタグがあり、さらに述部にrequireタグもある場合、そのコン タクト述部に相当するContact URIは落とされる。ただし、この述部にrequire タグがなかった場合、スコアは0に設定される。explicitタグがなかった場 合、スコアは変更されない。 次の手順では、スコアと、マッチングセットの述部に関連付けられたq値とを 組み合わせて、総合的な発呼側プリファレンスQaを実現する。残っているター ゲットセットのURIについて、マッチングセットの各Accept-Contact述部に対 するマッチを示すスコアができる。MのAccept-Contact述部がマッチングセッ トにある場合、各コンタクトごとに、S1〜SMまでのMスコアがある。総合的な 発呼側プリファレンスQaは、S1〜SMの数学的平均である。 Rosenberg, et al. Standards Track [Page 14] RFC 3841 Caller Preferences for SIP August 2004 この時点で、発呼側プリファレンスから免除されていたためにターゲットセッ トから削除したURIを戻し、そのURIのQaを1.0に設定する。 発呼側プリファレンスQaの目的は、着呼側が順序を指定しなかった場合に、 ターゲットセットに残っているコンタクトに順位付けすることである。これを 実行するには、ターゲットセットに残っているコンタクトを、着呼側から提供 されたq値によってソートする。ソート後、同じq値を持つコンタクトがすべて 同じ等値クラス(equivalence class)に含まれるように、等値クラスにグルー プ化する。次に、各等値クラス内で、Qa値に基づいてコンタクトに順位付けす る。結果として、プロキシが使用するコンタクトの順位付き一覧になる。 このセクションの処理を適用した後に、ターゲットセットにURIが存在せず、 発呼側プリファレンスが暗黙的プリファレンス(セクション7.2.2)に基づいて いた場合、このセクションの処理は破棄され、元のターゲットセット(元のq値 で順位付けされている)が使用される。 この処理で、メソッドまたはイベントパッケージの暗示的プリファレンス によって、すべてのターゲット候補が削除された場合に対応することがで きる。元のターゲットセットに戻ることによって、それらのURIが試行さ れ、結果として405または489応答が生成される。次に、UACは、この情報を 使用して再試行するか、エラーをユーザーに報告することができる。元の ターゲットセットに戻さないと、UACは480応答を受信するため、リクエス トが失敗した理由がわからない。当然ながら、明示的プリファレンスの適 用後に、ターゲットセットを空にすることもできる。この結果、プロキシ によって480応答が生成される。この動作は適用可能であり、実際のとこ ろ、明示的プリファレンスの場合には望ましい。発呼側が明示的プリファ レンスを作成するとき、プリファレンスの不一致によったリクエストが失 敗する可能性について、発呼側は了承している。発呼側が再試行できるよ うに、着呼側の能力を示すエラーを返そうと試行することもできる。ただ し、そうすると、着呼側からの認可がないまま、機密である可能性のある 情報を発呼側に漏らす結果になる。したがって、本仕様では、その方法を 提供しない。 プロキシサーバーが再帰している場合、プロキシサーバーは、リダイレクト応 答で返ってきたContactヘッダーフィールドをターゲットセットに追加して、 発呼側プリファレンスアルゴリズムを再適用する。 サーバーがリダイレクトしている場合、ターゲットセットのすべてのエントリ を返す。上記の処理で決定された順序と同一になるように、q値をこれらのエ ントリに適用する。ただし、ターゲットセットのエントリについて、フィー チャーパラメータを含めてはならない[MUST NOT]。含めると、アップストリー Rosenberg, et al. Standards Track [Page 15] RFC 3841 Caller Preferences for SIP August 2004 ムのプロキシサーバーが同じ発呼側プリファレンスをもう一度適用し、そのプ リファレンスが二重に適用される結果になる。リダイレクトサーバーでは、 フィーチャーパラメータをContactヘッダーフィールドに含めたい場合、発呼 側プリファレンスを適用する前に、元のターゲットセットと元のq値を使用し てリダイレクトしなければならない[MUST]。 7.2.5. 例 以下の例について考察する。この例は作為的だが、マッチング処理のさまざま な要素を説明するのに役立つ。以下のように、sip:user@example.comには5つ のContactが登録されている。 Contact: sip:u1@h.example.com;audio;video;methods="INVITE,BYE";q=0.2 Contact: sip:u2@h.example.com;audio="FALSE"; methods="INVITE";actor="msg-taker";q=0.2 Contact: sip:u3@h.example.com;audio;actor="msg-taker"; methods="INVITE";video;q=0.3 Contact: sip:u4@h.example.com;audio;methods="INVITE,OPTIONS";q=0.2 Contact: sip:u5@h.example.com;q=0.5 sip:user@example.comに送信されたINVITEには、以下の発呼側プリファレンス のヘッダーフィールドが含まれていた。 Reject-Contact: *;actor="msg-taker";video Accept-Contact: *;audio;require Accept-Contact: *;video;explicit Accept-Contact: *;methods="BYE";class="business";q=1.0 この例では、明示的プリファレンスが提示されているため、暗示的プリファレ ンスはない。 最初に、プロキシはターゲットセットからu5を削除する。これは、発呼側プリ ファレンス処理から免除されるためである。 次に、プロキシは、Reject-Contactヘッダーフィールドを処理する。Reject- Contactは、残りのコンタクト4つすべてに一致するが、明示的に一致するのは u3のみである。これは、ビデオの対応を明示的に示し、かつ、自身がメッセー ジ取得機(message taker)であることを明示的に示しているのは、u3のみとい う理由からである。そのため、u3は破棄され、その他は残る。 次に、残っている3つの各コンタクトは、3つの各Accept-Contact述部と比較さ れる。u1は、3つすべてに一致するので、最初の2つの述部については1.0、3つ 目の述部については0.5(methodsフィーチャータグがコンタクト述部にあった が、classタグはなかった)、というスコアを獲得する。u2は1つ目の述部に一 致しない。その述部にはrequireタグがあるため、u2は破棄される。u4は、最 初の述部に一致するため、1.0のスコアを獲得する。u4は2つ目の述部に一致す Rosenberg, et al. Standards Track [Page 16] RFC 3841 Caller Preferences for SIP August 2004 るが、一致は明示的ではないため(実際のところ、スコアは0.0)、スコアは0に 設定される(すでに0だったので、何も変わらない)。u4は3つ目の述部に一致し ない。 この時点で、u1とu4が残る。u1は3つのAccept-Contact述部に一致したため、 マッチセットには、1、1、0.5という3つのスコアが含まれる。u4は、最初の2 つの述部に一致し、1.0と0.0のスコアを獲得している。u1のQaは0.83であり、 u4のQaは0.5である。u5は、1.0のQaで戻される。 次に、ターゲットセットに残っているコンタクトが、q値でソートされる。u5 は0.5、u1とu4はそれぞれ0.2のq値である。2つの等値クラスがある。1つ目のq 値は0.5であり、u5でのみ構成される。このクラスのメンバーは1つしかないた め、クラスをソートしても何も変わらない。2つ目の等値クラスは0.2のq値で ある。そのクラス内で、u1とu4という2つのコンタクトは、Qa値によって順位 付けされる。u1のQaは0.83であり、u4のQaは0.5である。したがって、u1が1番 目になり、u4が2番目になる。結果として、ターゲットセットのコンタクト全 体の順序は、u5、u1、u4になる。 8. フィーチャーパラメータから述部へのマッピング フィーチャーパラメータとフィーチャーセット述部とのマッピングは、 RFC2533(参考文献[2])の構文に従ってフォーマットされていれば、簡単なこと である。このマッピングは、参考文献[3]のセクション5で説明されている処理 とはまったく対照的である。 手順は、フィーチャーパラメータのセットから開始し、以下のように続く。論 理積を構築する。論理積の各項は、1つのフィーチャーパラメータから派生す る。フィーチャーパラメータに値がない場合は、以降の処理に関して、 「TRUE」の値を持っている場合と同等である。 フィーチャーパラメータ値がtag-value-listである場合、この論理積の要素は 論理和(disjunction)である。tag-value-listの各tag-valueごとに、論理和に 1つの項が含まれる。 ここでは、tag-valueからフィルタを構築する場合を考察する。tag-valueが感 嘆符(!)で始まる場合、フィルタは以下の形式になる。 (! ) この「」は、感嘆符が存在し なかった場合に、tag-valueから構築されるフィルタを指す。 Rosenberg, et al. Standards Track [Page 17] RFC 3841 Caller Preferences for SIP August 2004 tag-valueがシャープ記号(#)で始まる場合、フィルタは数値比較になる。比較 演算子は、=、>=、<=、または、フレーズ内の次の数文字に基づく範囲であ る。次の数文字が=、>=、<=のいずれかである場合、フィルタは以下の形式に なる。 (name comparator compare-value) ここで、「name(名称)」は、デコード(後述参照)後のフィーチャーパラメータ 名であり、「comparator(比較演算子)」は、フレーズ内の最初の数文字に応じ て、=、>=、<=のいずれかである。イコールの後のtag-valueに残るテキストに 小数点が含まれる(有理数を意味する)場合、その小数点を、整数IになるまでN 回右にシフトする。次に、上の「compare-value(比較値)」は、「I / 10**N」 に設定される。この「10**N」は、数値10のN乗を算出する結果となる。 シャープ記号の後の値が数値の場合、フィルタは範囲である。フィルタの形式 は以下の通り。 (name=) この「name」は、デコード(後述参照)後のフィーチャータグである。 「」は、#の後のtag-valueに残っているテキストであり、 小数は有理式に変換され、コロンはダブルドット(..)に置換されている。 tag-valueがシャープ記号(#)で始まる場合(感嘆符なしのトークンまたはブー ル)、フィルタは以下の形式になる。 (name=tag-value) この「name」は、デコード(後述参照)後のフィーチャータグである。 フィーチャーパラメータに文字列値が含まれる場合(左山かっこ(「<」)で始ま り、右山かっこ(「>」)で終わることでわかる)、フィルタは以下の形式にな る。 (name="qdtext") 「qdtext」を囲む引用符を明示的に使用することで、その値が文字列であるこ とを示す、ということに注意。RFC2533では、文字列は大文字小文字を区別す る規則で比較され、トークンは大文字小文字を区別しない規則で比較される。 RFC2506(参考文献[13])で規定されるように、Contact、Accept-Contact、 Reject-Contactヘッダーフィールドには、フィーチャータグをヘッダーフィー ルドパラメータとして直接示すことができない。これは、これらの文法に矛盾 があるためであり、フィーチャーパラメータと他の拡張が使用するパラメータ Rosenberg, et al. Standards Track [Page 18] RFC 3841 Caller Preferences for SIP August 2004 とを区別する必要があるためである。したがって、フィーチャータグ値は RFC2506形式からエンコードされ、enc-feature-tagが生成されてから、 RFC2506形式にデコードされる。デコード処理は単純である。先頭にプラス(+) 記号があれば、削除する。すべての感嘆符(!)はコロン(:)に変換し、一重引用 符(')はフォワードスラッシュ(/)に変換する。先頭にプラス記号がなく、エン コード済み名称の残りが、「audio」、「automata」、「class」、 「duplex」、「data」、「control」、「mobility」、「description」、 「events」、「priority」、「methods」、「schemes」、「application」、 「video」、「actor」、「isfocus」、「extensions」、「text」のいずれか である場合、エンコード済み名称の残りに「sip.」を先頭に付け、フィー チャータグ名称を算出する。 たとえば、以下のAccept-Contactヘッダーフィールドがあるとする。 Accept-Contact:*;mobility="fixed" ;events="!presence,message-summary" ;language="en,de";description="";+sip.newparam ;+rangeparam="#-4:+5.125" これは、以下のフィーチャー述部へ変換される。 (& (sip.mobility=fixed) (| (! (sip.events=presence)) (sip.events=message-summary)) (| (language=en) (language=de)) (sip.description="PC") (sip.newparam=TRUE) (rangeparam=-4..5125/1000)) 9. ヘッダーフィールドの定義 本仕様は、Accept-Contact、Reject-Contact、Request-Dispositionという、3 つのヘッダーフィールドを新規に定義する。 図2と図3は、RFC3261(参考文献[1])の表2と表3をAccept-Contact、 Reject-Contact、Request-Dispositionヘッダーフィールドに合わせた拡張で ある。「INF」列はINFOメソッド(参考文献[6])、「PRA」はPRACKメソッド(参 考文献[7])、「UPD」はUPDATEメソッド(参考文献[8])、「SUB」はSUBSCRIBEメ ソッド(参考文献[5])、「NOT」はNOTIFYメソッド(参考文献[5])、「MSG」は MESSAGEメソッド(参考文献[9])、「REF」はREFERメソッド(参考文献[10])を示 す。 Rosenberg, et al. Standards Track [Page 19] RFC 3841 Caller Preferences for SIP August 2004 ヘッダーフィールド 位置 プロキシ ACK BYE CAN INV OPT REG Accept-Contact R ar o o o o o - Reject-Contact R ar o o o o o - Request-Disposition R ar o o o o o o 図2: Accept-Contact、Reject-Contact、Request-Dispositionヘッダー フィールド ヘッダーフィールド 位置 プロキシ ACK BYE CAN INV OPT REG Accept-Contact R ar o o o o o o o Reject-Contact R ar o o o o o o o Request-Disposition R ar o o o o o o o 図3: Accept-Contact、Reject-Contact、Request-Dispositionヘッダー フィールド 9.1. Request Disposition Request-Dispositionヘッダーフィールドでは、サーバーがリクエストを処理 する方法について発呼側プリファレンスを指定する。ヘッダーフィールドの値 は、トークンの一覧であり、各トークンで具体的な命令を指定する。構文はセ クション10に示す。短縮形として文字「d」が定義されたため、注意するこ と。命令は、タイプにグループ化される。1つのリクエストに付き、各タイプ の命令は1つしか存在し得ない(たとえば、同じRequest-Dispositionヘッダー フィールドに「proxy」と「redirect」の両方を指定することはできない)。 発呼側が命令を指定する場合、サーバーはその命令に順守すべきである [SHOULD]。 以下のタイプの命令が定義される。 proxy-directive: このタイプの命令は、発呼側が、各サーバーに対して、プ ロキシ(「proxy」)とリダイレクト(「redirect」)のどちらを希望するかを 示す。 cancel-directive: このタイプの命令は、発呼側が、各プロキシサーバーに対 して、ダウンストリームサーバーからの200 OKへの応答でCANCELリクエス トをダウンストリームに送信(「cancel」)するか(これは通常モードの操作 であり、冗長的になる)、または、この機能を発呼側に残す(「no- cancel」)かについて、希望を示す。プロキシが、「no-cancel」に設定さ れたこのパラメータを含むリクエストを受信する場合、2xxの受信時に、未 解決の分岐(branch)はどれもCANCELすべきではない[SHOULD NOT]。ただ し、6xxの受信時には、未解決の分岐についてCANCELを送信する。 Rosenberg, et al. Standards Track [Page 20] RFC 3841 Caller Preferences for SIP August 2004 fork-directive: このタイプの命令は、プロキシがリクエストをフォークすべ きか(「fork」)、1つのアドレスにのみプロキシすべきか(「no-fork」)に ついて示します。フォークしないように要求されたサーバーは、リクエス トを「最善の」アドレス(通常、最も高いq値のアドレス)にプロキシすべき である[SHOULD]。q値が最高のアドレスが複数存在する場合、サーバーは ローカルポリシーに従って1つを選択する。「redirect」が要求された場 合、命令は無視される。 recurse-directive: このタイプの命令は、3xx応答を受信するプロキシサー バーが、応答に列挙されているアドレスへリクエストを送信すべきか (「recurse」)、アドレスの一覧を発呼側に向けてアップストリームに転送 すべきか(「no-recurse」)を示す。「redirect」が要求された場合、命令 は無視される。 parallel-directive: フォークするプロキシサーバーの場合、この命令のタイ プは、発呼側がプロキシサーバーに対し、既知のアドレスすべてを同時に リクエストをプロキシするか(「parallel」)、前のアドレスの非2xxまたは 非6xxの最終応答を受信した後にのみ、次のアドレスを実行するか (「sequential」)、という希望を示す。「redirect」が要求された場合、 命令は無視される。 queue-directive: 着呼側パーティが一時的に連絡不可能な場合(別の電話に出 ている場合など)、発呼側は、呼をキューしてほしいか(「queue」)、直ち に拒否してほしいか(「no-queue」)を示すことができる。呼がキューされ る場合、サーバーは「182 Queued」を返す。キューされている呼は、参考 文献[1]で説明されているように、中止することができる。 例: Request-Disposition: proxy, recurse, parallel Request-Dispositionの命令セットが拡張できないのは、意図的である。これ は、このヘッダーフィールド経由で「トンネルされる(tunneled)」新規のSIP 拡張が増えないようにするためである。 9.2. Accept-Contact and Reject-Contactヘッダーフィールド このヘッダーフィールドの構文は、セクション10に記載されている。短縮形と して、Accept-Contactヘッダーフィールド用には文字「a」、Reject-Contact ヘッダーフィールドには文字「j」が定義されている。 Rosenberg, et al. Standards Track [Page 21] RFC 3841 Caller Preferences for SIP August 2004 10. Augmented BNF Request-DispositionヘッダーフィールドのBNFは以下の通り。 Request-Disposition = ( "Request-Disposition" / "d" ) HCOLON directive *(COMMA directive) directive = proxy-directive / cancel-directive / fork-directive / recurse-directive / parallel-directive / queue-directive proxy-directive = "proxy" / "redirect" cancel-directive = "cancel" / "no-cancel" fork-directive = "fork" / "no-fork" recurse-directive = "recurse" / "no-recurse" parallel-directive = "parallel" / "sequential" queue-directive = "queue" / "no-queue" Accept-ContactとReject-ContactヘッダーフィールドのBNFは以下の通り。 Accept-Contact = ("Accept-Contact" / "a") HCOLON ac-value *(COMMA ac-value) Reject-Contact = ("Reject-Contact" / "j") HCOLON rc-value *(COMMA rc-value) ac-value = "*" *(SEMI ac-params) rc-value = "*" *(SEMI rc-params) ac-params = feature-param / req-param / explicit-param / generic-param ;;feature param from RFC 3840 ;;generic-param from RFC 3261 rc-params = feature-param / generic-param req-param = "require" explicit-param = "explicit" BNFはあるが、1つのac-paramsには、複数のreq-paramまたはexplicit-paramを 含んではならない[MUST NOT]。さらに、feature-paramに存在するのは、1個の インスタンスのフィーチャータグのみである。 11. セキュリティの考慮 リクエストに発呼側プリファレンスが存在することで、サーバーにおけるリク エスト処理の方法に影響を与える。したがって、発呼側プリファレンスが含ま れるリクエストは、RFC3261のセクション26で既定されるsipsメカニズムで、 整合性を保護するべきである[SHOULD]。 発呼側プリファレンスの処理には、ある程度の計算を必要とする可能性があ る、複数の操作と検索を伴う。このため、ユーザーは、サーバーが過負荷にな ることを狙って、大量の発呼側プリファレンスを指定したリクエストを送信す Rosenberg, et al. Standards Track [Page 22] RFC 3841 Caller Preferences for SIP August 2004 ることで、DOS攻撃が可能になる。これに対抗するために、サーバーは規則が 多すぎるリクエストは拒否すべきである[SHOULD]。適度な数は20前後である。 12. IANA条項 本仕様は、RFC3261(参考文献[1])の手順に従い、3つのSIPヘッダーフィールド を新規に登録する。 Accept-Contactヘッダーフィールドの登録は以下の通り。 RFC番号: RFC 3841 ヘッダーフィールド名: Accept-Contact 短縮形: a Reject-Contactヘッダーフィールドの登録は以下の通り。 RFC番号: RFC 3841 ヘッダーフィールド名: Reject-Contact 短縮形: j Request-Dispositionヘッダーフィールドの登録は以下の通り。 RFC番号: RFC 3841 ヘッダーフィールド名: Request-Disposition 短縮形: d 13. 謝辞 本仕様で使われているメディアフィーチャータグの初期セットは、 ScotPetrackのCMA設計に影響を受けた。Jonathan Lennox、Bob Penfield、 BenCampbell、Mary Barnes、Rohan Mahy、John Heartyの各氏から有益なコメ ントをいただいた。Graham Klyneには、RFC2533の用法について援助していた だいた。 Rosenberg, et al. Standards Track [Page 23] RFC 3841 Caller Preferences for SIP August 2004 14. 参考文献 14.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] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999. [3] Rosenberg, J., Schulzrinne, J., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [6] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002. [8] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [9] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [10] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. 14.2. 有益な参考文献 [11] Lennox, J. and H. Schulzrinne, "Call Processing Language Framework and Requirements", RFC 2824, May 2000. [12] Rosenberg, J., "Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)", Work in Progress, November 2002. [13] Holtman, K., Muntz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999. Rosenberg, et al. Standards Track [Page 24] RFC 3841 Caller Preferences for SIP August 2004 15. 著者の連絡先 Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 US Phone: +1 973 952-5000 EMail: jdrosen@dynamicsoft.com URI: http://www.jdrosen.net Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027 US EMail: schulzrinne@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs Paul Kyzivat Cisco Systems 1414 Massachusetts Avenue BXB500 C2-2 Boxboro, MA 01719 US EMail: pkyzivat@cisco.com Rosenberg, et al. Standards Track [Page 25] RFC 3841 Caller Preferences for SIP August 2004 16. 完全な著作権表示 Copyright (C) The Internet Society (2004). 本文書は、BCP78に含まれる権 利、ライセンス、制限の対象となり、BCP78に記載されている例外に従い、著 者はすべての権利を持つ。 本文書と含まれる情報は、「保証なし(AS IS)」原則で提供される。また、寄 稿者、寄稿者が代表する組織、または(存在する場合)寄稿者のスポンサーであ る組織、インターネット協会(Internet Society)およびIETF(Internet Engineering Task Force)は、本書の情報の使用が、特定用途に関する商品適 格性または適合性の何らかの権利または暗示される保証を侵害しない、という 保証をはじめとして、すべての保証(明示または暗示)を放棄する。 知的財産権 IETFは、本文書で記述される技術の実装または使用に関して要求される、知的 所有権または他の諸権利の有効性または範囲に関して、またはこのような権利 下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何ら見解 を持たない。このような権利を確認する独自の取り組みを行ったことも示さな い。RFC文書に関する手順の情報は、BCP78とBCP79を参照のこと。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセン スの保証すべて、またはこのような所有権の使用に関して、本仕様の実装者ま たはユーザーが一般的なライセンスまたは許可の取得を試みた結果について は、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能であ る。 IETFは、本規格の実装に必要になる可能性がある技術の範囲に及ぶ可能性があ る、任意の著作権、特許、特許アプリケーション、その他の所有権への配慮 を、関係者に依頼している。情報については、IETFの ietf-ipr@ietf.org ま で連絡されたい。 謝辞 RFC編集者職務のための資金は、現在、インターネット協会によって提供され ている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2004年 ----------------------------------------------------------------------- Rosenberg, et al. Standards Track [Page 26]