Глава 8 Протокол управления шлюзами MGCP

8.1 Принцип декомпозиции шлюза

В недавнем прошлом рабочая группа MEGACO комитета IETF разработала протокол управления шлюзами - Media Gateway Control Protocol (MGCP). Ранее подобный протокол под названием SGCP - Simple Gateway Control Protocol (простой протокол управления шлюзами) - был разработан компанией Telecordia (бывшая компания Bellcore). фирма Level 3 предложила сходный протокол управления оборудованием, реализующим технологию маршрутизации пакетов IP, - IDCP (IP Device Control Protocol). Оба они впоследствии были объединены в протокол MGCP.

При разработке протокола управления шлюзами рабочая группа MEGACO опиралась на принцип декомпозиции, согласно которому шлюз разбивается на отдельные функциональные блоки (рис. 8.1):

• транспортный шлюз - Media Gateway, который выполняет функции преобразования речевой информации, поступающей со стороны ТфОП с постоянной скоростью, в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP: кодирование и упаковку речевой информации в пакеты RTP/UDP/IP, а также обратное преобразование;

• устройство управления - Call Agent, выполняющее функции управления шлюзом;

• шлюз сигнализации - Signaling Gateway, который обеспечивает доставку сигнальной информации, поступающей со стороны ТфОП, к устройству управления шлюзом и перенос сигнальной информации в обратном направлении.

Рис. 8.1 Архитектура сети, базирующейся на протоколе MGCP

Таким образом, весь интеллект функционально распределенного шлюза размещается в устройстве управления, функции которого, в свою очередь, могут быть распределены между несколькими компьютерными платформами. Шлюз сигнализации выполняет функции STP - транзитного пункта системы сигнализации по общему каналу - ОКС7. Транспортные шлюзы выполняют только функции преобразования речевой информации. Одно устройство управления обслуживает одновременно несколько шлюзов. В сети может присутствовать несколько устройств управления. Предполагается, что эти устройства синхронизованы между собой и согласованно управляют шлюзами, участвующими в соединении. Рабочая группа MEGACO не определяет протокол синхронизации работы устройств управления, однако в ряде работ, посвященных исследованию возможностей протокола MGCP, для этой цели предлагается использовать протоколы Н.323, SIP или ISUP/IP (рис. 8.2).

Перенос сообщений протокола MGCP обеспечивает протокол не гарантированной доставки - UDP. Кроме того, рабочая группа SIGTRAN комитета IETF в настоящее время разрабатывает механизм взаимодействия устройства управления и шлюза сигнализации. Последний должен принимать поступающие из ТфОП сигнальные единицы подсистемы МТР системы сигнализации ОКС7 и передавать сигнальные сообщения верхнего, пользовательского уровня к устройству управления. Основное внимание рабочей группы SIGTRAN уделено вопросам разработки наиболее эффективного механизма передачи сигнальной информации по IP-сетям. Следует отметить, что существует несколько причин, уже упонинавшихся ранее, по которым пришлось отказаться от использования для этой цели протокола TCP. Вместо него рабочая группа SIGTRAN предлагает использовать протокол Stream Control Transport Protocol (SCTP), который имеет ряд преимуществ перед протоколом TCP. Основным из этих преимуществ является значительное снижение времени доставки сигнальной информации и, следовательно, времени установления соединения -одного из важнейших параметров качества обслуживания.

Рис. 8.2 Синхронизация работы устройств управления

Если распределенный шлюз подключается к ТфОП при помощи сигнализации по выделенным сигнальным каналам (ВСК), то сигнальная информация вместе с пользовательской информацией сначала поступает в транспортный шлюз, а затем передается в устройство управления без посредничества шлюза сигнализации.

Одно из основных требований, предъявляемых к протоколу MGCP, состоит в том, что устройства, реализующие этот протокол, должны работать в режиме без сохранения информации о последовательности транзакций между устройством управления и транспортным шлюзом, т.е. в устройствах не требуется реализации конечного автомата для описания этой последовательности. Однако не следует распространять подобный подход на последовательность состояний соединений, сведения о которых хранятся в устройстве управления.

Отметим, что протокол MGCP является внутренним протоколом, поддерживающим обмен информацией между функциональными блоками распределенного шлюза. Протокол MGCP использует принцип master/slave (ведущий/ведомый), причем устройство управления шлюзами является ведущим, а транспортный шлюз - ведомым устройством, выполняющим команды, поступающие от устройства управления.

Такое решение обеспечивает масштабируемость сети и простоту эксплуатационного управления ею через устройство управления шлюзами. К тому же, не интеллектуальные шлюзы требуют меньшей производительности процессоров и, как следствие, оказываются менее дорогими. Кроме того, обеспечивается возможность быстро добавлять новые протоколы сигнализации и новые дополнительные услуги, так как нужные для этого изменения затрагивают только устройство управления шлюзами, а не сами шлюзы.

Основной недостаток этого подхода - незаконченность стандартов. Функциональные блоки распределенных шлюзов, разработанные разными фирмами-производителями телекоммуникационного оборудования, практически несовместимы. Функции устройства управления шлюзами точно не определены. Не стандартизированы механизмы переноса сигнальной информации от шлюза сигнализации (Signalling Gateway) к устройству управления и в обратном направлении. К недостаткам можно отнести также отсутствие стандартизированного протокола взаимодействия между устройствами управления. Кроме того, протокол MGCP, являясь протоколом управления шлюзами, не предназначен для управления соединениями с участием терминального оборудования пользователей (IP-телефонами). Это означает, что в сети, построенной на базе протокола MGCP, для управления терминалами должен присутствовать привратник или сервер SIP (рис. 8.3).

