Кратко

  • В RFC 3015 Context означал локальную для Media Gateway связь нескольких Terminations и их медиатопологию. Он не был ни всемирным идентификатором звонка, ни полным журналом разговора.
  • Ответ транзакции, аудит и защита от повторного исполнения подтверждали разные ограниченные факты управления. Доставка по внешнему пути, воспроизведение на приёмнике и общение людей требовали отдельных наблюдений.

Контроллер просит шлюз связать канал телефонной сети с потоком RTP. Шлюз создаёт Context, присваивает ему номер и успешно отвечает на Add. Локальная связь действительно появилась. Но удалённый абонент всё ещё может слышать тишину: ответ шлюза не наблюдал путь после своего выхода.

RFC 3015 вышел в ноябре 2000 года под названием Megaco Protocol Version 1.0 и имел общий текст с рекомендацией ITU-T H.248. Протокол связывал Media Gateway Controller (MGC) с физически отделённым Media Gateway (MG). Контроллер задавал желаемое состояние соединения, а шлюз управлял медиаресурсами. Такое разделение делало систему масштабируемой, но распределяло и право свидетельствовать о происходящем.

ContextID был местным именем

Модель строилась на двух сущностях. Termination порождала или принимала один либо несколько потоков. Context объединял Terminations и описывал, кто кого слышит или видит, а для групп — параметры смешивания и коммутации.

ContextID назначал сам MG, и уникальность требовалась только в пределах этого шлюза. Поэтому значение не становилось без дополнительных связей идентификатором мирового звонка, клиента, тарификации или человеческой беседы. Один сервис мог проходить через несколько шлюзов; один Context мог представлять лишь ожидание, отдельную ветвь конференции или временную обработку.

Сроки жизни также различались. Физическая Termination, например подготовленный TDM-канал, могла существовать долго. Эфемерная Termination потока RTP обычно жила только во время использования. В null Context находились физические Terminations, не связанные с другими. Add мог неявно создать Context, Move переносил членство, а Subtract удалял связь. После ухода последнего участника Context исчезал автоматически.

Исчезающий объект не был фикцией. Он был точным состоянием исполнителя в данный период. Просто он не являлся вечным архивом всех сетевых и человеческих последствий.

Топология описывала шлюз, а не слух собеседника

RFC 3015 отделял topology внутри Context от mode каждой Termination. Топология задавала отношения потоков между членами. Режим описывал поток на входе или выходе MG.

Фраза о том, что T1 «слышит» T2, означала запрограммированную связь в шлюзе. Удалённый слушатель не выдавал такой квитанции. MG мог правильно передать пакеты, которые затем терялись. Конечное устройство могло их получить, но не декодировать, оставить звук выключенным, направить его не туда или не иметь слушателя.

SDP описывал параметры сеанса. RTP добавлял последовательности, время и при наличии отчёты приёма. Эти источники расширяли доказательство, но не заменяли друг друга. Описание, конфигурация, отправка, доставка, декодирование, воспроизведение и понимание оставались отдельными событиями.

Порядок внутри Transaction не создавал всеобщую хронологию

Commands объединялись в Actions, а Actions — в Transactions. Одна Action обычно относилась к одному Context. Commands внутри одной Transaction исполнялись последовательно. TransactionReply возвращал результаты успешных команд и ошибку в месте сбоя.

Между разными Transactions автоматического общего порядка не было. MGC, которому нужна согласованность, должен был соблюдать дисциплину. Для одной Termination обычно следовало иметь не более одного незавершённого Add, Modify или Move, если они не находились в одной Transaction. Subtract мог вмешаться. Удаление по шаблону могло опередить ожидающий Add, после чего контроллеру приходилось отдельно убирать остатки.

Полномочия разделялись. MG отвечал за локальное исполнение. MGC отвечал за порядок намерений. Успешный ответ подтверждал отчёт шлюза об одной Transaction, но не одинаковое состояние нескольких контроллерных процессов и не сохранение связи следующей командой.

TransactionPending сообщал ещё меньше: обработка идёт, но не завершена. Он обновлял таймер запроса и снижал лишние повторы. Он не гарантировал окончательный успех, внешний ресурс или прохождение медиа.

Audit не останавливал изменения

AuditValue возвращал текущие свойства, события, сигналы и статистику. AuditCapabilities возвращал возможные значения. Возможность не была текущей конфигурацией, а конфигурация не была результатом услуги.

При шаблонном запросе ответ мог содержать объединение значений многих Terminations. Это экономило трафик, но теряло индивидуальную принадлежность. Наличие возможности в объединении не означало, что ею обладает или пользуется каждый член.

Главное временное ограничение было сформулировано прямо: AuditValue и AuditCapabilities не подчинялись sequencing. Пока выполнялся Modify, Audit мог правдиво увидеть состояние до него или после него. Слово «текущее» не превращало локальное наблюдение в глобальный снимок, линейно согласованный со всеми Transactions.

Subtract мог вернуть статистику участия Termination в Context. Это был полезный последний след перед исчезновением связи. Но локальное число пакетов не доказывало удалённое число, слышимость аудио или состоявшийся разговор.

At-most-once зависело от памяти

UDP мог потерять запрос или ответ. Большинство Commands не были идемпотентными; повторный Add мог сделать состояние MG непредсказуемым. Поэтому RFC требовал исполнение не более одного раза.

Стороны хранили недавние ответы и список выполняемых Transactions. TransactionID вместе с областью отправителя сравнивался с этой памятью. Для завершённого дубля ответ повторялся без нового исполнения. Для ещё выполняемого дубля второе исполнение подавлялось, и мог отправляться TransactionPending. Подтверждение ответа позволяло удалить его тело, но идентификатор сохранялся на LONG-TIMER для отбрасывания запоздалых копий.

Гарантия опиралась на уникальность номеров, сохранённую память, таймер и текущую эпоху процесса. После истечения срока или перезапуска старое знание не продолжало действовать само собой. Даже при идеальной работе смысл был узким: одна gateway-Transaction не была выполнена дважды в окне сравнения. Это не означало, что звонок произошёл ровно один раз.

TCP также не устранял границу сбоев. При падении процесса или переподключении мог теряться контекст Transaction, поэтому спецификация всё равно рекомендовала логику уровня приложения. Надёжный поток байтов не восстанавливал забытый Context.

Безопасный канал управления не удостоверял медиа

Несанкционированные Commands могли создать чужой звонок или разрушить законный. RFC требовал защищать протокольное соединение в IP-среде и указывал IPsec для аутентификации источника, целостности, противодействия повторам и при необходимости конфиденциальности. Эти свойства защищали отношения MGC и MG. Они не подтверждали звук на удалённом устройстве.

В 2003 году RFC 3525 заменила RFC 3015. RFC 3435 продолжила информационную линию MGCP и указывала Megaco/H.248 как стандартизованный подход. Такая история документов не доказывает реализацию конкретным продуктом, внедрение оператором, совместимость или долю успешных звонков.

Историческая сила RFC 3015 состояла в правильно ограниченном объекте. Протокол позволял назвать, создать, переместить, проверить и удалить локальную связь, упорядочить команды там, где порядок был определён, и подавить дубли в известном окне. Соединённый Context был сильным фактом — но не всем звонком.

Источники