Реферат Конвергенция сетей связи

Работа добавлена на сайт bukvasha.net: 2015-10-28

Поможем написать учебную работу

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

Предоплата всего

от 25%

Подписываем

договор

Имя

Выберите тип работы:

Принимаю Политику конфиденциальности

Скидка 25% при заказе до 9.11.2024

Конвергенция сетей связи

1.1. Пропорции в телекоммуникациях

Гуляя в тенистой роще, греческий философ Анаксимен беседовал со своим учеником. «Скажи мне, — спросил юноша, — почему тебя часто одолевают сомнения? Ты прожил долгую жизнь, умудрен опытом и учился у великих эллинов. Как же так вышло, что и для тебя осталось столь много неясных вопросов?». В ответ философ очертил посохом перед собой два круга: маленький и большой. «Твои знания — это маленький круг, а мои — большой. Но все, что осталось вне этих кругов, — неизвестность. Маленький круг c неизвестностью соприкасается мало. Чем шире круг твоих знаний, тем протяженнее его граница с неизвестностью. И впредь, чем больше ты будешь узнавать нового, тем больше у тебя будет возникать неясных вопросов».

Классическая телефония с ее традиционными телефонными услугами POTS (Plain Old Telephone Service), достаточно хорошо изученная за свою более чем столетнюю историю, соответствует малому кругу из этой поучительной притчи. Большой круг представляет нарождающуюся индустрию инфокоммуникаций, являющуюся результатом взаимопроникновения (конвергенции) информационных и телекоммуникационных технологий и услуг и действительно порождающую больше неясных вопросов, чем готовых ответов. Не планируя в этой главе (да и во всей книге) рассмотреть множество разнообразных аспектов инфокоммуникаций за исключением одного — IP-телефонии, — коснемся лишь их общей базы — телекоммуникаций.

Со времени своего возникновения телекоммуникации базируются на передаче электромагнитных сигналов через транспортную среду, каковой могут быть:

металлический кабель,
оптоволокно,
радиоканал.

Передаваемая в виде электромагнитных сигналов информация может представлять собой:

речь,
данные,
видеоизображение
или любую их комбинацию, называемую мультимедийной информацией.

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

Еще в 1996 г. в США трафик передачи данных впервые превысил речевой (рис. 1.1) и продолжает демонстрировать завидные темпы роста (до 30% в год по сравнению с 3% в год для телефонии). То же произошло в Европе в 1999 году. Все это послужило толчком к началу новой эры в телекоммуникациях — эры интегрированных решений и конвергенции всех видов связи. Протокол IP получил мировое признание и, в известной степени, стал «де-факто» стандартом для передачи мультимедийной информации.

Если добавить сюда феномен сети Интернет, где, по самым скромным подсчетам, рост числа пользователей составляет 5% в месяц, то станет совершенно ясно, что все эти события самым непосредственным образом влекут за собой коренное изменение подходов к построению информационных сетей. Речь и данные меняются местами. Традиционные сети передачи данных базировались на магистралях с коммутацией каналов, предназначенных для телефонного трафика. При новом подходе — все наоборот: телефония будет надстраиваться над инфраструктурой сети передачи данных.
Смещение центра тяжести в область передачи данных поставило вопрос о поиске удобного способа встраивания речи в мультимедийный цифровой поток. Причина популярности IP как раз и заключается в его восприимчивости к требованиям со стороны не только услуг передачи данных, но и приложений реального времени. Примером может служить успешно реализованная технология передачи речевой информации по сетям с маршрутизацией пакетов IP — Voice over IP (VolP) или IP-телефония.

Рост трафика Интернет (данные) и телефонного трафика

Рис. 1.1. Рост трафика Интернет (данные) и телефонного трафика

Но понятие Voice over IP подразумевает не только и не столько использование сети Интернет в качестве среды передачи речи, сколько сам протокол IP и технологии, обеспечивающие надежную и высококачественную передачу речевой информации в сетях пакетной коммутации. Отсутствие гарантированного качества обслуживания при передаче речи компенсируется появлением таких технологий, как многопротокольная коммутация по меткам — Multiprotocol Label Switching (MPLS), протокол резервирования ресурсов — Resource Reservation Protocol (RSVP), дифференциальное обслуживание разнотипного трафика — Differentiated Services (DiffServ) и других. Все большую популярность приобретает передача пакетов IP, упакованных в контейнеры систем синхронной цифровой иерархии — Synchronous Digital Hierarchy (SDH), а также технология спектрального мультиплексирования — Wave Division Multiplexing (WDM). Во всех случаях необходимым условием является подчинение каждого узла системы единой политике управления трафиком. Этому же призваны помочь протоколы RTP, RTSP, Diffentiaten Services и другие механизмы, рассматриваемые в следующих главах книги. Здесь же достаточно отметить, что стандартизация речевых технологий на основе стека TCP/IP и их поддержка лидерами рынка пакетной телефонии обеспечат совместимость оборудования разных производителей и позволят создавать системы, в которых возможны вызовы с аналогового телефонного аппарата, подключенного к порту маршрутизатора, на персональный компьютер, или с персонального компьютера на номер ТфОП, в рамках трех сценариев IP-телефонии, рассматриваемых в следующей главе.

1.2. Перспективы развития ТфОП и IP-сетей

