要約

  • RFC 5194の相互接続は、単なる文字コード変換ではない。旧式ネットワークへのゲートウェイは速度、半二重動作、文字集合、バッファリング、損失の見せ方を変え得る。
  • セッション成功や最終 transcript は、その変換が会話性を保った証拠ではない。入口と出口の媒体、変換規則、待ち時間、欠落、利用者への提示を別々に記録すべきである。

透明な線ではなく、判断する装置

ゲートウェイを単なる接続点として図示すると、責任が消える。IP側のT.140文字列と旧式テキスト電話は、同じ文字を扱っていても同じ時間モデルを持たない。低い伝送速度、半二重、限定された文字集合は、会話の順序と表現を変える。

RFC 5194がPSTN、携帯系、インスタントメッセージングとの相互接続を詳細に扱うのはこのためだ。変換は必要になり得る。しかし必要性は透明性を意味しない。

ゲートウェイは、入力プロトコル、出力プロトコル、バッファ規則、速度制限、二重性の変更、文字対応表、損失の扱いを持つ実行主体である。その版と結果がなければ、利用者が待った理由をネットワーク、端末、変換のどこにも帰属できない。

RFC 5194が守る時間

リアルタイムテキストは、入力された文字を会話のために逐次送る。文書は文字を可能な限り早く送るよう求め、行全体のバッファリングは文字遅延要件を満たさないと明記する。

一秒のエンドツーエンド遅延は良好とされ、300ミリ秒までの短縮が評価され、約二秒まで許容され得るという記述もある。これは現代の全サービスに同一SLAを課す規定ではない。入口から表示までの時間が媒体の意味であることを示している。

旧式区間が遅い場合、サービスはその境界を示すべきだ。IP側の高速なパケット時間だけを公開すると、ゲートウェイ待ちが消える。最終文面だけを公開すると、交互送信に変わった事実が消える。

合意、到着、表示

SIP、offer/answer、SDPは媒体を確立し記述する。RFC 4103はT.140をRTPで運ぶ。RTPは順序と時間の観測面を提供する。それぞれ重要だが、画面表示を直接証明しない。

運用状態は少なくとも、文字媒体の合意、最初の送信、最初の受信、損失と回復、デコード、表示を分ける必要がある。音声や映像が正常でも、文字の状態を緑にしてはならない。

入力時刻、送信時刻、到着時刻、表示時刻を結ぶと、端末の行バッファ、ネットワーク遅延、ゲートウェイ待ち、renderer待ちを区別できる。cpsの合意は能力であり、実測の会話速度ではない。

冗長化が残す境界

RFC 4103とRFC 2198の冗長ペイロードは、後続パケットに最近の文字を含めて損失を回復できる。だが text/red があることは無損失証明ではない。

どの順序欠落が起き、どの世代で何が回復し、何が残ったかを記録する必要がある。RFC 5194が想定する text-loss indication を表示せずに欠落の両端を連結すれば、読みやすさと引き換えに根拠を失う。

旧式区間で損失記号を表せない場合、その代替も変換結果である。ゲートウェイは「文字を出した」だけでなく、「不足をどう表現したか」を説明しなければならない。

文字集合は固有名を試す

国際文字を扱えるIP側から限定的な文字集合へ移ると、一般文は読めても人名や地名が壊れることがある。全体の可読率は、この局所的な重大性を薄める。

変換前のイベント、変換後のイベント、利用者への表示、保存 transcript を分ければ、どこで置換が起きたか分かる。保存時にUnicodeへ「修復」しても、相手が実際に見た文字を変えてはならない。

IMへの変換も別媒体である

RFC 5194のインスタントメッセージング相互接続例は、逐次文字を連結し、非英数字や改行などの境界で送る動作を扱う。これは実用的な橋だが、逐次文字をmessageへ変える。

その出口をリアルタイムテキストと同一に報告すると、turn timing が消える。正しい報告は、どの区間が逐次で、どの区間がmessageで、どの規則が境界を決めたかを示す。

緊急と多人数

RFC 5194は緊急通話とrelay利用を想定する。法的義務は地域と現行制度に依存し、本稿は適合性を断定しない。ただし、宛先へのrouting、relay readiness、文字媒体、最初の双方向表示は別イベントである。

RFC 9071が示す多人数表示の問題も同じ構造を持つ。読みやすい合流streamは、発言者帰属の証拠ではない。支援要請や訂正の主体を後から文脈で推測してはならない。

最小の変換receipt

本稿が提案するreceiptはRFC 5194のwire formatではない。sessionと媒体記述、streamと参加者、入力から表示までの時刻、一次到着、冗長回復、残存損失、利用者への表示、媒体別状態、各gatewayの入出力と変換版を保存する運用上の推論である。

Heng Luの現実層の原則では、connected はsessionだけを、received はtransportだけを、rendered は表示だけを語る。最終 transcript にそれら全部の権限を与えない。最小初期仕様は相互運用に必要な会話意味を守り、実装の自由はその境界の内側に残す。

Sources

  1. RFC 5194 HTML
  2. RFC 5194 text
  3. RFC 5194情報
  4. Datatracker RFC 5194
  5. RFC 5194履歴
  6. RFC 5194参照
  7. RFC 5194 errata
  8. RFC 4103
  9. RFC 4103情報
  10. RFC 9071
  11. RFC 9071情報
  12. RFC 4351
  13. RFC 3550
  14. RFC 2198
  15. RFC 3261
  16. RFC 3264
  17. RFC 8866
  18. Heng Lu — reality layers
  19. Heng Lu — minimum initial specification
  20. Heng Lu — running-code primacy