Системы voip: тест на совместимость

На выставке 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).

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

ОБ АВТОРАХ

Бетси Йоком — старший редактор, Уве Билгер — старший инженер тестовой лаборатории, Роб Смитерс - президент, а Майкл Хоммер — менеджер компании Miercom (Принстон, шт. Нью-Джерси), специализирующейся на консалтинговых услугах и тестировании телекоммуникационных продуктов. С ними можно связаться по адресам byocom@mier.coma>, ubilger@mier.com, rsmithers@mier.com и mhommer@mier.com

Методология тестирования

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

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

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

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

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