Успех программных коммутаторов будет зависеть от их совместимости и стандартизации протоколов.

Технология программной коммутации (Softswitch) по мере своего распространения меняет сложившийся облик телефонных сетей и расстановку сил на телекоммуникационном рынке. По прогнозам In-Stat/MDR, к 2008 г. объем мирового рынка программных коммутаторов — при среднегодовом росте около 65% — может вырасти до 2,05 млрд долларов. Как отмечают аналитики ФГУП ЦНИИС, программно-аппаратные решения на базе программных коммутаторов вызывают интерес операторов связи как средство модернизации телефонных сетей, внедрения новых услуг и подготовки инфраструктуры к услугам следующего поколения.

КТО В ЛЕС, КТО ПО ДРОВА

Сегодня практически все операторы, активно работающие с VoIP, осознают необходимость использования программных коммутаторов в своих сетях, однако главными сдерживающими факторами на пути массового внедрения данной технологии остаются проблемы совместимости, большое число открытых протоколов (MGCP, MEGACO, SIP, H.323, SIGTRAN и проч.), наличие конкурирующих стандартов и проектов стандартов. Неоднозначность спецификаций приводит к появлению различающихся реализаций протоколов. Кроме того, программные коммутаторы по-разному выполняют одинаковые функции. Вдобавок многие из них до сих пор не поддерживают целый набор операторских функций, свойственных АТС. Довольно часто недостаточно стабильно работают программные коммутаторы при пограничных и высоких нагрузках, из-за чего операторам приходится предварительно тестировать их, проверяя адекватность данных решений для различных объемов сетевого трафика.

Существующие схемы взаимодействия фрагментов сети на базе программных коммутаторов требуют высоких затрат на эксплуатацию инфраструктуры IP/TDM, а при инкапсуляции протоколов сигнализации телефонных сетей в пакеты IP по протоколу SIGTRAN могут возникать проблемы совместимости с традиционным коммутационным оборудованием TDM из-за особенностей обработки команд M3UA (протокола, реализующего функции передачи сообщений MTP3) контроллером медиа-шлюзов (Media Gateway Controller, MGC).

Александр Ляхов, руководитель группы голосовых решений для операторов компании «АМТ Груп», считает вопрос совместимости оборудования различных производителей одной из наиболее сложных проблем при внедрении и эксплуатации программных коммутаторов. В процессе выбора решения операторам приходится выполнять различные тесты на совместимость и тщательно проверять соответствие реализации протоколов сигнализации актуальным версиям стандартов: ведь только в случае четкого следования стандарту решение может успешно стыковаться с максимальным числом оконечных устройств и с оборудованием других операторов. Безусловно, такую оценку могут сделать только эксперты.

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

SIP И NAT

Одной из проблем IP-телефонии остается сложность передачи сигнализации и голосового трафика через межсетевые экраны/устройства Network Address Translation (NAT). В некоторых реализациях NAT после подмены адресов адреса в заголовках пакета Session Initiation Protocol (SIP) перестают соответствовать адресам в теле пакета, из-за чего возникают проблемы при обработке команд SIP программными коммутаторами.

Нередко в качестве решения предлагается применять шлюзы прикладного уровня (Application Layer Gateway, ALG), обрабатывающие как заголовки пакета IP, так и его информационное наполнение. Функции ALG могут выполнять пограничные контроллеры соединений (Session Border Controller, SBC) или маршрутизаторы, транслирующие управляющие сообщения SIP. К сожалению, обработка каждого пакета требует высокой производительности и повышает стоимость решения. К тому же новые модификации протокола требуют, чтобы ПО SIP ALG постоянно обновлялось, а его производитель следил за всеми изменениями, реализуемыми поставщиком устройств SIP и Softswitch. Остается и проблема обработки шифруемого трафика. Как отмечают аналитики ЦНИИС, попытки задействовать поддерживаемый в большинстве межсетевых экранов механизм Universal Plug and Play (UPnP), предназначенный для того, чтобы клиентские устройства SIP могли передавать межсетевому экрану/ NAT служебные сообщения с данными для автоматической настройки, угрожают безопасности сети. Вдобавок для этого требуется правильно идентифицировать большой спектр оборудования IP-телефонии и программных коммутаторов.

Более надежный вариант состоит в использовании специальных общедоступных серверов, с помощью которых клиенты SIP могли бы определить тип NAT и настроиться на него. Для этого разработан механизм Simple Traversal of UDP through NATs (STUN). К сожалению, STUN поддерживают не все разновидности NAT. Возможно, преодолеть эти препятствия поможет проект спецификации Interactive Connectivity Establishment (ICE), которая дополнит протокол SIP описанием возможностей телефона SIP и межсетевого экрана/NAT.