Продолжая анализ роста трафика данных и речи, представленного в виде графиков на рис.1 в предыдущем параграфе , авторы позволили себе привести прогноз роста количества абонентов (графики на рис.1.2а). Суть прогноза отнюдь не в том, что количество пользователей сетей стационарной связи, мобильной связи и Интернет к 2004-2006 годам достигнет миллиарда, а в том, что емкости этих сетей сближаются. В контексте данной главы последнее обстоятельство, согласно закону диалектики о переходе количества в качество, приводит к принципиально новым мыслям по поводу конвергенции этих сетей. Немаловажным стимулом таких мыслей является прогноз общемировых доходов от телекоммуникационных услуг, сделанный Dataquest (рис. 1.26), графическое представление которого почти совпадает с верхней кривой на рис. 1.2а. Пороговая величина в этом прогнозе составляет триллион долларов США совокупного дохода по сегментам рынка (речь, данные, мобильная связь), а переход за этот порог ожидается еще раньше — в 2002-2003 гг.

Рост численности абонентов и доходы от телекоммуникационных услуг

Рис.1.2. Рост численности абонентов, их перераспределение (а) и общемировые показатели доходов от телекоммуникационных услуг по сегментам рынка (б)

Одним из аспектов, способствующих упомянутой выше конвергенции, является ключевой принцип отделения организации услуг от транспортировки информации, составляющий основу идеи Интеллектуальных сетей. Суть концепции Интеллектуальной сети (IN) заключается в построении универсальной среды, обеспечивающей наибольшую эффективность создания и предоставления новых телефонных услуг. Постепенно эта концепция стала средством глобального нагнетания вычислительной мощности в телефонную сеть общего пользования (ТфОП), о чем немало сказано в только что вышедшей монографии [8].

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

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

Рис.1.3 иллюстрирует эволюцию телекоммуникационных приложений на основе IP.

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

Тенденции развития телекоммуникационных услуг

Рис. 1.3. Тенденции развития телекоммуникационных услуг

Первоочередная цель конвергенции сетей на базе протокола IP — это снижение общих расходов, складывающихся не только из капитальных затрат на приобретение и инсталляцию телекоммуникационного оборудования, но и из затрат на его содержание. Теоретически одна объединенная сеть уменьшила бы потребность в квалифицированном персонале — одни и те же люди стали бы заниматься и телефонией, и системами передачи данных. Наличие всего одного канала доступа к распределенной сети тоже основательно снизило бы ежемесячные расходы. Направляя речевой трафик через корпоративную магистральную сеть передачи данных, можно существенно уменьшить затраты на традиционные телефонные услуги. И, наконец, сокращение единиц используемого оборудования значительно уменьшит стоимость его технического обслуживания. Как отметил представитель одного международного оператора связи, переход на технологию IP-телефонии позволит ему сэкономить порядка 70% средств на капитальные затраты, 60–80% средств, выделяемых на организацию каналов доступа, и 50% средств на текущее обслуживание и ремонт сети [13].

Однако экономия на стоимости инфраструктуры — это не то, ради чего замышлялся переход к объединенным сетям. Революция произойдет тогда, когда появятся новые приложения, например, когда центры обслуживания клиентов смогут в реальном времени «сопровождать» каждого покупателя с момента его появления на домашней странице компании в сети Интернет до оформления заказа на покупку нужного продукта, «проводя» его через такие этапы, как демонстрация каталога предлагаемых изделий и выяснение неясных вопросов в ходе телефонного общения с представителем компании. Другой пример применения новых технологий — использование сотрудниками телефонного сервиса своей корпоративной УАТС независимо от того, где он и находятся, например, при работе дома. Кэтим применениям IP-телефонии авторы вернутся в главе 11.

При всех оптимистических прогнозах, изложенных выше, не следует забывать, что традиционная телефонная связь опирается на мощную базу, создававшуюся на протяжении многих десятилетий, и такая система не может не обладать определенной инерцией. Исходя из этого, вряд ли стоит ожидать, что не сегодня-завтра произойдет мгновенный революционный скачок в области связи, и Интернет-телефония вытеснит все остальные технологии. Скорее наоборот: на протяжении ближайших 5-10 лет традиционная телефония будет по-прежнему занимать доминирующие позиции. Переход на новые, более прогрессивные методы будет происходить постепенно эволюционным путем, в разных странах с разной скоростью. А это значит, что в течение длительного времени ТфОП и IP-сети будут вынуждены существовать параллельно, обеспечивая взаимную прозрачность и объединяя свои усилия в обслуживании разнородного абонентского трафика.

Согласно известной формуле о невозможности находиться в каком-то обществе и быть вне его законов, при вхождении IP-телефонии в давно сформировавшееся глобальное телефонное общество необходимо соблюдение основных законов существующей ТфОП:

эксплуатационная надежность с тремя девятками после запятой, жесткие нормы качества передачи речи в реальном времени и т.п.

Не менее законов, правил и норм важны традиции, сформировавшиеся за более чем столетний период существования ТфОП. И. Губерманом дана точная формулировка важности традиций:

Владыка наш — традиция. А в ней — свои благословенья и препоны;
неписаные правила сильней, чем самые свирепые законы.

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

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

1.3. Транспортные технологии пакетной коммутации

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

Основные технологии пакетной передачи речи — Frame Relay, ATM и маршрутизация пакетов IP — различаются эффективностью использования каналов связи, степенью охвата разных участков сети, надежностью, управляемостью, защитой информации и доступа, а также стоимостью. Ограниченный объем книги не позволяет дать глубокий сравнительный анализ этих технологий с точки зрения передачи речи, поэтому здесь приводятся в наиболее компактной графической форме только результаты такого анализа (рис.1.4).

Речь по ATM

а) Речь по ATM

Речь по Frame Relay

б) Речь по Frame Relay

Речь по IP

в) Речь по IP

Рис. 1.4. Сравнение технологий пакетной передачи речи: a)VoATM, 6)VoFR, B)VolP

