Глава 9 Протокол MEGACO/H.248

9.1 История создания и особенности протокола MEGACO/H.248

Рабочая группа MEGACO комитета IETF, продолжая исследования, направленные на усовершенствование протокола управления шлюзами, создала более функциональный (по сравнению с рассмотренным в предыдущей главе протоколом MGCP) протокол MEGACO. Но разработкой протоколов управления транспортными шлюзами, кроме комитета IETF, занималась еще и исследовательская группа SG 16 Международного союза электросвязи. Так, в проекте 4-й версии рекомендации Н.323 ITU-T ввел принцип декомпозиции шлюзов, уже описанный с той или иной степенью детализации в главах 1, 2 и 8. Важной особенностью нововведения ITU-T явилось то, что управление транспортными шлюзами - Media Gateway (MG) - осуществляется контроллером транспортных шлюзов - Media Gateway Controller (MGC) - при помощи протокола MEGACO, адаптированного под сетевое окружение Н.323. Спецификации адаптированного протокола приведены в недавно утвержденной рекомендации ITU-T H.248. В данной книге этот протокол называется MEGACO/H.248, так как авторам не хотелось бы умалить чьи-либо заслуги в разработке и адаптации этого протокола. На рис. 9.1. представлено дерево эволюции протокола MEGACO/H.248.

Рассмотрим кратко основные особенности протокола MEGACO/ H.248. Для переноса сигнальных сообщений MEGACO/H.248 могут использоваться протоколы UDP, TCP, SCTP или транспортная технология ATM. Поддержка для этих целей протокола UDP - одно из обязательных требований к контроллеру шлюзов. Протокол TCP должен поддерживаться и контроллером, и транспортным шлюзом, а поддержка протокола SCTP, так же, как и технологии ATM, является необязательной.

Рис. 9.1 Дерево эволюции протокола MEGACO/H.248

Еще одной особенностью протокола MEGACO/H.248 является то, что сообщения этого протокола могут кодироваться двумя способами. Комитет IETF предложил текстовый способ кодирования сигнальной информации, а для описания сеанса связи предложил использовать протокол SDP. ITU-T предусматривает бинарный способ представления сигнальной информации - ASN. 1, а для описания сеансов связи рекомендует специальный инструмент - Tag-length-value (TLV). Контроллер шлюза должен поддерживать оба способа кодирования, в то время как шлюз - только один из этих способов.

9.2 Модель процесса обслуживания вызова

При описании алгоритма установления соединения с использованием протокола MEGACO комитет IETF опирается на специальную модель процесса обслуживания вызова, отличную от модели MGCP. Протокол MEGACO оперирует с двумя логическими объектами внутри транспортного шлюза: порт (termination) и контекст (context), которыми может управлять контроллер шлюза. Пример модели процесса обслуживания вызова приведен на рис. 9.2.

Порты являются источниками и приемниками речевой информации. Определено два вида портов: физические и виртуальные. Физические порты, существующие постоянно с момента конфигурации шлюза, это аналоговые телефонные интерфейсы оборудования, поддерживающие одно телефонное соединение, или цифровые каналы, также поддерживающие одно телефонное соединение и сгруппированные по принципу временного разделения каналов в тракт Е1. Виртуальные порты, существующие только в течение разговорной сессии, являются портами со стороны IP сети (RTP-порты), через которые ведутся передача и прием пакетов RTP.

Рис. 9.2 Примеры модели процесса обслуживания вызова

Виртуальные порты создаются шлюзом при получении от контроллера команды Add и ликвидируются при получении команды Subtract, тогда как физические порты при получении команды Add или Subtract, соответственно, выводятся из нулевого контекста или возвращаются обратно в нулевой контекст.

Порт имеет уникальный идентификатор (TerminationID), который назначается шлюзом при конфигурации порта. Например, идентификатором порта может служить номер тракта Е1 и номер временного канала внутри тракта. Иногда команды могут относиться ко всему шлюзу, тогда используется специальный идентификатор порта (TerminationID) - «Root».

Порты обладают рядом свойств (properties), каждое из которых имеет уникальный идентификатор (propertylD). Например, порты могут обладать свойствами генерировать речевые подсказки, акустические и вызывные сигналы, а также детектировать сигналы DTMF.

