メインコンテンツまでスキップ

9. Canceling a Request

9 Canceling a Request

前節では, すべてのメソッドの要求を生成し, 応答を処理するための一般的な UA の動作について議論しました. この節では, CANCEL と呼ばれる汎用メソッドについて議論します.

名前が示すように, CANCEL 要求は, クライアントによって送信された以前の要求をキャンセルするために使用されます. 具体的には, UAS に対してその要求の処理を中止し, その要求に対するエラー応答を生成するよう求めます. CANCEL は, UAS がすでに最終応答を返した要求には影響しません. このため, 応答に時間がかかる可能性がある要求を CANCEL する場合に最も有用です. この理由から, CANCEL は応答の生成に時間がかかる可能性がある INVITE 要求に最適です. その使い方では, INVITE に対する CANCEL を受信したがまだ最終応答を送信していない UAS は, "鳴動を停止" し, その後 INVITE に対して特定のエラー応答 (487) で応答します.

CANCEL 要求は, プロキシとユーザエージェントクライアントの両方によって構築および送信できます. セクション 15 は UAC がいつ INVITE 要求を CANCEL するかを, セクション 16.10 は CANCEL のプロキシによる使用法を議論します.

ステートフルプロキシは, 下流要素から受信する応答を単に転送するのではなく, CANCEL に応答します. そのため, CANCEL は各ステートフルプロキシホップで応答されるため, "ホップバイホップ" 要求と呼ばれます.

9.1 Client Behavior

CANCEL 要求は, INVITE 以外の要求をキャンセルするために送信すべきではありません (SHOULD NOT).

  非 INVITE 要求は即座に応答されるため, 非 INVITE 要求に対する CANCEL の送信は常に競合状態を生じさせるでしょう.

以下の手順は, CANCEL 要求を構築するために使用されます. CANCEL 要求内の Request-URI, Call-ID, To, CSeq の数値部分, および From ヘッダフィールドは, キャンセルされる要求のものと (タグを含めて) 同一でなければなりません (MUST). クライアントによって構築された CANCEL は, キャンセルされる要求の先頭 Via 値と一致する単一の Via ヘッダフィールド値のみを持たなければなりません (MUST). これらのヘッダフィールドに同じ値を使用することで, CANCEL をそれがキャンセルする要求と照合できます (セクション 9.2 はそのような照合がどのように行われるかを示します). ただし, CSeq ヘッダフィールドのメソッド部分は, CANCEL という値でなければなりません (MUST). これにより, それ自体のトランザクションとして識別および処理できます (セクション 17 参照).

キャンセルされる要求に Route ヘッダフィールドが含まれている場合, CANCEL 要求はその Route ヘッダフィールドの値を含まなければなりません (MUST).

  これは, ステートレスプロキシが CANCEL 要求を適切にルーティングできるようにするために必要です.

CANCEL 要求は, Require または Proxy-Require ヘッダフィールドを含んではなりません (MUST NOT).

CANCEL が構築されると, クライアントは, キャンセルされる要求 (ここでは "元の要求" と呼びます) に対して応答 (暫定的または最終) を受信したかどうかを確認すべきです (SHOULD).

暫定的応答が受信されていない場合, CANCEL 要求は送信してはならなりません (MUST NOT). むしろ, クライアントは要求を送信する前に暫定的応答の到着を待たなければなりません (MUST). 元の要求がすでに最終応答を生成している場合, CANCEL は実質的に何もしない no-op であるため, 送信すべきではありません (SHOULD NOT). クライアントが CANCEL を送信することを決定したとき, それは CANCEL のためのクライアントトランザクションを作成し, 宛先アドレス, ポート, およびトランスポートとともに CANCEL 要求を渡します. CANCEL の宛先アドレス, ポート, およびトランスポートは, 元の要求の送信に使用されたものと同一でなければなりません (MUST).

  前の要求に対する応答を受信する前に CANCEL を送信することが許可されていた場合, サーバは元の要求より前に CANCEL を受信する可能性があります.

元の要求に対応するトランザクションと CANCEL トランザクションの両方が独立して完了することに注意してください. ただし, 要求をキャンセルする UAC は, 元の要求に対する 487 (Request Terminated) 応答の受信に依存できません. RFC 2543 準拠の UAS はそのような応答を生成しないためです. 元の要求に対する最終応答が 64*T1 秒以内にない場合 (T1 はセクション 17.1.1.1 で定義されます), クライアントは元のトランザクションがキャンセルされたと見なすべきであり (SHOULD), 元の要求を処理しているクライアントトランザクションを破棄すべきです (SHOULD).

9.2 Server Behavior

CANCEL メソッドは, サーバ側の TU に対して保留中のトランザクションをキャンセルすることを要求します. TU は, CANCEL 要求を受け取り, その後要求メソッドが CANCEL または ACK 以外のものであると仮定してセクション 17.2.3 のトランザクション照合手順を適用することにより, キャンセルされるトランザクションを決定します. 照合されるトランザクションがキャンセルされるものです.

サーバにおける CANCEL 要求の処理は, サーバの種類に依存します. ステートレスプロキシはそれを転送し, ステートフルプロキシはそれに応答し, 自身の CANCEL 要求のいくつかを生成する可能性があり, UAS はそれに応答します. CANCEL のプロキシによる扱いについては, セクション 16.10 を参照してください.

UAS は, 最初にセクション 8.2 で説明された一般的な UAS 処理に従って CANCEL 要求を処理します. ただし, CANCEL 要求はホップバイホップであり再送信できないため, 適切な資格情報を Authorization ヘッダフィールドで取得するためにサーバによってチャレンジされることはできません. CANCEL 要求には Require ヘッダフィールドが含まれないことにも注意してください.

UAS が上記の手順に従って CANCEL に一致するトランザクションを見つけられなかった場合, 481 (Call Leg/Transaction Does Not Exist) で CANCEL に応答すべきです (SHOULD). 元の要求のトランザクションがまだ存在する場合, CANCEL 要求を受信したときの UAS の動作は, 元の要求に対する最終応答をすでに送信したかどうかに依存します. 送信済みの場合, CANCEL 要求は, 元の要求の処理, セッション状態, および元の要求に対して生成された応答にはいかなる影響も及ぼしません. UAS が元の要求に対する最終応答をまだ発行していない場合, その動作は元の要求のメソッドに依存します. 元の要求が INVITE であった場合, UAS は INVITE に対して直ちに 487 (Request Terminated) で応答すべきです (SHOULD). CANCEL 要求は, 本仕様で定義されたその他のメソッドを持つトランザクションの処理には影響を与えません.

元の要求のメソッドに関係なく, CANCEL が既存のトランザクションと照合された限り, UAS は CANCEL 要求自体に 200 (OK) 応答で応答します. この応答はセクション 8.2.6 の手順に従って構築され, CANCEL への応答の To タグと元の要求への応答の To タグは同一であるべき (SHOULD) ことに注意してください. CANCEL への応答は, 送信のためにサーバトランザクションに渡されます.