Федеральный технический центр Panasonic
8 812 441 2414
Пограничный контроллер сессий
Автор Масленников Игорь
Развитие сервисов реального времени в Интернете, прежде всего IP-телефонии, привело к появлению нового функционального элемента IP-сетей, который «живет» на пятом уровне модели OSI и решает определенный ряд задач. В данной статье мы попытаемся разобраться в причинах появления этих устройств, способах и перспективах их применения.
Что же такое Session Border Controller (SBC), или Session Controller, или Edge Devise – пограничный контроллер сессий? Откуда пришло это понятие, почему у операторов возникла необходимость использовать SBC при построении сетей?
Как появился SBC?
Интернет возник достаточно давно как одна из первых сетей пакетной коммутации. Те сервисы, которые мы привыкли считать типично «интернетовскими», сервисы, характерные для раннего и сегодняшнего Интернета – http (web, WWW), ftp, e-mail – электронная почта, не являются сервисами реального времени. Но за прошедшие 10 лет ситуация с Интернетом вообще и с сервисами в частности изменилась кардинально: Интернет из модной и популярной новинки, набора новых способов обмена информацией превратился в глобальную всемирную инфокоммуникационную среду. И в Интернет приходят real time – сервисы, такие как телефония или видеоконференц-связь. IP-телефония – первый и очень важный пример массово распространенного в IP-сетях сервиса реального времени. Это переход традиционного сервиса телефонной связи из старого мира связи (телекоммуникаций) в новый – мир Интернет. Казалось бы, телефонный разговор просто перенесли из сетей с коммутацией каналов в сеть IP. Но для операторов IP-сетей такой перенос означал появление новых проблем, которых с обычными интернет-сервисами у них не возникало. Какого рода эти проблемы?
Рассмотрим типичный пример. Предположим, есть оператор IP-телефонии, работающий в Москве. Он имеет партнеров в Нью-Йорке и во Вьетнаме. Существуют установленные и обговоренные тарифы, но в какой-то момент может оказаться, что тариф на терминацию трафика, который предлагает вьетнамский оператор, выгоднее, чем тарифы американского оператора от его вьетнамских партнеров. Очевидное решение московского оператора – перепродать трафик от вьетнамского партнера американскому и заработать на этом. Это достаточно популярный сегодня бизнес. Однако здесь есть одно большое «но». Через некоторое время американский оператор, изучив IP-адреса пакетов с голосом от вьетнамского оператора, обнаруживает адрес IP-шлюза вьетнамского оператора, и посреднические услуги московского оператора становятся лишним звеном в цепи. Естественно, американский оператор попытается договориться с вьетнамским напрямую по его тарифам.
Так проявляется коренное отличие традиционной телефонии от IP-телефонии. В традиционной маршрут следования телефонной сигнализации, как правило, совпадает с маршрутом следования голоса – в этом логика сети с коммутацией каналов. В IP-сети сигнализация ходит по одному маршруту, а голос – по другому, обычно напрямую между дов и движение IP-телефонных вызовов – совсем разные вещи. Логика работы IP-сети и логика IP-телефонной сети, наложенной на IP-сеть – совершенно разные. Это как железные дороги – карта прокладки рельсовых магистралей ничего не может сказать о расписании поездов. Интернет как глобальная IP-сеть состоит из множества функциональных элементов и один из основных – IP-маршрутизатор, устройство третьего уровня модели OSI, которое маршрутизирует IP-пакеты. Но он не может контролировать медиа-потоки в отношении доступа (телефонных пользователей), трансляции адресов (не IP-адресов, а адресов телефонной сети), маршрутизации
(не IP-маршрутизации, а маршрутизации телефонных вызовов), обеспечения QoS (не QoS IP-сети, а качества телефонного сервиса). Ведь IP-маршрутизаторы не обладают интеллектом в смысле понимания телефонной (видео, мультимедиа) сигнализации и не управляют коммуникационными сессиями между абонентами-пользователями. Соответственно они не могут, например, блокировать или обслуживать вызовы на основании телефонного номера или адреса SIP, H.323 ID, сгенерировать, например, сигнал «занято» (busy).
С другой стороны, такие популярные устройства, как софтсвичи (softswitches), H.323 привратники (gatekeepers), SIP-прокси и сигнальные контроллеры (Call Agents), занимаются исключительно телефонной сигнализацией – инициированием, установлением соединения, его мониторингом, управлением и завершением, но не контролируют медиа-потоки, потоки голосового трафика. А там есть что контролировать и есть чем управлять – начиная от информации о качестве медиа-канала (протокол RTCP, например, способен нас проинформировать о таких важных для качества голоса вещах, как задержка, джиттер или процент потери пакетов) и заканчивая параметрами сети, которые зафиксированы в соглашении о качестве обслуживания (SLA). Но устройства, которое бы собирало эту информацию, анализировало бы ее и принимало бы какие-то решения на ее основе, например о маршрутизаци вызовов по критерию качества, нет. Таким устройством и должно стать SBC (рис. 1–3).
Защищая интересы оператора
Возвращаясь к примеру о московском, вьетнамском и американском операторах, можно отметить следующее. Если бы у московского оператора был хотя бы один SBC, то он бы и стал единственной точкой входа-выхода его операторской сети. Таким образом, «увода» американским партнером вьетнамского трафика можно было бы избежать, ибо, с точки зрения американского и вьетнамского операторов, вся сеть московского коллеги выглядела бы одним единственным IP-адресом – и для сигнализации и для медиа-трафика, для самих разговоров.
Вопрос безопасности работы в IP-сети (Интернет) со временем становится все более важным и применительно к теме SBC имеет два аспекта. Первый – работа конечных пользователей-абонентов через NAT/firewall. Сегодня практически нет домашних сетей или корпоративных сетей, не защищенных файрволом или NAT’ом от внешнего мира. Это означает, что входящие мульт. SBC может использоваться как единственная точка входа в сеть и как устройство, общающееся с файрволом для поддержания в открытом состоянии сигнальных портов и динамического управления портами для медиа-потоков.
Второй – работа инфраструктуры оператора (шлюзов, софтсвичей, гейткиперов и т. д.). Если SBC – единственная точка входа в операторскую сеть (и для сигнализации, и для медиа-потоков), то очень легко воспретить чрезмерно любознательным гражданам узнать принципы устройства и работы сети оператора, исключить тем самым возможность злоупотреблений.
Кстати, есть еще один аспект безопасности – борьба с перегрузками, в частности с DoS-атаками. Здесь SBC способен помочь предотвратить «падение» центрального софтсвича, имеющего конечную производительность.
Проблема обеспечения качества обслуживания с помощью SBC также имеет несколько аспектов. Один из наиболее важных – контроль за доступной полосой пропускания и управление количеством одновременных вызовов через канал фиксированной пропускной способности, например от корпоративной сети до оператора.
Необходимо, чтобы SBC контролировал в каждый момент времени количество сессий с учетом, например, типов используемых кодеков и давал сигнал отбоя в том случае, если оставшейся полосы пропускания недостаточно для очередного звонка – добавление этого звонка приведет к резкому ухудшению качества всех текущих разговоров. К тому же SBC может правильно приоритезировать трафик, так, чтобы его понимали пограничные IP-маршрутизаторы. Это обеспечит бесперебойную работу сервисов реального времени, включая телефонию даже на сильно загруженных каналах. Второй аспект – постоянный мониторинг статистики звонков по направлениям и ее анализ по критериям качества, принятие решений о маршрутизации вызова в реальном времени. Именно такой подход становится доминирующим при обеспечении качества сервиса IP-телефонии.