Рис. 8.3 Управление терминалами в сети, базирующейся на протоколе MGCP

8.2 Классификация шлюзов

Рабочей группой 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 соединениям

е) межсетевой экран или транскодер - порт ретрансляции пакетов

Подключение к одному соединению

ж) порт записи/воспроизведения телефонных разговоров

Подключения к К соединениям

з) АТМ-интерфейс

Рис. 8.4 Примеры использования компонентов модели

Подключения создаются устройством управления 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 включает в себя следующие параметры (в квадратных скобках указаны те из них, которые не являются обязательными).

ReturnCode

<—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

8.5 Структура команд

Команда протокола MGCP обязательно содержит заголовок, за которым может следовать описание сеанса связи (session description). Заголовок команды и описание сеанса связи представляют собой набор текстовых строк. Описание сеанса отделено от заголовка команды пустой строкой.

Заголовок содержит список параметров и командную строку вида CRCX 1204 ts/1@protei.loniis.net MGCP 0.1. Командная строка, в свою очередь, состоит из нескольких информационных полей:

1. Название команды представлено в виде кода из четырех букв (табл.8.2)

Таблица 8.2 Кодировка команд протокола MGCP

2. Идентификатор транзакции. Протокол MGCP предусматривает корреляцию команд и ответов. Команда и ответ на нее образуют транзакцию, имеющую уникальный идентификатор (Transaction-Identifier). Идентификатор транзакции включается в заголовок и команды, и ответа. Значения идентификаторов выбираются из диапазона чисел 1 -999999999, причем значение идентификатора текущей транзакции на единицу больше идентификатора предыдущей транзакции.

3. Идентификатор порта определяет тот порт шлюза, которому надлежит выполнить команду, за исключением команд Notify и ReStartlnProgress, в которых идентификатор определяет порт, передавший команду. Идентификаторы портов кодируются также, как кодируются адреса электронной почты в соответствии с документом RFC 821 комитета IETF. Например, возможен идентификатор ts/1@protei.loniis.net, который идентифицирует первый порт (временной канал) шлюза «protei», расположенного в домене loniis.

4. Версия протокола кодируется следующим образом: MGCP 1.0.

Выше указывалось, что заголовок команды, кроме командной строки, содержит список параметров. Параметры команд протокола MGCP сведены в таблицу 8.3.

Таблица 8.3 Параметры команд протокола MGCP

Не все параметры, приведенные в таблице 8.3, должны обязательно присутствовать во всех командах протокола MGCR В таблице 8.4 представлены возможные комбинации параметров в командах протокола MGCR Буква «М» означает обязательное присутствие параметра в команде, буква «О» - не обязательное присутствие, буква «F» запрещает присутствие параметра.

Таблица 8.4 Комбинации параметров в командах протокола MGCP

** - параметр Requestldentifier не обязателен для команд Create-Connection, ModifyConnection и DeleteConnection, но если эти команды содержат инкапсулированную команду NotificationRequest, присутствие в них параметра Requestldentifier становится обязательным;

* - параметры Requested Events и SignalRequests не обязательны для команды NotificationRequest.

8.6 Структура ответов на команды

Протокол MGCP предусматривает подтверждение получения всех команд. Структура ответов на команды в протоколе MGCP идентична вышеописанной структуре самих команд. Ответ на команду также представляет собой набор текстовых строк и обязательно содержит заголовок ответа, за которым (после пустой строки) может следовать описание сеанса связи.

В этом параграфе речь пойдет, главным образом, о заголовке ответа. Заголовок состоит из ответной строки, например, 2001203 OK, и списка параметров. Ответная строка, в свою очередь, состоит из нескольких информационных полей: кода ответа, идентификатора транзакции и необязательного комментария.

В таблице 8.5 приведены возможные варианты кода ответа на команды протокола MGCP.

Таблица 8.5 Коды ответов на команды протокола MGCP

Из представленного в таблице 8.5 перечня кодов ответов видно, что их основная роль заключается в защите от ошибок протокола, конфигурации или функциональных возможностей. На основании информации, предоставляемой этими кодами ошибок, невозможно реализовать осмысленный механизм диагностики. Для получения диагностической информации от шлюзов и портов шлюза нужны другие методы. Одним из возможных методов является упоминавшийся в главе 4 протокол SNMP (простой протокол эксплуатационного управления сетью), который, безусловно, найдёт применение в транспортных шлюзах IP-телефонии.

В заключение рассмотрения структуры ответов на команды протокола MGCP приведем возможные комбинации параметров в ответах (таблица 8.6).

Таблица 8.6 Возможные комбинации параметров в ответах протокола MGCP

8.7 Описания сеансов связи

При установлении соединений 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 Режимы соединения

Кроме вышеуказанных полей, для описания сеанса речевой связи в протоколе 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.

200 1205 OK

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.

Рис. 8.7 Инфраструктура IPConnect

Результатом эволюции ОКС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, может легко присоединить свою сеть к существующим сетям.