Транспортная технология ATM уже несколько лет успешно используется в магистральных сетях общего пользования и в корпоративных сетях, а сейчас ее начинают активно использовать и для высокоскоростного доступа по каналам xDSL (для небольших офисов) и SDH/ Sonet (для крупных предприятий). Главные преимущества этой технологии — ее зрелость, надежность и наличие развитых средств эксплуатационного управления сетью. В ней имеются непревзойденные по своей эффективности механизмы управления качеством обслуживания и контроля использования сетевых ресурсов. Однако ограниченная распространенность и высокая стоимость оборудования не позволяют считать ATM лучшим выбором для организации сквозных телефонных соединений от одного конечного узла до другого.

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

Технология передачи речевой информации по сетям с маршрутизацией пакетов IP привлекает, в первую очередь, своей универсальностью — речь может быть преобразована в поток IP-пакетов в любой точке сетевой инфраструктуры: на магистрали сети оператора, на границе территориально распределенной сети, в корпоративной сети и даже непосредственно в терминале конечного пользователя. В конце концов, она станет наиболее широко распространенной технологией пакетной телефонии, поскольку способна охватить все сегменты рынка, будучи при этом хорошо адаптируемой к новым условиям применения. Несмотря на универсальность протокола IP, внедрение систем IP-телефонии сдерживается тем, что многие операторы считают их недостаточно надежными, плохо управляемыми и не очень эффективными. Но грамотно спроектированная сетевая инфраструктура с эффективными механизмами обеспечения качества обслуживания, рассматриваемыми в главе 10, делает эти недостатки малосущественными. В расчете на порт стоимость систем IP-телефонии находится на уровне (или немного ниже) стоимости систем Frame Relay, и заведомо ниже стоимости оборудования ATM. При этом уже сейчас видно, что цены на продукты IP-телефонии снижаются быстрее, чем на другие изделия, и что происходит значительное обострение конкуренции на этом рынке.

1.4. Уровни архитектуры IP-телефонии

Архитектура технологии Voice over IP может быть упрощенно представлена в виде двух плоскостей. Нижняя плоскость — это базовая сеть с маршрутизацией пакетов IP, верхняя плоскость — это открытая архитектура управления обслуживанием вызовов (запросов связи).

Нижняя плоскость, говоря упрощенно, представляет собой комбинацию известных протоколов Интернет: Это — RTP (Real Time Transport Protocol), который функционирует поверх протокола UDP (User Datagram Protocol), расположенного, в свою очередь, в стеке протоколов TCP/IP над протоколом IP. Таким образом, иерархия RTP/UDP/IP представляет собой своего рода транспортный механизм для речевого трафика. Этот механизм будет более подробно рассмотрен в главе 4, посвященной протоколам Интернет для передачи речи в реальном времени. Здесь же отметим, что в сетях с маршрутизацией пакетов IP для передачи данных всегда предусматриваются механизмы повторной передачи пакетов в случае их потери. При передаче информации в реальном времени использование таких механизмов только ухудшит ситуацию, поэтому для передачи информации, чувствительной к задержкам, но менее чувствительной к потерям, такой как речь и видеоинформация, используется механизм негарантированной доставки информации RTP/UDPD/IP. Рекомендации ITU-Т допускают задержки водном направлении не превышающие 150 мс. Если приемная станция запросит повторную передачу пакета IP, то задержки при этом будут слишком велики. Эти проблемы более подробно рассматриваются в главе 10, посвященной качеству обслуживания.

Теперь перейдем к верхней плоскости управления обслуживанием запросов связи. Вообще говоря, управление обслуживанием вызова предусматривает принятие решений о том, куда вызов должен быть направлен, и каким образом должно быть установлено соединение между абонентами. Инструмент такого управления — телефонные системы сигнализации, начиная с систем, поддерживаемых декадно-шаговыми АТС и предусматривающих объединение функций маршрутизации и функций создания коммутируемого разговорного канала в одних и тех же декадно-шаговых искателях. Далее принципы сигнализации эволюционировали к системам сигнализации по выделенным сигнальным каналам, к многочастотной сигнализации, к протоколам общеканальной сигнализации №7 [6, 7] и к передаче функций маршрутизации в соответствующие узлы обработки услуг Интеллектуальной сети [8].

В сетях с коммутацией пакетов ситуация более сложна. Сеть с маршрутизацией пакетов IP принципиально поддерживает одновременно целый ряд разнообразных протоколов маршрутизации. Такими протоколами на сегодня являются: RIP — Routing Information Protocol, IGRP — Interior Gateway Routing Protocol, EIGRP — Enhanced Interior Gateway Routing Protocol, IS-IS — Intermediate System-to-intermediate System, OSPF — Open Shortest Path First, BGP — Border Gateway Protocol и др. Точно так же и для IP-телефонии разработан целый ряд протоколов. Рассматриваемые в этой книге стандарты содержат положения, относящиеся к передаче речи по IP-сетям (глава 3) и к сигнализации для IP-телефонии (главы 6, 7, 8 и 9).
Наиболее распространенным является протокол, специфицированный в рекомендации H.323 ITU-T, в частности, потому, что он стал применяться раньше других протоколов, которых, к тому же, до внедрения H.323 вообще не существовало. Этот протокол подробно рассматривается в главах 5 и 6.

Другой протокол плоскости управления обслуживанием вызова — SIP — ориентирован на то, чтобы сделать оконечные устройства и шлюзы более интеллектуальными и поддерживать дополнительные услуги для пользователей. Этот протокол подробно рассматривается в главе 7.

