要約

  • RFC 3487 は、SIP の優先度表示が待ち行列、横取り、容量配分、通話時間を直接指定せず、名前の付いた方針を呼び出すよう求めた。
  • 同じ表示でも、ゲートウェイ、回線交換網、プロキシ、受信端末では別の処理になり得る。認識、権限、受付、媒体資源、通話成立は別々の証拠である。

「優先」という語は一つの強い命令を連想させる。しかし RFC 3487 が扱った緊急時の通信網には、命令を一様に実行する単一の機械は存在しなかった。発信者は、どこが混雑しているか、誰がその資源を管理するか、既存の通信を切るべきか待つべきかを知り得ない。そこで 2003 年の文書は、具体的な SIP 拡張を定める前に、優先度表示が越えてはならない権限の境界を記した。

最初の手掛かりは五種類の資源である。回線交換網へ接続するゲートウェイには有限のトランクがある。回線網の内部には GETS や MLPP が扱う経路と回線がある。IP 網では SIP 信号と音声・映像の帯域が異なる制御に属する。受信システムには同時セッション数の上限がある。SIP プロキシはアクセス回線が空いていても計算能力を使い切る。RFC は、この五つを一つの機構で処理する必要はないと明記した。

したがって、実際の動作も一つではない。ゲートウェイは要求を先に並べたり、別の経路へ回したりできる。回線網は法規と運用手順が許せば既存通話を横取りできる。受信端末は高優先度の着信を知らせるだけかもしれない。プロキシは優先キューを用い、拒否し、あるいは過負荷時に選択的に捨てる。表示が共通でも、実行主体と損失は局所的である。

経路構成は制御できる範囲をさらに変える。RFC 3487 は IP 間、IP から回線網、回線網から IP、回線網から IP を介して別の回線網へ至る場合を分けた。中継ゲートウェイは、SIP の分岐後に相手が IP 端末になるのか回線端末になるのかを知らないことがある。両側の回線網が別の信号方式を使えば、優先度情報の完全な往復変換さえ保証できない。

IP 網の自由度も段階的だった。緊急通信向けに事前設定された網ならルーターや予約機構を変更できる。透明な網は有効なパケットを運ぶだけである。SIP/RTP には透明でも RSVP や DSCP を拒む網がある。制限された SIP 網では新しいヘッダーやメソッドが通らない。非常時に広い接続性を得るには、優先度表示が一つの運用環境を前提にしてはならなかった。

この異質性に対する答えが、値による呼び出しではなく参照による呼び出しだった。要求の中に「待ち行列を上げ、横取りせず、三分で終了」と書けば、遠隔の利用者が見えない資源の管理方法まで決めてしまう。名前付き方針を指定すれば、各要素は自分が管理する資源と現在の条件に応じて動作を選べる。優先度ごとの容量比率も局所方針に残された。

同じ表示が異なる結論を生むことは、仕様上の曖昧さではない。優先通信が少なく容量が大きい設備では、既存通話を切るより短く待つ方がよい。別の設備では横取りが必要かもしれない。プロキシでは廃棄せずにキューへ入れるだけで目的を達する場合がある。RFC は、この差を隠さず制度として受け入れた。

薄い表示を支える要件も慎重だった。国や制度ごとに異なる優先体系を名前空間で分け、特定の事業者やアドレス体系に依存させない。表示は正当な帯域内 SIP として運ばれ、複数のメソッドで働く。同じ方式を用いる二つの回線網の間では情報を失わないことを目指すが、異なる方式なら損失が避けられない。この限界は、相互運用という言葉だけで消されなかった。

対応していない網では通常の要求より不利にしないことが望まれた一方、適切な表示と認証がない呼び出しを拒む局所方針も認められた。端末は、要素が理解する名前空間を明示的に問い合わせるか、試行後の応答で知ることができる。しかし対応の発見は、空き容量、利用権限、選ばれた処理、通話成立のどれも証明しない。

本人確認だけでも足りない。同じ人が通常の連絡と優先連絡を使い分け、状況に応じて人間が等級を選ぶからである。RFC 3487 は、認証された本人、利用者の選択、方針の組合せが処理を決めるとした。From 欄の名前は恒久的な特権ではなく、ラベルも認可票ではない。

そのため安全性は中心要件になった。優先機能を悪用すれば、救援用に守るはずの資源を攻撃者が先に消費する。認証と認可は早い段階で行い、無権限の要求が使うパケット、計算、回線を減らす必要がある。各 SIP ノードは連鎖的な信頼に寄りかからず、自ら認可を検証すべきだとされた。再送、切り貼り、格下げへの耐性も要求された。

プライバシーは別の緊張を生む。利用者が借り物の端末を使う場合、再利用可能な秘密を端末へ渡すべきではない。優先通信を求めた事実そのものが状況を漏らすこともある。経路に必要な情報と、終端間で隠せる情報を分けなければならない。優先度表示と認証方式を独立させた理由はここにもある。

後の RFC 4412 は Resource-Priority と Accept-Resource-Priority を定義し、名前空間と値でこの要求を具体化した。OPTIONS 応答は処理可能な値を知らせられる。それでも同 RFC は、受け入れ可能な値が十分な資源や成功を意味しないと明記した。RFC 5115、RFC 5478、RFC 6401、RFC 6735、RFC 8443 は経路、名前空間、受付制御、認可を拡張したが、一つの表示を最終結果へ変換してはいない。

実際の記録では、発信者、認証、選択した名前空間と値、SIP メソッド、経路構成をまず保存する。続いて、各ゲートウェイ、プロキシ、受信端末、回線網が参照した方針の版を残す。経路変更、待ち行列、受付、横取り、媒体割当、そして人が会話できたかを別々に記録する。

Heng Lu が論じる象徴的な権限と実行層の区別に照らすと、この設計の価値が見える。共通ラベルは語彙を運ぶが、資源の所有者に代わって決定しない。RFC 3487 は同じ答えを約束したのではない。異なる管理主体が同じ問いを理解し、それぞれの境界で答えの証拠を残す仕組みを選んだのである。

出典