要約

  • RFC 3515 の 2xx は REFER の処理を引き受け、当初の仕様では暗黙の購読を作る応答だった。Refer-To が示す要求の成功応答ではない。
  • NOTIFY による観測、参照先要求、現実の結果は別の寿命を持つ。購読を終えても動作は CANCEL されず、fork した購読の状態も統合してはならない。

Alice が Bob に Carol へ連絡するよう頼む。RFC 3515 の有名な説明は call transfer を直感的に見せる。しかし wire 上では、Alice の指示、Bob の受理、Bob が発行する新しい要求、その状態通知、Carol 側の結果は別々である。REFER への応答一つで全部が完了するわけではない。

2003 年4月に Standards Track で公開された RFC 3515 は、REFER method、Refer-To header、refer event package を定義した。整形式の REFER は Refer-To 値を一つだけ持つ。受信者は URI type の通常の仕組みで対象へ接触する。SIP URI なら新しい INVITE になり得るが、別の scheme なら別の protocol が動く。

REFER には body を含められるが、仕様自身は意味を割り当てない。受信者は Content-Type に従って処理できる。この制限により、任意の payload が REFER に入っただけで標準命令へ昇格することはない。

受信者は syntax、対応能力、authentication、policy、user approval を評価する。整形式でも拒否できる。別の final response が決まらなければ、元の仕様は REFER transaction が期限切れになる前に 202 Accepted を返すよう求めた。

Accepted が証明したのは、受信者が REFER 処理の責任を受け入れたことだけである。新しい INVITE がすでに送られたこと、target が final 200 を返したこと、media が流れたこと、Carol が応答したこと、業務上の transfer が終わったことは示さない。最終的な利用者承認さえ後になる場合がある。

RFC 3515 の当初の契約では、2xx とともに refer event への暗黙 subscription が作られ、NOTIFY が送られる。初期応答では表せない後続結果を運ぶための観測路であり、飾りではない。

subscription 作成は即時 NOTIFY を発生させ、その NOTIFY は REFER transaction 完了前に届くことがある。pending なら body は SIP/2.0 100 Trying 一行でもよい。これは現在状態の報告であり、相手への到達、応答、完了の証拠ではない。

各 NOTIFY は Event: refer と message/sipfrag body を持ち、body は SIP Response Status-Line で始まる。response class が参照先動作の状態を伝える。各 body はその時点の complete statement で、過去の差分を積算する state delta ではない。

最小実装は pending に 100、成功報告に 200、失敗に 503、REFER 受理後に承認拒否となった場合に 603 を使える。最後の例は境界を明快にする。処理責任を先に受け入れても、参照先動作は後から拒否され得る。

また二種類の 200 を区別しなければならない。NOTIFY を受けた agent は、その NOTIFY transaction へ 200 OK を返す。これは報告受領の acknowledgment であり、sipfrag 内部の code や参照先動作を承認するものではない。CSeq と body を失ったログは、報告の receipt を動作成功へ変えてしまう。

SIP への参照なら、notifier は元の SIP response をさらに body に含め、debug に役立てられる。RFC 3515 は同時に深刻な security risk を警告した。header、topology、target 情報が、知る権限のない referrer に漏れる可能性がある。詳しい telemetry ほど audience authorization が必要になる。

非 SIP resource の状態も SIP status line へ写される。共通 event package には便利だが、それは adapter の報告である。native protocol が扱った正確な対象、副作用、receipt、物理結果まで保存するとは限らない。

subscription には独自の clock がある。REFER request と response に購読期間はなく、受理側が期間を選び、最初の NOTIFY で伝える。通常は参照先要求の完了許容時間より長くする。referrer は refresh も早期終了もできる。

しかし観測終了は実行終了ではない。明示的 unsubscribe や NOTIFY 拒否は、参照先要求を取り下げる指示ではない。referrer が event を追うのをやめたというだけで、受理側は実行中 SIP request に CANCEL を送るべきではない。monitoring control と action control は別物である。

fork は複数の時系列を生む。既存 dialog 内の REFER はこの契約では fork しない。dialog 外なら複数 agent が受理し、複数 subscription ができる。issuer はそれぞれを別に管理し、state を merge してはならない。一方の 200 と他方の 503 は、二つの actor による二つの試行である。

authorization は第三者への接触権を制御する。緩い policy なら、信頼位置の recipient を介して protected SIP、HTTP、その他の resource へ到達できる。保護対象には制限された Refer-To を使い、referrer identity と user approval を判断へ残す必要がある。

後続 RFC は観測の形を更新した。RFC 4488 は暗黙 subscription を抑止する提案を可能にし、RFC 7614 は explicit subscription を定義した。RFC 7647 は RFC 6665 の event framework と REFER の関係を明確化し、RFC 8217 なども syntax を整えた。どれも 2xx を参照先結果には変えていない。

Heng Lu の reality layers で見れば、202 は symbolic layer における責任受理の receipt である。NOTIFY は subscription 内の notifier report、参照先 request は対象 protocol の execution、media や人間の会話はさらに後の observation である。前の層の正しい message が後の層の事実を作ることはない。

RFC 3515 は delegation を弱くしたのではない。指示、観測、実行に別々の記録を与えた。REFER は確かに受理された。それでも参照先の動作は、まだ自分の証拠を必要としていた。

Sources