На выставке ComNet 2001, состоявшейся в конце января в Вашингтоне, усилиями редакции Network World и компании Miercom было организовано первое в истории публичное тестирование совместимости аппаратных и программных средств передачи голоса по протоколу IP. Поставщики шлюзов и контроллеров доменов VoIP (gatekeeper), IP-телефонов, приложений телефонии и устройств IP-PBX пытались продемонстрировать всем присутствующим базовый уровень взаимодействия своих продуктов. Основная их задача состояла в организации вызовов и передаче голосового трафика между терминальными устройствами в соответствии со стандартом H.323 Международного союза электросвязи и практически с тем же качеством, которое обеспечивают традиционные телефонные сети.

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

Большая часть из тех двух с лишним тысяч пользователей, которые посетили наш стенд на ComNet 2001, изначально были настроены весьма скептически. Но результаты тестирования убедили их в том, что производители средств IP-телефонии достигли того уровня взаимодействия продуктов, который уже в ближайшем будущем позволит строить реальные сети передачи голоса и данных на базе оборудования разных поставщиков.

Важно заметить, однако, что такое взаимодействие пока не возникает само собой. Чтобы заставить различные продукты работать в составе одной сети, техническим представителям фирм-участников пришлось изрядно потрудиться, и даже несмотря на это, к концу тестирования ряд проблем остался нерешенным. Некоторые компании сумели наладить передачу голосового трафика лишь в одном направлении, другим не всегда удавалось организовать телефонный сеанс на основе ускоренной процедуры Fast Connect, определенной в стандарте H.323, наконец, еще больше фирм потерпели фиаско при попытках инициировать «двунаправленные» вызовы с использованием алгоритма «медленного старта» протокола TCP (см. Сети, 1999, № 11, с. 16).

Изучая рынок систем Voice-over-IP в течение последних двух лет, компания Mericom пришла к выводу, что многие производители, декларирующие совместимость своих изделий с продуктами других фирм, не в состоянии подтвердить ее в работающей сети. За это время было организовано множество тестовых испытаний, однако все они проходили за закрытыми дверями. Стремясь сломать сложившуюся практику, в декабре 2000 г. редакция еженедельника Network World обратилась к поставщикам систем VoIP с предложением принять участие в открытом тестировании, причем за основу была принята вторая версия стандарта H.323.

На это предложение откликнулись Avaya, Cisco, Clarent, HearMe, Memotec Communications, подразделение сетевых технологий корпорации Oki, Polypix, Quintum Technologies и подразделение корпоративных сетей компании Siemens. Кроме того, фирма Sitara Networks протестировала работу функций обеспечения качества сервиса, управления трафиком и кэширования, реализованных в устройстве QoSWorks, при наличии в сети оборудования других производителей. Таким образом, появилась возможность оценить эффективность приоритезации трафика TCP и UDP, например при передаче голоса в смешанной транспортной среде. Наконец, несколько фирм предоставили компоненты сетевой инфраструктуры и средства тестирования. В нашем распоряжении оказались коммутаторы Summit 48 и Alpine 3808 производства Extreme Networks, средства генерации вызовов Hammer IT и H.323 Call Generation Tool компании Empirix (прежняя Hammer Technologies), анализаторы трафика Internet Advisor (Agilent), Sniffer (Network Associates), 400 Ethernet Generator/Analyzer (Ixia) и средства тестирования от Abacus.

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

Из десяти производителей от предварительных исследований отказалась лишь корпорация Avaya. Остальные предоставили свое оборудование и делегировали как минимум по одному техническому специалисту, помогавшему в инсталляции, настройке конфигурации и тестировании продуктов. От Cisco и Clarent мы получили «эталоны» контроллеров доменов для проведения испытаний, а также другое оборудование VoIP.

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

Однако основную проблему представляла несовместимость эталонных контроллеров доменов: Gatekeeper Version 1.1 производства Clarent и аналогичных продуктов, функционировавших на маршрутизаторах 2611, 3660 и 7200 компании Cisco. Эти две фирмы по-разному реализовали стандарт H.323, так что передать голосовые пакеты от одного контроллера к другому не представилось возможным.

В режиме «прямых» вызовов, который используется в оборудовании Cisco, процедуры регистрации и обнаружения сетевых ресурсов, преобразования адресов и разрешения вызова контроллер домена выполняет по служебному каналу RAS (Registration, Admission and Status). Однако осуществив эти первоначальные действия, контроллер сразу же выходит из игры, предоставляя терминальному оборудованию самостоятельно устанавливать параметры вызова и обмениваться управляющей сигнальной информацией. По мнению сотрудников Cisco, подобное решение значительно повышает масштабируемость сети, поскольку чем дольше контроллер домена осуществляет мониторинг конкретного вызова, тем меньшее число вызовов он успеет обслужить в единицу времени.

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

