Шесть ведущих производителей телефонных IP-шлюзов - Ascend Communications, Siemens, Cisco Systems, Dialogic, Natural MicroSystems и Clarent - намерены добиться полной совместимости своих IP-шлюзов и устройств доступа к ним (gatekeepers). С этой целью на­званные компании обеспечат в своих устройствах поддержку спецификаций iNow (Interoperability Now), совместно разработанных фирмами Lucent Technologies, ITXC и VocalTec Communications.

Спецификации iNow определяют способы обработки служебной информации при ус­тановлении телефонного соединения, меры безопасности и другие функции уровня управле­ния средой передачи, необходимые для ус тановления телефонного соединения между IP-шлюзами. iNow базируются на стандарте Н.323 и Приложении G рекомендации Н.225.0, ко­торое описывает процедуры организации междоменной связи.

Первыми о совместимости своих шлюзов объявили фирмы Lucent Technologies и VocalTec. В настоящее время их оборудование проходит испытания в коммерческой сети американского оператора ITXC. Остальные производители собираются представить обору­дование с поддержкой iNow в ближайшее время.

В настоящее время в IETF реализуется также проект в области управления сетью на основе правил: это исследования, связанные с определением стандартной инфраструктуры для применения данной методологии, а также набора необходимых протоколов и схем рабо­ты. Чтобы обеспечить оптимальный процесс хранения и извлечения из хранилища правил, составляющих стратегии, их внутреннее представление должно быть формализовано в струк­туру данных. Рабочая группа IETF Policy Framework Working Group (PFWG) разработала мо­дель Policy Framework Core Information Model, в которой определен высокоуровневый набор объектно-ориентированных классов, достаточный для представления базовых стратегий управления. Объектные классы могут расширяться производными классами конкретных ти­пов стратегий - например, обеспечения QoS или безопасности.

Две рабочие группы IETF работают над стандартом качества обслуживания QoS для Интернет. Одна из этих групп разрабатывает механизм многопротокольного коммутирования меток (Multiprotocol Label Switching, MPLS), а другая - спецификации дифференцированного обслуживания (Differentiated Services, Diff-Serv).

Группа MPLS была создана, чтобы помочь в расширении структурных связей сети Ин­тернет за счет внедрения методов коммутирования цепей в среду коммутации пакетов без установления логических соединений. Для этого в технологии MPLS предусматривается до­бавление к IP-пакетам специальной метки, указывающей, что трафик будет направляться через Internet по заранее определенным маршрутам. Очевидно, что спецификации MPLS по­зволяют коммутаторам и маршрутизаторам значительно уменьшить время поиска адресов, по которым должны передаваться пакеты. Кроме того, MPLS обеспечивает более детерминиро­ванное и предсказуемое функционирование сети Интернет, что важно для поддержки QoS.

В деятельности группы MPLS принимают активное участие представители крупней­ших поставщиков сетевых решений и оборудования. Эта архитектура выросла из системы Tag Switching, предложенной Cisco Systems, однако некоторые идеи были заимствованы у конкурирующей технологии IP-коммутации, созданной компанией Ipsilon, и проекта ARIS корпорации IBM. В архитектуре MPLS собраны наиболее удачные элементы всех упомяну­тых разработок, и, по прогнозам, она должна превратиться в стандарт Internet благодаря уси­лиям IETF и компаний, заинтересованных в скорейшем продвижении данной технологии на рынок.

Спецификация Diff-Serv предназначена для присвоения различным приложениям зна­чений параметров, присущих разным уровням QoS. Согласно Diff-Serv, биты типа службы (ToS) в IP-заголовках указывают на класс QoS для различных видов трафика и назначаются на основе соглашений об уровне обслуживания, заключаемых между пользователями и по­ставщиками услуг.

Возможности RTP были расширены путем объединения его с еще одним протоколом IETF, а именно с протоколом управления передачей в реальном времени (Real-time Transport Control Protocol, RTCP). С помощью протокола RTCP программы могут приспосабливаться к изменяющимся нагрузкам на сеть, уведомляя отправителей и получателей о всплесках (spikes) - резких изменениях объемов передаваемой по сети информации. Например, RTCP-совместимый телефон может отслеживать пропускную способность сети и мгновенно пере­ключаться на алгоритм кодирования/декодирования аудиосигнала более низкого качества, если в сети становится слишком много пользователей.

Быстрое развитие IP-телефонии выявило проблему совместимости шлюзов, предна­значенных для сопряжения IP-сетей и сетей с коммутацией каналов. Специальная рабочая группа по управлению многоточечными сеансами мультимедиа-связи (MMUSIC) организа­ции IETF разработала собственный протокол прикладного уровня для инициализации сеан­сов связи SIP (Session Initiation Protocol), который был принят в качестве стандарта RFC 2543 в марте 1999 года. Протокол SIP, не включенный пока ITU-T в стандарт Н.323, может оказать огромное влияние на распространение Интернет-телефонии, поскольку он стирает границы, пока еще существующие между ней и обычной телефонией.

Первое, что было рекомендовано IETF, - это протокол резервирования ресурсов (Resource Reservation Protocol, RSVP). С помощью PSVP мультимедиа-программы могут по­требовать специального качества обслуживания (specific quality of service, QoS) посредством любого из существующих сетевых протоколов - главным образом IP, хотя возможно исполь­зовать и UDP - чтобы обеспечить качественную передачу видео - и аудиосигналов. Протокол RSVP предусматривает QoS благодаря тому, что через каждый узел, который связывает меж­ду собой участников телефонного разговора, может передаваться определенное количество данных.

Протокол RSVP реализован в маршрутизаторах фирм Cisco, Nortel Networks и многих других производителей.

