要約

  • RFC 3372 は、ISUP を MIME 本文に入れて旧来の信号情報を保つ処理と、一部の情報を SIP ヘッダーへ変換してプロキシが経路を決められるようにする処理を分けた。
  • 本文が完全でも正しい経路や機能実現は証明されない。経路が正しくても、ISUP の復元、媒体確立、利用者が受けたサービスまでは証明されない。

PSTN から入った呼が IP 網を横断し、別の PSTN へ戻る場面を考える。入口では ISUP が電話網の状態と機能を語る。途中の SIP プロキシは宛先を選ぶ必要があるが、あらゆる ISUP 方言を読めるわけではない。出口では、SIP だけでは表現しきれない元の情報が必要になることがある。

2002 年9月に BCP 63 として公開された RFC 3372 は、この枠組みを SIP-T と呼んだ。ただし新しいプロトコルではないと明記した。重要なのは名称ではなく、一つの呼を二種類の表現で管理した点である。

上側の記録はカプセル化された ISUP だった。入口ゲートウェイは受け取った ISUP の種類を識別し、RFC 3204 の MIME 型を用いて SIP 本文へ入れる。PSTN 間を SIP 網で橋渡しする場合、出口ゲートウェイはそれを取り出し、旧来の機能に必要な情報を再利用できる。

もう一つは SIP 自身の可視情報である。プロキシは Request-URI やヘッダーで判断する。そこで入口ゲートウェイは、被呼番号など経路選択に必要な値を ISUP から SIP へ変換した。RFC 3372 が区別した「機能透過性」と「経路選択可能性」は、同じ合格印ではなかった。

カプセルが一バイトも変わらず届いても、変換した宛先が誤っていれば別の出口へ向かう。正しい出口へ着いても、本文が欠け、壊れ、または未対応の ISUP 変種なら機能は戻らない。保存の証拠と使用の証拠は分離される。

出口ゲートウェイも単純な再送装置ではない。本文の ISUP をひな型にし、SIP ヘッダーから得た値で一部を上書きし、ローカル方針のパラメータを追加できる。本文がなければ設定済みの標準ひな型を使う。PSTN へ出る信号は、原文の復元ではなく、根拠を追跡すべき再構成だった。

開始時に終端の種類は決まっていないことも多い。PSTN 発の呼が SIP 電話で終わるなら、電話は ISUP を通常無視する。ただし RFC 2046 と RFC 3261 の土台に従い、multipart や未知の MIME 型を理由なく拒否してはならない。逆に SIP 電話から始まる呼について、将来 PSTN に出るかもしれないというだけで端末に ISUP 生成を求めるのも不合理である。

通話中の情報には別の隙間があった。SIP セッション状態を変えない ISUP 信号を運ぶため、RFC 3372 は RFC 2976 の INFO メソッドを利用した。INFO の配達記録は、その意味が理解され、利用者の機能になったという記録ではない。

RFC 3219 の TRIP と RFC 2916 の ENUM は電話宛先を見つける周辺機構だったが、ISUP 本文の代わりにはならない。RFC 2633 に基づく S/MIME 署名は内容を保護できても、変換の正しさ、出口の権限、ローカル方針、音声経路の成立までは保証しない。

RFC 3398 は後に SIP と ISUP の詳細な対応を規定した。RFC 3326 の Reason は原因を運ぶが、説明そのものが動作を実行するわけではない。RFC 3331 と RFC 3332 は SS7 の適応点を SCTP 上へ移す話であり、SIP-T の二重表現とは責任範囲が異なる。

公式資料から現在の普及率や特定事業者の成功を推定することはできない。しかし設計上の教訓は明確だ。相互接続は、古い意味を新しい形式へ完全に変換して原本を捨てる作業ではなかった。途中の主体に必要な可視情報を作りながら、能力のある終点のために原信号も保持する作業だった。

Lu Heng の二つの論考を重ねると、その慎重さが見える。共通仕様は最小限にし、ローカルな判断を隠さない。そして、受信 SS7、封入本文、変換ヘッダー、選択経路、出口再構成、媒体、利用者体験を別々の現実層として記録する。RFC 3372 が残したのは「電話が IP になった」という物語ではなく、二つの真実を混同せず接続するための手順だった。

出典