Основная | О фирме  | Новости  | Продукция |  Продажа  | Поддержка  | Разное |

Протоколы Megaco и MGCP

Дуг Аллен

Централизация обработки сигнальной информации снижает требования к интеллектуальности терминалов.
    Хотя IP-телефония может стать хорошим трамплином для предложения новых, расширенных услуг передачи голоса и данных операторами связи, ее развертывание сдерживается отсутствием (либо чрезмерным количеством!) стандартов передачи голоса по IP (Voice over IP, VoIP). Разработка новейшего протокола управления вызовами Megaco (являющегося развитием протокола Media Gateway Control Protocol, MGCP) усугубляет эту проблему, несмотря на то что его создатели стремились к сокращению количества используемых протоколов.
    Megaco определяет взаимодействие, с одной стороны, шлюза между разными средами передачи данных (Media Gateway, MG), который преобразует голосовой сигнал сети с коммутацией каналов в пакетный трафик, и, с другой, — контроллера шлюзов между средами передачи данных (Media Gateway Controller, MGC), иногда называемого агентом вызовов или программным коммутатором, который определяет логику обработки этого трафика (см. Рисунок 1). Иными словами, Megaco разработан для внутридоменного удаленного управления устройствами, отвечающими за установление соединения или проведение сеанса связи, такими, как шлюзы VoIP, серверы удаленного доступа, мультиплексоры цифровых абонентских линий (Digital Subscriber Line Access Multiplexer, DSLAM), маршрутизаторы с поддержкой многопротокольной коммутации с использованием меток (Multiprotocol Label Switching, MPLS), оптические кросс-коннекторы, модули агрегирования сеансов PPP и другие.

Рисунок 1. Megaco связывает шлюз между средами передачи данных (Media Gateway, MG) с контроллером шлюзов (Media Gateway Controller, MGC) при внутридоменном управлении устройствами, участвующими в установлении соединения или проведении сеанса связи.

    Для операторов связи и производителей оборудования решение о внедрении Megaco равнозначно ответу на вопрос: «Сколько протоколов сигнализации — протоколов установления соединений между конечными точками, такими, как телефоны, магистральные порты офисных АТС и станции видеоконференций — должен поддерживать шлюз?» Разброс мнений по этому вопросу колеблется от: «Все действия производятся в конечных точках, следовательно, их нужно делать интеллектуальными» — до: «Взаимодействие — это главное, поэтому необходима централизация».
    По мнению тех, кто считает, что оконечные устройства должны быть интеллектуальными, сигнализация должна завершаться на самом шлюзе между средами. Примером может служить телефон с поддержкой протокола инициирования сеансов (Session Initiation Protocol, SIP), поскольку сигналы управления вызовами формируются и обрабатываются непосредственно самим телефонным аппаратом.
    Тем же, кто верит, что обработку сигнализации лучше поручить обычным компьютерам, оставляя специализированному устройству задачу согласования сред передачи по внешним и внутренним сторонам сети, необходим протокол, который бы определял взаимодействие между частью системы, согласующей среду, т. е. шлюзом, и частью системы, обрабатывающей сигнализацию, т. е. контроллером шлюза.
    Именно для этого и были разработаны протоколы MGCP и Megaco — протокол-новичок, известный также как стандарт ITU H.248. Эти сравнительно низкоуровневые протоколы управления устройствами сообщают шлюзу, каким образом связать потоки, поступающие в сеть с коммутацией пакетов или ячеек, с потоками пакетов или ячеек, переносимыми, например, транспортным протоколом реального времени (Real-Time Transport Protocol, RTP). По существу, Megaco повторяет MGCP в отношении архитектуры и взаимодействия контроллера со шлюзом, но при этом Megaco поддерживает более широкий диапазон сетевых технологий, в том числе ATM.
    Типичным примером работы протокола MGCP является проверка состояния конечной точки на предмет снятия трубки (которую поднимает абонент, чтобы сделать звонок). После фиксации события «снятие трубки» шлюз сообщает об этом контроллеру, после чего последний может послать шлюзу команду подать в линию непрерывный гудок и ждать тональных сигналов DTMF набираемого номера абонента. После получения номера контроллер решает, по какому маршруту следует направить вызов, и, используя протокол сигнализации между контроллерами, такой, как H.323, SIP или Q.BICC, взаимодействует с оконечным контроллером. Оконечный контроллер дает соответствующему шлюзу указание подать звонок на вызываемую линию. Когда этот шлюз определяет, что вызываемый абонент снял трубку, оба контроллера дают соответствующим шлюзам команды на установление двусторонней голосовой связи по сети передачи данных. Таким способом данные протоколы распознают состояния конечных точек, уведомляют об этих состояниях контроллер, генерируют в линии сигналы (например, непрерывный гудок), а также формируют потоки данных между подключенными к шлюзу конечными точками и сетью передачи данных, например потоки RTP.
    Сегодня многие производители считают более целесообразным построение крупных шлюзов, где сигнализация отделена от обработки потоков данных из-за повышенной плотности межсоединений (которые могут быть соединениями OC-3 или даже OC-12). Передача функций сигнализации быстрому серверу представляется более рациональным решением, чем попытка встраивания их в шлюз. Кроме того, снимая обязанности по формированию сигналов со шлюза в помещении заказчика, сетевые операторы сохраняют большую степень контроля, что, по мнению многих, приведет к повышению надежности сетей — важнейшему фактору для обеспечения связи в случае чрезвычайных обстоятельств.