Фирма Clarent позиционирует свою продукцию совсем не так, как Cisco, особо подчеркивая решающую роль управляющей системы Command Center в сборе и обработке сведений о функционировании сети. Эти данные являются жизненно важными для сервис-провайдеров, на плечи которых ложится колоссальный объем работы по обеспечению биллинга и других административных процедур. Мониторинг состояния вызова необходим для получения о нем точной информации, впоследствии направляемой в базу данных Command Center.

Чтобы хоть как-то преодолеть несовместимость контроллеров, были организованы два отдельных испытательных «полигона», каждый из которых включал в себя два домена. В одной тестовой сети управление осуществляли контроллеры доменов фирмы Cisco, а в другой — контроллеры производства Clarent.

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

Гибкость, обеспечиваемая стандартом H.323 и позволяющая разработчикам учесть конкретные требования сетевых приложений, имеет как положительные, так и отрицательные стороны. В процессе предварительного тестирования инженерам не раз приходилось подправлять исходные коды ПО, отвечавшего за управление вызовами, поскольку оборудование, которое устанавливалось на противоположном конце соединения, нередко было настроено на иной порядок следования служебных сообщений. Гибкость стандарта порождает несовместимость отдельных продуктов, так что в среде VoIP с оборудованием разных фирм приходится «подправлять» программное обеспечение IP-телефонии.

Именно по этой причине нельзя рассчитывать на способность изделий разных компаний успешно взаимодействовать друг с другом без какой-либо предварительной настройки. Нам повезло: и в ходе предварительных испытаний, и на самой выставке фирмы-участники взяли на себя устранение всех «шероховатостей», препятствовавших согласованному функционированию своих устройств. Однако в реальной жизни пользователи вряд ли могут рассчитывать на такой уровень технической поддержки. Скорее всего, им понадобится без конца «висеть» на телефоне, выясняя у сотрудников сервисных отделов производителей, как же заставить работать приобретенные продукты.

Сложность процедуры установления вызова представляет собой еще одну проблему. Согласно стандарту H.323, она включает в себя 18 (!) шагов. Неудивительно, что участники тестирования окрестили ее «медленным стартом». Стремясь упростить жизнь разработчикам и администраторам, авторы второй версии стандарта предусмотрели алгоритм быстрого соединения (Fast Connect), позволяющий организовать сеанс «точка — точка» всего за один цикл обращения по сети служебных пакетов (эта процедура иногда именуется «быстрым стартом» — по названию одного из компонентов кода, реализующего алгоритм Fast Connect).

Несмотря на то что большинству компаний удалось инициировать вызовы в соответствии с процедурой «медленного старта», некоторые столкнулись с затруднениями при попытке согласовать параметры вызова по алгоритму «быстрого старта». Причина крылась в особенностях кодирования речи. Так, в одном случае при наличии в сети контроллера доменов фирмы Clarent производителю не удалось завершить процедуру «быстрого старта», поскольку передающая сторона не имела IP-адреса и номеров портов RTP/RTCP (Real-Time Protocol/Real-Time Control Protocol), распознаваемых установленным контроллером. Небольшое изменение в программном коде, отвечавшем за инициацию вызова, позволило устранить проблему. Любопытно, однако, что никакой модификации того же ПО не потребовалось, когда дело дошло до реализации «быстрого старта» в сети с контроллером домена компании Cisco.

При испытании двух других продуктов, напротив, процедура Fast Connect прошла как по маслу, а инициировать вызовы по алгоритму «медленного старта» не удалось. Инженеры, занимавшиеся данной проблемой, несколько раз пытались проследить прохождение отдельных пакетов по сети, однако причина так и осталась невыясненной.

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

Поясним сказанное на простом примере. Допустим, что шлюз A поддерживает вокодеры стандартов G.711 и G.729, а шлюз B — вокодеры стандартов G.723 и G.729. Очевидно, что выбор в данном случае должен быть сделан в пользу вокодера G.729. Однако если шлюз B способен работать только с вокодерами G.723, взаимодействия достичь не удастся. Даже при наличии пересечения в списке поддерживаемых стандартов шлюз A может отправить сообщение о том, что он намерен работать с вокодером G.711 (хотя стандарт G.729 также поддерживается); в таком случае соединение будет разорвано.

Среди отрадных событий на этапе предварительного тестирования отметим удавшуюся пересылку факса со шлюза Cisco AS5300 на шлюз Clarent Gateway 400 через Clarent Gatekeeper в соответствии со стандартом факсимильной передачи T.38 Международного союза электросвязи. Если принять во внимание накопленный нами печальный опыт тестирования систем VoIP, данный факт следует признать крупным достижением.

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

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

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

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

