Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Видео по протоколу

А. Г. Барсков

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

Раньше, говоря о видеоконференц-связи, мы тут же вспоминали технологию ISDN и стандарт H.320. Действительно, долгие годы системы H.320 доминировали в мире видеоконференций, однако вихрь IP-революции изменил положение дел и в этой области телекоммуникаций.

Системы ISDN, может быть, и не слишком дорогие сами по себе, но пользование ими оказывается весьма накладным. Стандартной видеоконференции бизнес-качества требуется полоса пропускания 384 Кбит/с, т. е. объединение шести B-каналов ISDN (каждый по 64 Кбит/с). Поминутная оплата за такое соединение высока. Что же касается видеосвязи телевизионного качества (768 Кбит/с), то она, понятное дело, еще дороже. Высокая стоимость использования ISDN-систем видеоконференц-связи стала, пожалуй, главным препятствием на пути их массового развертывания на предприятиях и в организациях. В России свою роль сыграла еще и малая распространенность ISDN. Хотя большинство внедряемых в 90-х годах прошлого века АТС имели поддержку этой технологии, на федеральный уровень она так и не вышла.

Полную версию данной статьи смотрите в 12-ом номере журнала за 2003 год.

Технология IP работает не то что на федеральном — на глобальном уровне! Современные широкополосные сети передачи данных, которые активно развертываются и в России, без проблем могут обеспечить каналы со скоростью 2 Мбит/с и выше. Понятно, что качество передачи видео на таких скоростях выше. Стоимость же полосы пропускания в IP-сетях заметно ниже, чем в сетях ISDN. Кроме того, IP-системы в отличие от ISDN не требуют объединения каналов, что повышает их надежность. Если один из шести B-каналов, составляющих 384-Кбит/с соединение ISDN, “падает”, то разрывается и весь сеанс видеосвязи. Как это ни покажется на первый взгляд странным (в связи с нашими общими представлениями о надежности пакетных сетей и сетей с коммутацией каналов), но, по данным ряда зарубежных компаний, коэффициент доступности видеоконференц-связи для ISDN составляет 92—94%, а для IP зачастую превышает 99%.

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

Наконец, главный плюс IP-видеоконференций — возможность использовать существующую сеть передачи данных. Это конвергенция в чистом виде: возложение на одну инфраструктуру функций по транспортировке “великолепного трио” — данных, речи и видео. Поскольку при наличии ЛВС IP-соединения “заходят” в каждую комнату и “подходят” к каждому рабочему месту, масштабирование приложений, связанных с передачей видео, — задача несложная. Работа по ISDN требует наличия выделенной сети и отдельной группы техподдержки со всеми вытекающими отсюда следствиями — дополнительными расходами на оборудование, расширение сети, зарплату инженерам и т. п.

Несмотря на всю серьезность притязаний IP на роль короля видео, не стоит окончательно хоронить ISDN и другие технологии. Протоколам TCP/IP присущи ряд недостатков (о них мы поговорим ниже), которые могут ограничить возможность их использования в конкретных условиях. Большинство фирм-производителей не склонны следовать принципу “только IP”, предлагая видеотерминалы с поддержкой и IP и ISDN, а также шлюзы IP—ISDN для стыковки разных систем. Но в новых разработках упор все же делается на IP.

Протоколы

Основные протоколы, используемые при передаче видео по IP, те же, на которых базируется и пакетная передача речи (VoIP), а именно H.323 и SIP.

Зонтичная рекомендация МСЭ-Т H.323 объединяет семейство протоколов для мультимедиа-коммуникаций в пакетных сетях. Наиболее важные из них — H.225 и H.245 служат для установления соединений и управления ими. Что же касается кодирования аудиоинформации, то H.323 ссылается на все те алгоритмы (G.711, G.722, G.728, G.723), которые хорошо известны нашим читателям по системам IP-телефонии. Для кодирования видео предусмотрен алгоритм H.263, в нем, в частности, определены дополнительные форматы изображения (4CIF и 16CIF), которых не было в видеокодеке H.261 из семейства H.320. Многие производители сегодня используют свои фирменные кодеки, улучшенные варианты H.263, иногда они обозначают их как H.263+. Недавно МСЭ-Т принял новый стандарт видеокодирования — H.264, формально не попадающий под “колпак” H.323. В этом стандарте заложен более эффективный алгоритм сжатия видеофайлов, который позволяет улучшить качество изображения при существенной экономии полосы пропускания. Новый видеокодек уже реализован в последнем поколении систем видеосвязи ряда фирм.

