要約

  • RFC 3064 は、数十ミリ秒で反応すべき CAS の状態機械とタイマーをメディアゲートウェイに置き、番号分析や経路選択などの上位判断を Call Agent に残した。
  • rel と rlc は電話側の資源を解放してトランクを再利用可能にするが、パケット側の接続は削除しない。完全な後始末には、別の DLCX とその結果が要る。

往復遅延を状態機械に入れない

Channel Associated Signaling（CAS）では、捕捉、応答、オンフック、解放といった回線状態が短い時間幅で変化する。反応期限が数十ミリ秒なら、すべてを遠隔 Call Agent に問い合わせる設計は、制御網の遅延そのものを電話プロトコルの成否条件にしてしまう。

2001 年 2 月の RFC 3064 は、処理場所を責任ごとに分けた。CAS の低水準プロトコル、タイミング、タイムアウトは、可能な限りメディアゲートウェイが扱う。番号列の意味を解釈し、相手側を選び、パケット接続を構成する処理は Call Agent が担う。近い装置が速い動作を行うことと、通話全体を決めることは同じ権限ではなかった。

文書は六つの MGCP パッケージを収めた。基本 MF CAS の MS、DTMF とダイヤルパルスの DT、PBX/FXS の BL、FXO の DO、Feature Group D の EANA/EAIN 用 MD、オペレーターサービス用 MO である。IANA の登録は六つの version 0 名を現在も示すが、それは名前の割当て記録であり、特定製品の実装や現用回線の証拠ではない。

共通イベントの下に差異は残った

着信が一つの番号列を渡すだけなら、wink start と immediate start の違いごとに Call Agent の呼処理を作り直す必要はない。ゲートウェイが局所的な手順を吸収し、同じ call setup イベントを上へ渡せる。

しかし、抽象化は物理差を消さない。具体的なトランク種別は MGCP の外でゲートウェイに設定される。Call Agent も、使用パッケージと入方向・出方向・双方向の別は知らなければならない。共通名は制御契約であって、機器能力の自己証明ではない。

ここには局所判断の適切な幅が見える。期限の厳しい、戻しうる動作は端末の近くで行う。複数の端点や網に影響する決定は、広い状態を持つ制御側へ戻す。その間を流れる証拠を省けば、抽象化は障害を隠す覆いになる。

signal と event は反対向きだった

RFC 3064 の用語は責任の向きを残す。signal は Call Agent からゲートウェイへの命令であり、event はゲートウェイが観測して Call Agent へ通知する事実である。コマンドへの 200 OK は一段階の受理を示す。発信数字を送り終えたことは operation complete で通知され、相手の応答はさらに別の監視状態になる。

したがって、成功応答だけから「番号送出完了」「相手が出た」「双方向の音声が通った」「人が会話した」を導くことはできない。例示された呼の流れ自体が、これらを別時点として記述している。

一部のイベントには、監査可能な状態を表す S が付く。監査が答えるのは狭い問いである。回線で呼開始が起きたか。電話側が idle となり、新しい呼に使えるか。現在状態の再同期には役立つが、そこへ至る因果の全履歴までは戻らない。

解放完了は一枚では足りない

rel は単なるオンフックではなく、電話レッグの資源を解放する意味を持つ。Call Agent が送ることも、遠端のオンフックやゲートウェイ異常を受けて event として上がることもある。続く rlc は、トランク資源の解放が完了し、次の呼に利用できることを示す。

それでもネットワーク接続は残りうる。RFC 3064 は、rel が接続削除を含意しないと明記した。接続を含む呼全体を解放するには、rel と別に、または併せて DLCX を実行しなければならない。

二つの操作が扱う対象は異なる。回線側が idle でも、ゲートウェイ内にパケット接続が残っている場合がある。反対に接続を消しても、遠端の回線解放が終わっていない場合がある。rlc はトランク再利用の証拠、DLCX は接続ライフサイクルの証拠であり、互いを代用できない。

異常系では境界がさらに重要になる。双方向トランクを両端が同時に捕捉する glare などで、ゲートウェイが電話レッグを維持できず rel を出すことがある。このとき rlc は状態遷移を完了させるために使われ、必ずしも文字どおりの遠端オンフック観測を表さない。資源状態の報告を、人の行動の物語へ膨らませてはならない。

局所ポリシーも記録が必要だった

glare の扱いには、DS0 ごとの設定を含むゲートウェイ側の選択がありえた。衝突は物理ポート近くで起こり、時間制約も厳しいため、局所処理には理由がある。ただし Call Agent は結果と原因を受け取り、残る接続を処理しなければならない。

RFC は一つの選択を普遍化したのではなく、設定された処理を共通イベントへ写す方法を示した。運用者が保存すべきなのは、設定値、観測した hook 状態、原因、rel、rlc、そして DLCX の列である。最後の idle 表示だけでは、どちらの捕捉が勝ったかも、ネットワーク資源が戻ったかも分からない。

RFC 3064 は Informational であり、Internet Standard ではない。IESG Note は当時複数製品で展開中だったと述べる一方、IETF Megaco WG と ITU-T SG16 の後継作業へ注意を促した。後年の MGCP と Megaco/H.248 文書は移行の文脈を与えるが、RFC 3064 の意味を遡って変更せず、現在の採用も証明しない。

残った教訓は、短い締切を局所化するだけでは不十分だということだ。局所処理の権限を狭く定め、上位判断との境界に別々の受領証を置く必要がある。ミリ秒はゲートウェイに任せられる。それでも通話の完了は、一つの緑色表示では決まらない。

出典