要約

  • ReplacesはCall-ID、to-tag、from-tagで一つのINVITEダイアログを指し示す。正しく照合できても、受信UAは発信者を別途認証し、その置換を許可するか判断しなければならない。
  • 新しいINVITEを先に受け入れ、そこで初めて旧ダイアログへBYEまたはCANCELを送る。QoS、鍵、メディア、資源などで新規受入れに失敗した場合、旧ダイアログは変更してはならない。
  • REFERへの応答、Referred-By、Replaces付きINVITEの2xx、旧レッグの終了、実際のメディア継続は異なる証拠である。一つの成功フラグでは転送の権限も結果も説明できない。

一つの転送に、少なくとも四つの拒否権がある

転送元が転送要求を出したからといって、転送先が従う義務はない。転送を依頼された端末がREFERを受け入れても、参照先への新しいINVITEが成功したとは限らない。新しいINVITEが既存ダイアログを正しく指していても、その発信者に置換権限があるとは限らない。権限があっても、新しいメディアや鍵を受け入れられないことがある。

RFC 3891は、これらを一続きの処理として定義しながら、判断を混同しない。受信側のUser Agent Server（UAS）は、まず対象を照合し、次に権限を確認し、その後に新INVITEを受け入れられるか判定する。受入れに成功してから、既存ダイアログを終了する。

この順番こそが重要である。標準化された共有情報は、独立した端末が同じ対象を指すために必要だ。しかし、その情報自体が端末の代わりに判断してはならない。

Replacesは「既存通話の書き換え」ではない

Replacesヘッダーは新しいINVITEに入る。置換後のダイアログには新しいCall-IDが付く。旧ダイアログをその場で編集する命令ではない。

新しいINVITEを使えば、通常のセッション受入れ処理をそのまま適用できる。明示的なReplacesは、どのダイアログを置き換えたいのかを示す。関連を暗黙に推測しないため、未対応のUAが旧ダイアログを誤って壊す危険も減る。

UAはSupported: replacesで対応を示し、発信側は必要に応じてRequire: replacesで未対応時の明確な失敗を求められる。IANAのSIP Parametersには現在もReplacesとreplaces option tagが登録されている。

ただし、対応表明は許可表明ではない。ある製品がRFC 3891を実装していることは、特定のユーザー、テナント、ダイアログについて置換を認めることを意味しない。

また、ReplacesとREFERは別の仕組みである。REFERは受信者にあるリソースへのアクセスを依頼する。Replacesは新INVITEがどの既存ダイアログを置き換える意図かを伝える。転送では組み合わせることが多いが、一方の成功はもう一方の成功ではない。

三つの値は「一通話」ではなく「一ダイアログ」を指す

ReplacesにはCall-ID、to-tag、from-tagが含まれ、二つのtagはそれぞれ一つだけ必要である。受信UASはto-tagを自分のlocal tagに、from-tagをremote tagに照合する。

ここで重要なのは受信者の視点である。過去のメッセージに表示されたToとFromを、そのまま機械的に転記すればよいわけではない。ローカルとリモートの向きを取り違えると、存在するダイアログでも481になる。

RFC 3891のerrataには、early dialogの例でtagの向きが逆だったため修正されたVerifiedの編集上の誤りが一件ある。別の同種の記載はHeld for Document Updateである。規範的な処理を変える訂正ではないが、例文より視点の原則を優先すべきことをよく示している。

そして、この三つの値が選べるのは一つのダイアログだけだ。複数ダイアログ、通話全体、transaction全体、proxy forkの連鎖は選べない。初期INVITEから複数のearly dialogsが生じた場合、一つの枝を置換しても他の枝は対象外である。

アプリケーション側の「call ID」や「interaction ID」は、複数のSIPレッグ、録音、キュー、請求をまとめることがある。その集約単位とRFC 3891のダイアログ単位を同一視すると、一つのレッグの結果で全体を終了させてしまう。

同じ識別子でも、Joinなら意味は逆になる

形式が不正ならUASは早い段階で拒否する。Replacesが二つ以上ある、INVITE以外に入る、または矛盾するcall-controlヘッダーと併用される場合は400である。

RFC 3911のJoinは、この境界を理解するのに役立つ。JoinもCall-IDと二つのtagで既存ダイアログを照合する。しかし目的は、新しいダイアログを既存のconversation spaceへ加えることだ。Replacesは旧ダイアログを終了し、新しいものに置き換える。したがって同じINVITEに両方を入れると意味が矛盾する。

識別子は対象を示すだけで、操作を決めない。操作はヘッダー名が示し、誰が要求したかは認証が示し、その者に許すかは認可ポリシーが決め、実行可能かは受入れ処理が決める。

複数のダイアログに一致した場合、UAは一致なしとして扱う。一致しない、またはINVITEで作られたものではないダイアログに一致した場合は481。すでに終了したダイアログなら603で拒否することが推奨される。遅れて届いた置換要求を、通常の着信として再び鳴らさないためだ。

481の原因は一つではない。tagの逆転、状態の陳腐化、別インスタンスへの配送、フェイルオーバー時の状態消失、Contactのretargeting、終了との競合があり得る。観測系は単なる「置換失敗」ではなく、どの照合条件が崩れたかを残す必要がある。

認証された者が、常に置換できるわけではない

活動中のダイアログに一致した後、UASは新INVITEの発信者がそれを置き換える権限を持つか検証しなければならない。RFC 3891は、被置換ユーザーと同等の資格情報で認証された者、相手参加者のREFERに基づくReferred-By、その他のローカルポリシーを例示する。