Разработанный организацией IETF протокол SIP пронизан духом Интернет: сообщения этого протокола базируются на HTTP и имеют аналогичную текстовую структуру; он “полагается” в своей работе на другие протоколы компьютерных коммуникаций (SDP, RTP, TCP и UDP) и хорошо взаимодействует со службами SMTP, DNS и LDAP. Адреса SIP могут выглядеть как адреса электронной почты, например: sip:sasha@ccc.ru. Будучи протоколом сигнализации прикладного уровня, SIP обеспечивает установление, модификацию и завершение мультимедийных сеансов связи. Он используется в системах IP-телефонии и видеосвязи, планируется его применение и в сетях связи третьего поколения (3G).

Когда экран не пускает

Поскольку алгоритмы H.323 и SIP активно используют динамически выделяемые протокольные порты, для пропуска мультимедиа-трафика необходимо заранее открыть большой диапазон портов в межсетевом экране (firewall). Давайте в качестве примера посмотрим на рекомендации, которые дает для своей известной H.323-совместимой программы NetMeeting корпорация Microsoft. Чтобы исходящие соединения NetMeeting беспроблемно проходили через межсетевой экран, Microsoft советует разрешить пропуск через него первичных TCP-соединений через порты 389, 522, 1503, 1720 и 1731, а также вторичных TCP- и UDP-соединений через динамически выделяемые порты в диапазоне 1024—65 535.

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

Технологии SIP и H.323 используют для доставки медиатрафика протокол RTP, который, равно как и протокол управления H.245, не привязан к фиксированным портам транспортного (четвертого в модели OSI) уровня и может задействовать любой порт в диапазоне 1024—65 535. Это и вызывает появление описанной выше проблемы.

Традиционный способ ее решения — применение прокси-агента или шлюза прикладного уровня (Application Level Gateway — ALG). Это программные компоненты экрана, которые активным образом участвуют в работе протоколов SIP и H.323 (подробнее о прокси-агентах и ALG-шлюзах речь будет идти ниже). К сожалению, реализация процедур протоколов SIP и H.323 непосредственно в межсетевом экране значительно усложняет эту систему, делает более уязвимой для внешних атак, снижает ее производительность и масштабируемость. Не надо также забывать, что SIP и H.323 переносят интерактивный речевой и видеотрафик, очень чувствительный к задержкам, поэтому дополнительные промежуточные операции крайне нежелательны.

Популярный механизм трансляции сетевых адресов NAT тоже находится в определенной “конфронтации” с протоколами SIP и H.323. Как известно, входящие в состав H.323 протоколы управления H.225 и H.245 используют внутри своих сообщений IP-адреса. Предположим, хост в корпоративной сети имеет частный IP-адрес 172.18.0.51, которому система NAT ставит в соответствие глобально маршрутизируемый адрес 207.126.235.233. Но при переходе через NAT сообщений Н.225 информация о звонящем хосте внутри этих сообщений будет по-прежнему содержать его частный адрес (172.18.0.51) и все попытки внешнего хоста установить соединение по этому адресу окажутся безуспешными.

Что делать

Очевидный путь обхода всех проблем, связанных с межсетевыми экранами и NAT, заключается в отказе от их использования. Но для большинства организаций риск открытия своей сети слишком велик, да и получение необходимого числа глобально маршрутизируемых IP-адресов может оказаться затруднительным и дорогостоящим. Другой вариант — использовать IP для речевых и видеокоммуникаций внутри ЛВС, а снаружи задействовать традиционные службы сетей общего пользования с коммутацией каналов (ТфОП). Для сопряжения двух “миров” есть соответствующие шлюзы. Кстати, IP-телефоны “разговаривают” со своими обычными собратьями именно через такие шлюзы. Однако данный вариант лишает вас большинства преимуществ использования единой конвергированной инфраструктуры и “чистого” IP-решения.

