11. Querying for Capabilities

11 Querying for Capabilities

OPTIONS は, ユーザエージェントまたはプロキシの機能の問い合わせのために使用する要求メソッドです. これは HTTP/1.1 の OPTIONS に似ています. 宛先サーバは, その機能を記述するメッセージボディを伴う 200 (OK) 応答で応答します.

OPTIONS 要求により, 呼を確立することなく, 呼を確立する能力を問い合わせることができます. たとえば, ユーザエージェントクライアント (UAC) は, サポートされる拡張, コーデックなどを発見するために, 特定のユーザのユーザエージェントサーバ (UAS) へ OPTIONS を送信できます. ただし, この手法は, セッション記述プロトコル (SDP) の機能を使用して到達可能性を確認することもできるため, 到達可能性チェックには推奨されません (NOT RECOMMENDED). 代わりに, オファーを含む INVITE を送信し, エラー応答 (または成功) を観察することが推奨されます (RECOMMENDED). "prかけっこ" の理由は, INVITE を送信する前に UAC が認証を実行することはできず, したがって, 攻撃者は UAC が受信者の存在の問い合わせを容易に行えるようにするために OPTIONS 要求を偽造できるからです. したがって, 従来の SIP 動作が, 呼のピアツーピア性を維持するために受信者に認証を強制するため, OPTIONS ベースの到達可能性チェックは破られます.

OPTIONS 要求は, UAC から UAS, および UAC からプロキシの両方に送信できます. (UAS は, プロキシとして, またはリダイレクトサーバとして動作中のエンドポイントであるため, プロキシへ OPTIONS を送信することは UAS へ送信することと論理的に同等です. ) そのような要求は, 要求の Request-URI で識別されるドメイン内の任意のエンドポイントの機能の問い合わせに使用してもよい (MAY) です (セクション 16 のプロキシの動作に従います).

11.1 Constructing an OPTIONS Request

OPTIONS 要求は, [4] で定義された実体テンプレートを使用して作成され, 宛先のアドレスは Request-URI です. この要求に追加の Require または Proxy-Require ヘッダフィールドを含めることはできません (MUST NOT).

この要求の Accept ヘッダフィールドは, その他のすべての方法による能力の記述よりも好まれる (SHOULD) フォーマットを指定してもよい (MAY) です.

11.2 Processing of OPTIONS Requests

OPTIONS 要求の受信は, 非 INVITE 要求の受信と同様に扱われます. この仕様に従う UAS は, 受信した任意のメソッドに対して, それ以外の点では要求が INVALID の場合, 405 (Method Not Allowed) 応答を返します. したがって, OPTIONS メソッドの能力をサポートしていないサーバは, OPTIONS 要求を受信したとき, 405 (Method Not Allowed) を返すべきです (SHOULD).

11.3 Generating a Response to OPTIONS

OPTIONS 要求に対する 200 (OK) 応答の構築は, セクション 8.2.6 に記載された手順に従います. 応答のボディは, 任意です (OPTIONAL). ボディが空の場合, 200 (OK) は, 必須のヘッダフィールド (Contact を除く) のみを含みます. Allow, Accept, Accept-Encoding, Accept-Language, および Supported ヘッダフィールドは, UAS の機能を記述するため推奨されます (RECOMMENDED). メッセージ本体は, さらに詳細な機能の記述のために使用してもよい (MAY) です. そのようなボディは, 任意の適切なフォーマットでよく, 基本的には, 受信者がサポートされる機能を理解し, それを使用するかどうかを決定できるようにするための情報を提供する必要があります (MUST).

11.4 OPTIONS を用いたプロキシの問い合わせ

プロキシは, OPTIONS 要求を受信した場合, それがサポートする機能を記述する 200 (OK) 応答を返すべきです (SHOULD). プロキシの機能の記述は, プロキシの責任あるドメインに対応するアドレスを Request-URI に持つ OPTIONS 要求に対してのみ返されるべきです (SHOULD). 応答コード 501 (Not Implemented) は, プロキシがそのような要求をサポートしない場合に返されるべきです (SHOULD). 言い換えれば, コアがプロキシ側にある場合, プロキシは他の要求についてと同様にその要求を処理し, 応答を生成します. プロキシが自身の OPTIONS 要求を受信し, それを自身の責任あるドメインに向けて解決できない場合, プロキシは 404 (Not Found) を返すべきです (SHOULD) (URI が解決できない場合). プロキシが自身の OPTIONS 要求を受信し, それを自身の責任あるドメインに向けて解決できるがその機能を記述したくない場合, プロキシは 405 (Method Not Allowed) を返すべきです (SHOULD).