С тех пор как технология передачи голоса по IP (Voice over IP, VoIP) привлекла к себе поистине всеобщее внимание, многочисленные производители средств ИТ стали пропагандировать идею «объединенных коммуникаций», под которыми подразумевается сочетание аудио, видео (в реальном времени или потоковая передача – Streaming), систем индикации присутствия (Presence) и других коммуникационных технологий. На самом деле оснащение большинства современных рабочих мест уже вполне достаточное для введения решений начального уровня, таких как Skype или Microsoft Live Messenger, и с их помощью могут предоставить пользователям все базовые функции – от чатов до видеотелефонии. На вершине шкалы качества расположены системы для проведения конференций и решения «телеприсутствия» (TelePresence), с помощью которых на единой платформе по сетям IP можно организовать любые виды коммуникаций, будь то видеозвонки или трансляция дискуссий из конференцзалов. Однако простота телефонии, которую обеспечивает Skype, не должна вводить в заблуждение: при внедрении корпоративных аудио- и видеоприложений требования к сетевым технологиям совершенно иные.

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

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

ВИДЕОПОТОКИ ПРОИЗВОДЯТ НЕПРЕРЫВНУЮ НАГРУЗКУ

Из-за такой чувствительности к сбоям при передаче пакетов механизмы TCP оказываются непригодны для улучшения качества отправления. Ведь если бы в случае потока реального времени протокол пытался заново передать недошедшие до адресата пакеты, то из-за задержек на обработку и передачу по сети они всегда прибывали бы с опозданием, отставая от текущих телефонных разговоров или видеоконференций на десятые доли секунды и даже больше. По этой причине приложения реального времени используют в качестве альтернативы TCP протокол передачи дейтаграмм пользователя (User Datagram Protocol, UDP), который обходится без механизмов восстановления.

В связи со сказанным возникает закономерный вопрос: какие же альтернативные методы помогут обеспечить быстроту и надежность потоков данных? Здесь важнейшим механизмом является качество сервиса (Quality of Service, QoS). Речь идет о целом пакете функций, посредством которых обеспечивается приоритет определенных типов данных в сети, таких как аудио или видео, по сравнению с менее чувствительными к времени передачи элементами, что позволяет реализовать высокое качество передачи. К числу наиболее популярных опций QoS принадлежат приоритетное обслуживание (Priority Queuing), индивидуальная маршрутизация приложений, управление пропускной способностью, а также механизм формирования трафика (Traffic Shaping). Приоритетное обслуживание является наиболее распространенным и поддерживается во множестве сетей, поэтому именно данную функцию мы рассмотрим более подробно.

КАЧЕСТВО СЕРВИСА

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

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

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

Внедрение QoS. На этом этапе необходимо убедиться, что выбранный механизм приоритетного обслуживания трафика в реальном времени доступен на каждом коммутаторе и маршрутизаторе в сети. Наиболее распространенные механизмы QoS: IntServ (RSVP), DiffServ, IEEE 802.1p/Q и IP Precedence.

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

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

Как правило, встречи продолжаются от получаса до часа. При расчете можно воспользоваться так называемыми таблицами Эрланга, которые доступны по адресу http://www.erlang.com. Среди инфраструктурных компонентов для видеокоммуникаций центральное место занимает конференц-сервер. Так, если в демонстрационном сценарии в одном сеансе связи задействовано 20 конечных точек, то все они должны установить с сервером полнодуплексное соединение. Например, каждая из этих точек получает поток данных со скоростью 1,1 Мбит/с, достаточной для передачи изображения высокой четкости (High Definition, HD), тогда трафик на сервере составит 22 Мбит/с. Если к этой цифре приплюсовать 20%, дополнительные накладные расходы при передаче пакетов по IP (Overhead), то итоговое значение составит 26,4 Мбит/с.

Как только определено, какая пропускная способность требуется для функционирования коммуникационного решения в реальном времени, можно рассчитать необходимую пропускную способность локальной и глобальной сетей. По возможности все клиенты должны располагать полнодуплексным соединением 100 Мбит/с. При планировании глобальной сети следует исходить из того, что поток аудио- и видеоданных никогда не должен превышать 35% емкости соединений, так как начиная с этого значения механизмы приоритетного обслуживания QoS теряют свою эффективность. Обычную загрузку сети традиционными приложениями следует измерить с помощью мониторинговых инструментов, чтобы определить, какая пропускная способность необходима в рабочее время.

Управление потребностями. Если тестирование показывает, что на критических участках сети пропускная способность недостаточно высока для поддержки коммуникации в реальном времени, то существуют три пути решения этой проблемы. Первый — увеличение пропускной способности — для многих сценариев является единственным способом, ведущим к цели. Вторая возможность — ограничение ресурсов для видеокоммуникации, что достигается разными способами. Для начала администратор может ограничить параметры передачи. Хорошее качество передачи достигается уже при скоростях от 512 Кбит/с до 1 Мбит/с, а при скорости 256-384 Кбит/с качество все еще останется вполне приемлемым. При использовании современного алгоритма сжатия видео H.264 качество передачи даже при низкой пропускной способности существенно увеличивается (см. врезку «Эффективные и стандартизированные кодеки»).

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

