MGCP (Media Gateway Control Protocol)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 21:47, 11 мая 2016.
MGCP
MGCP.jpg
Уровень (по модели OSI): Прикладной
Разработан: рабочая группа MEGACO комитета IETF
Порт/ID: RTP / UDP
Назначение протокола: Протокол связи в распределённых VoIP системах передачи голоса по протоколу IP
Спецификация: RFC 3435
Вступил в силу с: 1999
Сфера использования: IP-телефония

MGCP (англ. Media Gateway Control Protocol - протокол управления шлюзом-носителем) протокол управления шлюзами VoIP, определенные комитетом IETF. Этот протокол управления шлюзом разработан для поддержки архитектуры VoIP, где функции мультимедийной среды отделены от функций сигнализации. Следовательно, его использование предпочтительно как на больших магистральных шлюзах, так и на шлюзах в жилых домах.

Обзор протокола MGCP

Протокол MGCP используется контроллерами шлюза-носителя (Media Gateway Controller— MGC), называемыми также агентами вызова (call agent), для управления шлюзом-носителем (Media Gateway— MG). В основе протокола MGCP лежит принцип главный-подчиненный (master/slave), где контроллер MGC является главным, а шлюз MG — подчиненным. Шлюз MG подтверждает команду, выполняет ее и уведомляет контроллер MGC о результате (успешном или не успешном). В этой архитектуре шлюз MG выполняет функции мультимедийной среды, например преобразование сигналов мультиплексирования с разделением времени (Time-Division Multiplexing — TDM) в аналоговые или потоков протокола передачи данных в реальном масштабе времени (Real-time Transport Protocol— RTP) в потоки протокола управления в реальном масштабе времени (Real-time Transport Control Protocol — RTCP). Функции сигнализации вызова выполняет контроллер MGC. В этой модели интеллект управления вызовом располагается на контроллере MGC, а шлюз MG — бессловесный объект, выполняющий команды контроллера MGC. Сообщения MGCP передаются поверх протокола пользовательских дейтаграмм (User Datagram Protocol — UDP). Поскольку протокол UDP не гарантирует передачи сообщения, они при необходимости передаются повторно. Историческими корнями протокола MGCP являются два прежних протокола — простой протокол управления шлюзом (SGCP) и протокол Интернета для управления устройствами (Internet Protocol Device Control — IPDC).
Для описания мультимедийных сеансов протокол MGCP использует протокол описания сеанса связи (Session Description Protocol — SDP). Протокол SDP описывает параметры сеанса передачи мультимедийных данных между шлюзами MG, включая IP-адреса, порты UDP, профили RTP и мультимедийные возможности конференций. Протокол MGCP следует соглашениям SDP, определенным в документе RFC 2327. Спецификация SDP определяет несколько типов мультимедийных средств, однако протокол MGCP ограничивает использование протокола SDP только двумя из них — звуковыми каналами и каналами доступа к данным.
Для поддержки телефонных шлюзов агенты вызова используют следующие параметры SDP:

  • IP-адрес. Для обмена пакетами RTP может использоваться отдаленный шлюз, локальный шлюз или многоадресатная звуковая конференция.
  • Порт UDP. Указывает транспортный порт, используемый для получения пакетов RTP от отдаленного шлюза.
  • Звуковая мультимедийная среда. Определение звуковой мультимедийной среды, включая кодек.

Архитектура сети

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

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

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

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

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

Представлена следующая классификация транспортных шлюзов:

  • 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 - коммутационные устройства с интерфейсом для управления от внешнего устройства.

Модель организации данных

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