При создании портов некоторые свойства присваиваются им по умолчанию. При помощи протокола MEGACO контроллер может изменять свойства портов шлюза. Свойства портов группируются в дескрипторы, которые включаются в команды управления портами (таблица 9.1).

Таблица 9.1 Дескрипторы протокола MEGACO

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

В общем случае для присоединения порта к контексту служит команда Add. При этом, если контроллер не специфицирует существующий контекст, к которому должен быть добавлен порт, то шлюз создает новый контекст.

Если шлюз поддерживает конференцию, то контекст определяет топологию связей между портами, участвующими в конференции, то есть возможные направления потоков информации для каждой пары портов. Примеры топологий, поддерживаемых протоколом MEGACO/H.323, приведены на рис. 9.3.

Вариант 1

Вариант 2

Вариант 3

Вариант 4

Вариант 5

Вариант 6

Рис. 9.3 Варианты топологии связей между портами внутри одного контекста

 Краткое описание вариантов топологии связей в конференции, представленных на рис. 9.3, сведено в таблицу 9.2. 

Таблица 9.2 Описание вариантов топологии

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

9.3 Сравнительный анализ протоколов MGCP и MEGACO

Цель данного параграфа - определить, в чем сходны и чем различаются протоколы MGCP и MEGACO. Начнем с общих черт протоколов.

Оба протокола используются в сетях с одинаковой архитектурой, где транспортными шлюзами управляют высокоинтеллектуальные контроллеры. Оба протокола умеют работать со шлюзами одних и тех же видов, классификация шлюзов была дана в предыдущей главе. Порты шлюзов поддерживают детектирование одних и тех же событий и генерацию одних и тех же сигналов. Используются одинаковые транспортные механизмы для доставки сообщений систем сигнализации ОКС7, DSS1, ВСК. Процедуры установления и разрушения соединений, реализуемые обоими протоколами, идентичны. Кроме того, используются одинаковые механизмы поддержания защиты сети. На этом сходство протоколов MGCP и MEGACO/H.248 заканчивается.

Самым важным отличием протокола MEGACO/H.248 от протокола MGCP является использование иной модели организации связи. Протокол MEGACO/H.248 работает не только с телефонными портами, но и UDP-портами. Кроме того, connection в модели MGCP - это, в общем случае, подключение к соединению между портами разного оборудования, в то время как context в модели MEGACO/H.248 всегда отображает связь между портами одного шлюза (рис. 9.4).

Рис. 9.4 Модели MGCP и MEGACO/H.248

Меняя топологию связей портов, относящихся к одному контексту, при помощи протокола MEGACO контроллер может гибко управлять конференциями. Данной возможности в протоколе MGCP не предусмотрено.

Выше уже отмечалось, что для протокола MEGACO/H.248 предусмотрено два способа кодирования, тогда как сообщения протокола MGCP представляются в текстовом формате, а бинарный способ кодирования не поддерживается. Кроме того, в протоколах используются разные параметры команд и коды ошибок.

Протокол MEGACO/H.248, так же, как и протокол MGCP, предусматривает корреляцию команд и ответов. Но если в протоколе MGCP транзакция образуется из команды и ответа на нее, то в протоколе MEGACO/H.248 транзакция состоит из запроса - совокупности акций и отклика на запрос. Общая структура запроса выглядит так:

TransactionRequest(Transactionid {

ContextiD {Command ... Command),

ContextiD {Command ... Command } })

Общая структура отклика на запрос приведена ниже:

TransactionReply(TransactionID {

ContextiD { Response ... Response },

ContextiD { Response ... Response } })

Каждая акция, в свою очередь, состоит из одной или нескольких команд, относящихся к одному контексту, и ответов на них (Рис. 9.5). Использование такого инструмента позволяет значительно уменьшить объем передаваемой сигнальной информации и увеличить скорость установления соединений за счет того, что контроллер может параллельно вести обработку сигнальной информации, относящейся к разным соединениям.

Аналоги двух избыточных команд EndpointConfiguration и Notifica-tionRequest протокола MGCP в протоколе MEGACO/H.248 отсутствуют, но, в тоже время, добавлена команда Move, позволяющая в одно действие перевести порт из одного контекста в другой. В качестве примера использования команды Move приведем сценарий дополнительных услуг «Уведомление о входящем вызове и перевод существующего соединения в режим удержания», англоязычное название услуг - Call Waiting и Call Hold.

