Материал: IP Телефония_Гольдштейн_1-4 части

15.После окончания разговорной фазы начинается фаза разруше ния соединения. Оборудование пользователя, инициирующего разрушение соединения, должно прекратить передачу речевой информации, закрыть логические каналы и передать сообщение RELEASE COMPLETE, после чего сигнальный канал закрывается.

16.Контроллер шлюзов передает сообщение RELEASE к АТС А c це лью завершения соединения.

17.Кроме того, контроллер передает к шлюзу команду DLCX.

18.Шлюз подтверждает завершение соединения и передает к кон троллерусобранныезавремясоединениястатистическиеданные.

19.После вышеописанных действий контроллер и оконечное обо рудование извещают привратник об освобождении занимавшей ся полосы пропускания. С этой целью каждый из участников со единения посылает привратнику по каналу RAS запрос выхода из соединения DRQ, на который привратник должен передать подтверждение DCF.

20.От АТС А приходит подтверждение разъединения RLC, после чего соединение считается разрушенным.

Следует заметить, что алгоритм взаимодействия протоколов SIP и MGCP не сильно отличается от вышеописанного алгоритма.

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

Международный союз электросвязи в проекте версии 4 рекомен дации Н.323 ввел принцип декомпозиции шлюзов. Управление функ циональными блоками распределенного шлюза будет осуществлять ся контроллером шлюза – Media Gateway Controller – при помощи адаптированного к H.323 протокола MEGACO, который в рекомен дации Н.248 назван Gateway Control Protocol.

Сообщения протокола MEGACO отличаются от сообщений про токола MGCP, но процедуры установления и разрушения соедине ний с использованием обоих протоколов идентичны, поэтому опи сание процедуры установления соединения на базе протокола MEGA CO здесь не приводится. Эти процедуры, вместе с детальным ана лизом протокола MEGACO, рассматриваются в главе 9.

1.5.4Сравнение подходов к построению сети IP,телефонии

Внастоящее время для построения хорошо функционирующих

исовместимых с ТфОП сетей IP телефонии подходят протоколы Н.323 и MGCP. Как уже отмечалось, протокол SIP несколько хуже взаи модействует с системами сигнализации, используемыми в ТфОП (сравнительный анализ протоколов H.323 и SIP приведен в главе 7).

Подход, основанный на использовании протокола MGCP, обладает весьма важным преимуществом перед подходом, предложенным ITU в рекомендации H.323: поддержка контроллером шлюзов сигнали зации ОКС7 и других видов сигнализации, а также прозрачная транс ляция сигнальной информации по сети IP телефонии. В сети, постро енной на базе рекомендации Н.323, сигнализация ОКС7, как и любая другая сигнализация, конвертируется шлюзом в сигнальные сооб щения Н.225.0 (Q.931).

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

Стоит также отметить, что в существующих приложениях IP теле фонии, таких как предоставление услуг международной и междуго родной связи, использовать протокол MGCP (так же, как и протокол SIP) нецелесообразно в связи с тем, что подавляющее количество сетей IP телефонии сегодня построено на базе протокола H.323. Оператору придется строить отдельную сеть IP телефонии на базе протокола MGCP (или SIP), что связано со значительными капитало вложениями. В то же время, оператор связи, имеющий оборудова ние стандарта H.323, может присоединиться к существующим сетям IP телефонии.

В последнем из упомянутых подходов (в проекте версии 4 реко мендации Н.323) ITU T ввел принцип декомпозиции шлюзов, исполь зованный в третьем подходе. Управление функциональными блока ми распределенного шлюза будет осуществляться контроллером шлюза – MGC (Media Gateway Controller) при помощи протокола MEGACO/Н.248. В проекте версии 4 рекомендации Н.323 предусмот рена также возможность прозрачной передачи сигнализации ОКС7 и других видов сигнализации по сетям IP телефонии и обработка сигнализации всех видов привратником без преобразования в сиг нальные сообщения Н.225.0.

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

Глава 2 Сетевые аспекты IP телефонии

2.1 Три основных сценария IP телефонии

Материал предыдущей главы дал в первом приближении ответ на вопрос: что такое IP телефония? Прежде чем обсудить более под робно различные подходы к архитектуре, протоколам и вариантам построения систем и оборудования, полезно обратить внимание на другой вопрос: для чего нужна IP телефония? В качестве ответа на этот вопрос рассмотрим три наиболее часто используемых сцена рия IP телефонии:

•«компьютер компьютер»;

•«компьютер телефон»;

•«телефон телефон».

Сценарий «компьютер компьютер» реализуется на базе стандарт ных компьютеров, оснащенных средствами мультимедиа и подклю ченных к сети Интернет.

Компоненты модели IP телефонии по сценарию «компьютер ком пьютер» показаны на рис. 2.1. В этом сценарии аналоговые речевые сигналы от микрофона абонента А преобразуются в цифровую форму с помощью аналого цифрового преобразователя (АЦП), обычно при 8000 отсчетов/с, 8 битов/отсчет, в итоге – 64 Кбит/с. Отсчеты речевых данных в цифровой форме затем сжимаются кодирующим устройст вом для сокращения нужной для их передачи полосы в отношении 4:1, 8:1или10:1.Алгоритмысжатияречиподробнорассматриваютсяв сле дующей главе. Выходные данные после сжатия формируются в паке ты, к которым добавляются заголовки протоколов, после чего пакеты