Для описания процесса обслуживания вызова с использованием протокола MGCP разработана модель организации соединения - Connection model. Базой модели являются компоненты двух основных видов: порты (Endpoints) и подключения (Connections).
Endpoints - это порты оборудования, являющиеся источниками и приемниками информации. Существуют порты двух видов: физические и виртуальные. Физические порты имеют аналоговые интерфейсы, поддерживающие каждый одно телефонное соединение, или цифровые каналы, также поддерживающие одно телефонное соединение и мультиплексированные по принципу временного разделения каналов в тракт Е1. Примером виртуального порта является источник речевой информации в интерактивном речевом сервере, т.е. некое программное средство.
Connection означает подключение порта к одному из двух концов соединения, которое создается между ним и другим портом. Такое соединение будет установлено после подключения другого порта к его второму концу. Соединение может связывать порты разных шлюзов через сеть с маршрутизацией пакетов IP или порты внутри одного шлюза.
На рисунке изображены примеры использования этих двух компонентов,причем порты некоторых видов могут участвовать в нескольких соединениях одновременно.
Подключения к N соединениям
а) цифровой порт
Подключения к М соединениям
б) аналоговый порт
Подключение к одному соединению
в) порт, передающий речевые извещения
г) интерактивная речевая система
д) порт записи/воспроизведения телефонных разговоров
Подключения к L соединениям
е) порт, поддерживающий конференцсвязь
Подключения к 2 соединениям
ж) межсетевой экран или транскодер - порт ретрансляции пакетов
Подключения к К соединениям
з) АТМ-интерфейс

Команды и сообщения MGCP

Протокол MGCP реализует интерфейс управления шлюз-носителя как набор транзакций. Транзакции состоят из команды и обязательного ответа. Все команды MGCP состоят из командной строки, сопровождаемой набором строк параметров и, необязательно, описанием сеанса. Командная строка имеет следующий формат: <имя команды> <идентификатор транзакции> <идентификатор конечной точки> <версия MGCP>. Каждая строка параметра, в свою очередь, состоит из кода параметра, сопровождаемого значением параметра. Все ответы состоят из заголовка ответа, сопровождаемого, необязательно,соответствующим описанием сеанса.
Команды MGCP можно разделить на три категории.

  1. Простые команды управления вызовом. Они используются при практически каждом случае вызова. Сюда относятся следующие команды:
     CreateConnection(CRCX)
     ModifyConnection (MDCX) 
     DeleteConnection(DLCX)
  2. Дополнительные команды управления вызовом. Контроллеру MGC могла бы понадобиться информация о местонахождении и некоторых событиях конечной точки, связанных с вызовом. Типичными примерами этих событий является двухтональный многочастотный набор (Dual-Tone Multifrequency — DTMF) цифр, факсимильные тона, события трубка снята (положена) и т.д. Протокол MGCP предоставляет интерфейс, позволяющий контроллеру MGC попросить шлюз отслеживать некоторые события на конечных точках и сообщать о них ему. Контроллер MGC использует команду NotificationRequest (RQNT) для того, чтобы попросить шлюз сообщать о некоторых событиях. Шлюз сообщает об этих событиях контроллеру MGC с помощью команды Notification (NTFY).
  3. Команды управления. Они не связаны непосредственно с управлением вызовом, но контроллер MGC и шлюз обмениваются ими, чтобы сообщить о некоторых событиях, не связанных с вызовом. Например, шлюз может испытывать проблемы с аппаратными средствами на некоторых из своих конечных точек и нуждаться в способе сообщить контроллеру MGC об этом. Для управления протокол MGCP предоставляет следующие четыре команды:
     AuditConnection (AUCX)
     AuditEndpoint (AUEP)
     Restartln-Progress (RSIP)
     EndpointConf iguration(EPCF)

Команда CreateConnection (CRCX)

Как и следует из ее названия (CreateConnection — СоздатьСоединение), эта команда создает соединение между двумя конечными точками. Параметры команды CreateConnection предоставляют информацию, необходимую шлюзу для создания соединения.

  • Идентификатор вызова (Call ID). Глобально уникальный параметр, назначаемый МСС. Все участвующие в вызове соединения совместно используют этот идентификатор.
  • Уведомляемый объект (Notified Entity — N). Этот необязательный параметр определяет, куда посылать уведомления.
  • Параметры локального соединения (Local Connection Options — L). Этот параметр описывает характеристики передачи данных, используемые при выполнении команды CreateConnection. Поля в этом параметре включают метод кодировки символов, период пакетирования, пропускную способность, тип обслуживания (Type of Service — ToS) и применение подавления эха. По умолчанию подавление эха выполняется всегда.
  • Режим (Mode — M). Этот параметр задает режим работы соединения, а именно дуплекс, только получение, только передача, неактивно и обратная связь.
  • Дескриптор отдаленного соединения (Remote Connection Descriptor — RC). Этот параметр указывает дескриптор для отдаленной стороны соединения, обычно для другой стороны сети IP. Этот параметр может иметь пустое значение, если информация об отдаленной стороне еще не известна.

