MGCP (MGCP)

MGCP или Media Gateway Control Protocol дословно — протокол управления медиашлюзами. Является протоколом связи в распределённых VoIP системах передачи голоса по протоколу IP.

MGCP описан в RFC 3435, который заменил устаревший к настоящему времени RFC 2705, заменивший, в свою очередь, Simple Gateway Control Protocol (SGCP).

Сходный протокол для тех же целей Megaco, совместная продукция IETF (RFC 3525) и ITU (рекомендации H.248-1). Оба протокола описаны единым аппаратно-программным интерфейсом (API) Архитектура и требования MGCP в RFC 2805.

Архитектура

Распределённые системы состоят из агента вызовов — Call Agent (или контроллера медиашлюза), по крайней мере одного медиашлюза (MG) и по крайней мере одного сигнального шлюза (SG), подключенных к Телефонной сети общего пользования (ТФОП). С точки зрения сети ОКС-7 такой симбиоз устройств рассматривается как один узел с одним общим пойнт-кодом.

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

В стандарте MGCP, описанном в RFC 2705 предлагается такая классификация телефонного оборудования по назначению:

Потоковый шлюз (англ. Trunking Gateway)— шлюз между ТфОП и сетью с маршрутизацией пакетов IP, ориентированный на подключение к телефонной сети посредством большого количества цифровых трактов (от 10 до нескольких тысяч) с использованием системы сигнализации ОКС 7;
Голосовой шлюз ATM (англ. Voice over ATM Gateway) — шлюз между ТфОП и АТМ-сетью, который также подключается к телефонной сети посредством большого количества цифровых трактов (от 10 до нескольких тысяч);
Домашний шлюз (англ. Residential Gateway) — шлюз, подключающий к IP-сети аналоговые, кабельные модемы, линии xDSL и широкополосные устройства беспроводного доступа;
Шлюз доступа (англ. Access Gateway) — шлюз для подключения к сети IP-телефонии небольшой учрежденческой АТС через аналоговый или цифровой интерфейс;
Бизнес-шлюз (англ. Business Gateway) — шлюз с цифровым интерфейсом для подключения к сети с маршрутизацией IP-пакетов учрежденческой АТС при использовании, например, системы сигнализации DSS1;
(англ. Network Access Server) — сервер доступа к IP-сети для передачи данных;
Канальный коммутатор и пакетный коммутатор (англ. Circuit switch и англ. packet switch) — коммутационные устройства с интерфейсом для управления от внешнего устройства.

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

Signaling Gateway (SG)

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

На практике сигнальный шлюз (SG) и медиашлюз (MG) могут быть подключены в один физический коммутатор, но это совсем не обязательно. Call Агент не использует MGCP для контроля сигнального шлюза (SG), для этих целей — обратной связи между сигнальным шлюзом (SG) и Агентом используются протоколы SIGTRAN.

Media Gateway (MG)

Медиашлюз выполняет функции преобразования речевой информации, поступающей со стороны ТфОП в голосовых каналах с постоянной скоростью передачи, в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP (кодирование и упаковку речевой информации в пакеты RTP, и далее в UDP и IP) а также обратное преобразование).

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

Call Agent

Call Агент - контроллер шлюзов, выполняет функции управления шлюзами, который использует протокол MGCP чтобы сообщать медиашлюзу:

какие события направлять Call Агенту
каким образом оконечные устройства должны соединяться друг с другом
какие тональные сигналы вызова должны воспроизводится на оконечных устройствах

MGCP позволяет также следить Call Агенту за состоянием оконечных устройств на медиашлюзе (MG).

Как правило, медиашлюз конфигурирован со списком Call Агентов, от которых может принимать инструкции-запросы.

В принципе, уведомления можно посылать разным Агентам от каждого оконечного устройства (как предусмотрено Call Агентами, для этого используется параметр NotifiedEntity). Практически однако, желательно, чтобы в данный момент всеми оконечными устройствами управлял один и тот контролер шлюзов; другие Call Агенты доступны в случае резервирования ресурсов для обеспечения избыточности, если первичный Агент отказывает, или теряет контакт с медиашлюзом. В случае такого отказа управление шлюзом автоматически переходит к резервному контролеру шлюзов. Всё о чём необходимо позаботиться для такого сценария, это обмен информацией о состоянии между двумя Агентами, однако, это не гарантирует, что оба не будут пытаться управлять одним и тем же шлюзом. Для разрешения конфликтов используется способность опрашивать шлюз, чтобы определить, который из Агентов является управляющим в данный момент.

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

Пакеты MGCP отличаются от многих других протоколов. Он резервирует обычно порт UDP 2427, датаграммы MGCP могут содержать и пустые значения, совсем не так как обычно строятся пакеты в протоколах TCP. Пакет MGCP является командой (запросом) или ответом. Команды (запросы) начинаются с четырехбуквенного кода, ответы начинаются с трехзначного цифрового кода.

