要約

  • RFC 5370 は、SIP トランスコーディングを会議ブリッジとして呼び出す方式を定める。T はプロキシではなく B2BUA であり、A からの取引を終端して B へ別の取引を生成する。
  • 文書は、T が A を先に受け入れ、B への招待結果を会議イベントで通知する案も検討した。その案は帰属を明確にできたが、複雑さ、メッセージ数、設定遅延のため採用されなかった。
  • 採用案では、仮応答が失われると同じ 603 から T の拒否か B の拒否かを判断できない。History-Info は、減らした手順が失った因果情報を補う証拠になる。

採用されなかった流れは判断を分けていた

代替案では、T が A の INVITE に 200 OK を返して最初のセッションを成立させる。その後 T は B に別の INVITE を送り、A は会議イベントパッケージを購読して二番目の結果を知る。

この構造なら、「T が A をサービスへ入れた」と「B が T からの招待を受け入れた」が別のイベントになる。最初の成功を見ても、B の結果を推測する必要はない。

観測面としては分かりやすい。サービス入場、宛先招待、会議状態という三つの記録が、それぞれ異なる権限を表す。

しかし RFC 5370 はこの案を選ばなかった。より複雑で、メッセージ数が増え、セッション設定の遅延が大きくなるためである。

短い流れは一つの取引ではなかった

採用された流れでは、A が T へ INVITE を送り、T が B へ新しい INVITE を送る。B の最終応答を受けた T は、A 側に新しい最終応答を生成する。

図は直線に見えるが、取引は連続していない。RFC は T を B2BUA とし、プロキシではないと明記する。T–B の INVITE は A–T の INVITE とは別の取引である。

T はサービス内容に応じた SDP も生成する。単に A のパケットを転送しているのではなく、別の主体としてメディア能力を提示し、B と交渉する。

メッセージを減らしても、二つの権限判断は残る。それらが同じ画面に圧縮されただけである。

同じ 603 は誰が拒否したかを言わなかった

B が 603 Decline を返すと、T は A にも 603 を生成する。コードを合わせることで、下流の結果分類は上流へ伝わる。

ところが T から A への 183 Session Progress が失われた場合、A は最終 603 の出所を区別できない。T 自身が最初の INVITE を拒否したのか、T が生成した INVITE を B が拒否したのかが分からない。

同じ数字は同じ原因を保証しない。拒否した主体が違えば、再試行、障害対応、利用者への説明、責任分担も違う。

終端状態だけを残す監視は、最も簡潔でありながら最も重要な問いに答えられない可能性がある。

History-Info が代替案の観測面を補った

RFC 5370 は、この曖昧さを解くため T と A の間で History-Info を用いる。履歴は 603 を別のコードに変えるのではない。どの経路で結果に到達したかを付加する。

つまり、採用案は会議状態という独立した観測チャネルを省き、履歴情報に因果の説明を担わせた。

この設計は、ログ削減の意味を変える。History-Info や仮応答を「診断用の余分な情報」として捨てれば、設計が前提にした補償手段そのものを失う。

当時の参照は RFC 4244 であり、後に RFC 7044 が History-Info の文脈を更新した。後継文書の存在は、個別セッションに履歴があった証明にはならない。実際のヘッダーと捕捉状態を確認する必要がある。

遅延指標は証拠予算でもある

プロトコル設計では、メッセージ往復を減らすことが設定時間の改善につながる。製品チームも同じ圧力を受ける。

だが、一つのイベントを減らすと、そのイベントが担っていた区別を別の証拠で保持しなければならない。RFC 5370 では History-Info がその役割を持つ。

運用で「呼設定時間」だけを最適化し、履歴生成や保存を無効にすれば、設計上の交換条件を片側だけ実行することになる。

意思決定者は遅延、メッセージ量、実装複雑性だけでなく、失敗帰属を維持するコストを同じ表に載せるべきである。

From の継承も観測を圧縮した

T は、受信した From の値を用いて送信側の From を生成しなければならない。ただし入信要求のプライバシー条件に従い、tag は引き継がない。

