Классификация шлюзов
Рабочей группой MEGACO предложена следующая классификация транспортных шлюзов (Media Gateways):
• Trunking Gateway - шлюз между ТфОП и сетью с маршрутизацией пакетов IP, ориентированный на подключение к телефонной сети посредством большого количества цифровых трактов (от 10 до нескольких тысяч) с использованием системы сигнализации ОКС 7;
• Voice over ATM Gateway - шлюз между ТфОП и АТМ-сетью, который также подключается к телефонной сети посредством большого количества цифровых трактов (от 10 до нескольких тысяч);
• Residential Gateway - шлюз, подключающий к IP-сети аналоговые, кабельные модемы, линии xDSL и широкополосные устройства беспроводного доступа;
• Access Gateway - шлюз для подключения к сети IP-телефонии небольшой учрежденческой АТС через аналоговый или цифровой интерфейс;
• Business Gateway - шлюз с цифровым интерфейсом для подключения к сети с маршрутизацией IP-пакетов учрежденческой АТС при использовании, например, системы сигнализации DSS1;
• Network Access Server - сервер доступа к IP-сети для передачи данных;
• Circuit switch или packet switch - коммутационные устройства с интерфейсом для управления от внешнего устройства.
8.3 Модель организации связи
Для описания процесса обслуживания вызова с использованием протокола MGCP рабочей группой MEGACO разработана модель организации соединения - Connection model. Базой модели являются компоненты двух основных видов: порты (Endpoints) и подключения (Connections).
Endpoints - это порты оборудования, являющиеся источниками и приемниками информации. Существуют порты двух видов: физические и виртуальные. Физические порты - это аналоговые интерфейсы, поддерживающие каждый одно телефонное соединение, или цифровые каналы, также поддерживающие одно телефонное соединение и мультиплексированные по принципу временного разделения каналов в тракт Е1. Примером виртуального порта является источник речевой информации в интерактивном речевом сервере, т.е. некое программное средство.
Connection - означает подключение порта к одному из двух концов соединения, которое создается между ним и другим портом.
Такое соединение будет установлено после подключения другого порта к его второму концу. Соединение может связывать порты разных шлюзов через сеть с маршрутизацией пакетов IP или порты внутри одного шлюза.
На рисунке 8.4 представлены примеры использования этих двух компонентов. Отметим, что порты некоторых видов могут участвовать в нескольких соединениях одновременно.
Подключения к N соединениям
а) цифровой порт
Подключения к М соединениям
б) аналоговый порт
Подключение к одному соединению
в) порт, передающий речевые извещения
Подключение к одному соединению
г) интерактивная речевая система
Подключения к L соединениям
д) порт, поддерживающий конференцсвязь
Подключения к 2 соединениям
е) межсетевой экран или транскодер - порт ретрансляции пакетов
Подключение к одному соединению
ж) порт записи/воспроизведения телефонных разговоров
Подключения к К соединениям
з) АТМ-интерфейс
Подключения создаются устройством управления Call Agent для каждого порта, участвующего в соединении. На рисунке 8.5 показана ситуация, когда одно устройство управления контролирует работу двух портов разных шлюзов при организации соединения между этими портами.
Рис. 8.5 Соединение в сети, построенной на базе протокола MGCP
8.4 Команды протокола MGCP
В ходе установления, поддержания и разрушения соединения при помощи протокола MGCP устройство управления и шлюз обмениваются командами и ответами, которые представляют собой набор текстовых строк. В этом параграфе дается краткое описание команд протокола MGCP, среди которых определены команды управления соединением и команды управления портами оборудования.
При помощи команды EndpointConfiguration устройство управления инструктирует шлюз, каким образом он должен обрабатывать получаемые речевые сигналы, например, использовать для преобразования цифрового сигнала в аналоговую форму закон А или закон |л.
Команда EndpointConfiguration содержит ряд параметров:
ReturnCode
<— EndpointConfiguration( Endpointid,
Bearer Information),
где Endpointid - идентификатор порта шлюза, к которому относится данная команда;
Bearerlnformation - параметр, определяющий закон (А или |i) декодирования принятой речевой информации.
ReturnCode - параметр, возвращаемый шлюзом устройству управления, чтобы информировать его о выполнении команды. Данный параметр представляет собой целое число, за которым могут следовать комментарии.
Call Agent при помощи команды Notification Request может дать указание шлюзу выявлять определенные события или сигналы и информировать о них устройство управления. В число детектируемых событий (сигналов) входит изменение сопротивления абонентского шлейфа, происходящее, когда абонент поднимает или кладет трубку, а также получение сигналов факсимильных аппаратов и сигналов DTMF.
Команда NotificationRequest включает в себя следующие параметры (в квадратных скобках указаны те из них, которые не являются обязательными).
<—NotificationRequest( Endpointid,
[NotifiedEntity,] [RequestedEvents,] Requestldentifier, [DigitMap,] [SignalRequests,] [QuarantineHandling,] [DetectEvents,] [encapsulated EndpointConfiguration])
Здесь NotifiedEntity - идентификатор устройства, которому должен быть передан ответ на команду. При отсутствии этого параметра ответ передается тому устройству, от которого получен запрос Notification Request.
Requested Events - список событий, о которых следует оповестить управляющее устройство. Кроме того, в этом параметре может быть указано, как шлюз должен реагировать на событие. Определены следующие действия шлюза: оповестить Call Agent о событии немедленно; ожидать дальнейших событий; если событие состоит в получении сигнала DTMF, то накапливать такие сигналы в соответствии с требованиями параметра DigitMap; в определенных ситуациях передавать в телефонный канал акустические или вызывные сигналы;
обработать инкапсулированную команду EndpointConfiguration; игнорировать событие и т.д.
Requestldentifier - идентификатор запроса, в ответ на который передается команда.
DigitMap - необязательный параметр, специфицирующий правила обработки сигналов DTMF. В этом параметре указывает количество сигналов, которые шлюз должен накопить для передачи их устройству управления.
SignalRequests - сигналы, которые должны быть переданы в канал, например, сигнал посылки вызова.
QuarantineHandling - необязательный параметр, определяющий правила обработки событий, которые были обнаружены до момента получения данной команды в период так называемого карантина (quarantine period) и о которых Call Agent еще не был оповещен.
DetectEvents - необязательный параметр, определяющий события, которые нужно выявить в период карантина, но не оповещать о них Call Agent до получения следующей команды NotificationRequest с включенным в нее параметром QuarantineHandling.
Encapsulated EndpointConfiguration - команда EndpointConfiguration, инкапсулированная в команду NotificationRequest.
Остальные параметры команды тождественны описанным выше.
При помощи команды Notify шлюз информирует устройство управления о том, что произошло событие из числа указанных в команде NotificationRequest. Команда Notify содержит следующие параметры:
ReturnCode
<- Notify (Endpointid,
[NotifiedEntity,] Requestldentifier, ObservedEvents)
Здесь ObservedEvents - параметр, в котором описываются произошедшие события, например, передаются набранные цифры номера. Остальные параметры были описаны ранее.
При помощи команды CreateConnection управляющее устройство может дать шлюзу указание создать соединение двух портов одного и того же шлюза или разных шлюзов.
Структура этой команды приведена ниже.
ReturnCode, Connectionid, [SpecificEndPolntId,1 [LocalConnectionDescriptor,] [SecondEndPointId,] [SecondConnectionId] <— CreateConnection(Callld,
Endpointid,
[NotifiedEntity,]
[LocalConnectionOptions,]
Mode,
[{RemoteConnectionDescriptor I
SecondEndpointId), ]
[Encapsulated NotificationRequest,] о [Encapsulated EndpointConfiguration])
Callld - уникальный параметр, идентифицирующий сессию, к которой относится данное соединение.
NotifiedEntity - необязательный параметр, идентифицирующий устройство, к которому должны быть переданы команды Notify или DeleteConnection.
LocalConnectionOptions - параметр, используемый Call Agent, чтобы дать шлюзу указания в отношении характеристик подключения порта к соединению. В параметр могут входить следующие поля:
метод кодирования, размер речевых пакетов, полоса пропускания, тип обслуживания, использование эхокомпенсатора, использование режима подавления пауз в разговоре, использование режима подавления шума, использование резервирования ресурсов и другие поля. Кодирование трех первых полей должно производиться в соответствии с протоколом описания сессий SDP (Session Description Protocol), причем Call Agent может у казать только полосу пропускания и оставить за шлюзом право выбора метода кодирования и размеров речевых пакетов.
Mode - параметр, определяющий режим работы для данного конца соединения. Определены следующие режимы: передача, прием, прием/передача, конференция, данные, отсутствие активности, петля, тестовый режим и другие.
RemoteConnectionDescriptor - описание подключения к соединению на другом его конце. Данный параметр содержит те же поля, что и параметр LocalConnectionOptions. Эти поля также должны кодироваться в соответствии с протоколом SDP. Стоит отметить, что при создании соединения между двумя шлюзами, при передаче первой команды CreateConnection параметр RemoteConnectionDescriptor отсутствует (ему присваивается нулевое значение), так как информация о подключении к соединению на другом его конце в этот момент отсутствует. Не имея такой информации, т.е. не получив команду ModifyConnection, шлюз может только принимать информацию (работать в режиме receive only).
SecondEndpointId - этот параметр может включаться в команду CreateConnection вместо параметра RemoteConnectionDescriptor при установлении соединения между двумя портами одного и того же шлюза.
Encapsulated NotificationRequest - инкапсулированная команда NotificationRequest.
В ответ на команду CreateConnection, кроме описанного выше параметра ReturnCode, шлюз возвращает следующие параметры:
Connectionid - уникальный идентификатор подключения данного порта к соединению.
SpecificEndPointId - необязательный параметр, идентифицирующий порт, который отвечает на команду CreateConnection, если он не был специфицирован устройством управления.
LocalConnectionDescriptor - параметр, содержащий информацию об IP-адресе и номере порта RTP в соответствии с протоколом SDP.
SecondEndPointId - параметр, означающий, что команда CreateConnection создала два соединения.
SecondConnectionId - идентификатор подключения для второго соединения.
Устройство управления может изменить параметры существующего соединения при помощи команды ModifyConnection, которая включает в себя следующие параметры.
ReturnCode,
[LocalConnectionDescriptor]
<——— ModifyConnection (Call Id,
Endpointid, Connectionid, [NotifiedEntity,] [LocalConnectionOptions,] [Mode,]
[RemoteConnectionDescriptor,] [Encapsulated NotificationRequest,] [Encapsulated EndpointConfiguration])
Здесь используются такие же параметры, как и в команде CreateConnection, но добавляется обязательный параметр Connectionid, который идентифицирует подключение к соединению данного порта оборудования, так как один порт может одновременно иметь подключения к нескольким соединениям.
Данная команда может использоваться для передачи информации о другом конце соединения в параметре RemoteConnection Descriptor, для активизации/деактивизации соединения при помощи параметра Mode, для изменения алгоритма кодирования, периода пакетизации передаваемой информации или для управления подавлением эха.
Таким образом, если первоначально порт мог только принимать информацию, так как не имел описания функциональных возможностей и адреса порта на другом конце соединения, то описываемая команда создает возможность передавать информацию.
Если параметры соединения на ближнем конце были изменены, например, был изменен номер порта RTP, то в ответе на команду ModifyConnection может возвращаться параметр LocalConnection-Descriptor.
Устройство управления может разрушить существующее соединение при помощи команды DeleteConnection. Кроме того, при помощи этой команды шлюз может передать к Call Agent индикацию того, что существующее соединение больше поддерживаться не может.
Команда DeleteConnection, передаваемая устройством управления, имеет следующий вид:
ReturnCode,
Connection-parameters
<— DeleteConnection (Callld/
Endpointid,
Connectionid,
[Encapsulated NotificationRequest,]
[Encapsulated EndpointConfiguration])
Все параметры были описаны ранее, однако следует отметить, что в параметр NotificationRequest может включаться инструкция, например, о действиях шлюза при детектировании размыкания абонентского шлейфа (абонент положил трубку): в этом случае шлюз должен разрушить соединение и ждать замыкания шлейфа (следующего вызова).
В общем случае, команда DeleteConnection передается обоим шлюзам, подключенным к соединению. После завершения соединения в ответ на команду DeleteConnection шлюз возвращает статистические данные, собранные за время соединения - connection-parameters:
• количество переданных RTP-пакетов,
• количество переданных байтов информации, не считая служебной информации (заголовков IP/UDP/RTP),
• количество полученных RTP-пакетов,
• количество принятых байтов информации, не считая служебной информации (заголовков IP/UDP/RTP),
• количество потерянных RTP-пакетов,
• вариация времени между поступлениями RTP-пакетов,
• средняя задержка RTP-пакетов.
В некоторых случаях, таких как неисправность порта, участвующего в соединении, или отсутствие ресурсов для поддержания существующего соединения, шлюз должен сам инициировать разрушение соединения при помощи команды DeleteConnection, которая имеет следующий вид:
RetumCode,
<— DeleteConnection (Callld,
Endpointid, Connectionid, Reason-code, Connection-parametera)
В параметре Reason-code указывается причина, по которой шлюз передает данное сообщение. Остальные параметры были описаны ранее.
Чтобы получить информацию о статусе какого-либо порта шлюза, управляющее устройство может передать запрос Audit EndPoint, который имеет следующий вид:
RetumCode,
EndPointIdLietl{ [RequestedEvente,] [DigitMap,] [SignalRequests,] [Requestldentifier,1 [NotifiedEntity,] [Connectionldentifiers,] [DetectEvents,] [ObservedEvents,] [EventStates,] [Bearer Information,1 [RestartReason,] [RestartDelay,] [ReasonCode,] [Capabilities]}
<- AuditEndPoint(Endpointid, [Requestedlnfo])
Requestedlnfo - необязательный параметр, описывающий информацию, которую запрашивает устройство управления.
В ответ на команду AuditEndPoint шлюз возвращает требуемую информацию (если никакой информации не запрашивается, но указанный в команде порт существует, то шлюз просто возвращает подтверждение). В ответе могут содержаться следующие параметры:
SignalRequests - необязательный параметр, в котором указывается список сигналов, обрабатываемых в настоящий момент;
Observed Events - необязательный параметр, в котором приводится текущий список обнаруженных событий;
RestartReason - необязательный параметр, в котором содержится причина рестарта порта, указанная в последней переданной шлюзом команде RestartlnProgress;
RestartDelay - необязательный параметр, в котором содержится величина задержки рестарта, указанная в последней переданной шлюзом команде RestartlnProgress;
Capabilities - необязательный параметр, содержащий такую же информацию, как и параметр LocalConnectionOptions.
При помощи команды AuditConnection устройство управления запрашивает параметры соединения, в котором участвует порт шлюза.
Команда имеет следующий вид:
ReturnCode, [Callld,]
[NotifiedEntity,] [LocalConnectionOptione,] [Mode,]
[RemoteConnectionDescriptor,] [LocalConnectionDescriptor,] [ConnectionParameters]
<— AuditConnection (Endpointid,
Connectionid,
Requestedlnfo)
Все параметры команды уже были описаны ранее. Если никакой информации не требуется и указанный порт существует, то шлюз проверяет, что соединение существует, и возвращает подтверждение.
Команда RestartlnProgress передается шлюзом для индикации того, что один или группа портов выводятся из рабочего состояния или возвращаются в рабочее состояние.
Данная команда имеет следующий вид:
ReturnCode, [NotifiedEntity] <—— RestartinProgress (EndPointId,
RestartMethod, [RestartDelay,] [Reason-code])
Параметр RestartMethod специфицирует вид рестарта. Определено несколько видов рестарта:
• Graceful restart - постепенный рестарт, при котором порты оборудования выводятся из обслуживания после определенной задержки. Установленные соединения не разрушаются, но и новые не создаются.
• Forced restart - принудительный рестарт, при котором разрушаются установленные соединения.
• Restart - рестарт, при котором порт оборудования возвращается в обслуживание после определенной задержки. При этом порт в момент рестарта не участвует ни в каких соединениях.
• Disconnected - данное значение присваивается параметру Restart-Method, когда порт находился вне обслуживания, но в данный момент пытается вернуться в обслуживание.
• Cancel-graceful - данное значение присваивается параметру Re-startMethod, когда шлюз отменяет предшествовавшую команду Restart с параметром RestartMethod, которому было присвоено значение Graceful.
Параметр RestartDelay определяет задержку рестарта в секундах.
По аналогии с предыдущими главами в таблицу 8.1 сведены все команды протокола MGCP.
Таблица 8.1 Команды протокола MGCP
| Команда | Направление передачи | Назначение |
| EndpointConfiguration (Конфигурация порта) | СА -> MG | Call Agent инструктирует шлюз, каким образом ему нужно обрабатывать получаемые речевые сигналы |
| CreateConnection (Создать соединение) | СА -> MG | Call Agent дает указание шлюзу создать соединение |
| ModifyConnection (Модифицировать соединение) | СА -> MG | Call Agent дает указание шлюзу изменить параметры существующего соединения |
| DeleteConnection (Завершить соединение) | СА -> MG, MG -> СА | Call Agent и шлюзы завершают соединение |
| NotificationRequest (Запрос уведомления) | СА -> MG | Call Agent инструктирует шлюз, какие события необходимо обнаруживать. |
| Notify (Уведомить) | MG -> СА | Шлюз информирует Call Agent о том, что произошло событие из числа тех, которые были специфицированы в команде NotificationRequest |
| AuditEndpoint (Проверить порт) | СА -> MG | Call Agent запрашивает информацию о каком-либо порте шлюза |
| AuditConnection (Проверить соединение) | MGC -> MG | Call Agent запрашивает параметры соединения |
| ReStartlnProgress (Идёт рестарт) | MG -> MGC | Шлюз информирует Call Agent о том, что один или несколько портов выводятся из рабочего состояния или возвращаются в рабочее состояние |
8.5 Структура команд
Команда протокола MGCP обязательно содержит заголовок, за которым может следовать описание сеанса связи (session description). Заголовок команды и описание сеанса связи представляют собой набор текстовых строк. Описание сеанса отделено от заголовка команды пустой строкой.
Заголовок содержит список параметров и командную строку вида CRCX 1204 ts/1@protei.loniis.net MGCP 0.1. Командная строка, в свою очередь, состоит из нескольких информационных полей:
1. Название команды представлено в виде кода из четырех букв (табл.8.2)
Таблица 8.2 Кодировка команд протокола MGCP
| Команда | Код |
| EndpointConfiguration | EPCF |
| CreateConnection | CRCX |
| ModifyConnection | MDCX |
| DeleteConnection | DLCX |
| NotificationRequest | RQNT |
| Notify | NTFY |
| AuditEndpoint | AUEP |
| AuditConnection | AUCX |
| ReStartlnProgress | RSIP |
3. Идентификатор порта определяет тот порт шлюза, которому надлежит выполнить команду, за исключением команд Notify и ReStartlnProgress, в которых идентификатор определяет порт, передавший команду. Идентификаторы портов кодируются также, как кодируются адреса электронной почты в соответствии с документом RFC 821 комитета IETF. Например, возможен идентификатор ts/1@protei.loniis.net, который идентифицирует первый порт (временной канал) шлюза “protei”, расположенного в домене loniis.
4. Версия протокола кодируется следующим образом: MGCP 1.0.
Выше указывалось, что заголовок команды, кроме командной строки, содержит список параметров. Параметры команд протокола MGCP сведены в таблицу 8.3.
Таблица 8.3 Параметры команд протокола MGCP
| Название параметра | Код | Описание и значение параметра |
| ResponseAck (Подтверждение транзакции) | К | Подтверждает завершение одной или нескольких транзакций. Например, параметр К: 6234-6255, 6257, 19030-19044 подтверждает завершение транзакций, имеющих идентификаторы с 6234 по 6255, 6257 и с 19030 по 19044. |
| Bearerlnformation (Сведения о виде информации) | В | Служит для доставки информации о законе кодирования речевой информации А или m |
| ReasonCode (Код причины) | Определены следующие коды причины; 000 - номинальное состояние порта, передается только в ответе на запрос о состоянии порта 900 - неисправность порта 901 - порт выведен из обслуживания 902 - отказ на физическом уровне (например, потеря синхронизации) | |
| CalllD (Идентификатор сеанса связи) | С | Идентифицирует сеанс связи, в котором может использоваться одно или несколько соединений. Идентификатор кодируется шестнадцатеричной последовательностью символов длиной не более 32 символом. |
| ConnectionID (Идентификатор подключения) | 1 | Идентифицирует подключение данного порта к одному соединению, так как один порт может быть одновременно подключен к нескольким соединениям |
| Notified Entity (Уведомляемый объект) | N | Идентификатор объекта, к которому следует передавать уведомления об обнаруженных событиях. Если данный параметр опущен, порт передает эту информацию к объекту, от которого была получена команда. Идентификатор объекта кодируется так же, как кодируются адреса электронной почты согласно RFC 821, например, MGC@ca.anynet.com:5625 или Joe@[128.23.0.4]. При использовании IP-адреса, он должен быть заключен в квадратные скобки. |
| Requestldentifier (Идентификатор запроса) | Х | Согласует требование уведомить о событии, полученное от Call Agent, с уведомлением, передаваемым шлюзом в команде Notify. |
| LocalConnection Options (Параметры подключения порта к соединению) | L | Данные об алгоритме кодирования информации, размере речевых пакетов в мс, используемой полосе пропускания в Кбит/с, типе обслуживания, использовании эхокомпенсации и другие сведения. Передается от Call Agent к шлюзу, обычно в команде CRCX. |
| ConnectionMode (Режим соединения) | М | Определены следующие режимы соединения: передача, прием, прием/передача, конференция, передача данных, отсутствие активности, петля, тест и другие режимы. Значение параметру присваивает Call Agent. |
| RequestedEvents (Запрашиваемые события) | R | Список событий, о которых следует оповестить Call Agent, и действия шлюза при обнаружении события. Определены следующие действия: оповестить Call Agent о событии немедленно; ожидать дальнейших событий; если событием является прием сигнала DTMF, то накапливать цифры в соответствии с требованиями параметра DigitMap; в определенных ситуациях передавать в канал акустические или вызывные сигналы; обработать инкапсулированную команду Endpoint Configuration, игнорировать событие и др. |
| SignalRequests (Требование передать сигнал) | S | Специфицируется сигнал, который должен быть передан абоненту, например, акустический сигнал "Ответ станции". |
| 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. Эти возможности порта включают в себя: поддерживаемые алгоритмы кодирования, период пакетизации, полосу пропускания, эхокомпенсацию, подавление пауз речи, режимы соединения, тип обслуживания, совокупность событий и др. |
Не все параметры, приведенные в таблице 8.3, должны обязательно присутствовать во всех командах протокола MGCR В таблице 8.4 представлены возможные комбинации параметров в командах протокола MGCR Буква “М” означает обязательное присутствие параметра в команде, буква “О” - не обязательное присутствие, буква “F” запрещает присутствие параметра.
Таблица 8.4 Комбинации параметров в командах протокола MGCP
| Имя параметра | EP CF |
CR CX |
MD CX |
DL CX |
RQ NT |
NT FY |
AU EP |
AU CX |
RS IP |
| ResponseAck | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| Bearerlnformation | M | 0 | 0 | 0 | 0 | F | F | F | F |
| Callld | F | M | M | 0 | F | F | F | F | F |
| Connectionid | F | F | M | 0 | F | F | F | M | F |
| Requestldentifier | F | 0** | o** | о** | M | M | F | F | F |
| LocalConnection | F | 0 | 0 | F | F | F | F | F | F |
| Options | |||||||||
| Connection Mode | F | M | M | F | F | F | F | F | F |
| Requested Events | F | 0 | 0 | 0 | O* | F | F | F | F |
| SignalRequests | F | 0 | 0 | 0 | O* | F | F | F | F |
| NotifiedEntity | F | 0 | 0 | 0 | 0 | 0 | F | F | F |
| ReasonCode | F | F | F | 0 | F | F | F | F | 0 |
| Observed Events | F | F | F | F | F | M | F | F | F |
| DigitMap | F | 0 | 0 | 0 | 0 | F | F | F | F |
| Connection | F | F | F | 0 | F | F | F | F | F |
| Parameters | |||||||||
| Specific Endpoint ID | F | F | F | F | F | F | F | F | F |
| Second Endpoint ID | F | 0 | F | F | F | F | F | F | F |
| Requestedlnfo | F | F | F | F | F | F | M | M | F |
| QuarantineHandling | F | 0 | 0 | 0 | 0 | F | F | F | F |
| DetectEvents | F | 0 | 0 | 0 | 0 | F | F | F | F |
| EventStates | F | F | F | F | F | F | F | F | F |
| RestartMethod | F | F | F | F | F | F | F | F | M |
| RestartDelay | F | F | F | F | F | F | F | F | 0 |
| SecondConnectionID | F | F | F | F | F | F | F | F | F |
| Capabilities | F | F | F | F | F | F | F | F | F |
| RemoteConnection | F | 0 | 0 | F | F | F | F | F | F |
| Descriptor | |||||||||
| LocalConnection | F | F | F | F | F | F | F | F | F |
| Descriptor |
** - параметр Requestldentifier не обязателен для команд Create-Connection, ModifyConnection и DeleteConnection, но если эти команды содержат инкапсулированную команду NotificationRequest, присутствие в них параметра Requestldentifier становится обязательным;
* - параметры Requested Events и SignalRequests не обязательны для команды NotificationRequest.
8.6 Структура ответов на команды
Протокол MGCP предусматривает подтверждение получения всех команд. Структура ответов на команды в протоколе MGCP идентична вышеописанной структуре самих команд. Ответ на команду также представляет собой набор текстовых строк и обязательно содержит заголовок ответа, за которым (после пустой строки) может следовать описание сеанса связи.
В этом параграфе речь пойдет, главным образом, о заголовке ответа. Заголовок состоит из ответной строки, например, 2001203 OK, и списка параметров. Ответная строка, в свою очередь, состоит из нескольких информационных полей: кода ответа, идентификатора транзакции и необязательного комментария.
В таблице 8.5 приведены возможные варианты кода ответа на команды протокола MGCP.
Таблица 8.5 Коды ответов на команды протокола MGCP
| Код | Значение кода |
| 100 | Полученная команда в данный момент обрабатывается, сообщение о выполнении команды будет передано позже |
| 200 | Полученная команда выполнена |
| 250 | Соединение разрушено |
| 400 | Транзакция не может быть выполнена из-за временной ошибки |
| 401 | Трубка телефона уже снята |
| 402 | Трубка телефона уже повешена |
| 403 | Команда не может быть выполнена из-за отсутствия в данный момент необходимых ресурсов |
| 404 | В настоящий момент отсутствует необходимая полоса пропускания |
| 500 | Команда не может быть выполнена, потому что порт неизвестен |
| 501 | Команда не может быть выполнена, потому что порт не готов к ее выполнению |
| 502 | Команда не может быть выполнена, потому что порт не имеет необходимой полосы пропускания |
| 510 | Команда не может быть выполнена из-за ошибки в протоколе |
| 511 | Команда не может быть выполнена, так как в ней содержится нераспознанное расширение |
| 512 | Команда не может быть выполнена, потому что шлюз не имеет средств детектирования одного из запрашиваемых сигналов |
| 513 | Команда не может быть выполнена, потому что шлюз не имеет средств генерирования одного из запрашиваемых сигналов |
| 514 | Команда не может быть выполнена, потому что шлюз не может передать необходимое речевое уведомление или подсказку |
| 515 | Команда имеет некорректный идентификатор соединения, например, идентификатор уже завершенного соединения |
| 516 | Команда имеет некорректный идентификатор сеанса связи |
| 517 | Неподдерживаемый или некорректный режим |
| 518 | Неподдерживаемая или неизвестная совокупность сигналов или событий |
| 519 | Порт не имеет сведений о плане нумерации |
| 520 | Команда не может быть выполнена, потому что идет рестарт порта |
| 521 | Порт передан другому Call Agent |
| 522 | Нет такого события или сигнала |
| 523 | Неизвестное действие или неразрешённая комбинация действий |
| 524 | Внутреннее несоответствие в параметре LocalConnectionOptions |
| 525 | Неизвестное расширение параметра LocalConnectionOptions |
| 526 | Недостаточная полоса пропускания |
| 527 | Отсутствует параметр LocalConnectionOptions |
| 528 | Несовместимая версия протокола |
| 529 | Отказ в аппаратном обеспечении |
| 530 | Ошибка в сигнальном протоколе CAS |
| 531 | Отказ группы каналов или трактов |
На основании информации, предоставляемой этими кодами ошибок, невозможно реализовать осмысленный механизм диагностики. Для получения диагностической информации от шлюзов и портов шлюза нужны другие методы. Одним из возможных методов является упоминавшийся в главе 4 протокол SNMP (простой протокол эксплуатационного управления сетью), который, безусловно, найдёт применение в транспортных шлюзах IP-телефонии.
В заключение рассмотрения структуры ответов на команды протокола MGCP приведем возможные комбинации параметров в ответах (таблица 8.6).
Таблица 8.6 Возможные комбинации параметров в ответах протокола MGCP
| Имя параметра | EP CF |
CR CX |
MD CX |
DL CX |
RQ NT |
NT FY |
AU EP |
AU CX |
RS IP |
| ResponseAck | F | F | F | F | F | F | F | F | F |
| Bearerlnformation | F | F | F | F | F | F | 0 | F | F |
| Callld | F | F | F | F | F | F | F | 0 | F |
| Connectionid | F | 0 | F | F | F | F | F | F | F |
| Requestldentifier | F | F | F | F | F | F | 0 | F | F |
| LocalConnection | F | F | F | F | F | F | 0 | 0 | F |
| Options | |||||||||
| Connection Mode |
F | F | F | F | F | F | F | 0 | F |
| RequestedEvents | F | F | F | F | F | F | 0 | F | F |
| SignalRequests | F | F | F | F | F | F | 0 | F | F |
| Notified Entity | F | F | F | F | F | F | F | F | 0 |
| ReasonCode | F | F | F | F | F | F | 0 | F | F |
| Observed Events | F | F | F | F | F | F | 0 | F | F |
| DigitMap | F | F | F | F | F | F | 0 | F | F |
| Connection | F | F | F | 0 | F | F | F | 0 | F |
| Parameters | |||||||||
| Specific Endpoint ID | F | 0 | F | F | F | F | F | F | F |
| Requested Info | F | F | F | F | F | F | F | F | F |
| QuarantineHandling | F | F | F | F | F | F | 0 | F | F |
| DetectEvents | F | F | F | F | F | F | 0 | F | F |
| EventStates | F | F | F | F | F | F | 0 | F | F |
| RestartMethod | F | F | F | F | F | F | 0 | F | F |
| RestartDelay | F | F | F | F | F | F | 0 | F | F |
| Capabilities | F | F | F | F | F | F | 0 | F | F |
| SecondConnectionId | F | 0 | F | F | F | F | F | F | F |
| SecondEndpointID | F | 0 | F | F | F | F | F | F | F |
| LocalConnection | F | м | 0 | F | F | F | F | 0 | F |
| Descriptor | |||||||||
| RemoteConnection | F | F | F | F | F | F | F | 0 | F |
| Descriptor |
При установлении соединений Call Agent предоставляет портам шлюзов, участвующим в этих соединениях, необходимую информацию друг о друге - описание сеансов связи.
Описание сеанса связи вводится в состав некоторых команд и ответов протокола MGCP и включает в себя IP-адрес, UDP/ RTP порт, вид информации, алгоритм кодирования информации, размер речевых пакетов и т.д. Синтаксис описания сеанса связи в протоколе MGCP соответствует синтаксису протокола описания сеансов связи - session description protocol (SDP), предложенному для использования в вышеуказанных целях комитетом IETF в документе RFC 2327 [53].
Протокол SDP может применяться для описания мультимедийных конференций, но текущая версия протокола MGCP использует протокол SDP только для описания параметров передачи речи и данных.
Так как книга посвящена анализу технологии передачи речевой информации по сетям с маршрутизацией пакетов IP, в данном параграфе мы рассмотрим синтаксис протокола SDP только в части описания сеанса речевой связи. Для описания такого сеанса в протоколе SDP предусмотрено несколько информационных полей:
• Версия протокола SDP. Текущая версия протокола - нулевая. Поле кодируется следующим образом: v=0.
• IP-адрес шлюза. Это поле содержит IP-адрес, который будет использоваться для обмена пакетами RTP. Если это поле включено в команды протокола MGCP, то оно означает адрес удаленного шлюза, если поле включено в ответы, то - адрес шлюза, передающего ответ.
• Поле описания речевого канала. Данное поле содержит индикацию вида передаваемой или принимаемой информации (в нашем случае - речи), номер порта, используемого для приема RTP пакетов удаленным шлюзом (если поле описания речевого канала включено в команды протокола MGCP) или локальным шлюзом (если это поле включено в ответы), индикацию использования протокола RTP для передачи речи и алгоритмы кодирования речевой информации. Поле кодируется буквой “т”.
• Режим соединения. Режимы соединений представлены в таблице 8.7.
)
Таблица 8.7 Режимы соединения
| Кодировка режима | Функционирование шлюза |
| sendonly | Шлюзу надлежит только передавать информацию |
| recvonly | Шлюзу надлежит только принимать информацию |
| sendrecv | Шлюзу надлежит передавать и принимать информацию |
| inactive | Шлюз не должен ни передавать, ни принимать информацию |
| loopback | Шлюз должен передавать принимаемую информацию в обратном направлении |
| contest | Шлюзу надлежит перевести порт в режим тестирования |
Кроме вышеуказанных полей, для описания сеанса речевой связи в протоколе SDP предусмотрено еще несколько необязательных информационных полей. Отметим, что если в команду или в ответ протокола MGCP включены описания нескольких сеансов связи, то они отделяются друг от друга строкой с указанием версии протокола SDP. Типичный пример описания сеанса речевой связи с использованием протокола SDP приведён ниже:
v = О
с = IN IP4 128.96.41.1
m = audio 3456 rtp/avp 0
Данный пример заслуживает краткого комментария. Для описания сеанса связи используется протокол SDP, версия 0, в сети используется протокол IP, версия 4, IP адрес шлюза- 128.96.41.1, передается или принимается речевая информация, упакованная в пакеты RTP, номер порта RTP - 3456, алгоритм кодирования речи G.711, закон [I.
8.8 Установление, изменение и разрушение соединений
В данном параграфе будет показано, каким образом при помощи протокола MGCP устанавливаются, изменяются и завершаются речевые соединения в сетях с маршрутизацией пакетов IP. Пример охватывает взаимодействие протокола MGCP с протоколом ОКС7 (рис. 8.6).
От телефонной станции АТС1 к шлюзу сигнализации SG1 по общему каналу сигнализации поступает запрос соединения - сообщение IAM. Шлюз SG1 передает сообщение IAM устройству управления шлюзами Call Agent, которое обрабатывает запрос и определяет, что вызов должен быть направлен к телефонной станции АТС2 посредством шлюза TGW2.
Далее Call Agent резервирует порт шлюза TGW1 (разговорный канал). С этой целью Call Agent передает шлюзу команду CreateConnec-tion. Отметим, что порт шлюза TGW1 может только принимать информацию (режим “recvonly”), так как он еще не осведомлен о том, на какой адрес и каким образом ему следует передавать информацию.
CRCX 1204 trunk-group-l/17@tgwl.whatever.net MGCP 0.1
С: A3C47F21456789FO
L: p:10, a:G.711
M: recvonly
В ответе на принятую команду шлюз TGW1 возвращает описание сеанса связи.
200 1204 OK
I:FDE234C8
v=0
C=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0
Рис. 8.6 Установление и разрушение соединения с использованием протокола MGCP
После приема от шлюза TGW1 подтверждения Call Agent передает команду CRCX второму шлюзу TGW2 с целью зарезервировать в нем порт:
CRCX 1205 trunk-group-2/$@tgw2.whatever.net MGCP 0.1
С: A3C47F21456789FO
M: sendrecv
v0
C=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0
Шлюз TGW 2 выбирает порт, который будет участвовать в связи, и подтверждает прием команды CRCX.
I:abc0
v=0
C-IN IP4 128.96.63.25
m=audio 1296 RTP/AVP 0
При помощи двух команд CRCX создается однонаправленный разговорный канал для передачи вызываемому абоненту акустических сигналов или речевых подсказок и извещений. В то же время, порт шлюза TGW 2 уже может не только принимать, но и передавать информацию, так как он получил описание сеанса связи от встречного шлюза. Далее Call Agent передает сообщение 1АМ к телефонной станции АТС2. На сообщение 1АМ станция АТС2 отвечает сообщением АСМ, которое немедленно пересылается к станции АТС1.
После того как вызываемый абонент примет вызов, телефонная станция АТС2 передает к Call Agent сообщение ANM. Далее Call Agent меняет режим соединения “recvonly” в шлюзе TGW1 на полнодуплексный режим:
MDCX 1206 trunk-group-I/17@tgwl.whatever.net MGCP 0.1
С: A3C47F21456789FO
I: FDE234C8
M: sendrecv
v=0
C=IN IP4 128.96.63.25
m=audio 1296 RTP/AVP 0
Шлюз TGW1 выполняет и подтверждает изменение режима соединения:
200 1206 OK
Call Agent передает сообщение ANM к телефонной станции АТС1, после чего наступает разговорная фаза соединения.
Завершение разговорной фазы происходит следующим образом. В нашем случае вызвавший абонент дает отбой первым, телефонная станция АТС1 через шлюз сигнализации передает к Call Agent сообщение REL. На основании этого сообщения Call Agent завершает соединение с вызвавшим абонентом:
DLCX 1207 trunk-group-I/17&tgwl.whatever.net MOCP 0.1
С: A3C47F21456789FO I:FDE234C8
Шлюз подтверждает завершение соединения и передает к Call Agent собранные за время соединения статистические данные:
250 1217 OK
Р: PS-1245, OS-62345, PR-780, OR'45123, PL-10, JI-27,LA=48
Далее Call Agent передает к АТС1 сообщение RLC с целью подтвердить разрушение соединения.
Параллельно Call Agent завершает соединение с вызванной стороной:
DLCX 1208 trunk-group-2/13@tgw2.whatever.net MGCP 0.1
С: A3C47F21456789FO
I:abc0
Шлюз TGW2 подтверждает завершение соединения и передает к Call Agent собранные за время соединения статистические данные
250 1218 OK
Р: PS=790, 08=45700, PR=1230, OR=61875, PL=15, JI=27,IA=48
После приема ответа на команду DLCX Call Agent может начинать процедуру завершения соединения с АТС2, которая должна подтвердить разъединение, после чего соединение считается разрушенным.
8.9 Реализация оборудования с поддержкой протокола MGCP
Рассмотрим реализацию протокола MGCP на примере оборудования IPConnect производства компании Nortel Networks. IPConnect -это набор совместимых аппаратно-программных средств, объединенных единой идеологией и технологической базой. Он охватывает системы управления соединениями и обработки вызовов, серверы приложений, шлюзы, а также аппаратуру, устанавливаемую непосредственно у пользователей. Масштабы сетей, создаваемых на базе этого решения, практически не ограничены.
И еще одна важная особенность: концепция построения оборудования IPConnect дает оператору возможность выбрать то решение, которое отвечает его текущим потребностям, и постепенно наращивать мощность сети, инвестируя средства поэтапно и соотнося этот процесс с темпами развития бизнеса и финансовыми возможностями.
Как известно, до недавнего времени единственным протоколом, регулирующим процесс управления соединениями в сетях IP-телефонии, был протокол Н.323. Этот протокол достаточно широко распространен и хорошо зарекоменовал себя в решениях IP-телефонии. Но, к сожалению, Н.323 не может гарантировать прозрачность соединений с ТфОП, использующими сигнализацию ОКС7. Это обстоятельство предопределило выбор протокола MGCP в качество основного протокола в оборудовании IPConnect (что, впрочем, не отвергает полностью протокол Н.323). Протокол MGCP специально оптимизирован для нужд телефонии, и компания Nortel Networks принимает активное участие в его разработке и внедрении.
С точки зрения функционального построения в IPConnect можно выделить четыре основных элемента (рис. 8.7):
• шлюз между ТфОП и IP-сетью (CVX 1800);
• система обработки вызовов (IPConnect Call Engine - ICE);
• шлюз сигнализации (USP);
• различные приложения - например, IVR.
Результатом эволюции ОКС7 в направлении пакетной передачи информации стало появление семейства протоколов IPS7 (более 20), описывающих конкретные процедуры упаковки/распаковки сигналов ОКС7. В их числе - аналоги протоколов ISUP, INAP и других, используемых в системе сигнализации ОКС7. Эти протоколы имеют различные модификации, учитывающие особенности, присущие национальным системам сигнализации. В частности, имеются специальные разновидности и для России (например, аналог протокола ISUP-R).
8.10 Возможности и перспективы протокола MGCP
Для построения хорошо функционирующих и совместимых с ТфОП сетей IP-телефонии сегодня подходят протоколы Н.323 и MGCP. Подход с использованием MGCP обладает весьма важным преимуществом перед подходом, предложенным ITU в рекомендации Н.323: Call Agent поддерживает сигнализацию ОКС7 и другие виды телефонной сигнализации; поддерживается также прозрачная трансляция сигнальной информации по сети IP-телефонии. В сети, построенной на базе рекомендации Н.323, сигнализация ОКС7, как и любая другая сигнализация, должна конвертироваться шлюзом в сигнальные сообщения Н.225.0 (Q.931).
В целом же, анализируя функциональные возможности протокола MGCP, можно сделать следующий вывод: протокол, предлагаемый рабочей группой MEGACO организации IETF, лучше других подходит для развертывания глобальных сетей IP-телефонии, приходящих на смену традиционным телефонным сетям.
Но, в то же время, следует отметить, что в существующих сегодня приложениях IP-телефонии, таких как предоставление услуг международной и междугородной связи, использовать протокол MGCP (так же, как и протокол SIP) нецелесообразно в связи с тем, что подавляющее большинство сетей IP-телефонии сегодня построено на базе протокола Н.323.Оператору придется строить на базе протокола MGCP (или SIP) отдельную сеть IP-телефонии, что потребует значительных капиталовложений, в то время как оператор связи, имеющий оборудование стандарта Н.323, может легко присоединить свою сеть к существующим сетям.
