Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Занятие 7: ПРОТОКОЛ УПРАВЛЕНИЯ ШЛЮЗАМИ MGCP
7.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 опиралась на принцип декомпозиции, согласно которому шлюз разбивается на отдельные функциональные блоки (рис. 7.1):
• транспортный шлюз - Media Gateway, который выполняет функции преобразования речевой информации, поступающей со стороны ТфОП с постоянной скоростью, в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP: кодирование и упаковку речевой информации в пакеты RTP/UDP/IP, а также обратное преобразование;
• устройство управления - Call Agent, выполняющее функции управления шлюзом;
• шлюз сигнализации - Signaling Gateway, который обеспечивает доставку сигнальной информации, поступающей со стороны ТфОП, к устройству управления шлюзом и перенос сигнальной информации в обратном направлении.
Рис. 7.1 Архитектура сети, базирующейся на протоколе MGCP
Таким образом, весь интеллект функционально распределенного шлюза размещается в устройстве управления, функции которого, в свою очередь, могут быть распределены между несколькими компьютерными платформами. Шлюз сигнализации выполняет функции STP - транзитного пункта системы сигнализации по общему каналу - ОКС7. Транспортные шлюзы выполняют только функции преобразования речевой информации. Одно устройство управления обслуживает одновременно несколько шлюзов. В сети может присутствовать несколько устройств управления. Предполагается, что эти устройства синхронизованы между собой и согласованно управляют шлюзами, участвующими в соединении.
Перенос сообщений протокола MGCP обеспечивает протокол не гарантированной доставки - UDP.
Одно из основных требований, предъявляемых к протоколу MGCP, состоит в том, что устройства, реализующие этот протокол, должны работать в режиме без сохранения информации о последовательности транзакций между устройством управления и транспортным шлюзом, т.е. в устройствах не требуется реализации конечного автомата для описания этой последовательности. Однако не следует распространять подобный подход на последовательность состояний соединений, сведения о которых хранятся в устройстве управления.
Отметим, что протокол MGCP является внутренним протоколом, поддерживающим обмен информацией между функциональными блоками распределенного шлюза. Протокол MGCP использует принцип master/slave (ведущий/ведомый), причем устройство управления шлюзами является ведущим, а транспортный шлюз - ведомым устройством, выполняющим команды, поступающие от устройства управления.
Такое решение обеспечивает масштабируемость сети и простоту эксплуатационного управления ею через устройство управления шлюзами. К тому же, не интеллектуальные шлюзы требуют меньшей производительности процессоров и, как следствие, оказываются менее дорогими. Кроме того, обеспечивается возможность быстро добавлять новые протоколы сигнализации и новые дополнительные услуги, так как нужные для этого изменения затрагивают только устройство управления шлюзами, а не сами шлюзы.
Основной недостаток этого подхода - незаконченность стандартов. Функциональные блоки распределенных шлюзов, разработанные разными фирмами-производителями телекоммуникационного оборудования, практически несовместимы. Функции устройства управления шлюзами точно не определены. Не стандартизированы механизмы переноса сигнальной информации от шлюза сигнализации (Signalling Gateway) к устройству управления и в обратном направлении. К недостаткам можно отнести также отсутствие стандартизированного протокола взаимодействия между устройствами управления. Кроме того, протокол MGCP, являясь протоколом управления шлюзами, не предназначен для управления соединениями с участием терминального оборудования пользователей (IP-телефонами). Это означает, что в сети, построенной на базе протокола MGCP, для управления терминалами должен присутствовать привратник или сервер SIP (рис. 7.2).
Рис. 7.2 Управление терминалами в сети, базирующейся на протоколе MGCP
7.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 - коммутационные устройства с интерфейсом для управления от внешнего устройства.
7.3 Модель организации связи
Для описания процесса обслуживания вызова с использованием протокола MGCP рабочей группой MEGACO разработана модель организации соединения - Connection model. Базой модели являются компоненты двух основных видов: порты (Endpoints) и подключения (Connections).
Endpoints - это порты оборудования, являющиеся источниками и приемниками информации. Существуют порты двух видов: физические и виртуальные. Физические порты - это аналоговые интерфейсы, поддерживающие каждый одно телефонное соединение, или цифровые каналы, также поддерживающие одно телефонное соединение и мультиплексированные по принципу временного разделения каналов в тракт Е1. Примером виртуального порта является источник речевой информации в интерактивном речевом сервере, т.е. некое программное средство.
Connection - означает подключение порта к одному из двух концов соединения, которое создается между ним и другим портом. Такое соединение будет установлено после подключения другого порта к его второму концу. Соединение может связывать порты разных шлюзов через сеть с маршрутизацией пакетов IP или порты внутри одного шлюза.
7.4 Команды протокола MGCP
В ходе установления, поддержания и разрушения соединения при помощи протокола MGCP устройство управления и шлюз обмениваются командами и ответами, которые представляют собой набор текстовых строк. Далее дается краткое описание команд протокола MGCP, среди которых определены команды управления соединением и команды управления портами оборудования.
При помощи команды EndpointConfiguration устройство управления инструктирует шлюз, каким образом он должен обрабатывать получаемые речевые сигналы, например, использовать для преобразования цифрового сигнала в аналоговую форму закон А или закон µ.
Команда EndpointConfiguration содержит ряд параметров:
ReturnCode
<— EndpointConfiguration( Endpointid,
Bearer Information),
где Endpointid - идентификатор порта шлюза, к которому относится данная команда;
Bearerlnformation - параметр, определяющий закон (А или µ) декодирования принятой речевой информации.
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 управляющее устройство может дать шлюзу указание создать соединение двух портов одного и того же шлюза или разных шлюзов.
Устройство управления может разрушить существующее соединение при помощи команды DeleteConnection. Кроме того, при помощи этой команды шлюз может передать к Call Agent индикацию того, что существующее соединение больше поддерживаться не может.
При помощи команды AuditConnection устройство управления запрашивает параметры соединения, в котором участвует порт шлюза.
Команда 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 определяет задержку рестарта в секундах.
В таблицу 7.1 сведены все команды протокола MGCP.
Таблица 7.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 о том, что один или несколько портов выводятся из рабочего состояния или возвращаются в рабочее состояние |
7.5 Структура ответов на команды
Протокол MGCP предусматривает подтверждение получения всех команд. Структура ответов на команды в протоколе MGCP идентична вышеописанной структуре самих команд. Ответ на команду также представляет собой набор текстовых строк и обязательно содержит заголовок ответа, за которым (после пустой строки) может следовать описание сеанса связи.
Заголовок ответа состоит из ответной строки, например, 2001203 OK, и списка параметров. Ответная строка, в свою очередь, состоит из нескольких информационных полей: кода ответа, идентификатора транзакции и необязательного комментария.
В таблице 7.2 приведены возможные варианты кода ответа на команды протокола MGCP.
Таблица 7.2 Коды ответов на команды протокола 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 |
Отказ группы каналов или трактов |
7.6 Описания сеансов связи
При установлении соединений Call Agent предоставляет портам шлюзов, участвующим в этих соединениях, необходимую информацию друг о друге - описание сеансов связи. Описание сеанса связи вводится в состав некоторых команд и ответов протокола MGCP и включает в себя IP-адрес, UDP/RTP порт, вид информации, алгоритм кодирования информации, размер речевых пакетов и т.д. Синтаксис описания сеанса связи в протоколе MGCP соответствует синтаксису протокола описания сеансов связи - session description protocol (SDP), предложенному для использования в вышеуказанных целях комитетом IETF в документе RFC 2327 [53].
Протокол SDP может применяться для описания мультимедийных конференций, но текущая версия протокола MGCP использует протокол SDP только для описания параметров передачи речи и данных.
Для описания сеанса речевой связи в протоколе SDP предусмотрено несколько информационных полей:
• Версия протокола SDP. Текущая версия протокола - нулевая. Поле кодируется следующим образом: v=0.
• IP-адрес шлюза. Это поле содержит IP-адрес, который будет использоваться для обмена пакетами RTP. Если это поле включено в команды протокола MGCP, то оно означает адрес удаленного шлюза, если поле включено в ответы, то - адрес шлюза, передающего ответ.
• Поле описания речевого канала. Данное поле содержит индикацию вида передаваемой или принимаемой информации (в нашем случае - речи), номер порта, используемого для приема RTP пакетов удаленным шлюзом (если поле описания речевого канала включено в команды протокола MGCP) или локальным шлюзом (если это поле включено в ответы), индикацию использования протокола RTP для передачи речи и алгоритмы кодирования речевой информации. Поле кодируется буквой «т».
• Режим соединения. Режимы соединений представлены в таблице 7.3.
Таблица 7.3 Режимы соединения
|
Кодировка режима |
Функционирование шлюза |
|
sendonly |
Шлюзу надлежит только передавать информацию |
|
recvonly |
Шлюзу надлежит только принимать информацию |
|
sendrecv |
Шлюзу надлежит передавать и принимать информацию |
|
inactive |
Шлюз не должен ни передавать, ни принимать информацию |
|
loopback |
Шлюз должен передавать принимаемую информацию в обратном направлении |
|
contest |
Шлюзу надлежит перевести порт в режим тестирования |
7.7 Возможности и перспективы протокола 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, может легко присоединить свою сеть к существующим сетям.
Контрольные вопросы
Контрольное задание