Еще один протокол — SGCP — разрабатывался, начиная с 1998 года, для того, чтобы уменьшить стоимость шлюзов за счет реализации функций интеллектуальной обработки вызова в централизованном оборудовании. Протокол IPDC очень похож на SGCP, но имеет много больше, чем SGCP, механизмов эксплуатационного управления (ОАМ&Р). В конце 1998 года рабочая группа MEGACO комитета IETF разработала протокол MGCP, базирующийся, в основном, на протоколе SGCP, но с некоторыми добавлениями в части ОАМ&Р. Протокол MGCP подробно рассматривается в главе 8.

Рабочая группа MEGACO не остановилась на достигнутом, продолжала совершенствовать протокол управления шлюзами и разработала более функциональный, чем MGCP, протокол MEGACO. Его адаптированный к H.323 вариант (под названием Gateway Control Protocol) ITU-T предлагает в рекомендации H.248. Протоколу MEGACO/H.248 посвящена глава 9.

1.5. Различные подходы к построению сетей IP-телефонии

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

1.5.1. Построение сети по рекомендации H.323

Первый в истории подход к построению сетей IP-телефонии на стандартизованной основе предложен Международным союзом электросвязи (ITU) в рекомендации H.323 [42]. Сети на базе протоколов H.323 ориентированы на интеграцию с телефонными сетями и могут рассматриваться как сети ISDN, наложенные на сети передачи данных. В частности, процедура установления соединения в таких сетях IP-телефонии базируется на рекомендации Q.931 [44] и аналогична процедуре, используемой в сетях ISDN.

Рекомендация H.323 предусматривает довольно сложный набор протоколов, который предназначен не просто для передачи речевой информации по IP-сетям с коммутацией пакетов. Его цель — обеспечить работу мультимедийных приложений в сетях с негарантированным качеством обслуживания. Речевой трафик — это только одно из приложений H.323, наряду с видеоинформацией и данными. Атак как ничего в технике (как и в жизни) не достается даром, обеспечение совместимости с H.323 различных мультимедийных приложений требует весьма значительных усилий. Например, для реализации функции переключения связи (call transfer) требуется отдельная спецификация Н.450.2.
Вариант построения сетей IP-телефонии, предложенный Международным союзом электросвязи в рекомендации H.323, хорошо подходит тем операторам местных телефонных сетей, которые заинтересованы в использовании сети с коммутацией пакетов (IP-сети) для предоставления услуг междугородной и международной связи. Протокол RAS, входящий в семейство протоколов H.323, обеспечивает контроль использования сетевых ресурсов, поддерживает аутентификацию пользователей и может обеспечивать начисление платы за услуги.

На рис 1.5. представлена архитектура сети на базе рекомендации H.323. Основными устройствами сети являются: терминал (Terminal), шлюз (Gateway), привратник (Gatekeeper) и устройство управления конференциями (Multipoint Control Unit- MCU).

Архитектура сети H.323

Рис. 1.5. Архитектура сети H.323

Терминал H.323 — оконечное устройство пользователя сети IP-телефонии, которое обеспечивает двухстороннюю речевую (мультимедийную) связь с другим терминалом H.323, шлюзом или устройством управления конференциями.
Шлюз IP-телефонии реализует передачу речевого трафика по сетям с маршрутизацией пакетов IP по протоколу H.323. Основное назначение шлюза — преобразование речевой информации, поступающей со стороны ТФОП, в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP. Кроме того, шлюз преобразует сигнальные сообщения систем сигнализации DSS1 и ОКС7 в сигнальные сообщения H.323 и производит обратное преобразование в соответствии с рекомендацией ITU H.246.

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

Зона сети H.323

Рис. 1.6. Зона сети H.323

Наиболее важными функциями привратника являются:

регистрация оконечных и других устройств;
контроль доступа пользователей системы к услугам IP-телефонии при помощи сигнализации RAS;
преобразование alias-псевдонима вызываемого пользователя (объявленного имени абонента, телефонного номера, адреса электронной почты и др.) в транспортный адрес сетей с маршрутизацией пакетов IP (IP адрес + номер порта TCP);
контроль, управление и резервирование пропускной способности сети;
ретрансляция сигнальных сообщений H.323 между терминалами.

В одной сети IP-телефонии, отвечающей требованиям рекомендации ITU H.323, может находиться несколько привратников, взаимодействующих друг с другом по протоколу RAS.

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

Устройство управления конференциями обеспечивает возможность организации связи между тремя или более участниками. Рекомендация H.323 предусматривает три вида конференции (рис. 1.7):

централизованная (т.е. управляемая MCU, с которым каждый участник конференции соединяется в режиме точка-точка), децентрализованная (когда каждый участник конференции соединяется с остальными ее участниками в режиме точка-группа точек) и смешанная.

Виды конференции в сетях H.323

Рис. 1.7. Виды конференции в сетях H.323

Преимуществом централизованной конференции является сравнительно простое терминальное оборудование, недостатком — большая стоимость устройства управления конференциями.

Для децентрализованной конференции требуется более сложное терминальное оборудование и желательно, чтобы в сети IP поддерживалась передача пакетов IP в режиме многоадресной рассылки (IP multicasting). Если этот режим в сети не поддерживается, терминал должен передавать речевую информацию каждому из остальных участников конференции в режиме точка-точка.

Устройство управления конференциями состоит из одного обязательного элемента-контроллера конференций (Multipoint Controller — МС), и, кроме того, может включать в себя один или более процессоров для обработки пользовательской информации (Multipoint Processor — МР). Контроллер может быть физически совмещен с привратником, шлюзом или устройством управления конференциями, а последнее, в свою очередь, может быть совмещено со шлюзом или привратником.

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

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

