Кратко

  • RFC 3525 гарантировал последовательную обработку команд внутри одной транзакции; разные транзакции могли выполняться в произвольном порядке или одновременно.
  • TransactionPending, повторная передача, подтверждение ответа и механизм at-most-once фиксировали узкие факты доставки, но не создавали причинный порядок между транзакциями и не доказывали результат медиа.

Протокол управлял физически разделённым мультимедийным шлюзом. Media Gateway Controller принимал управляющие решения, а Media Gateway держал Terminations и ресурсы медиа. Такая граница требовала и координации, и возможности параллельной работы.

Структура выглядела иерархично: Message переносило Transactions, Transaction включала Actions, Action относилась к одному Context и содержала Commands. Но внешняя вложенность не давала общей очереди.

Порядок был гарантирован только внутри Transaction. Commands выполнялись последовательно. Первая ошибка в необязательной команде останавливала все последующие Commands. Ошибка в Command с пометкой Optional позволяла продолжить обработку.

Между Transactions порядок прямо не гарантировался. Они могли исполняться в любой последовательности либо параллельно. Помещение в одно Message этого не меняло: Message служило транспортной оболочкой и не имело собственного прикладного подтверждения.

Запросы A, B и C могли уйти вместе, а ответы для A и C вернуться раньше B. Порядок записи в сообщении не был журналом фактической работы шлюза.

Такой выбор сохранял производительность. Независимые Terminations могли обслуживаться разными процессами или потоками. Задержка одного ресурса не обязана была блокировать остальные.

Зависимость должен был распознать MGC. Для одной Termination обычно следовало держать не более одной ожидающей Add, Modify или Move, если Commands не находились в одной Transaction. Если Modify зависела от Add, их следовало объединить либо дождаться результата Add.

Subtract мог быть отправлен в любой момент. Поэтому ранее посланная Modify иногда обрабатывалась уже после удаления Termination. MG должен был проигнорировать её и вернуть ошибку. Хронология отправителя расходилась с хронологией состояния.

Notify создавал другой вариант гонки. Запоздалое уведомление могло прийти после установки нового EventsDescriptor. Для UDP спецификация советовала обычно не иметь более одного ожидающего Notify на Termination. RequestID и принадлежность к запросу становились частью доказательства.

Слово Transaction не означало полную атомарность базы данных. При ошибке MG должен был по возможности вернуть состояние, существовавшее до попытки именно этой Command. Отмены всех ранее успешных Commands текст не обещал.

TransactionReply сохранял частичный результат: значения успешных Commands и Error Descriptor для сбойной. Простая отметка «транзакция неуспешна» смешала бы применённые изменения, ошибку и хвост, который вообще не запускался.

Wildcard TerminationID расширял одну Command на все совпадения. Для каждого возвращался отдельный ответ. Если хотя бы одно совпадение давало ошибку, последующие Commands не выполнялись. Успехи и отказ могли сосуществовать до точки остановки.

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

Транспортное приложение решало потерю и повторы. TransactionID, сохранённые Replies, retransmission и response acknowledgement поддерживали at-most-once. Распознавание дубликата не упорядочивало две разные исходные Transactions.

Защищённый канал также решал другой вопрос. Он мог удостоверить отправителя и целостность. Но две подлинные команды без выраженной зависимости всё равно могли исполниться в нежелательном порядке.

Даже успешный Reply оставался протокольным свидетельством. Audit мог прочитать свойства Context или Termination. Прохождение медиапакетов, декодирование звука и восприятие абонентом требовали других наблюдений.

Исторический статус нельзя скрывать. RFC 3525 заменил RFC 3015 в 2003 году и отражал совместную работу IETF Megaco и ITU-T. В 2008 году RFC 5125 перевёл его в Historic, поскольку H.248.1 продолжил развиваться в ITU-T. Механизм важен для истории, но не описывает все нынешние реализации.

Реестр IANA Megaco/H.248 продолжает координировать имена пакетов, коды ошибок, причины ServiceChange и profiles по более поздним ссылкам. Реестр сохраняет словарь, но не знает версию конкретного шлюза и порядок его выполнения.

Главный принцип RFC 3525 — локализовать порядок. Независимые Terminations могут работать параллельно. Зависимые Commands должны находиться в одной Transaction или ждать подтверждённого состояния. Общая оболочка координирует язык; running code определяет реальность.

Sources