Хотя протокол RSVP предусматривает решение проблемы QoS, в нем не устранен принципиальный недостаток, присущий протоколам Интернет для программ мультимедиа, -недостаточно развитые средства синхронизации данных. Надежные протоколы, такие, как

Рис. 2.2. Структура проекта TIPHON

Рис. 2.3. Сценарий 1 проекта TIPHON

Рис. 2.4. Сценарий 2 проекта TIPHON

Рис. 2.5. Сценарий 3 проекта TIPHON

Рис. 2.6. Сценарий 4 проекта TIPHON

TCP/IP, располагают многоуровневыми средствами, предотвращающими потерю данных. Однако многоуровневая архитектура может помешать выполнению чувствительных к вре­менной упорядоченности процедур декодирования аудио - и видеосигналов, реагирующих на несвоевременное поступление данных. Кроме того, временные критерии вообще не фигури­руют в IP. Из этого следует, что синхронизация может оказаться крайне сложной задачей. Поэтому комитетом IETF был разработан транспортный протокол реального времени (RTP, Real-time Transport Protocol). Протокол описан в документе RFC 1889, а также включен в Рекомендацию Н.323.

Задачу реализации проекта TIPHON предполагается решить в четыре этапа. На первых двух этапах стандартизуются процессы установления соединения между Н.323-терминалами и пользователями ТфОП (рис. 2.3), а затем между телефонной сетью и Н.323-терминалами (рис. 2.4). На третьем этапе предполагается через IP-сети обеспечить соединение между абонентами ТфОП (рис. 2.5). Наконец, четвертая фаза определит процедуру соединения терминалов-Н323 через телефонную сеть (рис. 2.6). В марте 1999 года было официально объявлено о заверше­нии первой фазы, а работа над реализацией второго и третьего этапов продолжается.

Рис. 2.1. Конфигурация сети на базе стандарта Н.323 Таблица 2.2. Основные компоненты стандарта Н.323

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

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

• Н.320 - узкополосные цифровые коммутируемые сети, включая ISDN;

• Н.321 - широкополосные сети ISDN и ATM;

• Н.322 — пакетные сети с гарантированной полосой пропускания;

• Н.324 - телефонные сети общего пользования (ТфОП).

Одна из основных целей разработки стандарта Н.323 - обеспечение взаимодействия с другими типами сетей мультимедиа-связи (рис. 2.1). Данная задача реализуется с помощью шлюзов, осуществляющих трансляцию сигнализации и форматов данных. Стандарт Н.323 позволяет создать надежные решения для организации коммуникаций по ненадежным сетям с переменной задержкой. При условии соответствия стандарту устройства с различными возможностями могут и взаимодействовать друг с другом. Например, терминалы с видео­средствами могут участвовать в аудиоконференции. В совокупности с другими стандартами МСЭ-Т на мультимедийную связь и телеконференции рекомендации Н.323 применимы для любых видов соединений - от многоточечных до соединений «точка-точка». Основные ком­поненты этого стандарта приведены в табл. 2.2.

Стандарт Н. 323 определяет также порядок взаимодействия с оконечными устройства­ми других стандартов. Наиболее часто такая задача возникает при сопряжении телефонных сетей с коммутацией пакетов и коммутацией каналов. Сети стандарта Н.323 совместимы и с другими типами Н.32х-сетей. Межсетевое взаимодействие различных Н.32х-сетей определя­ет рекомендация Н.246. На следующем этапе развития IP-телефонии к спецификациям Н.323, соответствующим нижним уровням эталонной модели взаимодействия открытых систем (ЭМВОС), будут добавлены новые. Они зафиксируют возможности обеспечения классов (class-of-service, CoS) и качества обслуживания (quality-of-service, QoS), т. е. услуг, относя­щихся, соответственно, ко второму (канальному) и третьему (сетевому) уровням. Разработ­кой спецификаций CoS/QoS занимается ряд организаций, в том числе рабочие группы IEEE 802.1р и IETF Diff-Serv, а также Европейский институт стандартизации в области электро­связи (ETSI), который включил продукты Н.323 в свой проект Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON).

Стандарты Т.37, Т.38

Факсимильная связь на базе IP-сети опирается на два основных стандарта МСЭ-Т. Реко­мендация Т.37 описывает преобразование традиционных сигналов факсов в почтовые сообще­ния SMTP с MIME-совместимыми вложениями в формате TIFF. Эта методика используется обычно поставщиками IP-факсов и сводит передачу факсов к доставке с промежуточным хра­нением, так как изображения факсов передаются в виде вложений электронной почты.

Стандарт Н.323

Набор рекомендаций МСЭ-Т Н.323 определяет сетевые компоненты, протоколы и про­цедуры, позволяющие организовать мультимедиа-связь в пакетных сетях, в том числе в ЛВС Ethernet. Они определяют порядок функционирования абонентских терминалов в сетях с раз­деляемым ресурсом, не гарантирующих качества обслуживания QoS. Н.323-совместимые уст­ройства могут применяться для телефонной связи (IP-телефония), передачи звука и видео (ви­деотелефония), а также звука, видео и данных (мультимедийные конференции).

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

В настоящее время готовится следующая версия стандарта. В ней будут описаны соз­дание пакетных сетей факсимильной связи и организация связи между Н.323-шлюзами. Речь идет и о функциях, распространенных в современной телефонии, включая уведомление о поступлении второго вызова и режим справки. Некоторые компании добиваются включения в Н.323 поддержки мультимедиа-возможностей, основанных на предложенном IETF прото­коле Session Initiation Protocol. Помимо «телефонных» функций новая версия будет дополне­на средствами, позволяющими учитывать параметры сеансов для целей тарификации, а так­же поддержкой каталогов - вместо цифровых IP-адресов можно будет пользоваться именами абонентов.