Существует еще один элемент сети H.323 — прокси-сервер H.323, т.е. сервер-посредник. Этот сервер функционирует на прикладном уровне и может проверять пакеты с информацией, которой обмениваются два приложения. Прокси-сервер может определять, с каким приложением (H.323 или другим) ассоциирован вызов, и осуществлять нужное соединение. Прокси-сервер выполняет следующие ключевые функции:

• подключение через средства коммутируемого доступа или локальные сети терминалов, не поддерживающих протокол резервирования ресурсов (RSVP). Два таких прокси-сервера могут образовать в IP-сети туннельное соединение с заданным качеством обслуживания;
маршрутизацию трафика H.323 отдельно от обычного трафика данных;
обеспечение совместимости с преобразователем сетевых адресов, поскольку допускается размещение оборудования H.323 в сетях с пространством адресов частных сетей;
защиту доступа — доступность только для трафика H.323.

Более подробно архитектура сети H.323 будет рассмотрена в главе 5, а сейчас целесообразно сказать несколько слов о протоколах сигнализации, входящих в семейство H.323.

Протокол RAS (Registration, Admission, Status) обеспечивает взаимодействие оконечных и других устройств с привратником. Основными функциями протокола являются: регистрация устройства в системе, контроль его доступа к сетевым ресурсам, изменение полосы пропускания в процессе связи, опрос и индикация текущего состояния устройства. В качестве транспортного протокола используется протокол с негарантированной доставкой информации UDP.
Протокол H.225.0 (Q.931) поддерживает процедуры установления, поддержания и разрушения соединения. В качестве транспортного протокола используется протокол с установлением соединения и гарантированной доставкой информации TCP.

По протоколу Н.245 происходит обмен между участниками соединения информацией, которая необходима для создания логических каналов. По этим каналам передается речевая информация, упакованная в пакеты RTP/UDP/IP, которые рассматриваются в главе 4.

Выполнение процедур, предусмотренных протоколом RAS, является начальной фазой установления соединения с использованием сигнализации H.323. Далее следуют фаза сигнализации H.225.0 (Q.931) и обмен управляющими сообщениями Н.245. Разрушение соединения происходит в обратной последовательности: в первую очередь закрывается управляющий канал Н.245 и сигнальный канал H.225.0, после чего привратник по каналу RAS оповещается об освобождении ранее занимавшейся полосы пропускания.

Сложность протокола H.323 демонстрирует рис. 1.8, на котором представлен упрощенный сценарий установления соединения между двумя пользователями. В данном сценарии предполагается, что конечные пользователи уже знают IP-адреса друг друга. В обычном случае этапов бывает больше, поскольку в установлении соединения участвуют привратники и шлюзы; это будет рассмотрено в главе 6.

Рассмотрим шаг за шагом этот упрощенный сценарий.

Оконечное устройство пользователя А посылает запрос соединения — сообщение SETUP — к оконечному устройству пользователя ВнаТСР-порт 1720.
Оконечное устройство вызываемого пользователя В отвечает на сообщение SETUP сообщением ALERTING, означающим, что устройство свободно, а вызываемому пользователю подается сигнал о входящем вызове.
После того, как пользователь В принимает вызов, к вызывающей стороне А передается сообщение CONNECT с номером ТСР-порта управляющего канала Н.245.
Оконечные устройства обмениваются по каналу Н.245 информацией о типах используемых речевых кодеков(G.729, G.723.1 и т.д.), а также о других функциональных возможностях оборудования, и оповещают друг друга о номерах портов RTP, на которые следует передавать информацию.
Открываются логические каналы для передачи речевой информации.
Речевая информация передаётся в обе стороны в сообщениях протокола RTP; кроме того, ведется контроль передачи информации при помощи протокола RTCP.

Рис. 1.8. Упрощённый сценарий установления соединения в сети H.323

Приведенная процедура обслуживания вызова базируется на протоколе H.323 версии 1. Версия 2 протокола H.323 позволяет передавать информацию, необходимую для создания логических каналов, непосредственно в сообщении SETUP протокола H.225.0 без использования протокола Н.245. Такая процедура называется «быстрый старт» (Fast Start) и позволяет сократить количество циклов обмена информацией при установлении соединения. Кроме организации базового соединения, в сетях H.323 предусмотрено предоставление дополнительных услуг в соответствии с рекомендациями ITU H.450.X. Более детальный обзор сигнализации H.323 приводится в главе 6.

Следует отметить еще одну важную проблему — качество обслуживания в сетях H.323. Оконечное устройство, запрашивающее у привратника разрешение на доступ, может, используя поле transportQoS в сообщении ARQ протокола RAS, сообщить о своей способности резервировать сетевые ресурсы. Рекомендация H.323 определяет протокол резервирования ресурсов (RSVP) как средство обеспечения гарантированного качества обслуживания, что предъявляет к терминалам требование поддержки протокола RSVP. К сожалению, протокол RSVP используется отнюдь не повсеместно, что оставляет сети H.323 без основного механизма обеспечения гарантированного качества обслуживания. Это — общая проблема сетей IP-телефонии, характерная не только для сетей H.323.

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

1.5.2. Сеть на базе протокола SIP