B から見ると A の本人性が継続しているように見える。一方、タグと取引は新しい。これは矛盾ではなく、表示される発信者とメッセージを生成した主体が別であることを表す。

認証された利用者、T による認可、外向きの表示、原送信者についての本人性アサーションも別の証拠である。

RFC 5370 が参照した RFC 4474 は後に RFC 8224 に置き換えられた。歴史的参照を、現在の導入方式や検証成功の証拠にしてはならない。

一件の recipient-list が権限を限定した

A は T への INVITE に SDP と recipient-list を含める。リストには B の URI が一つだけ入る。

T が複数 URI のリストを受け取った場合、488 を返し、最大一件であることを示すべきだと RFC は定める。

SDP は A–T のメディア提案を制御し、リストは T が誰へ新しい要求を生成できるかを制御する。同じ multipart 内でも権限の対象は異なる。

リストの完全性、ハッシュ、件数、実際に使用した URI を保存しなければ、交渉成功から宛先の正しさを推測するしかなくなる。

opt-in 不要は三条件の結論だった

RFC 5363 のリストサービスは、増幅や望まない要求のリスクを扱う。RFC 5370 はこの特定サービスについて opt-in リストを要求しない。

根拠は、T が一つの INVITE しか生成しないこと、A が既知の B の URI を自ら書くこと、T の送信要求に発呼者の本人性が存在することにある。

サービス名が同じでも、グループ展開、未知宛先への変換、本人性の非表示が加われば条件が変わる。過去の結論をそのまま適用できない。

例外は静的フラグではなく、毎回検証される前提集合として実装すべきである。

完全性は結果品質を保証しなかった

RFC 5370 はリストの完全性を重視し、S/MIME や TLS などを挙げる。また T は利用者を認証し、認可しなければならない。

これらは指示の改変とサービス利用権を扱う。T が正しい SDP を作り、期待した変換を行い、不要な媒体を保持せず、適切な出力を返したことまでは証明しない。

A–T と T–B は異なる脚であり、一方の暗号的保護がもう一方へ自動継承されるわけでもない。

RFC 5246 など出版時の参照は歴史として扱い、現在の暗号設定をそこから推定してはならない。

302 はさらに別の判断を A に返した

B が A の SDP を受け入れられない場合、T の URI と ?body= パラメータを含む 302 Moved Temporarily を返すことができる。body には B の URI を持つリストが入る。

この応答だけでは T は呼び出されない。A が元の試行を ACK し、複雑なエスケープを解釈し、T へ新しい INVITE を送る必要がある。

RFC は、着呼者が開始する場合には 3pcc の方が簡単だと述べる。body を URI に埋め込む複雑性が判断と検証の面を増やすためである。

監査では 302、Contact、復号後の本文、A の追随判断、T への要求、T の下流要求を別々に残すべきである。

アクセシビリティは最後の層に残った

このモデルは、聴覚障害や発話障害を持つ人を支えるトランスコーディングサービスの要件を満たす目的を持つ。音声テキスト化はその例である。

両方の SIP 脚が成功し、媒体が T を通過しても、人が理解できたことはまだ証明されない。言語、方向、精度、遅延、提示方法が利用目的に合う必要がある。

設定時間を短縮する設計判断が、利用者成果の計測を短縮してよい理由にはならない。

インフラ成功とアクセシビリティ成功を分け、後者の観測がなければ「不明」を保持する必要がある。

最小仕様は交換条件を明示する

Lu Heng の Minimum Initial Specification を明示的な分析レンズとして使うと、共有すべき最小記録が見える。認証した呼出者、認可、保護された単一宛先、プライバシー、二取引、脚別応答、因果履歴、T のサービス本人性である。

すべての導入方法を統一する必要はない。しかし、短い流れを選ぶなら、失った観測面を何で補うかは共通契約に含めなければならない。

Reality Layers は、表示名、credential、取引、状態、媒体、変換、人の理解を別の現実層として扱う。一つの成功を他の層へコピーしない。

RFC 5370 の設計はメッセージを減らした。証拠を減らす許可までは与えていない。