要約

  • RFC 3327 では、REGISTER を中継するプロキシが順序付きの Path を追加できる。登録が成功すると、登録サーバーはそのベクトルを AOR と Contact のバインディングに結び付け、応答で返す。
  • 後にホーム・プロキシは保存したベクトルを Route に入れ、その Contact 宛ての要求を中継できる。ただし、このベクトルは REGISTER パケットが実際に通った経路を証明しない。

応答に現れる中継点を読む

SIP の登録サーバーは、ユーザーエージェント（UA）が到達可能なアドレスを保存できる。このバインディングが答えるのは、「この Address-of-Record（AOR）宛ての要求を、どの Contact に届けるか」という限られた問いだ。そこに至るまで、要求がどの中間プロキシを通る必要があるかまでは分からないことがある。

REGISTER がエッジ・プロキシを経由していても、ホーム・プロキシが DNS や自らのルーティング表からその経路を再構成できない場合に、隙間が生じる。UA が訪問先ネットワークから登録し、登録サーバーが別の場所にあり、後の着信が Contact URI からは見えない中継ノードを通る場合だ。2002 年 12 月に公開された RFC 3327 は、登録のやり取りに経路ベクトルを残す方法を導入した。

「Path」は経路測定のように聞こえるが、それが目的ではない。REGISTER が通過するプロキシは Path 値を追加できる。登録サーバーは順序を保った値を Contact と AOR のバインディングに保存し、成功した REGISTER 応答で反射する。その後、ホーム・プロキシはバインディングを引き、ベクトルを事前設定した Route に入れて、新たな要求をそのプロキシ群に通せる。保存されるのはバインディングに必要な経路参照であり、REGISTER トランザクションのパケット・キャプチャではない。

トランザクションの先まで使う経路

Path は Record-Route に似ているが、有効に働く時間軸が異なる。Record-Route は、それを作ったダイアログ内の要求に経路を設定する。Path は REGISTER とその成功応答に載り、後続のダイアログに使うプロキシ列を作る。Route を実行する基礎の仕組みは RFC 3261 が担い、RFC 3327 は登録を越えてその列を渡す。

範囲は限定されている。対象は、ユーザーのホーム・ドメインを通過する要求、または同ドメインから発信される要求だ。Path 値は Route 要素の構文に従い、ルース・ルーティングを示す ;lr を含む。UA は Supported: path で対応を知らせられる。通常、UA が対応を示していない場合にプロキシは Path を追加すべきではない。対応表示のない Path を登録サーバーが受け取った場合、RFC は拒否を推奨しつつ、ローカル・ポリシーの余地を残した。

歴史的な変化は、SIP が各パケットの通過先を把握するようになったことではない。登録の交換を、後続の着信要求に影響する経路情報をプロキシがバインディングに結び付ける場にしたことだ。登録サーバーは Path を UA に返すため、追加された中継点は確認できる。全世界のトポロジー・データベースに暗黙に昇格するわけではない。

ベクトルは証言ではない

RFC 3327 は、トポロジーを知るプロキシが別ノードを指す Path 値を加えることを明示的に認めている。その値は、REGISTER が実際に通った経路と一致しなくてもよい。この条項は読み方を決める。Path はプロキシや登録サーバーのポリシーの下で組み立てられた、順序付きのルーティング指示であり、パケットが通過した事実のフォレンジックな記録ではない。単独では、プロキシが以前のメッセージを中継したこと、提案経路が今も到達可能なこと、後続の呼が届くことを証明できない。

この設計はセキュリティ上の境界も生んだ。保存されるベクトルにプロキシが挿入されれば、その後の要求にも組み込まれ、呼を傍受できるおそれがある。RFC 3327 は TLS や IPsec などによる通信の完全性と相互認証を取り上げ、登録サーバーが応答に署名付き S/MIME の複製を添えて UA が Path の改変を検出する方法も説明する。URI として構文が正しいことは、中継者として認可されたことを意味しない。

後の標準は、この仕組みをより限定した用途に再利用した。RFC 5626 は固有のフロー・トークンを Path に含め、エッジ・プロキシが後続の要求を特定のクライアント起点接続に対応付ける。フローごとの処理は後続拡張のものであり、すべての RFC 3327 のベクトルに当てはめてはならない。RFC 3608 の Service-Route は反対方向で、UA 自身が発信する要求用のルートを与える。UA 宛ての着信経路ではない。

参照資料