Сравнительный анализ протоколов MGCP и MEGACO

Цель данного параграфа - определить, в чем сходны и чем различаются протоколы MGCP и MEGACO. Начнем с общих черт протоколов.

Оба протокола используются в сетях с одинаковой архитектурой, где транспортными шлюзами управляют высокоинтеллектуальные контроллеры. Оба протокола умеют работать со шлюзами одних и тех же видов, классификация шлюзов была дана в предыдущей главе. Порты шлюзов поддерживают детектирование одних и тех же событий и генерацию одних и тех же сигналов. Используются одинаковые транспортные механизмы для доставки сообщений систем сигнализации ОКС7, DSS1, ВСК. Процедуры установления и разрушения соединений, реализуемые обоими протоколами, идентичны. Кроме того, используются одинаковые механизмы поддержания защиты сети. На этом сходство протоколов MGCP и MEGACO/H.248 заканчивается.

Самым важным отличием протокола MEGACO/H.248 от протокола MGCP является использование иной модели организации связи. Протокол MEGACO/H.248 работает не только с телефонными портами, но и UDP-портами. Кроме того, connection в модели MGCP - это, в общем случае, подключение к соединению между портами разного оборудования, в то время как context в модели MEGACO/H.248 всегда отображает связь между портами одного шлюза (рис. 9.4).

Рис. 9.4 Модели MGCP и MEGACO/H.248

Меняя топологию связей портов, относящихся к одному контексту, при помощи протокола MEGACO контроллер может гибко управлять конференциями. Данной возможности в протоколе MGCP не предусмотрено.

Выше уже отмечалось, что для протокола MEGACO/H.248 предусмотрено два способа кодирования, тогда как сообщения протокола MGCP представляются в текстовом формате, а бинарный способ кодирования не поддерживается. Кроме того, в протоколах используются разные параметры команд и коды ошибок.

Протокол MEGACO/H.248, так же, как и протокол MGCP, предусматривает корреляцию команд и ответов. Но если в протоколе MGCP транзакция образуется из команды и ответа на нее, то в протоколе MEGACO/H.248 транзакция состоит из запроса - совокупности акций и отклика на запрос. Общая структура запроса выглядит так:

TransactionRequest(Transactionid {

ContextiD {Command ... Command),

ContextiD {Command ... Command } })

Общая структура отклика на запрос приведена ниже:

TransactionReply(TransactionID {

ContextiD { Response ... Response },

ContextiD { Response ... Response } })

Каждая акция, в свою очередь, состоит из одной или нескольких команд, относящихся к одному контексту, и ответов на них (Рис. 9.5). Использование такого инструмента позволяет значительно уменьшить объем передаваемой сигнальной информации и увеличить скорость установления соединений за счет того, что контроллер может параллельно вести обработку сигнальной информации, относящейся к разным соединениям.

Аналоги двух избыточных команд EndpointConfiguration и Notifica-tionRequest протокола MGCP в протоколе MEGACO/H.248 отсутствуют, но, в тоже время, добавлена команда Move, позволяющая в одно действие перевести порт из одного контекста в другой. В качестве примера использования команды Move приведем сценарий дополнительных услуг «Уведомление о входящем вызове и перевод существующего соединения в режим удержания», англоязычное название услуг - Call Waiting и Call Hold.

Рис. 9.5 Транзакция протокола MEGACO/H.248

Абонент А разговаривает с абонентом В, а абонент С вызывает абонента А, при этом вызываемому абоненту передается акустическое уведомление о входящем вызове (рис. 9.6). Далее абонент А переводит соединение с абонентом В в режим удержания и соединяется с абонентом С (рис. 9.7). Реализация комбинации дополнительных услуг Call Waiting и Call Hold, т.е. передача порта из одного контекста в другой, стала возможной благодаря команде Move.

Рис. 9.6 Сценарий реализации услуги Call Waiting

В заключение данного параграфа хотелось бы отметить, что неизвестно, как скоро понадобится расширенная, по сравнению с MGCP, функциональность протокола MEGACO/H.248. Кроме того, на базе протокола MGCP построен ряд сетей IP-телефонии. Все это означает, что оба протокола MGCP и MEGACO/H.248 вполне могут совместно использоваться в одной сети.

Рис. 9.7 Сценарий реализации услуги Call Hold