MGCP

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

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

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

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

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

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

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

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

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

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

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

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

CRCX 1204 aaln/1@rgw-2567.whatever.net 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/1@rgw-2567.whatever.net MGCP 1.0
C: A3C47F21456789F0
I: FDE234C8
N: ca@ca1.whatever.net
M: sendrecv

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

200 1209 OK

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

MDCX 1210 aaln/1@rgw-2567.whatever.net 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