Протокол MGCP
САЛИФОВ Ильнур Илдарович
Дисциплина “Цифровые сети интегрального обслуживания”
2013 г.
Принцип декомпозиции шлюза
Распространение принципа распределенной архитектуры привело к тому, что моноблочные шлюзы сети NGN разбиваются на отдельные функциональные блоки.
Для взаимодействия данных блоков разработаны специализированные протоколы управления шлюзами:
-MGCP; -MEGACO/H.248.
САЛИФОВ Ильнур Илдарович |
УрТИСИ, 2013 |
Архитектура сети, базирующейся на протоколе MGCP
MGC – контроллер шлюзов – находится на уровне управления вызовом. Управляет несколькими MG. Осуществляет назначение и освобождение ресурсов MG.
MG – транспортный шлюз – находится на транспортном уровне. Выполняет прием речевой информации, поступающей от “классической” сети ТфОП, и преобразует ее в вид, пригодный для транспортировки по IP-сетям.
SG – шлюз сигнализации – обеспечивает перенос сигнальных сообщений между сетью ТфОП и контроллером шлюзов.
САЛИФОВ Ильнур Илдарович |
УрТИСИ, 2013 |
Протокол управления шлюзами MGCP
MGCP - Media Gateway Control Protocol - протокол управления шлюзами с помощью внешнего устройства MGC (Media Gateway Controller - контроллер шлюзов). Разработан рабочей группой MEGACO комитета IETF.
В основе протокола лежит принцип главный-подчиненный (master-slave), где контроллер MGC является главным, а шлюз MG – подчиненным. Шлюз MG подтверждает команду, выполняет ее и уведомляет контроллер MGC о результате.
Протокол MGCP обеспечивает следующие функции:
-создание соединения «точка-точка»;
-создание соединения «точка-несколько точек»;
-изменение параметров существующих соединений;
-завершение соединения;
-контроль соединения;
-добавление соединений в существующие сеансы связи.
Сообщения MGCP передаются поверх протокола пользовательских дейтаграмм (User Datagram Protocol - UDP).
САЛИФОВ Ильнур Илдарович |
УрТИСИ, 2013 |
Классификация шлюзов MGCP
Рабочей группой MEGACO предложено классифицировать шлюзы в зависимости от типа подключаемых устройств и функционального назначения следующим образом :
-Trunking Gateway - шлюз между ТфОП и сетью IP обеспечивающий подключение станций коммутации по каналам Е1;
-Voice over ATM Gateway - шлюз между ТфОП и сетью АТМ обеспечивающий подключение станций коммутации по каналам Е1;
-Residential Gateway - оборудование пользователя предназначенное для подключения аналоговых телефонов к сетям IP;
-Access Gateway - шлюз доступа для непосредственного подключения абонентов по двухпроводным абонентским линиям;
-Business Gateway - шлюз с небольшим числом портов в корп. сети, предназначенный для подключения УПАТС по цифровым абонентским интерфейсам;
-Network Access Server - аналог шлюза AG, но дополнительно реализует функции модемного пула;
-Circuit switch или packet switch - иные устройства, управляемые MGC.
САЛИФОВ Ильнур Илдарович |
УрТИСИ, 2013 |
Модель протокола MGCP
Модель оперирует компонентами двух видов:
1.Endpoint – это порты оборудования, являющиеся источниками и приемниками информации. Например, интерфейс шлюза MG, который завершает канал, получаемый от ТфОП. Каждая конечная точка (endpoint) определяется идентификатором, который имеет два компонента: имя домена, содержащего шлюз MG; локальное имя или идентификатор внутри шлюза.
2.Connection - означает подключение порта к одному из двух концов соединения, которое создается между ним и другим портом.
Такое соединение будет установлено после подключения другого порта к его второму концу. Конечные точки, участвующие в соединении, находятся в разных шлюзах.
Локально каждое соединение обозначено идентификатором соединения (connection ID) и характеризуется набором атрибутов (свойств) соединения.
САЛИФОВ Ильнур Илдарович |
УрТИСИ, 2013 |
Команды и ответы MGCP
Общение MGC и MG осуществляется в виде набора транзакций. Каждая транзакция состоит из команды и обязательного ответа.
В ходе установления, поддержания и разрушения соединения при помощи протокола MGCP устройство управления и шлюз обмениваются командами и ответами, которые представляют собой набор текстовых строк.
Структура команды:
1.Заголовок
-Командная строка [Название команды, Идентификатор транзакции, Идентификатор порта, Версия протокола])
-Список параметров;
2.Пустая строка
3.Описание сеанса связи
Структура ответа:
1.Заголовок
-Командная строка [Код ответа, Идентификатор транзакции, Комментарий])
-Список параметров;
2.Пустая строка
3.Описание сеанса связи
САЛИФОВ Ильнур Илдарович |
УрТИСИ, 2013 |
Команды MGCP
Все команды можно разделить на три группы:
1.Простые команды управления вызовом:
-CreateConnection (CRCX) – создать подключение
-ModifyConnection (MDCX) – модифицировать соединение
-DeleteConnection (DLCX) – удалить подключение
2.Дополнительные команды управления вызовом:
-NotificationRequest (RQNT) – запрос уведомления
-Notify (NTFY) – уведомление
3.Команды управления:
-EndpointConfiguration (EPCF) – конфигурация порта
-AuditEndpoint (AUEP) – проверить порт
-AuditConnection (AUCX) – проверить соединение
-ReStartInProgress (RSIP) – идёт рестарт
САЛИФОВ Ильнур Илдарович |
УрТИСИ, 2013 |
Команды MGCP
Пример команды:
CRCX 1204 ts/1@protei.loniis.net MGCP 0.1
C: A3С47F21456789FO
L:p:10, a:G.711
M:recvonly
CRCX - Название команды. Представлено в виде кода из четырех букв.
1204 - Идентификатор транзакции. Команда и ответ на нее образуют транзакцию, имеющую уникальный идентификатор (Transaction-Identifier). Включается в заголовок и команды, и ответа. Значения идентификаторов выбираются из диапазона чисел 1 -999999999, причем значение идентификатора текущей транзакции на единицу больше идентификатора
предыдущей транзакции.
ts/1@protei.loniis.net - Идентификатор порта определяет тот порт шлюза, которому надлежит выполнить команду. В данном случае идентифицируется первый порт (временной канал) шлюза «protei», расположенного в домене loniis.
MGCP 0.1 - Версия протокола.
САЛИФОВ Ильнур Илдарович |
УрТИСИ, 2013 |
|
|
Команды MGCP |
Название параметра |
Код |
Описание и значение параметра |
ResponseAck(Подтверждени |
К |
Подтверждает завершение одной или нескольких транзакций. Например, параметр К: 6234-6255, 6257, |
е транзакции) |
|
19030-19044 подтверждает завершение транзакций, имеющих идентификаторы с 6234 по 6255, 6257 и с |
|
|
19030 по 19044. |
Bearerlnformation(Сведения |
В |
Служит для доставки информации о законе кодирования речевой информации А или m |
о виде информации) |
|
|
ReasonCode (Код причины) |
|
Определены следующие коды причины; 000 - номинальное состояние порта, передается только в |
|
|
ответе на запрос о состоянии порта 900 - неисправность порта 901 - порт выведен из обслуживания 902 |
|
|
- отказ на физическом уровне (например, потеря синхронизации) |
CalllD (Идентификатор |
С |
Идентифицирует сеанс связи, в котором может использоваться одно или несколько соединений. |
сеанса связи) |
|
Идентификатор кодируется шестнадцатеричной последовательностью символов длиной не более 32 |
|
|
символом. |
ConnectionID(Идентификатор |
1 |
Идентифицирует подключение данного порта к одному соединению, так как один порт может быть |
подключения) |
|
одновременно подключен к нескольким соединениям |
Notified |
N |
Идентификатор объекта, к которому следует передавать уведомления об обнаруженных событиях. |
Entity(Уведомляемый |
|
Если данный параметр опущен, порт передает эту информацию к объекту, от которого была получена |
объект) |
|
команда. Идентификатор объекта кодируется так же, как кодируются адреса электронной почты |
|
|
согласно RFC 821, например,MGC@ca.anynet.com:5625 или Joe@[128.23.0.4]. При использовании IP- |
|
|
адреса, он должен быть заключен в квадратные скобки. |
Requestldentifier(Идентифика |
Х |
Согласует требование уведомить о событии, полученное от Call Agent, с уведомлением, передаваемым |
тор запроса) |
|
шлюзом в команде Notify. |
LocalConnection |
L |
Данные об алгоритме кодирования информации, размере речевых пакетов в мс, используемой полосе |
Options (Параметры |
|
пропускания в Кбит/с, типе обслуживания, использовании эхокомпенсации и другие сведения. |
подключения порта к |
|
Передается от Call Agent к шлюзу, обычно в команде CRCX. |
соединению) |
|
|
ConnectionMode(Режим |
М |
Определены следующие режимы соединения: передача, прием, прием/передача, конференция, |
соединения) |
|
передача данных, отсутствие активности, петля, тест и другие режимы. Значение параметру |
|
|
присваивает Call Agent. |
RequestedEvents(Запрашива |
R |
Список событий, о которых следует оповестить Call Agent, и действия шлюза при обнаружении |
емые события) |
|
события. Определены следующие действия: оповестить Call Agent о событии немедленно; ожидать |
|
|
дальнейших событий; если событием является прием сигнала DTMF, то накапливать цифры в |
|
|
соответствии с требованиями параметра DigitMap; в определенных ситуациях передавать в канал |
|
|
акустические или вызывные сигналы; обработать инкапсулированную команду Endpoint |
|
|
Configuration, игнорировать событие и др. |
SignalRequests(Требование |
S |
Специфицируется сигнал, который должен быть передан абоненту, например, акустический сигнал |
передать сигнал) |
|
"Ответ станции". |
САЛИФОВ Ильнур Илдарович |
УрТИСИ, 2013 |
|
|
Команды MGCP |
DigitMap (План |
D |
Специфицирует правила обработки сигналов DTMF. При накоплении количества цифр, |
нумерации) |
|
указанного в данном параметре, шлюз должен передать их устройству управления. |
ObservedEvents(Обнаруже |
0 |
Список обнаруженных событий. |
нные события) |
|
|
ConnectionParameters(Пар |
Р |
Статистические данные о соединении, передаваемые шлюзом после его завершения. |
аметры соединения) |
|
|
SpecifiedEndPointID(Идент |
Z |
Идентификатор порта в формате RFC821, например, EndPoint@hub1 .anynet.com:5625, |
ификатор порта) |
|
|
Requestedlnfo(Запрашива |
F |
Описывает информацию, которую Call Agent запрашивает у шлюза, например, цифры |
емая информация) |
|
номера вызываемого абонента, набранные вызывающим абонентом. |
QuarantineHandling(Каран |
Q |
Определяет правила обработки событий, которые были обнаружены до получения |
тинная обработка) |
|
данной команды в период так называемого карантина (quarantine period), и о |
|
|
которых Call Agent еще не был оповещен. |
DetectEvents(Выявляемы |
Т |
Перечень событий, которые порт должен отслеживать, а при их обнаружении - извещать |
е события) |
|
об этом Call Agent. |
EventStates(Состояния, |
ES |
Перечень состояний порта, обусловленных, например, тем, что абонент снял или |
обусловленные |
|
положил трубку; информация об этих состояниях должна передаваться к Call Agent в |
событиями) |
|
ответ на команду AuditEndpoint. |
RestartMethod(Метод |
RM |
Способ индикации шлюзом вывода порта из обслуживания или ввода его в |
рестарта) |
|
обслуживание. Поддерживаются несколько вариантов рестарта: "graceful", "forced", |
|
|
"restart", "disconnected" or "cancel-graceful". |
RestartDelay(Задержка |
RD |
Определяет время в секундах, после которого производится производится порта. Если |
рестарта) |
|
этот параметр отсутствует, задержка рестарта равна нулю. При получении от Call |
|
|
Agent требования о принудительном рестарте порта команда выполняется |
|
|
незамедлительно. |
Capabilities(Функциональ |
А |
Информацию о функциональных возможностях порта запрашивает Call Agent при |
ные возможности порта) |
|
помощи команды AuditEndpoint. Эти возможности порта включают в себя: |
|
|
поддерживаемые алгоритмы кодирования, период пакетизации, полосу пропускания, |
|
|
эхокомпенсацию, подавление пауз речи, режимы соединения, тип обслуживания, |
|
|
совокупность событий и др. |
САЛИФОВ Ильнур Илдарович |
УрТИСИ, 2013 |