Проблемы с NAT-трансляцией, так же как и с процедурами firewall, позволяют обойти уже упомянутые выше прокси-агенты SIP и H.323.

В случае с NAT-системой такой агент должен “иметь представление” об адресации в частной (корпоративной) и глобальной IP-сетях. Он ставится “в разрыв” IP-соединения, разбивая его на два соединения: одно — от хоста частной сети до прокси-агента, другое — от прокси-агента до хоста-адресата в сети общего пользования. Внутри себя прокси объединяет эти два соединения. Функциональность прокси-агента может быть реализована по-разному, — например, встроена в привратник (gatekeeper) H.323 или в межсетевой экран. Если NAT-трансляция выполняется в нескольких узлах распределенной сети, тогда и прокси-агенты должны быть развернуты в каждом таком узле.

Еще одни дополнительные элементы, способные разрешить ситуацию, — шлюзы прикладного уровня (ALG). По сути, это межсетевые экраны, “понимающие” специфику IP-протоколов H.323 и SIP. Вместо того чтобы просто просматривать заголовок пакета (с целью определения, пропускать его или блокировать), такой шлюз проводит анализ его полезной нагрузки. Протоколы H.323 и SIP переносят в теле пакетов та-кую важную информацию, как номера протокольных портов, которые конечные узлы “предполагают” использовать для передачи речевой и видеоинформации. Получив такую информацию, межсетевой экран динамически открывает эти порты, оставляя остальные закрытыми. Досконально разбирая приходящие пакеты, ALG-компоненты значительно повышают загрузку межсетевых экранов, что является серьезным минусом их использования.

Некоторые компании обходят проблемы, возникающие при прохождении видеотрафика через системы firewall/NAT, путем помещения блока многоточечных конференций (Multipoint Control Unit — MCU) в так называемую демилитаризованную зону, расположенную между межсетевым экраном внутренней сети и Интернет. Компании обычно организуют демилитаризованные зоны для размещения Интернет-служб общего пользования (Web-, ftp-, почтовые серверы). Устройство MCU, находящееся в такой зоне, оборудуется двумя сетевыми интерфейсами: один принимает трафик из внутренней сети, другой “смотрит” в сеть общего пользования. Недостатком такого подхода является то, что MCU вступает в игру даже для соединения двух терминалов. (Обычно устройства MCU задействуются только в случае организации конференций между тремя участниками или большим их числом).

Вообще говоря, к проблеме систем firewall/NAT привлечено серьезное внимание в телекоммуникационной отрасли, и предложено немало схем ее решения. Объем данной статьи не позволяет рассказать обо всех, но все же упомяну появившиеся недавно технологии MIDCOM и STUN (Simple Traversal of UDP through NAT). Работы по их стандартизации ведет организация IETF, на ее же сайте (www.ietf.org) находится и подробная информация об этих технологиях.

Сеть и ее качество

Видеокоммуникации — это новое приложение для IP-сетей, и оно, естественно, накладывает определенные требования к характеристикам сети. Как и в случае с развертыванием систем VoIP, здесь говорят, как правило, о четырех ключевых характеристиках обеспечения качества обслуживания (QoS): полосе пропускания, временной задержке, ее вариации (джиттер) и потере пакетов.

Итак, полоса пропускания. Помимо очевидного замечания, что для мультимедиа-трафика 100-Мбит/с сеть, конечно, лучше, чем 10-Мбит/с, а коммутаторы лучше концентраторов, хочется напомнить читателю о дополнительных накладных расходах IP. Если традиционная конференция бизнес-качества в сетях ISDN требует 384 Кбит/с, то в IP к этому добавляется примерно 25%-ный довесок в виде служебной информации — итого примерно 480 Кбит/с. Как уже говорилось в начале статьи, в IP-сетях полоса пропускания дешевле, чем в сетях ISDN, но все равно перед развертыванием системы видеоконференц-связи надо все четко рассчитать, чтобы быть уверенным, что полосы пропускания хватит.