Александр Фелижанко, системный инженер-консультант Cisco Systems в области пакетных решений, считает, что проблема NAT решается по мере развития механизмов STUN — например TURN (Traversal Using Relay NAT, draft-rosenberg-midcom-turn-06) и ICE (draft-ietf-mmusic-ice-03), — а также с помощью SBC: оснащенные функциями NAT и RTP Proxy, они устанавливаются между абонентским оборудованием и программным коммутатором.

В целях оптимизации доступа к услугам SIP компания Nortel разработала портал RTP, применяемый в ряде зарубежных сетей. В частности, он позволяет подключать к сети клиентов, когда их оборудование (СРЕ) не поддерживает корректной реализации NAT для SIP. Портал RTP может внедряться как в приложения SIP, так и в H.323, а также в другие протоколы, например в SIP-T для связи с другими сетями VoIP, поскольку он не зависит от используемого протокола управления, а работает только с голосовым трафиком (RTP).

Портал RTP предназначен для операторов, чье оборудование работает без поддержки SIP ALG. Это устройство с функциями посредника устанавливается на границе сети доступа и операторской сети, позволяет обойти трансляцию адресов протокола SIP и избежать проблем некорректной обработки сообщений. Технология Nortel подходит только для ею же выпускаемых программных коммутаторов: компания использует собственный набор команд управления порталом RTP в рамках протокола MGCP+, а программный коммутатор должен уметь включать его в цепочку установления вызова. Последний соединяет двух абонентов с порталом RTP, объединяющим трафик клиента SIP и удаленного шлюза.

По мнению Алексея Собкевича, менеджера российского офиса Nortel, портал RTP позволит оператору предоставлять услуги SIP даже клиентам с ограниченным бюджетом, которые не могут использовать Customer Premises Equipment (СРЕ) с SIP ALG. В этом случае кроме возможности быстрого выхода на новые рынки VoIP оператор сможет предоставить клиентам реальную мобильность в Internet, где существует много систем NAT, не выполняющих корректных функций NAT для SIP. Соединение будет устанавливаться при прохождении звонка через любые устройства NAT и proxy, а оператор тарифицирует звонки в своей сети, где бы ни находился клиент, получающий унифицированный набор услуг с единым счетом за них. В представлении специалистов Nortel такой способ организации сетей доступа решает множество задач, включая выполнение требований российских регулирующих органов. Конфигурация портала RTP не зависит от используемых расширений протоколов и характера трафика, и через него могут работать различные мультимедийные услуги.

Как утверждают в Nortel, это решение упрощает требования к клиентской сети и оборудованию, обеспечивая безопасное взаимодействие по IP. В отличие от SBC, портал RTP не терминирует сигнализацию и трафик RTP, поэтому не вносит дополнительных задержек; он способен работать с различными модификациями RTP, включая шифрование RTP на оконечном оборудовании. Кроме того, портал RTP помогает оптимизировать архитектуру сетей и обеспечивать скрытность услуг (СОРМ) и изоляцию сети (безопасность), а также контроль доступа и защиту от атак DoS/DDoS (в комбинации с другими продуктами Nortel). Для согласования нестандартных протоколов рекомендуется комбинировать его с SBC.

Другие специалисты отводят SBC более весомую роль. Иван Дементьев, руководитель инженерного отдела компании CTI, выделяет такие проблемы с внедрением VoIP в реальных проектах, как IP-адресация и безопасность (NAT/межсетевые экраны), агрегирование трафика VoIP в сетях доступа (xDSL, MPLS VPN), взаимодействие с операторами-партнерами (безопасность, совместимость протоколов VoIP, кодеков и оборудования). Он считает, что большая их часть решается при помощи SBC с поддержкой ALG. С другой стороны, облегчаются и задачи мониторинга качества соединений (QoS). Наделение SBC функциональностью посредника RTP позволяет анализировать параметры QoS без применения агентов и зондов. Обычно для контроля QoS необходимо отслеживать неравномерность задержки, задержку и потерю пакетов.

В БОРБЕ ЗА КАЧЕСТВО

Производители используют различные способы достижения требуемого качества соединений VoIP. В частности, технология VoIP не предусматривает встроенных средств по ограничению количества вызовов, проходящих через пакетный интерфейс. Как вариант Nortel предлагает использовать в магистральных сетях (например, построенных на базе арендованных каналов Е-1) VoATM с дальнейшей миграцией к VoIP. Шлюзы пакетной сети, связанные через интерфейсы ATM, могут проверить возможность установления вызова с заданным качеством по конкретному направлению (Call Admission Control для SVC), что позволяет ввести ограничения для обеспечения требуемого уровня QoS. В результате упрощаются автоматическое реагирование на проблемы в магистральной сети и настройка конфигурации, а канальная емкость используется эффективнее. Качество же речи выше в каналах ATM за счет меньших задержек по сравнению с VoIP.