Штефан Карапетков – директор по новейшим технологиям компании Polycom.

© ITP Verlag

Типичные препятствия для видеокоммуникации

Главными препятствиями при введении аудио- и видеопотоков считаются непригодные компоненты инфраструктуры, прежде всего брандмауэры. Так, брандмауэры прикладного уровня (Application Layer Firewalls) обеспечивают более высокую надежность по сравнению с технологией фильтрации пакетов, однако им требуется больше вычислительных ресурсов. Как следствие, при возрастании объемов данных эти системы не успевают быстро обрабатывать пакеты, из-за чего пропускная способность, необходимая для коммуникации в реальном времени, снижается. Кроме того, следует проверить степень пригодности серверов-посредников и устройств преобразования сетевых адресов (Network Address Translation, NAT).

Интерактивные видеоприложения, как правило, базируются на протоколах H.323 и требуют наличия отдельного контроллера зоны (Gatekeeper), который отвечал бы за распознание адресов, управление пропускной способностью, а также за авторизацию и аутентификацию пользователей (см. Рисунок 1). Такой подход предполагает выполнение сложных настроек на брандмауэре для обеспечения требуемого функционала корпоративных приложений. Спектр необходимых мероприятий различен: от изолирования систем в пределах брандмауэра до открытия нескольких портов на устройствах с поддержкой H.323 и IP-туннелирования.

Новые возможности видеокоммуникации открываются с внедрением протокола инициирования сеансов (Session Initiation Protocol, SIP), который для прохождения брандмауэра задействует ряд механизмов, известных под названием Interactive Connectivity Establishment (ICE). Стандартизация ICE завершится в ближайшее время, а первые решения с его использованием уже разрабатываются.

Рисунок 1. Архитектура для передачи видео по IP: с точки зрения пользователей, системы для проведения видеоконференций (имя производителя значения не имеет) должны быть такими же простыми, как телефония, независимо от того, каким образом они реализуются – с помощью программного клиента или из специального помещения для TeleРresence. Предпосылкой для этого является инфраструктура, базирующаяся на открытых стандартах, например, H.323, и состоящая из специально предназначенных для этого компонентов.

Рисунок 2. Сжатие видео: по вертикальной оси откладывается качество изображения, в то время как на горизонтальной оси отображается требуемая пропускная способность. Стандартное разрешение (Standard Definition, SD), примерно соответствующее традиционному телевизионному формату, можно передавать при скорости от 56 Кбит/с. При активном движении в кадре понадобится около 356 Кбит/с.

Рисунок 3. Сжатие аудио: в зависимости от доступной пропускной способности выбор аудиокодека для видеоконференций делается в пользу узкого или широкого частотного спектра. Новый стандарт G.719 обеспечивает в монорежиме естественное воспроизведение звука с частотой 20 кГц уже при скорости от 32 Кбит/с. Для сравнения: его «прародителю» G.711, воспроизводящему всего 4 кГц, требуется достаточно большая пропускная способность.

Эффективные и стандартизированные кодеки

Быстрое распространение приложений с поддержкой VoIP и видеокоммуникаций было бы невозможно без разработки все более эффективных аудио- и видеокодеков (см. Рисунки 2 и 3). Наиболее известный пример — mp3, обеспечивающий высокое качество звучания при малом размере данных. Появление все новых приложений повлекло за собой целый поток оптимизированных алгоритмов кодирования и раскодирования в расчете на самые разнообразные области применения. Некоторые из них, такие как ITU-T G.711, разработаны для телефонных разговоров со средним качеством звука при скромных 64 Кбит/с, в то время как новый кодек H.264 пригоден для передачи видео с высоким разрешением во всех сетях.

В настоящее время существует около 250 аудио- и 730 видеокодеков – данное обстоятельство существенно затрудняет процесс стандартизации в среде объединенных коммуникаций. В попытке обеспечить максимальную совместимость систем и устройств производители стремятся внедрить в свою продукцию как можно больше кодеков, что делает решения излишне сложными: чем больше кодеков поддерживается, тем дольше осуществляется согласование конечных точек, а значит, и построение соединения. К тому же с интеграцией каждого дополнительного кодека возрастают требования к ресурсам памяти на конечных устройствах, что ведет к удорожанию аппаратного обеспечения.

С некоторых пор предпринимаются усилия по снижению количества кодеков для коммуникации в реальном времени. В июне 2008 г. ITU стандартизировала аудиокодек G.719. Его особенность заключается в том, что он кодирует полный спектр воспринимаемых человеком частот – от нуля до 20 кГц и благодаря этому как нельзя лучше подходит для систем конференц-связи и решений TeleРresence, ведь вопреки общему мнению именно воспроизведение аудиосигналов оказывает основное влияние на восприятие докладов и обсуждений. Участники конференции практически не замечают недостатки качества изображения, зато аутентичная передача фоновых разговоров и шумов существенно способствует созданию интерактивной атмосферы заседания. G.719 базируется на кодеке Siren 22 компании Polycom, который был доработан совместно с Ericsson и предоставлен для стандартизации.