要約

  • RFC 3525 が保証したのは一つのトランザクション内の逐次コマンド処理であり、複数のトランザクションは任意の順番または同時に実行できた。
  • TransactionPending、再送制御、応答確認、at-most-once はそれぞれ限定された配送事実を示すだけで、トランザクション間の因果関係やメディア成果を証明しない。

TransactionPending の意味は慎重に限定されていた。受信側が未完了のトランザクションを能動的に処理していることを知らせ、送信側のタイマーを再始動させる。それ以上ではない。どのコマンドまで進んだか、最終的に成功するか、別の処理との前後関係は含まれない。

この狭さは、RFC 3525 全体の時間設計を映している。Media Gateway Controller と Media Gateway は、物理的に分解されたマルチメディアゲートウェイの別要素だった。制御判断とメディア資源の実行をつなぐには、並列性を残したまま、必要な範囲だけ順序を共有する必要があった。

その範囲が Transaction である。Transaction は Action を持ち、Action は一つの Context に属し、Command を並べる。同じ Transaction 内の Command は逐次実行される。最初の非 Optional エラーで後続 Command は停止する。

Optional と指定された Command は例外だった。失敗しても後続処理を続けられる。つまり順序だけでなく、失敗時に列を切るかどうかも送信者が表現した。

しかし Transaction 同士に順序保証はなかった。任意の順で実行しても、同時に実行してもよい。一つの Message にまとめても関係は変わらない。Message は本質的に運搬の仕組みであり、アプリケーションレベルの一括確認を持たなかった。

要求 A、B、C が同じ Message に入っていても、A と C の Reply が先に一つの Message で返り、B が後から別に返ることがある。送信バイト列の並びを、ゲートウェイ内部の時間軸として読むことはできない。

この設計は無秩序のためではなく、独立した Termination を並行して扱うためだった。Termination ごと、あるいはその集合ごとに別プロセスやスレッドが動ける。関連のない処理を一列に並べる必要はない。

依存がある場合は Controller が責任を持つ。同じ Termination に対しては、同じ Transaction に入っていない限り、未完了の Add、Modify、Move は通常一つまでとされた。Add の完了を前提に Modify するなら、一緒に並べるか Reply を待つ。

Subtract はいつでも発行できた。このため、先に送った Modify が後から処理され、すでに Subtract された Termination を対象にする場合がある。MG はその Modify を無視し、エラーを返すべきだった。送信順序と状態順序が分かれる具体例である。

Notify にも競合があった。古い EventsDescriptor に対応する Notify が遅れ、新しい Descriptor の送信後に MGC へ到着し得る。UDP のように順序配送を保証しない場合、一つの Termination で未完了 Notify は通常一つまでとされた。

Transaction という名称も、データベースの全面 rollback を意味しない。Command が失敗した場合、MG はその Command を試す前の状態へ可能な限り戻す。先に成功した全 Command を取り消すという規定ではない。

TransactionReply は成功 Command の戻り値と失敗 Command の Error Descriptor を併記する。これは部分的な現実を消さない設計だった。成功、失敗、未実行を一つの赤い印にまとめると、次の判断に必要な情報が失われる。

Wildcard の TerminationID では、一つの Command が各一致対象に試され、それぞれの応答が返る。一件でもエラーなら後続 Command は試されない。複数の成功結果とエラー、そして未実行部分が同じ Transaction に存在し得る。

再送と応答確認は別の問題を解く。Reply が失われれば Request が繰り返される可能性がある。TransactionID、保存された Reply、Response Acknowledgement により重複実行を抑え、at-most-once を支える。しかし別々の Transaction に因果順序を与えるものではない。

通信路を認証しても同じである。正当な MGC から改変されずに届いたことは示せる。依存を表現しなかった二つの正当な命令が、望まない順番で実行される可能性は残る。

さらに、Command の成功は人間の成果ではない。Audit は Context や Termination の属性を読めるが、メディアパケットの通過、音声の復号、利用者の聴取には別の観測が必要である。

RFC 3525 は 2003 年に RFC 3015 を置き換え、IETF Megaco WG と ITU-T SG16 の共同作業を反映した。だが 2008 年、RFC 5125 は ITU-T が H.248.1 を更新し続けたことを理由に RFC 3525 を Historic とした。ここで読むべきなのは歴史的な制御境界であり、現在の全装置の仕様ではない。

IANA の Megaco/H.248 登録簿は後続参照の下で残っている。共有識別子を維持する機能と、特定のゲートウェイが実行する版・順序は別物である。

最小の共通仕様は弱さではない。RFC 3525 は、一つの Transaction に明示された依存だけを順序化し、それ以外の将来判断を Controller の近くに残した。Running code を理解するには、器ではなく、TransactionID、Command、状態監査、パケットの順に証拠を追う必要がある。

Sources