Рис. 9.5 Транзакция протокола MEGACO/H.248

Абонент А разговаривает с абонентом В, а абонент С вызывает абонента А, при этом вызываемому абоненту передается акустическое уведомление о входящем вызове (рис. 9.6). Далее абонент А переводит соединение с абонентом В в режим удержания и соединяется с абонентом С (рис. 9.7). Реализация комбинации дополнительных услуг Call Waiting и Call Hold, т.е. передача порта из одного контекста в другой, стала возможной благодаря команде Move.

Рис. 9.6 Сценарий реализации услуги Call Waiting

В заключение данного параграфа хотелось бы отметить, что неизвестно, как скоро понадобится расширенная, по сравнению с MGCP, функциональность протокола MEGACO/H.248. Кроме того, на базе протокола MGCP построен ряд сетей IP-телефонии. Все это означает, что оба протокола MGCP и MEGACO/H.248 вполне могут совместно использоваться в одной сети.

Рис. 9.7 Сценарий реализации услуги Call Hold

9.4 Структура команд и ответов

Далее идет описание команд, которые используются для манипулирования двумя основными объектами протокола MEGACO/H.248:

портами и контекстами. В большинстве случаев команды передает контроллер, но существу ют два исключения: команда Notify, передается шлюзом, а команда ServiceChange может передаваться и шлюзом, и контроллером. В квадратных скобках указаны необязательные дескрипторы команд. Те дескрипторы, которые расположены над командами, передаются в ответах на команды.

Команда Add добавляет порт к контексту. Если команда относится к первому порту, который должен быть добавлен к контексту, то создается новый контекст.

[TerminationID] ,MediaDescriptor] ,ModeinDescriptor] ,MuxDescriptor] ,EventsDescriptor] ,SignalsDescriptor] ,DigitMapDescriptor] ,ObservedEventsDescriptor] ,StatisticsDescriptor] ,PackagesDescriptor] Add( TerminationID

MediaDescriptor]

ModemDescriptor]

MuxDescriptor]

EventsDescriptor]

SignalsDescriptor]

DigitMapDescriptor]

AuditDescriptor] ),

где TerminationID - это идентификатор порта, который должен быть добавлен к контексту. Для уже существующего порта должен быть указан его идентификатор, для несуществующего порта должен быть указан идентификатор «$». В ответе на команду должен передаваться TerminationID, назначенный шлюзом.

MediaDescriptor - необязательный дескриптор, описывающий информационные потоки.

ModemDescriptor - необязательный дескриптор, описывающий тип модема, который должен быть подключен к контексту.

MuxDescriptor - необязательный дескриптор, содержащий список портов, которые должны быть подключены к контексту.

EventsDescriptor - необязательный дескриптор, определяющий список событий, при детектировании которых порт должен оповестить контроллер.

SignalsDescriptor - необязательный дескриптор, определяющий сигналы, которые порт должен передавать в канал.

DigitMapDescriptor- необязательный дескриптор, определяющий план нумерации, который должен быть использован для соединения.

AuditDescriptor - необязательный дескриптор, специфицирующий параметры порта, которые должны быть переданы шлюзом контроллеру.

PackagesDescriptor - необязательный дескриптор, описывающий пакет поддерживаемых сигналов и событий.

Команда Modify изменяет свойства, события или сигналы для существующего порта.

[TerminationID] MediaDescriptor] ModemDescriptor] MuxDescriptor] EventsDescriptor] SignalsDescriptor] DigitMapDescriptor] ObservedEventsDescriptor] StatisticsDescriptor] PackagesDescriptor]

Modify( TerminationID

[ MediaDescriptor]

[ ModemDescriptor]

[ MuxDescriptor]

[ EventsDescriptor]

[ SignalsDescriptor]

[ DigitMapDescriptor]

[ AuditDescriptor] )

Если команда относится к конкретному порту шлюза, участвующего в контексте, то должен быть указан идентификатор порта.

В команде Modify используются такие же дескрипторы, как и в команде Add.

Команда Subtract отключает порт от существующего контекста.

[TerminationID]

,MediaDescriptorJ            ^^—•/ ,ModemDescriptor] ,MuxDescriptor] ,EventsDescriptor] ,SignalsDescriptor] ,DigitMapDescriptor] ,ObservedEventsDescriptor] ,StatisticsDescriptor] ,PackagesDescriptor]