Второй подход к построению сетей IP-телефонии, предложенный рабочей группой MMUSIC комитета IETF в документе RFC 2543 [54], основан на использовании протокола SIP — Session Initiation Protocol. SIP представляет собой текст — ориентированный протокол, который является частью глобальной архитектуры мультимедиа, разработанной комитетом Internet Engineering Task Force (IETF). Эта архитектура также включает в себя протокол резервирования ресурсов (Resource Reservation Protocol, RSVP, RFC 2205), транспортный протокол реального времени (Real-Time Transport Protocol, RTP, RFC 1889), протокол передачи потоков в реальном времени (Real-Time Streaming Protocol, RTSP, RFC 2326), протокол описания параметров связи (Session Description Protocol, SDP, RFC 2327), протокол уведомления о связи (Session Announcement Protocol, SAP). Однако функции протокола SIP не зависят от любого из этих протоколов.

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

Подход SIP к построению сетей IP-телефонии намного проще в реализации, чем H.323, но меньше подходит для организации взаимодействия с телефонными сетями. В основном это связано с тем, что протокол сигнализации SIP, базирующийся на протоколе HTTP, плохо согласуется с системами сигнализации, используемыми в ТфОП. Поэтому протокол SIP более подходит поставщикам услуг Интернет для предоставления услуги IP-телефонии, причем эта услуга будет являться всего лишь частью пакета услуг.

Тем не менее, протокол SIP поддерживает услуги интеллектуальной сети (IN), такие как преобразование (мэппинг) имён, переадресация и маршрутизация [8], что существенно для использования SIP в качестве протокола сигнализации в сети общего пользования, где приоритетной задачей оператора является предоставление широкого спектра телефонных услуг. Другой важной особенностью протокола SIP является поддержка мобильности пользователя, т.е. его способности получать доступ к заказанным услугам в любом месте и с любого терминала, а также способности сети идентифицировать и аутентифицировать пользователя при его перемещении из одного места в другое. Это свойство SIP не уникально, и, например, протокол H.323 тоже в значительной степени поддерживает такую возможность. Сейчас настал момент, когда эта возможность станет главной привлекательной чертой сетей IP-телефонии нового поколения. Данный режим работы потребует дистанционной регистрации пользователей на сервере идентификации и аутентификации.

Перейдем непосредственно к архитектуре сетей, базирующихся на протоколе SIP (рис. 1.9).

Пример сети на базе протокола SIP

Рис. 1.9. Пример сети на базе протокола SIP

Сеть SIP содержит основные элементы трех видов: агенты пользователя, прокси-серверы и серверы переадресации.
Агенты пользователя (User Agent или SIP client) являются приложениями терминального оборудования и включают в себя две составляющие: агент пользователя — клиент (User Agent Client — UAC) и агент пользователя — сервер (User Agent Server — UAS), иначе известные как клиент и сервер соответственно. Клиент UAC инициирует SIP-запросы, т.е. выступает в качестве вызывающей стороны. Сервер UAS принимает запросы и возвращает ответы, т.е. выступает в качестве вызываемой стороны.

Кроме того, существует два типа сетевых серверов SIP: прокси-серверы (серверы-посредники) и серверы переадресации. Серверы SIP могут работать как в режиме с сохранением состояний текущих соединений (statefull), так и в режиме без сохранения состояний текущих соединений (stateless). Сервер SIP, функционирующий в режиме stateless, может обслужить сколь угодно большое количество пользователей, в отличие от привратника H.323, который может одновременно работать с ограниченным количеством пользователей.

Прокси-сервер (Proxy-server) действует «от имени других клиентов» и содержит функции клиента (UAC) и сервера (UAS). Этот сервер интерпретирует и может перезаписывать заголовки запросов перед отправкой их к другим серверам (рис. 1.10). Ответные сообщения следуют по тому же пути обратно к прокси-серверу, а не к клиенту.

Сеть SIP с прокси-сервером

Рис. 1.10. Сеть SIP с прокси-сервером

Ниже представлен алгоритм установления соединения с помощью протокола SIP при участии прокси-сервера:

Прокси-сервер принимает запрос соединения INVITE от оборудования вызывающего пользователя.
Прокси-сервер устанавливает местонахождение клиента с помощью сервера определения местоположения (location server).
Прокси-сервер передает запрос INVITE вызываемому пользователю.
Оборудование вызываемого пользователя уведомляет последнего о входящем вызове и возвращает прокси-серверу сообщение о том, что запрос INVITE обрабатывается (код 100). Прокси-сервер, в свою очередь, направляет эту информацию оборудованию вызывающего пользователя.
Когда вызываемый абонент принимает вызов, его оборудование извещает об этом прокси-сервер (код 200), который переправляет информацию о том, что вызов принят, к оборудованию вызывающего пользователя.
Вызывающая сторона подтверждает установление соединения передачей запроса АСК, которое прокси-сервер переправляет вызываемой стороне. Установление соединения закончено, абоненты могут обмениваться речевой информацией.

Сервер переадресации (Redirect server) определяет текущее местоположение вызываемого абонента и сообщает его вызывающему пользователю (рис. 1.11). Для определения текущего местоположения вызываемого абонента сервер переадресации обращается к серверу определения местоположения, принципы работы которого в документе RFC 2543 не специфицированы.

Сеть SIP с сервером переадресации

Рис. 1.11. Сеть SIP с сервером переадресации

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

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

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

Дадим краткую характеристику самого протокола SIP. Следует заметить, что сообщения SIP могут переноситься как протоколом TCP, так и протоколом UDP.

Протокол SIP предусматривает 6 запросов и ответов на них. Сигнализация SIP дает возможность пользовательским агентам и сетевым серверам определять местоположение, выдавать запросы и управлять соединениями.