Команда ModifyConnection (MDCX)

Команда ModifyConnection изменяет характеристики представления шлюза соединения или вызова. Для команды ModifyConnection допустимы те же самые параметры и поля, что и для команды CreateConnection, плюс параметр идентификатор соединения (Connection ID). Этот параметр уникально идентифицирует соединение в конечной точке. Используя команду ModifyConnection, можно изменять следующие параметры соединения: схема кодирования, период пакетирования, подавление эхо, а также активизировать и деактивизировать соединение.

Команда DeleteConnection (DLCX)

Агент вызова и шлюзы используют команду DeleteConnection для завершения соединения. Агенты вызова используют эту команду для завершения соединения между двумя конечными точками, а также для освобождения всех соединений, которые завершаются на данной конечной точке. Шлюз может использовать эту команду для разрыва соединения, если он обнаружит, что данная конечная точка больше не может посылать или получать звук. Если соединение разрывает шлюз, в сообщение включается код причины разрыва соединения. После того как соединение завершается, шлюз должен перевести конечную точку в неактивный режим, сделав ее таким образом доступной для последующего сеанса. Весьма ценным свойством команды DeleteConnection является то, что она возвращает статистику вызова. Список статистических данных, содержащихся в сообщении команды DeleteConnection, приведен в таблице:

Данные Описание
Послано пакетов Количество пакетов, посланных по соединению
Послано октетов Количество октетов, посланных по соединению
Получено пакетов Количество пакетов, полученных по соединению
Получено октетов Количество октетов, полученных по соединению
Потеряно пакетов Количество потерянных пакетов, выясненное по порядковым номерам
Дребезг Средняя задержка между пакетами в миллисекундах
Запаздывание Среднее запаздывание, в мс

Команда NotificationRequest (RQNT)

Контроллер MGC использует команду NotificationRequest для того, чтобы попросить шлюз послать уведомление об определенных событиях, происходящих на конечной точке. Двумя важнейшими параметрами этой команды являются требуемые события (Requested Events), код параметра R, и требуемые сигналы (Signal Requests), код параметра S. Прежде чем переходить к других параметрам, следует подробно рассмотреть параметры R и S. Параметр "требуемые события (R)" содержит список событий, о которых шлюз просит сообщить агента вызова. В списке могут быть указаны такие события, как тон факса и модема, продолжительность тона и выяснение того, лежит ли трубка и была ли она снята, сброс, зависимые от канала сигналы (Channel-Associated Signaling— CAS), мигание и DTMF (или импульсные цифры). Кроме того, каждое событие может квалифицировать запрошенное действие. Действия, когда они определены, кодируются как заключенный в круглые скобки список ключевых слов, разделяемый запятыми. Список кодов для различных действий приведен в таблице:

Действие Код
Уведомлять немедленно (Notify immediately) N
Накапливать (Accumulate) A
Обрабатывать согласно цифровой карте (Treat according to digit map) D
Перестановка (Swap) S
Игнорировать (Ignore) I
Хранить сигнал активным (Keep signal active) K
Встроенный запрос уведомления (Embedded notification request) E

Команда Notification (NTFY)

Шлюз посылает команду Notification на основании запрошенных событий и местонахождения отслеживаемых событий. Команда Notification содержит следующие параметры:

  • Уведомляемый объект (Notified Entity — N). Если присутствует, определяет, куда посылать уведомление. Если отсутствует, значит уведомление должно быть послано отправителю
  • Идентификатор запроса (Request Identifier — X). Аналогичен параметру идентификатор запроса команды NotificationRequest. Соотносит запрос с уведомлением.
  • Наблюдаемые события (Observed Events — О). Этот параметр содержит список событий, которые шлюз обнаруживает на основании запрашиваемого параметра события в более ранней команде Notif icationRequest, полученной от контроллера MGC.

Команда AuditConnection (AUCX)

