В апреле нынешнего года в одном из корпусов компании iLabs мы погрузились в тестирование сотен сетевых продуктов. Через несколько недель это оборудование должно было предстать взору посетителей весенней выставки Networld + Interop, традиционно проходящей в Лас-Вегасе. Как информационный спонсор демонстрации взаимодействия разработок разных фирм InteropNet Labs, организованной на выставке, редакция Network World получила эксклюзивный доступ к результатам предварительного тестирования.
Одна из серий тестов была посвящена взаимодействию систем пакетной телефонии, поддерживающих протокол Session Initiation Protocol (SIP). Но сказать только то, что прошло испытание SIP-оборудования, значит не сказать ничего. При проведении тестов пришлось исследовать множество нюансов, связанных с этим протоколом.
В испытаниях участвовали более 50 изделий от пяти производителей SIP-серверов и множество оконечных SIP-устройств, выпускаемых 13 компаниями (см. рисунок). Используя столь представительную совокупность продуктов, мы попытались доказать, что работоспособную сеть пакетной телефонии, основанную на протоколе SIP, можно построить на основе оборудования нескольких фирм. Основные результаты испытаний сводятся к следующему: взаимодействие протестированных устройств на уровне базовых возможностей SIP выше всяких похвал, а вот более «продвинутые» функции, будь то переадресация вызовов или организация конференц-связи между несколькими узлами, далеко не всегда выполняются гладко.
Простота — главный аргумент в пользу применения SIP в сетях VoIP (по сравнению с гораздо более сложным протоколом H.323). Теоретически, именно эта простота должна привести к минимизации проблем на уровне взаимодействия разных продуктов и заметному упрощению конфигурирования устройств. По сравнению с испытаниями оборудования H.323, которые сотрудники iLabs провели ранее, переход на SIP позволил подключить больше терминальных устройств к большему числу серверов, затратив на это гораздо меньше времени. За исключением единственной устаревшей модели, позаимствованной одним из инженеров из собственной сети, все оконечные SIP-устройства прошли базовые тесты на обработку вызовов.
Начнем сначала
При построении среды тестирования мы исходили из потребностей компании среднего размера, стремящейся развернуть «с нуля» сеть пакетной телефонии на базе протокола SIP. Проектирование такой сети во многом схоже с проектированием ЛС. Вы обязаны предусмотреть все детали, включая IP-адреса оконечных устройств, настройку сервисов голосовой почты и конференц-связи, поддержку вокодеров и схему именования сетевых узлов. Одним из первых шагов при этом является выбор плана нумерации, который определяет длину телефонных номеров, особенности адресации абонентов ТфОП через голосовой шлюз и разделение внутренней телефонной сети между несколькими SIP-серверами (см. врезку).
В традиционной корпоративной телефонной сети план нумерации «встроен» в учрежденческую АТС, а в сети SIP его необходимо настраивать отдельно на каждом телефоне. Если этого не сделать, конечным пользователям при наборе номера придется либо дожидаться тайм-аута, предусмотренного в самом телефоне, либо вводить специальный символ завершения набора номера (обычно для этого используется знак фунта) аналогично нажатию кнопки вызова на сотовом телефоне.
Сложность конфигурации среды тестирования заставила нас прибегнуть к весьма замысловатому плану нумерации; как оказалось, поддерживать его в состоянии далеко не всякий телефон. В пределах сети звонок с одного телефона на другой осуществлялся при помощи четырех цифр, но для выхода в ТфОП и использования SIP-сервиса eNet, доступного на выставке Networld + Interop, либо бесплатного сервиса Free World Dialup приходилось вводить однозначный префикс (например, цифру «9») и лишь затем — номер абонента другой сети. Ряд терминальных SIP-устройств не продемонстрировал подобной гибкости, при работе с ними понадобилось набирать последовательность из 19 цифр, после чего дожидаться тайм-аута или вводить символ завершения набора номера. Не беремся утверждать, что эта проблема связана с несовместимостью продуктов разных поставщиков; возможно, дело в элементарных просчетах разработчиков.
Задав план нумерации, мы установили пять прокси-серверов, поддерживающих протокол SIP: Asterisk фирмы Digium и SIP Express Router (SER) компании iptel.org, использующие открытый код, а также коммерческие продукты Avaya, Cisco и Nortel. Каждый из SIP-серверов должен был поддерживать несколько телефонов и посылать вызовы на другие серверы. В общей сложности в тестировании задействовалось более 40 телефонов, каждый из которых был «приписан» только к одному прокси-серверу; именно этот сервер отвечал за маршрутизацию всех SIP-вызовов, относившихся к данному телефону.
Когда на уровне обычных телефонных вызовов между SIP-серверами было достигнуто стопроцентное взаимодействие, мы решили усложнить задачу, запустив Enum-тест (Enum — технология универсальной адресации для различных терминальных устройств, подключенных к сетям разных типов. — Прим. ред.). Хотя в США проект международного стандарта, регламентирующего взаимодействие сетей VoIP на базе Internet и телефонных сетей общего пользования посредством DNS Enum, погряз в пучине политических интриг, сама концепция Enum может быть использована на уровне корпоративной сети, в которой сформировано самостоятельное дерево DNS. На SIP-серверах Asterisk и SER, поддерживающих технологию Enum, соответствующие функции выполнялись превосходно.
Завершив тестирование базовой функциональности, мы приступили к проверке взаимодействия терминальных устройств, подключенных к конкретному SIP-серверу (их отключили от остальных). И тут возникли определенные проблемы: ряд телефонов заставил инженеров изрядно попотеть как на стадии инсталляции, так и непосредственно при проведении тестов.
Большая часть SIP-терминалов представляла собой телефонные аппараты, управление которыми, как правило, осуществлялось через Web-интерфейс. Среди изготовителей таких изделий были и крупнейшие производители (Avaya, Cisco, Siemens), и менее известные компании (Grandstream Networks, ipDialog, Pingtel, Polycom, Pulver Innovations, Snom Technology). Кроме того, мы протестировали программные телефоны для операционных сред Windows и Mac OS X производства Xten, а также FXS-шлюзы (устройства, обеспечивающие подключение обычных аналоговых телефонов к SIP-сети. — Прим. ред.) производства AudioCodes, Cisco, D-Link, MIP Telecom и Multi-Tech Systems.
При звонках между телефонами, подключенными к одному и тому же SIP-серверу, было достигнуто практически стопроцентное взаимодействие продуктов разных фирм. Тест запускался 230 раз, и только в семи случаях не удалось добиться его выполнения путем перенастройки конфигурации. Все эти случаи относились к двум довольно специфическим сочетаниям телефонов и прокси-серверов (телефон фирмы ipDialog с прокси-сервером SER и аппарат Polycom с прокси-сервером Avaya). Наиболее типичная проблема состояла в том, что телефоны устанавливали соединение друг с другом, но отказывались воспринимать голосовой трафик.
Хотя в целом этот этап тестирования прошел успешно, надо отметить, что VoIP-решения, поддерживающие протокол SIP, еще далеки от совершенства. Мы столкнулись, например, с тем, что часть вызовов не завершалась, а отдельные телефоны не звонили. Впрочем, все нормализовалось, стоило перезагрузить телефоны или набрать номер еще раз.
В нашей сети пакетной телефонии для каждого терминального устройства был выделен один порт коммутатора с пропускной способностью 100 Мбит/c. Как оказалось, сеть VoIP чрезвычайно чувствительна к минимальным изменениям в топологии. Обнаружив, что многим SIP-телефонам небезразлично, какая именно реализация протоколов TCP/IP используется в сети, мы были вынуждены выполнить ряд настроек для сервисов DNS и DHCP. Скажем, телефоны Cisco время от времени отказывались завершать сеанс, если запросы к серверу DNS передавались через маршрутизатор, но стали функционировать нормально, как только на сервер DNS загрузили функцию немаршрутизируемой передачи вызовов.
Полной неожиданностью для нас стал сбой при выполнении одного из простейших сценариев взаимодействия. Мы подключили демультиплексор фирмы Adtran (который разбивает мультиплексированный телефонный канал T1 на 24 отдельные линии для подключения традиционных аналоговых аппаратов) к плате фирмы Digium с интерфейсом T1, дабы обеспечить выход с некоторых телефонов в ТфОП. К сожалению, демультиплексор не совладал с недорогими аналоговыми аппаратами, специально приобретенными для тестирования. Два телефона вообще вышли из строя.
Функции против правил
Простое осуществление вызовов — лишь одна из задач корпоративной системы пакетной телефонии. В процессе тестирования нас особенно интересовала переадресация вызовов. С ней возникли дополнительные проблемы, как только мы попытались наладить взаимодействие телефонов с прокси-серверами, поддерживающими протокол SIP.
Само по себе тестирование этих функций не представляет труда, но определить причины некорректной работы оборудования — задача не из легких. Хорошей подмогой стали анализаторы протоколов EtherPeek NX компании WildPackets и ClearSight Analyzer производства ClearSight Technology. Второй продукт создавался специально для применения в системах VoIP. Особенно полезной оказалась его способность записывать вызовы VoIP, а затем воспроизводить их, без чего практически невозможно выявить причины невысокого качества голоса в пакетной сети.
Многочисленность функций, встроенных непосредственно в SIP-телефоны, а не в прокси-серверы, приводит к тому, что в сети уже нет единственного узла, который отвечает за поддержку всей функциональности. Например, функция перевода звонка сильно страдает от отсутствия стандартной номенклатуры, поддерживаемой разными поставщиками. Под переводом звонка одни компании понимают перевод «вслепую», при котором вызов просто переадресуется с одного телефона на другой. Другие имеют в виду «совещательный» перевод: абонент сначала берет трубку и лишь потом указывает, какую операцию следует выполнить. В мире традиционной телефонии подобные функции очень похожи и реализуются на удивление просто, но в системах VoIP различия между ними носят принципиальный характер.
Проблемы на уровне взаимодействия разных устройств возникли и в тех областях, в которых VoIP-сообщество не достигло согласия по концептуальным вопросам. Так, до сих пор сохраняется несколько вариантов транспортировки по сети VoIP двухтональных многочастотных сигналов (DTMF), которые мы слышим при наборе номера. Один вариант — их передача непосредственно в тональном режиме в виде DTMF-сигналов наряду с другими данными. Другой — предварительное преобразование в специальный формат, определяемый спецификацией RFC 2833 и предполагающий использование дополнительных заголовков, по которым принимающая сторона распознает факт генерации DTMF-сигналов.
Мы использовали формат RFC 2833, отличающийся повышенной надежностью, и неожиданно столкнулись с тем, что два сочетания устройств (телефон WiSIP с прокси-сервером Asterisk и телефон Siemens с прокси-сервером Avaya) не хотели работать, как положено. Самое любопытное, что упомянутые телефоны успешно взаимодействовали с другими SIP-серверами, а названные прокси-серверы без проблем обслуживали другие телефоны. Нам так и не удалось определить, какое же оборудование стало источником проблемы.
Тестируя другие функции, представляющие интерес для корпоративных клиентов (удержание и восстановление вызова, отправка и прием вызовов по нескольким линиям, динамическая переадресация вызова и установление конференц-связи), мы также столкнулись с проблемами. Хотя большинство функций поддерживалось, в целом процент успешно завершенных тестов оказался намного ниже, чем при простом дозвоне с одного телефона на другой.
Иногда виновник проблем обнаруживался довольно быстро. Например, невозможность осуществить перевод вызова при наличии в сети прокси-сервера Asterisk недвусмысленно указывала на то, что причина крылась именно в нем. Аналогичный дефект проявился и у телефонов Siemens: нам не удалось выполнить перевод вызова с этих телефонов при использовании разных SIP-серверов.
ТфОП и брандмауэры
Среди задач испытания было намерение продемонстрировать варианты подключения корпоративной SIP-сети к ТфОП непосредственно через Internet, с использованием услуг Internet-провайдера. Для этого мы организовали соединение с Free World Dialup, бесплатной SIP-сетью, которая имеет выходы в ТфОП нескольких операторов. Надо отметить, что три провайдера коммерческих услуг SIP-телефонии — Voicepulse, Vonage и Packet8 — отказались сотрудничать с нами.
Использование канала в Free World Dialup выявило еще одну серьезную проблему совместимости продуктов — обеспечения безопасности. Первоначально для защиты тестовой SIP-сети мы установили последнюю и наиболее «продвинутую» версию брандмауэра Firewall-1 производства Check Point. В его состав включен прокси-сервер, поддерживающий протокол SIP. Основываясь на весьма распространенной модели мониторинга, SIP-шлюз этого брандмауэра собирает информацию о работающих в сети прокси-серверах и применяемой SIP-сигнализации. Затем эти данные используются при установлении соединений между прокси-серверами, так что два телефона получают возможность «общаться» друг с другом напрямую.
К сожалению, мировые сети IP-телефонии, вроде Free World Dialup, практически не отгорожены от остального мира, поэтому подключиться к ним через Internet можно с любого компьютера. В этой связи реализованные в Firewall-1 расширенные возможности SIP-телефонии не представляли для нас большой ценности. Даже если вы не подсоединили собственную SIP-сеть к аналогичной инфраструктуре другой компании, вы столкнетесь с проблемами, как только разрешите конечным пользователям применять программные телефоны или обычные телефонные аппараты в дистанционном режиме. При таком сценарии вам наверняка понадобятся надежные средства защиты, например на базе туннелей IPSec VPN.
Наконец, в тестовой сети был установлен SIP-брандмауэр IX66 компании Intertex, размещенный между прокси-сервером Asterisk и SIP-телефоном Polycom. При работе с этим продуктом мы не заметили каких-либо изменений ни в области взаимодействия различных устройств, ни в наборе поддерживаемых функций.
Тестируйте сами
Следует отметить несколько областей, требующих дополнительного тестирования оборудования. Одна из них — качество голоса. Некоторые SIP-устройства, например FXS-шлюз производства AudioCodes, настроены на оптимальное функционирование в сетях с низкой задержкой (вроде FastEthernet). Работая с ними, мы не заметили какой-либо задержки при передаче голосового трафика. Напротив, при использовании программных телефонов X-Pro фирмы Xten (в версиях и для Windows, и для Mac OS) сочетание задержек, вносимых тестовыми ноутбуками и средствами обработки вызовов в Internet, приводило к высокой вариабельности суммарной задержки.
Большинство аппаратных и программных SIP-телефонов, а также шлюзов позволяют настроить неравномерность задержки с учетом общей производительности сети. При тестировании конкретной системы с целью определить возможность ее развертывания в корпоративной среде следует принять во внимание и человеческий фактор, будь то управление флуктуациями или корректная настройка задержки для голосового трафика.
Нумерация в сетях SIP
Всякой телефонной сети требуется план нумерации, определяющий, что должно происходить при наборе того или иного номера. Скажем, в США используется североамериканский план нумерации, в соответствии с которым международным вызовам должны предшествовать цифры «011», а междугородным — «1».
Приступая к разработке плана нумерации для тестирования, мы и не подозревали, с каким разнообразием деталей нам придется иметь дело. Как и во всех случаях обсуждения человеко-машинного интерфейса, при выборе того, какие цифры следует набирать и чему они должны соответствовать, страсти накалились до предела.
Чтобы читатель составил себе адекватное представление о возникающих в этой области проблемах, достаточно упомянуть схему выхода за пределы компактной тестовой УАТС, т. е. во внешние телефонные сети. Одна половина нашей команды настаивала на использовании традиционной «девятки», другая — на полном исключении каких бы то ни было префиксов: снял трубку и сразу набираешь номер абонента.
У каждого из этих вариантов есть свои плюсы и минусы. Например, в тех местах, где зональный код требуется вводить перед набором любого телефонного номера, в дополнительной «девятке» нет необходимости. И наоборот, если в организации ранее использовалась традиционная учрежденческая УАТС (с привычной «девяткой»), то переход на протокол SIP пройдет безболезненно при полном сохранении прежнего плана нумерации, даже если в таком префиксе уже нет необходимости. Последнее соображение справедливо вдвойне, если наряду с сетью пакетной телефонии на предприятии намечено какое-то время использовать традиционную УАТС.
К сожалению, проблемы с планом нумерации на этом не заканчиваются. В среде тестирования мы никогда не знали, через какое число прокси-серверов проходил наш звонок на пути к вызываемому абоненту. В результате из четырех цифр любого телефонного номера первые две пришлось использовать для маршрутизации вызова на определенный прокси-сервер, а две последние — для адресации собственно телефона. Подобный вариант маршрутизации позволяет не хранить на каждом SIP-сервере сведения обо всех существующих в сети телефонах; вполне достаточно информации об остальных серверах.
План нумерации задается на уровне программного обеспечения на каждом SIP-сервере сети и частично загружается на каждый телефон. Телефонам не требуется информация о маршрутизации вызовов, но без данных о количестве цифр в телефонном номере обойтись они не могут. Причина проста: в сетях VoIP именно телефоны, а не УАТС, как прежде, определяют, закончен ли набор номера и не пора ли отправлять вызов в сеть.
Телефоны без загруженного плана нумерации инициируют вызов либо после ввода специального символа окончания набора номера, либо по истечении определенного промежутка времени — тайм-аута (он обычно составляет 4—5 с). Некоторые телефоны способны функционировать без сведений о плане нумерации, использования терминирующего символа и прочих ухищрений. Они пытаются инициировать вызов после каждой введенной цифры, ориентируясь на различные коды состояния, поступающие от SIP-сервера (номер не существует, имеет недостаточную длину и т. п.). В крупных сетях корпоративной телефонии необходимые сведения о плане нумерации записываются в конфигурацию телефона при его загрузке.
Разработка плана нумерации — важная стадия при проектировании любой системы SIP-телефонии, поскольку его последующая корректировка потребует внесения изменений в конфигурацию всех устройств сети. Подобно тому как правильное проектирование пространства IP-адресов и схемы адресации подсетей должно предшествовать развертыванию всякой сети TCP/IP, правильный выбор плана нумерации избавит вас от множества проблем.