要約

  • レジストラは成功した REGISTER 応答に順序付き Service-Route を含められ、端末は address-of-record ごとに保存し、後の発信要求で利用できる。
  • 保存値が示すのは、その登録時点の提案である。後続要求への採用、DNS の選択、各プロキシの通過、サービス処理、セッション成功は別の証拠を要する。

RFC 3608 は 2003 年 10 月に Standards Track 文書として発行された SIP 拡張であり、現在の特定事業者網を観測した報告ではない。

運用記録で最も危険なのは、値そのものより履歴の欠落である。設定画面に二つのプロキシ名が残っている。そこで「この端末の発信は二つのプロキシを経由する」と説明したくなる。しかし、その値が現在の登録から得られたのか、一世代前の残骸なのかを画面は教えない。

RFC 3608 のライフサイクルは明確だ。端末は REGISTER の成功応答にある Service-Route を address-of-record と結び付けて保存できる。再登録に成功すれば最新応答で更新する。応答に Service-Route がなければ以前の値を消す。登録が拒否されたり、期限切れ後に再登録しなかったりすれば破棄すべきだ。

従って監査対象は URI の文字列だけではない。応答の Call-ID と CSeq、Contact、対象 identity、受信時刻、有効期限、認証結果、置き換え元と置き換え先が必要になる。世代のないルートは、いつの意図か分からない。いつの意図か分からないものから、現在の経路を推定してはならない。

しかも端末はそのルートを「利用できる」のであって、未来の全要求に利用した事実が自動的に生まれるわけではない。発信要求を作る時点で、端末はローカルの出口ルートや outbound proxy 規則と組み合わせることがある。RFC 3608 は、この統合が実装依存であり、最終的にローカル環境で有効なルーティングを構成しなければならないとする。

ホーム側のレジストラが知る範囲にも限界がある。ローミング先のネットワーク構成を当然には把握できないため、返される Service-Route は通常ホーム管理域の要素を示す。したがって、仕様通りに使われた場合でも、そのベクトルが端末から宛先までの全経路を表すとは限らない。

RFC 3327 の Path との違いも履歴管理には重要だ。Path は REGISTER がレジストラへ進む際に中継プロキシが積み上げ、後にホーム側から登録 contact へ向かうために使う。Service-Route はレジストラから端末へ伝え、端末発の要求をホームサービスへ導く。向きも利用者も違う二つを一つの「SIP 経路」欄に押し込むと、証拠の所有者が消える。

要求が実際に作られた後も、Route と Via は同じものではない。Route はこれから処理される指示であり、Via はプロキシが転送時に加えるトランザクションの観測に近い。Route に名前があるだけでは到達を証明しない。Via に現れても、その装置内部で期待した課金、記録、ポリシーなどのサービスが動いた証明にはならない。

さらに URI と具体的な接続先の間には RFC 3263 の名前解決がある。DNS の TTL は切れ、優先度や重みは変わり、ある transport endpoint が失敗すれば別候補へ進む。同じ URI でも時刻が違えば IP アドレス、ポート、トランスポートが変わり得る。保存した Service-Route だけでは、その選択を復元できない。

RFC 5626 の outbound flow や flow token、RFC 5923 の connection reuse は、接続状態についてより強い手掛かりを与える。だが接続が存在したことと、対象の要求がその接続を通ったことは別である。まして、所期のサービスを受け、最終結果が成功したことまでは導けない。

Service-Route 自体の真正性は重要である。RFC 3608 は途中のプロキシによる挿入や改変を警告し、整合性と相互認証を求める。保護された応答は「誰が何を提案したか」を強くできる。しかし、その保護は将来の DNS、障害、ローカル判断、サービス実行を先回りして保証しない。

必要なのは段階ごとの受領証だ。第一に登録応答とルート世代。第二にローカル規則を適用した後の実要求と Route。第三に DNS 応答、TTL、選択 endpoint、transport、fallback。第四にトランザクション識別子で結ばれた各 hop の観測。第五にサービス機能のバージョンと実行結果。第六に SIP 応答、dialog、必要なら media や application の結果である。

RFC 7989 の Session-ID は装置をまたぐ相関に役立つ。それでも、観測のない hop や実行記録のない service を作り出すことはできない。相関キーは証拠そのものではなく、存在する証拠を結ぶための道具だ。

この分離により障害の責任が見える。レジストラが誤ったベクトルを返したのか。クライアントが消すべき旧世代を残したのか。DNS が利用不能な宛先を選んだのか。プロキシが転送だけしてサービスを省いたのか。信号は成功したがメディアが失敗したのか。REGISTER 200 だけでは区別できない。

すべてを永久保存する必要はない。保存期間、サンプリング、仮名化、アクセス制御はリスクに応じて設計できる。ただし削った後に残る主張も同じ幅まで狭めるべきだ。登録応答しか残さないなら、証明できるのは登録時の提案だけである。

RFC 3608 は共通層を小さく保っている。順序付き提案の形式と更新規則を定め、その後の選択を実装と運用へ残す。問題は中央の記録が、後から走ったコードより強い現実だと扱われる時に生じる。更新履歴を保ち、意図と実行を分けることが、その逆転を防ぐ。