Агенты вызова используют команду AuditConnection для получения информации о соединении. Эта команда содержит идентификатор конечной точки и идентификатор соединения, указывающие контролируемое расположение и соединение. К запрошенной информации относится следующая.

  • Идентификатор вызова (Call ID). Уникальный идентификатор вызова, к которому принадлежит контролируемое соединение.
  • Уведомляемый объект (Notified Entity — N). Текущий уведомляемый объект соединения.
  • Параметры локшьного соединения (Local Connection Options — L). Параметры, примененные к соединению в настоящий момент.
  • Режим (Mode — м). Текущий режим соединения.
  • Дескриптор отдаленного соединения (Remote Connection Descriptor— RC).Параметры SDP отдаленного объекта, используемые для соединения.
  • Дескриптор локального соединения (Local Connection Descriptor— LC). Шлюз, используемый для соединения.
  • Параметры соединения (Connection Parameters— Р). Текущее значение параметра контролируемого соединения.

Команда AuditEndpoint (AUEP)

Агент вызова может использовать команду AuditEndpoint для определения состояния конечной точки. Обычно это происходит при инициализации агента вызова при поиске состояния всех конечных точек, которыми он управляет. Этот запрос содержит параметр идентификатор конечной точки (Endpoint ID), который идентифицирует контролируемую конечную точку, и параметр запрошенная информация (Requested Information), содержащий следующие внутренние параметры:

  • Список конечных точек (endpoint list). Идентифицирует контролируемую конечную точку. Чтобы указать все конечные точки, соответствующие определенной схеме, можно использовать шаблон.
  • Уведомляемый объект (Notified Entity— N). Объект, уведомляемый об активных запросах.
  • Запрошенные события (Requested Events — R). Список событий, запрошенных в настоящий момент.
  • Цифровая карта (digit map). Текущая цифровая карта конечной точки.
  • Требуемые сигналы (Signal Requests — S). Список сигналов, которые в настоящее время применяются на конечной точке.
  • Идентификатор запроса (Request Identifier— X). Идентификатор последней команды Notif icationRequest, полученной конечной точкой.
  • Идентификаторы соединения (Connection Identifiers — I). Список текущих соединений, поддерживаемых определенной конечной точки.
  • События поиска (Detect Events — Т). Список событий, которые в настоящее время обнаруживаются в режиме карантина.
  • Параметры локального соединения (Local Connection Options — L). Список всех текущих значений, например период пакетирования и кодек. Этот параметр можно использовать для запроса пакета текущих событий, которые поддерживаются определенной конечной точкой.

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

Сообщения ответа MGCP

Все команды MGCP следует подтверждать. Подтверждение несет код возврата, который указывает состояние команды. Код возврата (return code) — это целое число, для которого определены четыре диапазона значений:

  1. значения от 100 до 199 означают предварительный ответ;
  2. значения от 200 до 299 означают успешное завершение;
  3. значения от 400 до 499 означают нерезидентную ошибку;
  4. значения от 500 до 599 означают постоянную ошибку.
Список кодов возврата и их описания
Код возврата Описание
100 Команда в настоящее время выполняется. Финальный ответ будет позже
200 Нормальное выполнение транзакции
250 Соединение было удалено
400 Неспособность выполнять транзакцию из-за нерезидентной ошибки
401 Трубка телефона уже снята
402 Трубка телефона уже лежит
500 Неспособность выполнить транзакцию, поскольку конечная точка неизвестна
501 Неспособность выполнить транзакцию, поскольку конечная точка не готова
502 Неспособность выполнить транзакцию из-за нехватки ресурсов конечной точки
510 Неспособность выполнить транзакцию из-за обнаружения ошибок протокола
511 Неспособность выполнить транзакцию из-за того, что запрос содержит неизвестное расширение
512 Неспособность выполнить транзакцию из-за невозможности шлюза обнаружить одно из запрошенных событий
513 Неспособность выполнить транзакцию из-за невозможности шлюза создать один из запрошенных сигналов
514 Неспособность выполнить транзакцию из-за невозможности шлюза послать определенное уведомление
515 Транзакция относится к неверному идентификатору соединения
516 Транзакция относится к неизвестному идентификатору вызова
517 Неподдерживаемый режим
518 Неподдерживаемый пакет событий
519 Шлюз не имеет цифровой карты
520 Невозможность завершать транзакцию из-за перезапуска конечной точки
522 Нет такого события или сигнала
523 Неизвестное действие или комбинация действий
524 Несогласованность с локальными параметрами соединения