Subtract(TerminationID

[, AuditDescriptor] )

где TerminationID - идентификатор порта, который должен быть отсоединен от контекста. В случае отключения всех портов от контекста используется TerminationID «*».

В ответ на команду Subtract в дескрипторе StatisticsDescriptor шлюз посылает статистику, собранную за время соединения.

Команда Move переводит порт из текущего контекста в другой контекст в одно действие.

[TerminationID] [ MediaDescriptor] ModemDescriptor] MuxDescriptor] EventsDescriptor] SignalsDescriptor] DigitMapDescriptor] ObservedEventsDescriptor] StatisticsDescriptor] PackagesDescriptor] Move( TerminationID

MediaDescriptor] ModemDescriptor] MuxDescriptor] EventsDescriptor] SignalsDescriptor] DigitMapDescriptor] AuditDescriptor] )

где TerminationID - идентификатор порта, который должен быть переведен из одного контекста в другой. Дескрипторы здесь используются такие же, как в команде Modify.

При помощи команды AuditValue контроллер запрашивает сведения о свойствах порта, произошедших событиях или сигналах, передаваемых в канал, а также статистику, собранную на текущий момент.

[TerminationID] MediaDescriptor] ModemDescriptor] MuxDescriptor] EventsDescriptor] SignalsDescriptor] DigitMapDescriptor] ObservedEventsDescriptor] StatisticsDescriptor] PackagesDescriptor]

AuditValue(TerminationID,

AuditDescriptor )

В ответ на команду передаются запрашиваемые параметры порта или портов шлюза.

При помощи команды AuditCapabilities контроллер запрашивает возможные значения свойств порта, список событий, которые могут быть обнаружены портом, список сигналов, которые порт может передавать в канал, статические данные.

[TenninationID] MediaDescriptor] ModemDescriptor] MuxDescriptor] EventsDescriptor] SignalsDescriptor] DigitMapDescriptor] ObservedEventsDescriptor] StatisticsDescriptor] PackagesDescriptor]

AuditCapabilities(TenninationID,

.AuditDescriptor )

В ответ на команду передаются запрашиваемые параметры порта.

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

Notify(TenninationID,

ObservedEventsDescriptor ),

где TerminationID идентифицирует порт, передавший команду Notify.

ObservedEventsDescriptor-дескриптор, содержащий список произошедших событий (в том порядке, в каком они происходили).

Команда ServiceChange позволяет шлюзу известить контроллер о том, что порт или группа портов вышли из обслуживания или вернулись в обслуживание. Media Gateway Controller может предписать порту выйти из обслуживания или вернуться в обслуживание. При помощи данной команды контроллер может передать управление шлюзом другому контроллеру.

[ServiceChangeDescriptor]

ServiceChange(TerminationID

,ServiceDescriptor ),

где TerminationID идентифицирует порт или порты, вышедшие из обслуживания или вернувшиеся в обслуживание. Значение «Root» дескриптора TerminationID показывает, что весь шлюз вышел из обслуживания или вернулся в обслуживание.

ServiceDescriptor - дескриптор, содержащий поля со сведениями: о методе изменения состояния; причине изменения; задержке;

адресе, куда должны передаваться сообщения; профиле поддерживаемого протокола и другие поля.

По аналогии с предыдущими главами, в таблицу 9.3 сведены все команды протокола MEGACO/H.248.

В заключение данного параграфа в таблице 9.4 приведены коды ошибок, используемые в протоколе MEGACO/H.248.

Таблица 9.3 Команды протокола MEGACO/H.248

Таблица 9.4 Коды ошибок

9.5 Пример установления и разрушения соединения

На рисунке 9.8 приведен пример установления соединения с использованием протокола MEGACO между двумя шлюзами (Residential Gateway), управляемыми одним контроллером.

Рис. 9.8 Алгоритм установления и разрушения соединения с помощью протокола MEGACO

В данном примере вызывающий шлюз MG1 - имеет IP-адрес 124.124.124.222, адрес вызываемого шлюза MG2 - 125.125.125.111, адрес контроллера шлюзов MGC - 123.123.123.4. Порт для связи по протоколу MEGACO для всех трех устройств по умолчанию имеет значение 55555.

