Интернет возник достаточно давно как одна из первых сетей пакетной коммутации. Те услуги, которые мы привыкли считать типично «интернетовскими», сервисы, характерные для раннего и сегодняшнего Интернета – http (WWW), ftp, e-mail – не являются услугами реального времени. Но за прошедшие 10 лет ситуация с Интернетом вообще, и с сервисами в частности, кардинально изменилась. Интернет из модной новинки превратился в глобальную всемирную инфокоммуникационную среду. И в Интернет приходят real time – сервисы, такие как телефония и видеоконференц-связь. IP-телефония – первый и очень важный пример массово распространенного в IP-сетях сервиса реального времени. Это переход традиционного сервиса телефонной связи из старого мира связи (телекоммуникаций) в новый – мир Интернет. Казалось бы, телефонный разговор просто перенесли из сетей с коммутацией каналов в сеть IP. Но для операторов IP-сетей такой перенос означал появление новых проблем, которых с обычными интернет-сервисами у них не возникало. Какого рода эти проблемы?
В традиционной телефонии маршрут следования сигнализации, как правило, совпадает с маршрутом следования голоса – в этом логика сети с коммутацией каналов. В IP-сети сигнализация проходит по одному маршруту, а голос – по другому, обычно напрямую между двумя абонентами. Логика работы IP-сети и логика IP-телефонной сети, наложенной на IP-сеть – совершенно разные. Интернет, как глобальная IP-сеть, состоит из множества функциональных элементов и один из основных – IP-маршрутизатор – устройство третьего уровня модели OSI, которое маршрутизирует IP-пакеты. Но он не может контролировать медиа-потоки в отношении доступа (телефонных пользователей), трансляции адресов (не IP-адресов, а адресов телефонной сети), маршрутизации (не IP-маршрутизации, а маршрутизации телефонных вызовов), обеспечения QoS (не QoS IP-сети, а качества телефонного сервиса). Ведь IP-маршрутизаторы не обладают интеллектом в смысле понимания телефонной (видео, мультимедиа) сигнализации и не управляют коммуникационными сессиями между абонентами-пользователями. Соответственно, они не могут, например, блокировать или обслуживать вызовы на основании телефонного номера или адреса SIP, H.323 ID, сгенерировать, например, сигнал «занято».
Следующим этапом развития IP-телефонии является появление Softswitch (SS). SS – программный коммутатор – это элемент сети, который позволяет осуществлять контроль сигнализации различных форматов и осуществлять сопряжение оборудования разных фирм производителей, а так же интеллектуальную маршрутизацию на основании различных параметров (стоимость разговора, время поступления вызова, номера вызываемого абонента и приоритета различных направлений) и другие функции.
Такие популярные устройства, как SS, H.323 привратники (gatekeepers), SIP-прокси и сигнальные контроллеры (Call Agents), занимаются исключительно телефонной сигнализацией – инициированием, установлением соединения, его мониторингом, управлением и завершением, но не контролируют медиа-потоки, потоки голосового трафика (протокол RTCP, например, способен нас проинформировать о таких важных для качества голоса вещах, как задержка, джиттер или процент потери пакетов) и заканчивая параметрами сети, которые зафиксированы в соглашении о качестве обслуживания (SLA). Но устройства, которое бы собирало эту информацию, анализировало бы ее и принимало бы какие-то решения на ее основе, например, о маршрутизации вызовов по критерию качества, нет. Таким устройством и должно стать SBC – Session Border Controller (пограничный контроллер сессий).
Вопрос безопасности работы в IP-сети (Интернет) со временем становится все более важным и применительно к теме SBC имеет два аспекта. Первый – работа конечных пользователей-абонентов через NAT/firewall (межсетевой экран). Сегодня практически нет домашних сетей или корпоративных сетей, не защищенных firewall или NAT’ом от внешнего мира. SBC может использоваться как единственная точка входа в сеть и как устройство, общающееся с firewall для поддержания в открытом состоянии сигнальных портов и динамического управления портами для медиа-потоков.
Если SBC – единственная точка входа в операторскую сеть (и для сигнализации, и для медиа-потоков), то очень легко запретить «чрезмерно любознательным гражданам», узнать принципы устройства и работы сети оператора, исключив тем самым возможность злоупотреблений.
Еще один аспект безопасности – борьба с перегрузками, в частности с DoS-атаками (Denial of Service – отказ в обслуживании). Здесь SBC способен помочь предотвратить выход из строя, из-за перегрузки, центрального SS, имеющего конечную производительность.
Проблема обеспечения качества обслуживания с помощью SBC также имеет несколько аспектов. Один из наиболее важных – контроль за доступной полосой пропускания и управление количеством одновременных вызовов через канал фиксированной пропускной способности, например от корпоративной сети до оператора.
Необходимо, чтобы SBC контролировал в каждый момент времени количество сессий с учетом, например, типов используемых кодеков и давал сигнал отбоя в том случае, если оставшейся полосы пропускания недостаточно для очередного звонка – добавление этого звонка приведет к резкому ухудшению качества всех текущих разговоров. К тому же SBC может правильно приоритезировать трафик, так, чтобы его понимали пограничные IP-маршрутизаторы. Это обеспечит бесперебойную работу сервисов реального времени, включая телефонию даже на сильно загруженных каналах.
Второй аспект – постоянный мониторинг статистики звонков по направлениям и ее анализ по критериям качества, принятие решений о маршрутизации вызова в реальном времени. Именно такой подход становится доминирующим при обеспечении качества сервиса IP-телефонии.
Еще одна полезная функция SBC заключается в следующем. Как известно, самым популярным и распространенным протоколом IP-телефонии является H.323. Этот протокол (точнее, набор рекомендаций ITU) не гарантирует интер-операбельности, т. е. взаимодействия устройств от разных производителей. В данной ситуации SBC как прокси-сервер для сигнализации и для медиа-трафика может выступить согласователем-преобразователем. При наличии в сети SBC устройство способно «на лету» преобразовывать пакеты, «подгоняя» их под оборудование на другой стороне, и «налаживая» таким образом, взаимодействие между операторами. Кроме того, SBC может решать проблемы взаимодействия сетей, работающих на разных протоколах, например SIP-сети и Н.323 сети, или обеспечивать транскодинг – преобразование медиа-потоков из одного кодека в другой. Введена возможность законного перехвата контента и информации о вызове, т.е. появляется новая функция СОРМ.
Итак, SBC – новый элемент операторской сети, ответственный за ее соединения с другими операторскими сетями. Ему еще только предстоит пройти долгий путь развития и дополнения новыми функциями, которые будут развиваться. Совершенно очевидно, что в глобальном мире – мире, где есть серьезная конкуренция, по предоставлению IP-услуг, на первое место выходит борьба за качество и стоимость услуг. И в этой борьбе пограничный контроллер сессий SBC станет серьезным подспорьем, обеспечивающим высокий уровень управляемости услуг.
Рассмотрим понятие SBC более подробно:
SBC – Session Border Controller – пограничный контроллер сессий можно определить следующим образом:
· «сессия» (session) – это любая интерактивная речевая, видео или мультимедийная связь в реальном времени, использующая сигнальный протокол SIP.
· «граница» (border) – это любая сетевая граница (IP-IP), как например между сервис-провайдером и клиентом/абонентом или между двумя сервис-провайдерами.
· «управление» (control) – это функция, удовлетворяющая требованиям безопасности, гарантии качества услуг и обеспечения законного перехвата.
Появление SBC обусловлено интересом операторов связи, предоставляющих услуги передачи речи по IP-сетям. Из-за роста сетей у операторов возникла необходимость передавать IP-трафик между сетями. SBC позволяет соединять отдельные IP-сети и контролировать трафик на границах, при передаче речевого, видео и мультимедийного трафика реального времени. Для получения биллинговой информации операторы использовали речевые шлюзы. Подобная схема приводила к использованию двойного преобразования кодеков, что ухудшало качество речи и повышало стоимость обслуживания трафика. На выходе сети трафик преобразовывался в TDM-формат, а на входе другой сети упаковывался в IP. Все это не приводило к большим проблемам, пока трафика реального времени в мире было немного, т. к. соединения сводились к соединениям «точка-точка». С ростом трафика возникла проблема взаимодействия между операторами. При большом количестве переходов схема с речевыми шлюзами приводила к ухудшению качества обслуживания. SBC разрешает все эти актуальные проблемы и обеспечивает обмен трафиком через границы.
SBC находится в состоянии постоянного видоизменения, чтобы приспособиться к ситуации в сети. Первые реализации SBC были ориентированы на управление речевыми сеансами, но уже сейчас добавляется поддержка следующих услуг: передача видео, мультимедийные конференции, дистанционное оборудование и т. п.
Т.о. SBC решает задачи межсетевого взаимодействия, безопасности сети, надежности и качества обслуживания трафика реального времени.
Основные функции SBC сосредоточены на пятом уровне (уровень сеансов) семиуровневой модели OSI. Основные из этих функций выглядят следующим образом:
· межпротокольное взаимодействие сетей (двухстороннее преобразование сигнальных протоколов SIP и H.323);
· внутрипротокольное (преобразование разных версий стеков протоколов);
· контроль установлении телефонных соединений;
· управление качеством обслуживания QoS, путем ограничения числа обновременного обслуживания вызовов;
· безопасность, включая функции RTP-proxy для сокрытия внутренней структуры сети;
· функции сигнального контроллера SIP;
· функции B2BUA (Back-to-Back User Agent);
· функции MGCP proxy/NAT;
· обеспечение прохождения трафика через NAT и межсетевые экраны;
· концентрация речевого и сигнального трафика;
· поддержка СОРМ.
Рассмотрим архитектуры построения SBC. SBC состоит из двух функциональных модулей: сигнальный (занимается сигнализацией) и мультимедиа (работающий с пользовательским трафиком).
Возможны два варианта построения SBC: интегрированный и распределенный. В интегрированном варианте построения оба функциональных модуля расположены в едином аппаратном комплексе, в распределенном – каждый из модулей находится в разных сетевых элементах, взаимодействующих по протоколам MGCP, H.248 и др.