INVITE — запрос привлекает пользователя или услугу к участию в сеансе связи и содержит описание параметров этой связи. С помощью этого запроса пользователь может определить функциональные возможности терминала своего партнера по связи и начать сеанс связи, используя ограниченное число сообщений и подтверждений их приема.
АСК — запрос подтверждает прием от вызываемой стороны ответа на команду INVITE и завершает транзакцию.
OPTIONS — запрос позволяет получить информацию о функциональных возможностях пользовательских агентов и сетевых серверов. Однако этот запрос не используется для организации сеансов связи.
BYE — запрос используется вызывающей и вызываемой сторонами для разрушения соединения. Перед тем как разрушить соединение, пользовательские агенты отправляют этот запрос к серверу, сообщая о намерении прекратить сеанс связи.
CANCEL — запрос позволяет пользовательским агентам и сетевым серверам отменить любой ранее переданный запрос, если ответ на нее еще не был получен.
REGISTER — запрос применяется клиентами для регистрации информации о местоположении с использованием серверов SIP.

Более подробная информация о протоколе SIP приведена в главе 7.

1.5.3. Сеть на базе MGCP и MEGACO

Третий подход к построению сетей IP-телефонии, основанный на использовании протокола MGCP [56], также предложен комитетом IETF, рабочей группой MEGACO.

При разработке этого протокола рабочая группа MEGACO опиралась на сетевую архитектуру, содержащую основные функциональные блоки трех видов (рис. 1.12):

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

Рис. 1.12. Архитектура сети на базе протокола MGCP

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

Шлюз сигнализации выполняет функции STP — транзитного пункта сети сигнализации ОКС7. Сами шлюзы выполняют только функции преобразования речевой информации. Один контроллер управляет одновременно несколькими шлюзами. В сети могут присутствовать несколько контроллеров. Предполагается, что они синхронизованы между собой и согласованно управляют шлюзами, участвующими в соединении. Вместе с тем, MEGACO не определяет протокола для синхронизации работы контроллеров. В ряде работ, посвященных исследованию возможностей протокола MGCP, для этой цели предлагается использовать протоколы H.323, SIP или ISUP/IP.

Сообщения протокола MGCP переносятся протоколом без гарантированной доставки сообщений UDP. Рабочая группа SIGTRAN комитета IETF в настоящее время разрабатывает механизм взаимодействия контроллера шлюзов и шлюза сигнализации.

Шлюз сигнализации должен принимать поступающие из ТфОП пакеты трех нижних уровней системы сигнализации ОКС7 (уровней подсистемы переноса сообщений МТР) и передавать сигнальные сообщения верхнего, пользовательского, уровня к контроллеру шлюзов. Шлюз сигнализации также должен уметь передавать по IP-сети приходящие из ТфОП сигнальные сообщения Q.931.

Основное внимание рабочей группы SIGTRAN уделяется вопросам разработки наиболее эффективного механизма передачи сигнальной информации по IP-сетям. Следует отметить, что существует несколько причин, по которым пришлось отказаться от использования для этой цели протокола TCP. Рабочая группа SIGTRAN предлагает использовать для передачи сигнальной информации протокол Stream Control Transport Protocol (SCTP), имеющий ряд преимуществ перед протоколом ТСР, основным из которых является значительное снижение времени доставки сигнальной информации и, следовательно, времени установления соединения — одного из важнейших параметров качества обслуживания.

Если в ТфОП используется сигнализация по выделенным сигнальным каналам (ВСК), то сигналы сначала поступают вместе с пользовательской информацией в транспортный шлюз, а затем передаются в контроллер шлюзов без посредничества шлюза сигнализации.

Отметим, что протокол MGCP является внутренним протоколом для обмена информацией между функциональными блоками распределенного шлюза, который извне представляется одним шлюзом. Протокол MGCP является master/slave протоколом. Это означает, что контроллер шлюзов является ведущим, а сам шлюз — ведомым устройством, которое должно выполнять все команды, поступающие от контроллера Call Agent.

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

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

Третий подход, предлагаемый организацией IETF (рабочая группа MEGACO), хорошо подходит для развертывания глобальных сетей IP-телефонии, приходящих на смену традиционным телефонным сетям. Более подробная информация о протоколе MGCP приведена в главе 8.

Рассмотрим алгоритмы установления и разрушения соединения с использованием протокола MGCP. Первый пример охватывает взаимодействие протокола MGCP с протоколом ОКС7 (рис. 1.13).

Установление и разрушение соединения с использованием протокола MGCP (пример 1)

Рис. 1.13. Установление и разрушение соединения с использованием протокола MGCP (Пример 1)