Если ATM дает определенные преимущества на магистрали, то технология IP обеспечивает более широкие (и менее дорогие) возможности подключения пользователей и реализации услуг Класса 5. Уже разработаны коммерческие реализации средств Call Admission Control (CAC) для сетей доступа, например на Nortel MSC 5200 (сервере приложений SIP для CS 2000 Softswitch), однако разработки ведутся и по интеграции этих функций в CS 2000 для использования в магистральных сетях IP. CS 2000 и CS 2000 Compact поддерживают и IP, и АТМ, а методы построения конфигураций сетей в конкретных проектах упрощают переход от одной технологии к другой без перерывов в функционировании сети. В решениях других производителей функции CAC иногда возлагаются на SBC.

Для контроля качества линии связи операторы нередко применяют комплексные индикаторы. Например, в «Зебра Телеком» используют комбинацию процента удачных звонков и средней продолжительности соединения. Внедряя такой индикатор, специалисты разработали для него единую шкалу, оценив разброс показателя и критические значения на основе данных, накопленных компанией за длительный период работы. Это дает возможность автоматически переключать направление на альтернативный канал, а визуализация подобных показателей позволяет точнее контролировать состояние сети. Для партнерских сетей предлагается еще один метод обеспечения сквозного качества VoIP — организация качественных каналов MPLS в удаленные регионы России с максимально близким доведением к технической площадке партнера.

УГРОЗЫ БЕЗОПАСНОСТИ

При использовании VoIP приходится всерьез задумываться о возможных угрозах: хакерских атаках, «червях» и спаме по протоколу VoIP (в случае широкого распространения программ наподобие Skype). Наиболее серьезной проблемой остаются атаки, нарушающие функционирование сетей (такие, как DoS), в частности вследствие уязвимости отдельных реализаций протокола H.323. Эксперты считают проблемы безопасности VoIP очень серьезными, поскольку действия злоумышленников могут привести к неприемлемому снижению качества, выходу из строя клиентского оборудования и парализовать работу сети. Нередко при сопоставимой «мощности атак» ущерб оказывается несравнимо большим, чем от проблем в сетях передачи данных, поэтому безопасности уделяется особое внимание, и для ее обеспечения в сетях VoIP производители предлагают набор решений, обычно на уровне протокола IP.

Распространенным методом защиты сети от атак DoS является механизм CAC: при настройке SBC провайдер устанавливает ограничение на максимальное количество входящих звонков, по достижении которого система прерывает соединение для всех новых вызовов или завершает его со специальным кодом разъединения для возможного направления звонка на другой маршрут (пример — новая версия MERA MVTS Softswitch). Кроме того, SBC обычно работают как межсетевые экраны уровня приложений (VoIP Firewall), защищая сеть на уровне протоколов VoIP. В сочетании с традиционным межсетевым экраном SBC способны реализовать комплексную защиту от атак DoS в сети провайдера VoIP.

ПО ПУТИ СТАНДАРТИЗАЦИИ

Дальнейшее развитие рассматриваемой технологии могло бы способствовать применению программных коммутаторов как элементов унифицированной сервисной архитектуры IP Multimedia Subsystem (IMS), поддерживающей широкий спектр услуг на базе SIP, где с помощью серверов приложений реализуются не только услуги обычной телефонии, но и услуги обмена сообщениями, конференц-связи, передачи видеопотоков и т. д. Ожидается, что IMS позволит операторам беспроводных сетей предоставлять услуги VoIP и мультимедийные услуги на базе IP, однако для конвергенции услуг в проводных и беспроводных сетях необходимо разработать стандартизованные механизмы обмена пользовательской информацией между услугами, механизмы аутентификации и биллинга, внедрить открытые стандартные интерфейсы и API.

Как считает Александр Ляхов, проблемы не столько в самой технологии программных коммутаторов, сколько в ее реализации. Успех во многом зависит от того, смогут ли крупные разработчики программных коммутаторов консолидировать свои усилия для улучшения совместимости и совершенствования стандартов протоколов сигнализации. Возможны два пути — повышение качества самих стандартов (более подробные и однозначные формулировки) и разработка рекомендаций по их реализации. В настоящий момент активные действия ведутся по обоим направлениям.

Сергей Орлов — обозреватель «Журнала сетевых решений/LAN». С ним можно связаться по адресу: sorlov@lanmag.ru.