これは権限モデルの例であって、万能な委任ではない。同一identityを使う複数端末や正規の代理者に共有資格情報が必要な場合はある。しかし、広いservice credentialを使えば、あるシステムが多数の利用者やテナントの通話を置換できる。credentialの所持は、現在の人間の意思、会社法上の権限、契約上の権利を自動的に示さない。

RFC 3892はReferred-Byの限界を明示する。refereeはreferrerの情報を転送先へ運ぶ中継者であり、その情報を見たり改変したりできる。保護tokenのないReferred-Byは入場判断の参考にはなっても、信頼済み事実として扱うべきではない。表示するなら疑わしい情報であることを利用者に知らせる必要がある。

有効なtokenがあっても、証明できるのはreferralに含まれるidentityやURI、日時などである。録音同意、医療情報の取扱い、金融取引権限、顧客契約の承継まで一括して証明するものではない。

RFC 4538のTarget-Dialogは、ダイアログ識別子を知っていることが条件付きの認可材料になり得る例だ。SIPSで保護された経路と十分にランダムな識別子なら、その知識は元の経路にいた主体との関係を示し得る。保護されていない経路では盗聴者も値を知るため、同じ推論は弱くなる。

知識は証拠になり得る。しかし、どの操作まで許すかを知識自身が決めることはできない。

新しいセッションが成立しなければ、古いものを守る

認可が成功すると、UASは新INVITEの受入れ、ユーザーインターフェースや資源の再割当て、旧ダイアログの停止を試みる。ここで「試みる」と書かれている点が重要である。

必要なQoSや鍵を確立できない、メディアが非互換、資源が足りないなど、新INVITEが成立しない理由はある。その場合、RFC 3891は適切なエラーを返し、対象の旧ダイアログを変更しないよう要求する。

つまり、正しい対象を見つけ、正しい人を認証し、その人に権限があっても、置換はまだ完了していない。新しいセッションが実際に受け入れられなければ、稼働中の既存セッションを残す。これは可用性のためのローカルな拒否権である。

confirmed dialogの場合、early-onlyがなければ新INVITEへ2xxを返し、その後に旧ダイアログへBYEを送る。自分が開始したearly dialogなら、新INVITEを受け入れて旧INVITEへCANCELを送る。

early-onlyは、まだ呼出し中のダイアログだけを置換したい意思を表す。すでにconfirmedなら486で拒否する。受信UAが開始したのではないearly dialogに一致した場合は481とし、旧状態を残す。単一ダイアログの置換要求には、別主体が開始したforkを安全に再現する力がないからである。

2xxが返れば、UASは新ダイアログを受け入れたという強い事実が得られる。それでもBYEの喪失、B2BUAのレッグ対応不良、残存fork、メディア障害、録音や請求の誤結合は別に観測しなければならない。

REFERの200は「試すことを受け入れた」記録

RFC 3515では、well-formedなREFERを受け入れるUAは、対話画面または設定済みポリシーを通じて利用者の承認を求めるべきだとされる。承認後、Refer-Toで示されたリソースへ通常の方法でアクセスする。

attended transferでは、Refer-To URIにescaped Replacesを含めることが多い。transfereeが新INVITEを生成し、transfer targetがRFC 3891の照合・認可・受入れを行う。transferorがREFERを送ったという事実だけで、targetの判断は代行できない。

REFER transactionの受入れと、参照されたactionの結果はNOTIFYで分かれている。RFC 7647は、受け入れたREFERに202ではなく200を使うよう更新し、既存ダイアログを示す場合にTarget-Dialogを要求する。この200も転送完了証明ではない。

RFC 5589は、成功したREFER transactionが元のsessionを終了しないことを明記する。終了したいなら後続BYEが必要だ。target busy、無応答、Replaces拒否などの失敗時には、transferorとtransfereeの元のsessionを再開できる流れが示されている。

転送管理では、少なくともREFER承認、REFER応答、triggered INVITE結果、旧ダイアログ終了、メディア・業務結果を別々に保持すべきである。

再構成できる記録を作る

新INVITEのCall-IDと、Replacesが指すCall-ID/tag tripleを別の項目として保存する。受信者のlocal/remote tag、照合時のearly/confirmed/terminated状態、Contact、route、fork branch、early-onlyを含める。

次に、認証identity、Referred-Byとtoken検証、適用したpolicy version、ユーザーまたはテナントの承認、決定理由を残す。単一のauthorized=trueでは、権限の由来を監査できない。

新INVITEの受入れ記録にはresponse code、SDP fingerprint、codecとdirection、keying、QoS、target instance、ACKを含める。成功後は旧ダイアログへのBYE/CANCEL、その応答、再送、最後に観測した信号とメディアを結び付ける。

REFER側はCall-ID、CSeq、Target-Dialog、Refer-To fingerprint、承認、応答、NOTIFYを同じtimelineに置く。ただし一つの状態欄に上書きしない。NOTIFYの成功は、実際のreplacement INVITEと旧レッグ終了に照合する。

テストには、逆tag、曖昧な一致、終了済みdialog、early-onlyのrace、未対応Require: replaces、正しい一致後の認可拒否、無効Referred-By token、media/key/QoS不成立、busy/no-answer、2xx後のBYE喪失、fork残存、retargeting、failoverでの状態喪失、B2BUAの上下流対応欠落を含める。

最終的に必要なのは「成功」の回数ではない。誰が依頼し、何を指し、誰が許可し、何が受け入れられ、何が終了し、利用者が何を受け取ったかを、第三者が順番に確かめられる記録である。

情報源