1. Шлюз MG1 регистрируется у контроллера MGC при помощи команды ServiceChange. Использование нулевого контекста означает, что порт в настоящий момент не участвует ни в каком соединении, а использование идентификатора порта ROOT означает, что команда относится ко всему шлюзу, а не к какому-нибудь определенному порту.

MGl to MGC:

MEGACO/1.0 [124.124.124.222] Transaction = 9998 { Context = - {

ServiceChange = ROOT {Services {

Method=Restart, Port=55555, Pro£ile=ResGW/1.0) }

)

2. Контроллер подтверждает регистрацию шлюза:

MGC to MGl:

MEGACO/1.0 [123.123.123.41:55555 Reply = 9998 {

Context = - {ServiceChange = ROOT { Servicee { Port=55555, Profile=ResGW/1.0} )

)

3. Шлюз имеет свободные аналоговые порты, которые должны быть запрограммированы для отслеживания изменения сопротивления абонентского шлейфа, означающего поднятие абонентом трубки, после чего шлюз должен передать абоненту акустический сигнал «Ответ станции». Программирование производится при помощи команды Modify с соответствующими параметрами, причем программируется порт, находящийся в нулевом контексте. В команде указывается идентификатор порта (terminationid) -А4444, идентификатор информационного потока (streamid) -1, транспортный адрес оборудования, передавшего команду - [123.123.123.4] :55555, специфицируется режим функционирования -дуплексный (SendReceive).

MGC to MGl:

MEGACO/1.0 [123.123.123.4]:55555 Transaction = 9999 { Context = - {

Modify = A4444 { Media {

TerminationState {

Buf feredEventHandling{Step,Procese}

}, Stream = 1 {

LocalControl {

Mode = SendReceive, g/GainControl=2, ; in dB, g/Encryption=xxx, g/EchoCancellation=Gl65, g/VoiceActDet=yes )

),

Events в 2222 {glinesup/offhook}

Signals {g/PlayTone{tone=dialtone} ) ) 

На этом же этапе в шлюз может быть загружен план нумерации (в дескрипторе digit map). В этом случае, после того как абонент поднимет трубку, шлюз должен передать ему акустический сигнал «Ответ станции» и начинать прием сигналов DTMF в соответствии с планом нумерации. Однако в нашем примере план нумерации будет загружен только после того, как абонент поднимет трубку, на 8 шаге.

Кроме того, следует отметить, что шаги 3 и 4 данного алгоритма могут быть совмещены с шагами 8 и 9, соответственно, при помощи дескриптора EventsDescriptor. При этом шаги 6 и 7 опускаются.

4. Шлюз MG1 подтверждает выполнение команды Modify:

mgi to mgc:

MEGACO/l.O [124.124.124.222]:55555 Reply = 9999 {

Context = - {Modify} >

5. Подобным же образом (шаги 1-4) программируется аналоговый порт шлюза MG2, в нашем примере имеющий идентификатор А5555.

6. Далее шлюз MG1 обнаруживает, что абонент А поднял трубку, и извещает об этом событии Media Gateway Controller при помощи команды Notify. mgi to mgc:

MEGACO/l.O [124.124.124.222]:55555 Transaction = 10000 { Context = - {

Notify = A4444 {ObservedEvents =2222 {

19990729T22000000:glinesup/offhook} > ) )

7. Контроллер подтверждает получение команды Notify:

mgc to mgi;

MEGACO/l.O [123.123.123.4]$55555 Reply = 10000 {

Context = - (Notify) )

8. На следующем шаге MGC дает шлюзу инструкцию накапливать цифры номера вызываемого абонента в соответствии с выбранным планом нумерации. Кроме того, после получения первой цифры номера необходимо остановить передачу акустического сигнала «Ответ станции».

14. Контроллер MGC создает в шлюзе MG2 контекст для установления дуплексного соединения (режим SendReceive) с вызывающим пользователем.

MGC to MG2:

MEGACO/1.0 [123.123.123.4]:55555 Transaction = 50003 { Context = $ {

Add = A5555 { Media {

Stream • 1 { )

),

Add = $ { Media {

Stream = 1 {

LocalControl {

Mode = SendReceive, g/NetworkType = RTP/IP4, g/MaxJitterBuffer=40, ; in ms g/PreferredPacketization=30, ; in ms g/PreferredEncoders =[G723, PCMU], g/PreferredDecoders=[G723, PCMU] , g/Gain=0 ; in dB ),

Remote=SDP{ v=0

c=IN IP4 124.124.124.222 m=audio 2222 RTP/AVP 4 0 a=sendrecv

} ; RTF profile for G.723 is 4 ) )

> 

15. Создание контекста подтверждается, физический порт шлюза MG2 A5555 соединяется с UDP/RTP портом, имеющим идентификатор А5556. Отметим, что RTP-порт имеет номер 1111, т.е. отличный от номера порта Megaco/H.248 - 55555.

MG2 to MGC:

MEGACO/1.0 [124.124.124.2221:55555 Reply = 50003 {

Context = 5000 { Add, Add = А5556{ Media {

Stream = 1 {

Local • SDP { v=0

c=IN IP4 125.125.125.1111 m=audio 1111 RTP/AVP 4 0 a=sendreceive }

} ; RTF profile for G723 is 4 )

)

16. Контроллер MGC предписывает порту А5555 шлюза MG2 начать передачу вызывного сигнала.

MGC to MG2:

MEGACO/1.0 [123.123.123.41:55555 Transaction = 50004 { Context = 5000 {

Modify = А5555 {

Signals {glinesup/PlayTone{tone=ring}} }

)

17. Шлюз MG2 подтверждает передачу сигнала «Посылка вызова» вызываемому абоненту.

MG2 to MGC:

MEGACO/1.0 [125.125.125.111]:55555 Reply = 50004 (

Context = 5000 {Modify} }

18. Контроллер предписывает шлюзу MG1 начать передачу вызывающему абоненту акустического сигнала «Контроль посылки вызова (КПВ)».

MGC to MG1:

MEGACO/1.0 [123.123.123.4]:55555 Transaction = 10005 { Context = 2000 {

Modify = A4444 {

Signals {g/PlayTone{tone=ringback}} }

}

19. Шлюз MG1 подтверждает передачу указанного акустического сигнала в порт A4444.

MG1 to MGC:

MEGACO/1.0 [124.124.124.222]:55555 Reply = 10005 {

Context = 2000 {Modify) )

На этом этапе обоим абонентам, участвующим в соединении, посылаются соответствующие сигналы, и шлюз MG2 ждет, пока вызываемый абонент примет входящий вызов, после чего между двумя шлюзами будут организованы двунаправленные разговорные каналы.

20. Шлюз MG2 обнаружил, что вызываемый абонент поднял трубку, и извещает об этом контроллер MGC.

MG2 to MGC:

MEGACO/1.0 [125.125.125.111]:55555 Transaction = 50005 { Context = 5000 {

Notify = А5555 {ObservedEvents =1234 {

19990729T22020002:glinesup/offhook)

)

) 

21. Контроллер подтверждает получение команды Notify.

MGC to MG2:

MBGACO/1.0 [123.123.123.41:55555 Reply = 50005 {

Context = - (Notify) )

22. Далее контроллер MGC предписывает шлюзу MG2 прекратить передачу вызывного сигнала.

MGC to MG2:

MEGACO/1.0 [123.123.123.4]:55555 Transaction = 50006 { Context = 5000 {

Modify = A5555 {

Events = 1235 {glinesup/onhook}, Signals {g/StopTone} ; to turn off ringing )

)

23. Шлюз MG2 подтверждает выполнение команды.

MG2 to MGC:

MEGACO/1.0 [125.125.125.111]:55555 Reply = 50006 {

Context = 5000 {Modify} )

24. Далее, контроллер разрешает шлюзу MG1 не только принимать, но и передавать информацию (режим SendReceive), и останавливает передачу вызывающему абоненту акустического сигнала «КПВ».

MGC to MG1:

MEGACO/1.0 [123.123.123.41:55555 Transaction = 10006 { Context = 2000 {

Modify = A4445 { Media {

Stream = 1 {

LocalControl {

Mode=SendReceive }

,, } /}

Modify = A4444 {

Signals { g/StopTone} ) } >

25. Шлюз MG1 подтверждает выполнение команды.

MG1 to MGC:

MEGACO/1.0 [124.124.124.222]:55555 Reply = 10006 {

Context s 2000 {Modify, Modify»

26. После этого начинается разговорная фаза соединения, в течение которой участники обмениваются речевой информацией. Следующим шагом контроллер MGC принимает решение проверить РТР-порт в шлюзе MG2.

HOC to MG2:

MEGACO/1.0 [123.123.123.4]:55555 Transaction = 50007 {

Context = - {AuditValue = A5556{

AuditOtodia, Digit-Map, Events, Signals, Packages, Statietice }}

} }

27. Шлюз MG2 выполняет команду. В ответе на команду AuditValue передается вся запрашиваемая информация, в том числе статистика, собранная за время соединения. Кроме того, из ответа видно, что не произошло никаких событий и не передавалось никаких сигналов.

MEGACO/1.0 [125.125.125.111]:55555 Reply = 50007 { Context = - {

AuditValue ( Media {

TerminationState {

BufferedEventHandling{Process} }, Stream = 1 {

LocalControl {

Mode = SendReceive, g/MaxJitterBuffer=40, ; in ms g/PreferredPacketization=30, ; in me g/PreferredEncoders =[G723, PCMU], g/PreferredDecoders=[G723, PCMU], g/Gain=0 ; in dB ), Local = SDP {

v=0

c=IN IP4 125.125.125.111 m=audio 1111 rtp/avp 4 0 a=sendrecv }, Remote = SDP{

v=0

c=IN IP4 124.124.124.222 m=audio 2222 RTP/AVP 4 0 a=sendrecv

} ; RTF profile for G.723 is 4 ) ), Packages {g, glinesup/ RTPPkg),

Statistics { RTPPkg/PacketsSent=1200, RTPPkg/OctetsSent=62300, RTPPkg/PacketsReceived=700, RTPPkg/OctetsReceived=45100, RTPPkg/PacketsLost=6, RTPPkg/Jitter=20, RTPPkg/AverageLatency=40 } } } )

 28. Вызываемый абонент первым завершает соединение, и шлюз MG2 извещает об этом контроллер MGC.

MG2 to MGC:

MEGACO/1.0 [125.125.125.111]:55555 Transaction = 50008 { Context = 5000 {

Notify = A5555 {ObservedEvents =1235 {

19990729T24020002:glinesup/onhook) )

}

29. Контроллер MGC подтверждает получение сообщения Notify.

MGC to MG2:

MEGACO/1.0 [123.123.123.4]:55555 Reply = 50008 {

Context = - {Notify} }

30. Получив информацию от любого из шлюзов о том, что один из абонентов положил трубку, контроллер MGC завершает соединение. К обоим шлюзам передается команда Subtract. Алгоритм завершения соединения предусматривает одинаковый обмен сигнальными сообщениями между контроллером и обоими шлюзами, поэтому здесь этот алгоритм рассматривается на примере шлюза MG2.

From MGC to MG2:

MEGACO/1.0 [123.123.123.4]:55555 Transaction = 50009 { Context = 5000 {

Subtract = A5555 {Audit{Statistics}}, Subtract = A5556 {Audit{Statistics}} ) }

31. Каждый из портов шлюза MG2, участвующих в соединении (физический порт - A5555 и RTP-порт - A5556), возвращает статистику, собранную за время соединения. В общем случае, контроллер может запрашивать статистическую информацию только у одного из портов.

From MG2 to MGC:

MEGACO/1.0 [125.125.125.H1] :55555 Reply = 50009 { Context = 5000 { Subtract {

Statistics { ; what are the stats for a TIM connection? TEMPkg/OctetsSent=45123, TEMPkg/Duration=40 ; in seconds } }. Subtract {

Statistics (

RTPPkg/PacketsSent=1245, RTPPkg/OctetsSent=62345/ RTPPkg/PacketsReceived=780, RTPPkg/OctetsReceived=45123, RTPPkg/PacketsLost=10, RTPPkg/Jitter=27, RTPPkg/AverageLatency=48 }

) 

32. После завершения соединения контроллер MGC предписывает шлюзам MG1 и MG2 быть готовыми к тому, что кто-то из обслуживаемых ими абонентов поднимет трубку. Примечательно, что портам шлюза, отображаемым окончаниями в нулевом контексте, по умолчанию может быть предписано обнаруживать, что абонент поднял трубку, при этом контроллер не передает шлюзам специальные команды, как это было показано ранее (шаг 3).