RFC 5244：イベント受信は通話状態の証明ではない

要約

送信側ゲートウェイが信号を検出し、イベントを三回送った。受信側では欠落も改ざんもない。ここまでなら強い証拠である。しかし「通話が期待どおり進んだ」という結論には、まだ何段もの空白がある。

RFC 5244 の RTP トランクは、回線交換網の間を IP で結ぶための翻訳層だ。音声コーデックは低位ビットに埋め込まれた信号を壊し、多周波トーンにも影響を与え得る。そこでゲートウェイが信号を認識し、番号付きイベントとして別に運ぶ。

翻訳は観測点を明確にする一方、因果を短縮しない。入口の検出が正しいか、双方が同じイベント定義を使うか、重複を一度だけ適用したか、正しいトーンやビット状態を再構成したか、旧来の状態機械が時間内に受理したかは別問題である。

RFC 5244 は RFC 4733 を更新し、RFC 2833 の曖昧、誤り、重複を含む割当てを整理する。完全な後方互換性があるのは full ABCD-bit signaling の場合に限られると明記されている。

したがって、イベント番号だけを保存する運用台帳は不十分だ。SS No. 5、R1/MF、R2、ABCD のどれか、どの RFC 世代か、何をネゴシエートしたか、受信側のローカル設定は何かを一緒に残す必要がある。

両端がエラーなくパースできても、意味が一致しているとは限らない。移行時に最も危険なのは、壊れたパケットではなく、双方が異なる解釈で「成功」と記録する正常なパケットである。

ABCD の状態は相互排他的で、最新の遷移が現在状態を表す。遷移時には 5 ミリ秒間隔で三回送り、変化がなければ定期的に更新する方式が推奨される。これは損失耐性のための仕組みだ。

ところが A だけ、または A/B だけを使う方式では、使わないビットを受信ゲートウェイがローカル設定に従って補う。同じイベントを受け取っても、完成した物理条件は設定に依存する。入力ログから出力状態を推定してはいけない。

状態には鮮度もある。RFC 4733 の soft state は duration が切れ、更新がなければ unknown になり得る。最後のイベントを無期限の現在値として表示する監視は、過去の観測を現在の事実に変えてしまう。

continuity check-tone の名称は、イベント到着を試験合格と誤解させる。四線式では発信側が検査トーンを送り、遠端がループバックし、発信側が戻りを検出して初めて成功する。二線式では逆方向の verify-tone も使う。

コード 121 の送受信は検査開始の証拠であり、コード 122 は応答報告の証拠である。最終判定点が戻りを認識したという証拠ではない。パケットキャプチャだけで「媒体経路は連続」と結論づけると、観測範囲を越える。

輻輳時にはさらに判断が入る。遅延や欠落でトーンを途中停止すると呼設定が失敗し得るため、継続再生が望ましい場合がある。ただし設定時間は伸びる。時間制約の厳しい register signaling では、報告 duration のコピーより、元の信号規格に従う再生が重視される。

metering pulse は課金用途の離散イベントで、再送が求められる。音声と同時に流れることもある。再送された複数パケットは複数料金ではない。

正しい会計証拠には、通話との対応、イベントの一意性、重複排除、料金規則、顧客口座、元帳への受理が必要だ。イベント受信はこの鎖の入口にすぎない。ネットワークの耐損失性を会計の加算規則にすると、可用性の改善が誤請求を生む。

trunk unavailable も同様である。RFC は故障と管理操作の両方を原因として挙げる。イベントは状態報告であって故障診断ではない。更新が止まったことも復旧証明ではない。

RFC 5244 は盗聴、不正接続、ハイジャック、DoS を想定し、必要な場合に自動鍵管理を伴う SRTP を推奨する。通話設定、課金、切断を扱う以上、真正性と完全性は欠かせない。

それでも、認証された送信者が正しく検出したとは限らず、そのイベントで課金を発生させる業務権限を持つとも限らない。暗号は「誰が何を送ったか」を強化する。ポリシーは「何を許すか」を決め、下流受領証は「何が起きたか」を示す。

最低限、信号認識、定義バージョン付きイベント化、認証済み配送、復号・重複排除、信号復元、旧状態機械の受理、通話または業務結果を別々に記録するべきだ。相関IDはそれらを結ぶが、欠落を埋めない。

これは Lu Heng の reality-first という要求に沿う。標準への適合は重要な設計条件だが、現実の結果は観測して初めて存在する。unknown を残せる設計の方が、最初の緑ランプで全工程を成功扱いする設計より強い。