В приложениях H.323 время “путешествия” пакетов (и с речью и с видео) от одной конечной точки до другой не должно превышать 125—150 мс. Средний размер пакета с видео (800—1500 байт) обычно больше размера аудиопакета (480 байт и менее). Это значит, что время задержки последних может оказаться меньше, поскольку коммутаторы/маршрутизаторы в сети обычно более “благосклонны” к маленьким пакетикам, пропуская их первыми в случае перегрузок. Что касается вариации задержки, то в рамках одного потока данных она не должна превышать 20—50 мс.

В предыдущем предложении я не случайно оговорился о вариации задержки в рамках одного потока данных. Дело в том, что при проведении сеанса видеоконференц-связи H.323 существует четыре информационных потока: каждый узел передает и принимает и аудио и видео. Разница в задержках пакетов разных потоков может привести к несинхронности изображения и звука. Если аудиопоток прибывает раньше видео, то участники конференции замечают эту несинхронность при разнице в задержке от 30 мс. В случае же если аудио запаздывает, несинхронность становится заметной лишь при более высокой разнице — 40 мс и более.

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

Если вы смогли выделить достаточную для всех приложений полосу пропускания, то основными для обеспечения требуемого качества обслуживания (для “разруливания” пакетов с разным трафиком) выступают алгоритмы классификации пакетов и их обработки в очередях. Как правило, пакетам с речевой информацией назначают наивысший приоритет (эти пакеты не слишком требовательны к полосе пропускания, но весьма чувствительны к задержкам и джиттеру), видеопакетам — чуть меньший уровень приоритета, а пакетам таких приложений, как, например, электронная почта, — самый низкий приоритет. Существует масса возможных схем классификации, одна из наиболее популярных предполагает установку значения IP Precedence в пакетах VoIP, равным 5, а в пакетах видеоконференц-связи — 4. После того как пакеты классифицированы, за дело берутся механизмы обработки очередей, которые и должны обеспечить каждому типу трафика необходимые ему характеристики передачи.

Для решения задачи гарантии качества обслуживания в пакетных сетях существует несколько основных подходов. По меньшей мере три из них предложены организацией IETF (RSVP, IP Precedence и DiffServ), один вышел из-под пера института IEEE (802.1p). Обо всех этих подходах наш журнал неоднократно рассказывал.

***

Надеюсь, теперь вы понимаете, что за красивой картинкой на проекционном экране в кабинете вашего шефа кроется большая работа по подготовке сетевой инфраструктуры и обходу всех тонких мест, связанных с развертыванием видеосистемы в пакетной сети. Что же касается выбора конкретной системы, то рекомендую читателям обратиться к предыдущему номеру нашего журнала, где в статье “Видео- и Web-конференции” представлен обзор продуктов основных игроков в этой области — компаний Polycom, Tandberg, RADVision и VCON. Помимо них, назову и таких производителей систем видеоконференц-связи, как Aethra, Ezenia!, Sony и VTEL. Недавно свои видеорешения представили активно работающие на российском рынке китайские компании Huawei и ZTE..


Товарный бетон м300 купить.




  
12 '2003
СОДЕРЖАНИЕ

электронная Россия

• Проблемы информатизации в ДФО

бизнес

• Заметки аудитора: как в России обслуживают пользователей?

• Новые перспективы развития рынка услуг спутниковой связи

• Пляжная форма обучения для дистрибуторов

инфраструктура

• Рекомендации по поддержке пользователей на дому

• Как организовать долговременное хранение данных

• Принципы выбора IP-УАТС

• Centrex в стиле IP

• Точное время в вашей сети

• Тестируем соединители MAPI для Microsoft Outlook

информационные системы

• «Повзрослевшие» системы обмена сообщениями

сети связи

• Поколение Next, или Метро-Ethernet в столице

• Видео по протоколу

• Конвергенция становится беспроводной

• IP-телефония. Кризис позади

кабельные системы

• Средства сращивания оптических волокон

• Тест не пройден. Что делать дальше?

• Как улучшить охлаждение серверов, сократив при этом затраты на их охлаждение

защита данных

• Сертификация средств безопасности

• К безопасному информационному обществу

новые продукты

• Система абонентского доступа IPTL компании Terayon


• Калейдоскоп



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх