要約

  • RFC 3624は、一度に一つの対象しか調べられなかったMGCP監査を拡張し、データグラムの上限に達した後も続けられる一括レポートを定めた。
  • 200 OK は要求範囲全体の完了を意味しない。BA/NE は再開位置を示し、BA/EL は短縮されたカウントや状態の各値がどの対象に対応するかを示す。

2003年の課題は、呼制御エージェントがフェイルオーバーした際、数百から数千のエンドポイントを持つメディアゲートウェイの状態を再構成することだった。従来のMGCP監査は一つずつ照会する。RFC 3624はBulk Auditパッケージを加え、対象群の命名、選択した状態や接続情報をまとめて得られるようにした。ただし文書の位置づけはInformationalであり、IESG注記はMGCPと、標準に基づくMegacoの選択肢を区別している（RFC 3015）。したがってこれは歴史的な復旧インターフェースの記録であって、特定事業者の採用を示す証拠ではない。背景となる初期MGCPのRFC 2705、後続のMGCP 1.0、RFC 3435も参照した。

一括監査は、ワイルドカードで混同されやすい問いを分ける。BA/Z は設定された名前のパターンを求め、BA/X は現在インスタンス化されている非永続の仮想エンドポイントを求める。たとえば conference/* という命名規則があっても、その全対象が実際に作成済みとは限らない。可能な名前の規則を、現存する対象一覧と取り違えてはならない。

既存エンドポイントについて、BA/C は接続数を順番に返す。16進数字は0〜15を表し、Z は16以上ではなく「15を超える」という分類で、正確な数ではない。BA/M は接続モードを符号化する。BA/S は指定条件を評価し、T、F、またはサービス外を示す O を返す。複数条件に対する論理和の要約であり、各接続の状態表ではない。RFCもエンドポイント状態の値が接続状態を説明するものではないと明記する。これらの数値から、通話完了、音声の伝送、アプリケーション動作、顧客へのサービス提供までは証明できない。

次にデータグラムの大きさが効いてくる。全結果が最大サイズを超えるなら、ゲートウェイは要求数より少ない対象だけを返してよい。その場合は次のローカル名を BA/NE に含める。呼制御エージェントはその値を次の BA/SE に設定して続きを求められる。成功コードは今回の応答を認めるだけで、カーソルは一連の監査がまだ終わっていないと伝える。(RFC 3624 §§2.1.1.1、2.1.1.7)

カウントや状態の解釈には、もう一つ対応関係が必要だ。BA/EL は BA/C や BA/S の前に置かれ、各位置がどのエンドポイントを指すかを示す。仮想エンドポイントの実体範囲は飛び飛びになり得るため、単なる飾りではない。名前との対応を失えば、整形式のベクトルでも誤った対象に割り当ててしまう。件数と状態を同時に要求した場合は、双方が同じ対象範囲を示さなければならない。(RFC 3624 §§2.1.1.8、2.1.2)

RFC 3624は巨大な監査を再開する方法を定めるが、複数要求をまたぐ原子的なスナップショットは定義しない。ページごとの観測時刻は異なり得て、それらを同一時点の状態に束ねる共通エポックもない。フェイルオーバー後に有用な制御面の見取り図は得られても、それが完全・同時であることや、提供中のサービスと同じであることは別問題だ。「実際に動くコードに基づいて考える」という視点は、Heng LuのRunning-Code Primacyを分析上のレンズとして限定的に参照する。これはMGCP実装を裏付ける資料ではない。

応答形式の控えめさには意味がある。ゲートウェイが何を返し、各値が何を指し、次の要求をどこから始めるかを知らせる一方で、制御状態をエンドツーエンドのサービス試験に見せかけない。接続、メディア、アプリケーション、利用者への結果は、それぞれ別の証拠で確かめる必要がある。