От телефонной станции АТС-А к шлюзу сигнализации SG1 по общему каналу сигнализации поступает запрос соединения в виде сообщения IAM протокола ISUP [6]. На рис. 1.13 шлюз сигнализации SG1 и SG2 совмещены с транспортными шлюзами TGW1 и TGW2 соответственно. Шлюз SG1 передает сообщение IAM к контроллеру шлюзов, который обрабатывает запрос и определяет, что вызов должен быть направлен к АТС-Б посредством шлюза TGW2.
Контроллер резервирует порт шлюза TGW1 (разговорный канал). С этой целью он передает к шлюзу команду CreateConnection. Отметим, что порт шлюза TGW1 может только принимать информацию (режим «recvonly»), так как он еще не осведомлен о том, по какому адресу и каким образом ему следует передавать информацию.
В ответе на эту команду шлюз TGW1 возвращает описание параметров сеанса связи.
Приняв ответ шлюза TGW1, контроллер передает команду CRCX второму шлюзу TGW2 с целью зарезервировать порт в этом шлюзе.
Шлюз TGW2 выбирает порт, который будет участвовать в соединении, и подтверждает прием команды CRCX. При помощи двух команд CRCX создается однонаправленный разговорный канал для передачи вызывающему абоненту акустических сигналов или речевых подсказок и извещений. В то же время, порт шлюза TGW2 уже может не только принимать, но и передавать информацию, так как он получил описание параметров связи от встречного шлюза.
Далее контроллер шлюзов передает сообщение IAM к АТС-Б.
На сообщение IAM станция АТС-Б отвечает подтверждением АСМ, которое немедленно пересылается к станции АТС-А.
После того как вызываемый абонент примет вызов, АТС-Б передает к контроллеру шлюзов сообщение ANM.
Далее контроллер заменяет в шлюзе TGW1 режим «recvonly» на полнодуплексный режим при помощи команды MDCX.
Шлюз TGW1 выполняет и подтверждает изменение режима.
Контроллер передает сообщение ANM к АТС-А, после чего начинается разговорная фаза соединения.
Завершение разговорной фазы происходит следующим образом. В нашем случае вызвавший абонент Б дает отбой первым. АТС-Б передает через шлюз сигнализации сообщение REL к контроллеру шлюзов.
Приняв сообщение REL, контроллер шлюзов завершает соединение с вызванным абонентом.
Шлюз подтверждает завершение соединения и передает к контроллеру собранные за время соединения статистические данные.
Контроллер шлюзов передает сообщение RLC к АТС-Б с целью подтвердить разъединение.
Параллельно контроллер завершает соединение с вызвавшей стороной
ШлюзТGW1 подтверждает завершение соединения и передает к контроллеру собранные за время соединения статистические данные.
АТС-А подтверждает завершение соединения передачей сообщения RLC, после чего соединение считается разрушенным.

Второй пример иллюстрирует взаимодействие протокола MGCP с протоколами ОКС7 и H.323 (рис. 1.14).

Установление и разрушение соединения с использованием протокола MGCP (пример 2)

Рис. 1.14. Установление и разрушение соединения с использованием протокола MGCP (Пример 2)

С телефонной станции АТС-А к шлюзу сигнализации SG1 по общему каналу сигнализации поступает запрос соединения (сообщение IAM). На рис. 1.14 шлюз сигнализации SG1 также совмещен с транспортным шлюзом TGW1. Шлюз SG1 передает сообщение IAM контроллеру шлюзов, который обрабатывает запрос и определяет, что вызов должен быть направлен к оконечному устройству вызываемого пользователя — терминалу H.323.
Контроллер шлюзов резервирует порт шлюза TGW1 (разговорный канал). С этой целью он передает к шлюзу команду CreateConnec-tion. И в этом примере порт шлюза TGW1 может только принимать информацию (режим «recvonly»).
В ответе на принятую команду шлюз TGW1 возвращает описание параметров связи.
Приняв ответ от шлюза TGW1, контроллер передает к привратнику сети H.323 сообщение ARQ с alias адресом вызываемого абонента.
В ответ на сообщение ARQ привратник передает сообщение ACF с указанием транспортного адреса своего сигнального канала.
Контроллер передает запрос соединения SETUP на транспортный адрес сигнального канала привратника, при этом используется процедура Fast Start. Привратник пересылает сообщение SETUP к вызываемому терминалу.
Вызываемый терминал передает запрос допуска к ресурсам сети ARQ.
В ответ на запрос ARQ привратник передает подтверждение запроса ACF.
Вызываемый терминал передает сообщение ALERTING, которое привратник маршрутизирует к контроллеру шлюзов. При этом вызываемому пользователю подается визуальный или акустический сигнал о входящем вызове, а вызывающему пользователю подается индикация того, что вызываемый пользователь не занят и получает сигнал о вызове.
Контроллер преобразует сообщение ALERTING в сообщение АСМ, которое немедленно пересылается к АТС-А.
После того как вызываемый пользователь примет входящий вызов, контроллер получит сообщение CONNECT.
Контроллер шлюзов меняет в шлюзе TGW1 режим «recvonly» на полнодуплексный режим.
Шлюз TGW1 выполняет и подтверждает изменение режима соединения.
Контроллер передает сообщение ANM к АТС-А, после чего начинается разговорная фаза соединения, в ходе которой оборудование вызвавшего пользователя передает речевую информацию, упакованную в пакеты RTP/UDP/IP, на транспортный адрес RTP-канала терминала вызванного абонента, а тот передает пакетированную речевую информацию на транспортный адрес RTP-канала терминала вызвавшего абонента. При помощи канала RTCP ведется контроль передачи информации по RTP каналу.
После окончания разговорной фазы начинается фаза разрушения соединения. Оборудование пользователя, инициирующего разрушение соединения, должно прекратить передачу речевой информации, закрыть логические каналы и передать сообщение RELEASE COMPLETE, после чего сигнальный канал закрывается.
Контроллер шлюзов передает сообщение RELEASE к АТС-А с целью завершения соединения.
Кроме того, контроллер передает к шлюзу команду DLCX.
Шлюз подтверждает завершение соединения и передает к контроллеру собранные за время соединения статистические данные.
После вышеописанных действий контроллер и оконечное оборудование извещают привратник об освобождении занимавшейся полосы пропускания. С этой целью каждый из участников соединения посылает привратнику по каналу RAS запрос выхода из соединения DRQ, на который привратник должен передать подтверждение DCF.
От АТС-А приходит подтверждение разъединения RLC, после чего соединение считается разрушенным.
Следует заметить, что алгоритм взаимодействия протоколов SIP и MGCP не сильно отличается от вышеописанного алгоритма.

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

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

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

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

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

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

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

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

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

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

Bukvasha