要約

  • RFC 5369 は Informational 文書であり、SIP セッションでトランスコーディングの必要性を発見し、3pcc または会議ブリッジでサービスを呼び出す枠組みを示す。
  • 会議ブリッジは呼出側端末の信号交換を減らし、単純な端末でも利用しやすい。一方、ストリームや方向ごとに異なる T を選べず、途中変更には遠端の Replaces 対応が要る。
  • 簡素化は権限の移転である。T は二つの媒体レッグと信号を扱い、媒体を読んで変更する。認証しても通常のエンドツーエンド媒体保護は T を越えて維持されない。

「簡単」は誰にとってか

システム設計で簡単という言葉は、しばしば費用の移転先を隠す。端末が送るメッセージを減らせば、サーバーが状態と判断を引き受ける。

RFC 5369 の会議ブリッジモデルでは、T は二者会議サーバーとして振る舞う。B2BUA として A–T と T–B を個別にネゴシエートする。

呼出側端末は一般に 3pcc より少ない信号交換で済む。低帯域・高遅延のアクセスや、3pcc を実行できない単純な端末に価値がある。

ただし運用、プライバシー、障害解析まで単純になるとは書かれていない。端末から消えた判断は T に集まる。

必要性は応答端末が決める

Presence 文書や SDP は遠端能力を示せる。OPTIONS の 200、INVITE の 488、offer/answer などが証拠になり得る。

しかし SIP の並列 fork は、能力の異なる複数のユーザーエージェントへ要求を送る。次に電話、ソフトクライアント、ボイスメールのどれが応答するかを、発信前に確定できない場合がある。

RFC 5369 はこの困難を HERFP と結び付け、一般解決を範囲外に置く。能力を人の固定属性へ変換してよいという意味ではない。

記録は発行主体、Contact、時刻、版、fork 分岐、最終応答端、offer と answer を結び付ける必要がある。

早い呼出しは二重変換を生む

文書は、answerer が必要能力を持たないと確認する前に offerer が T を呼び出さないよう勧告する。

両端が相手について誤った推測をすれば、それぞれ T を追加できる。共通 GSM コーデックを持つ端末間で、GSM–PCM–GSM の余計な変換が起きる例が示される。

二つの T は遅延、品質劣化、費用、故障点、媒体閲覧者を増やす。単なる最適化問題ではない。

自動化は、実際の応答端末に結び付いた不一致証拠を要求すべきである。以前の呼の結果や端末群の多数派は代用にならない。

サーバー URI は別に得る

RFC 5369 は媒体サーバー発見を扱わない。呼出側がサービス URI を知っていると仮定する。

したがって、必要性を発見しても、適切な T を発見したことにはならない。形式、方向、言語、容量、管轄、保持、可用性を別に検証する。

サービス名「音声テキスト化」は、精度や遅延、出力表現を証明しない。カタログは候補であり実行受領証ではない。

必要性、選択、T 認証、両レッグの交渉、媒体受信、変換出力を別のイベントとして保存する。

人の不一致には目的が要る

端末間に共通コーデックがない場合と、聴覚障害者に音声だけが届く場合は、どちらも情報表現の不一致である。

RFC 5369 は同じ SIP 呼出機構を適用するが、証拠の意味は違う。コーデック集合は比較できても、人のアクセシビリティは好み、言語、方向、状況を含む。

音声からテキストとテキストから音声を両方必要とする場合も、片方向だけ必要な場合もある。

「トランスコード中」は目的を語らない。誰のために、どの方向を、何へ変え、いつ届いたかが必要である。

3pcc は選択を端末に残す

3pcc モデルでは、呼出端末が T と遠端の双方へ信号関係を持つ。T と遠端の間には信号関係がない。

高度な端末は、変換が必要なストリームだけを T に送り、互換ストリームを直接流せる。

送信方向と受信方向に異なる T を選ぶこともできる。セッションを一つの経路ではなく方向付きの媒体集合として扱う。

その代わり端末は多くの状態を調整する。柔軟性には主体、再試行、失敗、終了を関連付ける責任が伴う。

ブリッジは選択をまとめる

会議ブリッジでは T が双方と信号し、媒体も両レッグを通る。端末側は軽くなる。

しかし異なるストリームや方向へ別々の T を割り当てられない。音声だけが互換でも、設計上より広い媒体が橋へ集まり得る。

単純端末を支援する価値と、T の信頼集中は同時に記録すべきである。一方を理由に他方を消してはいけない。

受領証にはモデル、各レッグ、媒体種別、方向、T、形式、開始と終了を含める。

途中変更で Replaces が現れる

音声で始まったセッションが後から動画を追加し、その時点で不一致が判明することがある。

RFC 5369 は 3pcc なら進行中に T を挿入しやすいとする。ブリッジモデルで T を挿入または変更するには、遠端が Replaces 拡張を支える必要がある。

2008 年当時、対応ユーザーエージェントが多くないという記述がある。現在の普及率として引用してはならない。

変更前に、選択された端末自身の対応を確認する。製品シリーズの資料や別セッションの成功は受領証ではない。

認証は媒体の必要最小化ではない

T は媒体を解釈し変更するため、少なくとも一部へアクセスする。RFC 5369 は悪意ある T を避けるため認証を勧める。

認証は資格情報の下で誰かを答える。必要な流だけを受け取ったか、変換が正しいか、保持しなかったかは答えない。

T が読めないエンドツーエンド暗号や、変更できない完全性保護は機能と両立しない。A–T と T–B の各レッグは保護できる。

二レッグの暗号化を「A と B だけが読める」と表示してはならない。T が保護終端であることを開示する。

方向分離にも運用費用がある

3pcc は送信と受信に異なる T を使い、一つの T が全媒体を見る集中を減らせる。

同時に二つのサービス ID、認可、ログ、保持規則、故障処理が生じる。共通運営者や時刻相関が全体像を作る可能性もある。

「単一 T は全部を見ない」は正確な限定主張である。「誰も会話を復元できない」は別の証明を要する。

方向ごとに媒体、T、レッグ鍵境界、出力、削除を記録する。

2008 年の参照は現在設定ではない

RFC 5369 は 2008 年 10 月の Informational 文書で、インターネット標準を定義しないと明記する。

当時の TLS と S/MIME を認証手段として挙げる。RFC 5246 は後に RFC 8446 に置き換えられ、RFC 3850 は古い S/MIME 系列に属する。本稿は現在の暗号設定を勧告しない。

NOTIFY の参照 RFC 3265 は RFC 6665 に置き換えられた。文書更新は能力の主体を変更しない。

RFC 3351 はアクセシビリティ要件、RFC 4117 と RFC 5370 は各モデルを扱う。文書状態は個別導入の成果を証明しない。

接続後にも人の結果が残る

能力発行、応答端末、不一致、T 選択、二レッグ、媒体入力、変換出力、利用者の理解は別の層である。

RTP が流れても字幕の正確さや到着時間は分からない。テキストが生成されても利用者が読めたとは限らない。

Lu Heng の Minimum Initial Specification は、共有契約を必要最小限にし、局所情報を持つ端末と利用者へ判断を残す明示的な視点として使う。Reality Layers は presence、SDP、応答、媒体、理解を分離する。プロトコル事実は RFC に基づく。