ИТАК, ИЗ ЧЕГО СОСТОИТ MEGACO?
    Megaco оперирует двумя базовыми конструкциями: окончаниями и контекстами (см. Рисунок 2). 

Рисунок 2. Пример взаимосвязи окончаний и контекстов в решении на основе протокола Megaco.

Окончания соответствуют потокам, входящим в или выходящим из шлюза (например, аналоговые телефонные линии, потоки RTP или потоки MP3). Окончания имеют свойства, к примеру максимальный размер буфера компенсации задержек, которые контроллер может проверять и контролировать. Шлюз присваивает окончаниям имена, или идентификаторы (TerminationID). Некоторые окончания, обычно представляющие собой порты шлюза, такие, как аналоговые линии или цифровые каналы DS0, инициализируются шлюзом при его загрузке и остаются активными все время. Другие — формируются по мере необходимости и освобождаются после использования. Такие окончания называются «эфемерными» и используются для представления потоков в пакетной сети, например потоков RTP.
    Окончания могут включаться в контексты, которые определяются, когда два или более оконечных потока смешиваются и соединяются вместе. Нормальный, «активный», контекст может состоять, например, из одного физического окончания (скажем, один канал DS0 в канале DS3) и одного эфемерного окончания (поток RTP, связывающий шлюз с сетью). Контексты создаются и освобождаются шлюзом по команде, поступающей от контроллера. Сразу после создания контексту присваивается имя (идентификатор контекста, ContextID), причем окончания могут как добавляться, так и удаляться из него. Контекст создается добавлением первого окончания, а освобождается в результате удаления (изъятия) последнего.
    Если в случае простого вызова контекст может содержать два окончания (одно представляет оконечное устройство, например телефон, а другое — соединение с сетью по протоколу RTP), то в случае организации конференции он может включать десятки окончаний, представляющих участников конференции. В принципе контекст может содержать лишь одно окончание (например, в случае трехстороннего вызова). В любой момент два окончания находятся в одном контексте (и, следовательно, связаны друг с другом), тогда как третье окончание присутствует в контексте, состоящем только из него самого. Когда пользователь указывает, что хочет переключиться с активного на ждущего абонента (например, используя кнопку Flash на телефонном аппарате), одно из окончаний перемещается в другой контекст.
    Окончание может состоять из нескольких потоков, поэтому и контекст может быть многопотоковым. Потоки аудио- и видеосигналов, а также данных (например, электронная доска сообщений общего пользования стандарта T-120) могут существовать в контексте среди нескольких окончаний.
    Кроме функции осуществления простых соединений, сводящейся к размещению окончаний в контекстах, шлюзы могут также генерировать тональные сигналы, объявления, звонки и другие сигналы, доходящие до слуха пользователя. В Megaco включены средства подачи сигналов на окончания и управления ими. С помощью этих средств Megaco может управлять шлюзами, которые поддерживают функции интерактивного голосового отклика (Interactive Voice Response, IVR), а также обеспечивать генерацию сигналов, сопутствующих обычному телефонному вызову.
    Шлюз может выявлять такие асинхронные события, как снятие телефонной трубки или нажатие клавиши тонового набора DTMF и сообщать об этом контроллеру. Используя сокращенную нотацию, называемую digitmap, шлюзы могут быть запрограммированы на поиск полного телефонного номера или вызова вспомогательной функции и посылать «строку набора номера» на контроллер за одну операцию. Шлюз может собирать статистику о количестве переданных или принятых байт, потерянных пакетов и т. п., а затем передавать ее контроллеру.
    Управление окончаниями, контекстами, событиями и сигналами осуществляется в Megaco с помощью последовательности команд. Команда Add добавляет окончание в контекст и в то же время может использоваться для создания нового контекста. Команда Subtract удаляет окончание из контекста и в результате может вызвать освобождение контекста, если в нем больше не остается окончаний. Команда Move перемещает окончание из одного контекста в другой. Modify изменяет состояние окончания. AuditValue и AuditCapabilities возвращают информацию об окончаниях, контекстах и об общем состоянии и возможностях шлюза. ServiceChange устанавливает управляющую связь между шлюзом и контроллером и также применяется в некоторых ситуациях для аварийного восстановления. Все эти команды посылаются от контроллера к шлюзу, хотя команда ServiceChange может посылаться и шлюзом. Команда Notify, с помощью которой шлюз информирует контроллер о том, что произошло одно из событий, представляющих для последнего интерес, передается от шлюза контроллеру.
    Команды группируются в транзакции, которые представляют собой последовательности команд, выполняемых по порядку. Транзакции выступают в качестве единицы передачи информации между шлюзом и контроллером. Передача транзакций осуществляется с использованием широкого спектра транспортных протоколов, включая UDP и TCP (поддержка других транспортных опций пока только планируется). Затем контроллер посылает на шлюз подтверждение транзакции вместе с ответами на каждую команду.
    Комплект (package) — это набор свойств, событий, сигналов и статистических характеристик, которые определяются некоторым документом и применяются к набору окончаний в шлюзе. Megaco определяет базовый набор комплектов для наиболее общих объектов и операций, таких, как аналоговые и цифровые линии, распознавание и формирование DTMF, а также для RTP. Как IETF, так и ITU работают над дополнительными определениями комплектов.
    Определяя комплект, мы задаем все специфические характеристики окончаний, к которым он может быть применим, и управление всеми реализующими этот комплект шлюзами может осуществляться контроллером, если он также «понимает» этот комплект.
    Например, комплект аналоговой линии включает события для состояния трубки (лежит/снята), сигналов звонка и статистики принятых и переданных байт. К одному окончанию может применяться более одного комплекта. Комплекты могут определяться любыми организациями, даже производитель может определить свой собственный комплект.

