Кратко

  • RFC 3624 расширила аудит MGCP с одной конечной точки за запрос до группового отчёта, который можно продолжать при достижении предельного размера датаграммы.
  • 200 OK не подтверждает охват всего запрошенного диапазона: BA/NE указывает место продолжения, а BA/EL связывает компактные значения счётчиков или состояния с конкретными точками.

В 2003 году задача была вполне практической: после переключения Call Agent требовалось восстановить представление о шлюзе с сотнями или тысячами конечных точек. Базовые команды аудита 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 возвращал числа соединений по порядку. Шестнадцатеричная цифра обозначала от нуля до пятнадцати; Z означала «больше пятнадцати», а не точное число. BA/M компактно кодировал режимы соединений. BA/S проверял заданные условия и возвращал T, F или O — вне обслуживания. Это логическое «ИЛИ» между критериями, а не полное описание каждого соединения. RFC прямо предупреждает, что индикатор состояния конечной точки ничего не говорит о состоянии соединений. Ни одно из этих значений само по себе не доказывает состоявшийся звонок, передачу медиа, работу приложения или доступность услуги клиенту.

Затем вступало ограничение датаграммы. Если полный отчёт превышал бы максимальный размер, шлюз мог вернуть сведения о меньшем числе точек, но обязан был добавить BA/NE со следующим локальным именем. Call Agent мог использовать его как начальную позицию 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 описывает продолжение большого аудита, но не атомарный снимок между запросами. Страницы могут содержать наблюдения, сделанные в разное время; протокол не вводит общей эпохи, которая объединяла бы их в единый срез. Поэтому после переключения можно восстановить полезное представление плоскости управления, не доказав его полноту, одновременность или тождество работающей услуге. Как явно обозначенная аналитическая перспектива — не техническое свидетельство об MGCP — эта граница перекликается с эссе Heng Lu о приоритете работающего кода.

Сдержанный формат сообщает, что именно вернул шлюз, к каким именам относятся значения и откуда начинать следующий запрос. Он не превращает наблюдение за плоскостью управления в сквозную проверку услуги. Для соединений, медиа, приложений и клиентского результата нужны отдельные подтверждения.