В MGCP каждая команда несёт в себе идентификатор транзакции и получает ответ на каждую.

Список запросов содержит всего восемь команд: AUEP, AUCX, CRCX, DLCX, MDCX, NTFY, RQNT, RSIP.

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

AUEP — Audit Endpoint, аудит конечного устройства (медиа-канала на шлюзе)
AUCX — Audit Connection, аудит статуса соединения.

Три команды используются Call Агентом, чтобы управлять RTP соединением на медиа-шлюзе:

CRCX — Create Connection, создать соединение,
DLCX — Delete Connection, удалить соединение; шлюз может послать команду DLCX, когда нужно удалить соединение для самоуправления
MDCX — Modify Connection, изменить соединение. Используется для изменения характеристик соединения, например изменения голосовых кодеков, отключения передачи звука в одностороннем или двустороннем порядке или (например полу-дуплексная связь) и т.п.

Команда RQNT (Request for Notification) используется медиа шлюзом для запроса об уведомлениях используется агентом (CallAgent), чтобы запросить уведомление о событиях на медиашлюзе. В частности может использоваться для передачи сообщения о нажатой клавише в рамках тонального набора (в качестве альтернативного варианта вместо RFC 2833 или G.711-inband).

Команда NTFY (Notify) используется медиашлюзом, чтобы сообщить Агенту, что обнаружено событие, о котором Агент предварительно запросил уведомление (командой RQNT). Пример использования: переключение на другой тип передаваемых данных (с голоса на факс или наоборот).

Команда EPCF — Endpoint Configuration, используется медиашлюзом для уведомления CallAgent об необходимости изменении ожидаемых параметров кодирования со стороны линии оконечного устройства.

Команда RSIP — Restart In Progress, рестарт в процессе, используется медиашлюзом, чтобы указать Агенту, что идёт процесс перезапуска.

Примеры обмена сообщениями

Первый пример (из RFC 3435) показывает, команду CRCX (CreateConnection), создающую соединение с указанным оконечным устройством endpoint (aaln/[email protected], где rgw-2567.whatever.net является названием домена, а aaln/1 наименованием endpoint). Команда отправлена в контексте транзакции 1204. Соединение будет иметь определённый идентификатор CallID (A3C47F21456789F0). LocalConnectionOptions указывает, что будет использоваться кодек G.711 (PCM) по мю-закону и период пакетирования составит 10 мс. Режим работы соединения будет "receive only" (только получение):

CRCX 1204 aaln/[email protected] MGCP 1.0
C: A3C47F21456789F0
L: p:10, a:PCMU
M: recvonly

Код ответа 200 ОК означает, что операция прошла успешно, а для идентификации принадлежности ответа к команде отображается идентификатор транзакции (1204) для вновь созданного соединения. В сообщении приходит также описание формата сессии (SDP) для нового соединения, этому ему предшествует пустая строка:

200 1204 OK
I: FDE234C8
 
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 0

Второй пример (из RFC 3435) представляет команду ModifyConnection которая просто устанавливает режим соединения "send/receive" (отправка/получение) и также информирует что установлено "Notified entity".

MDCX 1209 aaln/[email protected] MGCP 1.0
C: A3C47F21456789F0
I: FDE234C8
N: [email protected]
M: sendrecv

Ответ означает, что транзакция выполнена успешно.

200 1209 OK

Теперь пример команды ModifyConnection, где передаётся принятое описание звонковой сессии (SDP) и запрос уведомления. Оконечное устройство (endpoint) начнёт проигрывать контроль посылки вызова абоненту (длинные гудки, ожидание ответа вызываемого).

MDCX 1210 aaln/[email protected] MGCP 1.0
C: A3C47F21456789F0
I: FDE234C8
M: recvonly
X: 0123456789AE
R: L/hu
S: G/rt
 
v=0
o=- 4723891 7428910 IN IP4 128.96.63.25
s=-
c=IN IP4 128.96.63.25
t=0 0
m=audio 3456 RTP/AVP 0

Ответ означает, что транзакция (1210) выполнена успешно.

200 1210 OK

RFC

RFC 3435 — Media Gateway Control Protocol (MGCP) Version 1.0 (this supersedes RFC 2705)
RFC 3660 — Basic Media Gateway Control Protocol (MGCP) Packages (informational)
RFC 3661 — Media Gateway Control Protocol (MGCP) Return Code Usage
RFC 3064 — MGCP CAS Packages
RFC 3149 — MGCP Business Phone Packages
RFC 3991 — Media Gateway Control Protocol (MGCP) Redirect and Reset Package
RFC 3992 — Media Gateway Control Protocol (MGCP) Lockstep State Reporting Mechanism
RFC 2805 — Media Gateway Control Protocol Architecture and Requirements

См. также