ПРИШЛО ЛИ ЕГО ВРЕМЯ?
    В конце августа 2000 г. в лаборатории функциональной совместимости университета Нью-Гемпшира проводилось тестирование более десяти независимых разработок, использующих протокол Megaco. Это говорит о том, что процесс его внедрения сдвинулся с мертвой точки. Некоторые операторы начали обращаться к своим поставщикам с просьбой о поддержке Megaco. Конечно, на рынке уже есть немало шлюзов. В этих устройствах поддерживаются более старые, устоявшиеся протоколы, из которых наиболее известными являются IPDC и MGCP. Многих волнует, сможет ли Megaco потеснить протокол MGCP, или же крепко стоящий на ногах MGCP воспрепятствует принятию Megaco в качестве международного стандарта для приложений с различными средами передачи данных.
    «Я не могу уверенно предсказывать, укоренится ли Megaco за счет MGCP или IPDC, или же случится обратное, — замечает Айк Эллиот, вице-президент по программной коммутации компании Level 3 Communications. — Честно говоря, эти протоколы очень похожи друг на друга, и для многих приложений не имеет значения, какой из них будет использоваться. Однако Megaco лучше интегрирован с приложениями с поддержкой нескольких сред передачи, чем MGCP, потому что в базовый протокол включены семантические элементы для конференций. Благодаря этому MGCP может быть лучшей основой для приложений, не привязанных к какой-либо среде, например для управления сеансами на базе MPLS».

Источник: http://www.osp.ru