要約

  • comp=sigcomp は、次ホップ URI ではリクエスト、最上位 Via ではレスポンス、Contact や Record-Route では将来の通信を左右した。同じダイアログでも区間と方向ごとに選択が異なり得た。
  • マーカーが示したのは対応能力と、その時点で圧縮メッセージを受け取る意思である。実際の圧縮、SIP 解析、配送、認証、セッション成立は別の証拠だった。

RFC 3486 を読むと、判断主体がメッセージの往復に合わせて移動する。リクエストでは次ホップの SIP または SIPS URI が基準になる。レスポンスでは最上位の Via が基準になる。ダイアログ内の後続リクエストでは Contact、Route、Record-Route が次の判断材料を作る。文字列だけを抜き出したログでは、この移動する権限を復元できない。

出発点は DNS の組み合わせ問題だった。SIP は NAPTR と SRV を使って UDP、TCP、SCTP などを発見できた。そこへ TLS の有無と SigComp の有無を別々の DNS レコードとして掛け合わせれば、対応する層が増えるたびに候補が膨らむ。RFC 3486 は圧縮信号を SIP 層へ移した。通常の SIP と SigComp は同じポートに届き、圧縮メッセージ先頭の cookie ビットで識別できた。

構文は comp=sigcomp と短い。SIP/SIPS URI にあれば、その URI が示す次ホップへのリクエストを圧縮すべきだと伝える。最上位 Via にあれば、レスポンスを圧縮して返すべきだと伝える。同じ表記でも、対象のメッセージと方向は同じではない。

さらに、このパラメータは「サポート」と「受信意思」を同時に表した。実装が存在するだけでは、いつでも圧縮を受ける義務にならない。受信側はパラメータを提示するかどうかによって、その時点の選択へ関与できた。能力表と運用上の意思は近接していても同一ではない。

この境界から禁止規則が生まれる。次ホップのサーバーが SigComp を理解するか不明なら、クライアントは圧縮リクエストを送ってはならない。ただし通常のリクエストを送り、自分の最上位 Via にパラメータを置くことはできた。サーバーが対応していれば、戻りのレスポンスだけを圧縮できる。往路の非圧縮と復路の圧縮は矛盾しない。

最初の INVITE では、ダイアログの Route 集合がまだない。それでも待ち時間を減らしたい場面では、最初から圧縮可能な URI が必要になる。手動設定のほか、クライアントは送信プロキシへ非圧縮の OPTIONS を送り、200 応答の Contact からパラメータ付き代替 URI を得られた。ただし、その応答は利用可能な経路の提示であり、次のリクエストが実際にその経路や圧縮形式を使った証拠ではない。

ダイアログが始まると Contact と Record-Route が意思を将来へ運んだ。後続リクエストを圧縮で受けたいユーザーエージェントは Contact にパラメータを置く。経路に残るプロキシは Record-Route を使う。レスポンスを処理する際、上流の次ホップを調べ、自分の Record-Route エントリへパラメータを追加または削除した。将来の経路は局所的な編集の積み重ねだった。

RFC の例では四つの SIP 要素が登場し、複数が SigComp を実装する。それでも圧縮されるのはメッセージ 1、6、7 だけである。最初のプロキシは圧縮 INVITE を受け取り、次へは通常形式で転送する。レスポンスは一つの区間を非圧縮で通り、別の区間では Via に従って圧縮される。ACK でも組み合わせが変わる。「このダイアログは圧縮済み」という一文では重要な差が消える。

Double Record-Routing も均質化を意味しない。二つのネットワーク間にあるプロキシは、二つのインターフェースを表すエントリを置いて書き換えを避けられた。それでも片側から圧縮を受け、もう片側へ非圧縮で送ることができる。次ホップが自分自身でネットワーク送信が起きない場合は、URI にパラメータがあっても圧縮しない選択も可能だった。

障害時には証拠の空白が現れる。SigComp を理解しないサーバーは、圧縮リクエストを Via まで解析できず、SIP エラーを返す宛先さえ分からないかもしれない。クライアントはトランザクションのタイムアウト後、同じリクエストを非圧縮で再送すべきとされた。しかし沈黙だけでは、未対応、パケット損失、応答損失などを区別できない。

TCP では接続境界も変える必要があった。圧縮リクエストに使った接続を閉じ、新しい接続で通常の SIP を送る。古いストリームを再利用すると、未対応サーバーが新しいメッセージの先頭を見つけられない恐れがある。試行、タイムアウト、再送形式、新接続は別々に保存すべき記録である。

マーカーは挿入者を認証しない。攻撃者が comp=sigcomp を追加できれば、未対応の相手へ圧縮データを送らせられるため、完全性保護が必要だった。解凍処理は通常の解析より計算量を少し増やし、サービス拒否の負荷もわずかに悪化させる。指示と身元は同じではない。

IANA 登録が固定したのは語彙であって実行結果ではない。RFC 3320 は SigComp の基盤、RFC 3485 は SIP/SDP 静的辞書を定義した。RFC 5049 は後に RFC 3486 を更新し、資源下限、compartment、状態管理を加えた。RFC 4077、RFC 4896、RFC 5112、RFC 5626 は別の境界を補う。文書の系譜から普及率や効果測定を推測してはならない。

実際の出来事を再構成するなら、次ホップ URI、最上位 Via、Contact、Route、Record-Route、方向、完全性、ワイヤ上の形式、トランスポート、接続 ID を保存する。OPTIONS による発見と後続利用を分離し、沈黙の後にはタイムアウト、非圧縮再送、TCP 再接続も別に記録する。その後で初めて、解凍、SIP 解析、認証、ダイアログ、利用者の結果を結合できる。

Heng Lu の現実層の考え方で見れば、comp=sigcomp は次の試行に対する限定的な許可である。RFC 3486 は DNS の組み合わせを増やさずに圧縮を選べるようにしたが、経路全体を一つの状態にはしなかった。マーカーは移動した。しかし権限は次のホップで止まった。

出典