Впечатляющие результаты удалось получить в ходе измерений производительности. После развертывания двух тестовых сетей (с контроллерами от Cisco и от Clarent) сотрудники фирмы Miercom запустили тест, который должен был выявить число вызовов между шлюзами Cisco AS5300 и Clarent Gateway 400, «прошедших» через контроллер Clarent Gatekeeper и успешно осуществленных в течение фиксированного отрезка времени. При этом для генерации вызовов использовался продукт Hammer IT компании Empirix. В течение 12 часов было предпринято 38 тыс. попыток инициировать вызов, и только шесть из них закончились неудачей. Таким образом, надежность сервиса VoIP в данной конфигурации составила 99,9984%. Надо заметить, что многие шлюзы VoIP, тестировавшиеся по отдельности в лаборатории компании Miercom, не смогли достичь такого уровня производительности.

Из продуктов, оказавшихся в нашем распоряжении, наиболее универсальным следует признать IP-телефон optiPoint 300 Advance корпорации Siemens: он успешно взаимодействовал с большинством остальных изделий, причем практически без предварительной настройки. Задержка после набора номера (Post-Dial Delay, PDD) составила 4 с, в то время как для обычных аналоговых и цифровых телефонов типичными являются значения 2 с и даже меньше. Четырехсекундная пауза, хотя и остается незамеченной, никак не влияет на качество последующей передачи голоса. В стандарте H.323 максимальная величина PDD вообще принята равной 10 с: по истечении указанного промежутка времени вызов срывается. Правда, на этом этапе мы не сравнивали задержку, которую выдает optiPoint, с аналогичными параметрами других IP-телефонов. Возможно, у них величина PDD оказалась бы еще большей.

Несмотря на изнуряющее многочасовое отслеживание прохождения пакетов по сети и анализ используемого программного обеспечения, некоторым производителям так и не удалось разрешить возникшие проблемы. Например, при работе в домене под управлением контроллера компании Clarent шлюз BV1250 фирмы Oki на стадии инициации вызова (но не при получении запроса об установлении сеанса) сумел наладить со шлюзами 3640 фирмы Cisco и шлюзами 100 и 400 компании Clarent только одностороннюю передачу. А вот «общение» со шлюзами Tenor, разработанными Quintum, и уже упоминавшимися IP-телефонами optiPoint 300 Advance от Siemens прошло без каких-либо затруднений.

Шлюзы Tenor фирмы Quintum отказались работать в одной сети с устройством CX950 производства Memotec; проблемы возникли при попытке инициировать вызов в соответствии с процедурой Fast Connect. Специалисты Avaya не смогли разрешить «противоречия», возникшие между IP-PBX IP600 этой фирмы и шлюзом Tenor. Судя по всему, загвоздка заключалась в несовпадении точек зрения на процедуры маршрутизации вызовов.

Итак, что же дальше? Принципиальная несовместимость контроллеров доменов производства Cisco и Clarent делает актуальным переход к следующему этапу тестирования, в ходе которого предстоит повторно оценить способность взаимодействия систем Voice-over-IP. Мы надеемся, что основные поставщики контроллеров (к таковым, помимо Cisco и Clarent, стоит отнести еще и Avaya) уже в текущем году решат проблему межзонного взаимодействия. Правда, ни одна из компаний не указала, когда такое взаимодействие удастся проследить на практике.

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

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

Что же касается способности изделий разных фирм успешно взаимодействовать друг с другом без какой-либо настройки, то этой заветной мечте всех пользователей сбыться, по-видимому, не суждено никогда. Кажется, в гетерогенной сети передачи голоса и данных избежать стадии предварительной «подгонки» попросту нереально. Стандарт H.323 слишком сложен и громоздок, чтобы можно было надеяться на обратное. Его новые версии, в настоящее время находящиеся в стадии рассмотрения, позволят несколько упростить ситуацию, тем не менее от сотрудников корпоративных IT-отделов все равно потребуется глубокое знание всех существующих вариантов H.323 – лишь тогда они сумеют совладать с весьма своенравными системами VoIP разных производителей. Не обойтись и без детального сервисного контракта, в соответствии с которым поставщик обязан оказывать техническую поддержку с выездом в офис организации-заказчика, по крайней мере на стадии развертывания и наладки комбинированной сети с оборудованием IP-телефонии.

Чтобы оценить возможности практического использования систем H.323 в среднесрочной перспективе, имеет смысл выяснить, как обстоит дело с протоколами попроще, например с Media Gateway Control Protocol и SIP. Наше следующее открытое тестирование взаимодействия систем VoIP состоится на июньской выставке SuperComm, которая будет проходить в Атланте. Там мы снова предложим производителям, не устающим заявлять о полной совместимости своих продуктов с чем бы то ни было, подтвердить справедливость этих слов перед судом общественности.

ОБ АВТОРАХ

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

В тестах базового уровня производителям предстояло инициировать телефонный вызов через шлюз AS5300 фирмы Cisco или Gateway 400 компании Clarent между своим продуктом (IP-телефоном, приложением IP-телефонии или IP-PBX) и терминальным оборудованием телефонной сети общего пользования. Соединение между шлюзом и ТфОП осуществлялось по каналу T1 с использованием устройства TSU-100 от Adran. В роли терминального оборудования, подключенного к аналоговой коммутируемой линии, выступал обычный аналоговый телефон.

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

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

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