Session border controller что это
Что такое SBC (Пограничный Контроллер Сессий) и зачем он нужен
Рынок пограничных контроллеров сессий с каждым годом набирает обороты, при этом для многих в области VoIP данное устройство остаётся неким вопросом – а зачем он нужен и где его правильно применять. Собственно, хотелось бы описать те функции и задачи, которые выполняет данное оборудование и почему установка данного устройства, если не обязательно, то уж точно крайне желательно на сети VoIP.
Пойдём от простого к сложному. Для начала определим те самые три функции, которые SBC выполняет на сети заказчика.
1. Безопасность
2. Совместимость
3. Обеспечение и контроль качества
В большинстве случаев для многих сразу возникает масса вопросов, так как, казалось бы, что есть Firewall, который отлично справляется с функцией безопасности и зачем сеть VoIP защищать дополнительно. Зачем обеспечивать совместимость, если есть стандарт RFC3261 и все работают согласно этому стандарту. А качество – есть мнение, что VoIP качество больше зависит от качества сети, а не от какого-то устройства. Теперь более подробно разберёмся, в чем собственно состоит обеспечение безопасности VoIP сети, и почему совместимости по RFC3261 (SIP v2) не достаточно, что именно обеспечивает, с точки зрения качества, Пограничный Контроллер Сессий.
1. Безопасность
Для начала, надо разобраться, а от чего мы хотим защитить и что может сделать злоумышленник? Самое первое и болезненное, что может сделать злоумышленник, это воровство траффика. Злоумышленник получает доступ к тому, чтобы от вашего лица была возможность звонить на оператора связи и далее делает достаточно дорогие вызовы куда-нибудь на солнечную Кубу через вашу систему. Чем это грозит, наверное, всем понятно – большой счет со стороны оператора связи.
Как происходит воровство и какие есть механизмы его предотвращения?
Как всегда, всё должно начинаться с самого примитивного. Причем, это примитивное обезопасит вас достаточно сильно. Злоумышленники в большинстве случаев начинают с того, что просто проверяют все IP адреса по ответу на порт SIP (UDP 5060). Например, посылая сообщение OPTIONS на данный порт последовательно на все IP адреса. Таким образом он просто ищет очередную жертву. Далее происходит следующее: как только они получают ответ, то сразу злоумышленник получает массу информации о вас. А именно – он знает, что у вас SIP доступен через Интернет и в 99% случаев он знает тип вашей IP-PBX. Как именно он это делает? Легко. Когда IP-PBX отвечает на SIP запрос, она дает ответ, где указано поле User-Agent с именем и версией устройства. Например: user-agent: Asterisk 1.2.3. Сразу хочу извиниться перед всеми любителями Asterisk, буду упоминать именно её, так как она является наиболее популярной для взлома системой. Что делает SBC в данном случае: по рекомендации он использует отличный от 5060 порт и легко подменяет значение поля User-Agent. Тут мы сразу ставим злоумышленника в более сложную ситуацию – во-первых, его система не всегда определяет, что вы используете SIP, так как в большинстве случаев вы на его запросы просто не отвечаете; во-вторых, даже получив ответ, он не будет знать, что у вас за станция и каким боком к ней подступиться. Почему второе так же является очень важным. А всё просто. Например: злоумышленник определил, что у вас Asterisk версии 1.2.3, на который был баг, который позволял позвонить на внутренний номер и далее с помощью DTMF набора установить переадресацию этого внутреннего номера. А далее он звонит на этот внутренний номер, где стоит переадресация на нужный ему номер. И в целом, чем больше функционал у АТС, тем больше есть различных способов воспользоваться этим функционалом в не тех целях, для которых предназначается данный функционал.
А если уж говорить о переадресации, то она является одним из самых тонких, с точки зрения безопасности в VoIP. Так как в большинстве случаев никто не думает, как и где передавать номер, кто совершал вызов, а он просто без вариантов подменяется на номер, кто переадресовал вызов. Это тоже важно и нужно проверять, что SBC так же делает. В данной статье не буду углубляться в тему переадресации номера.
Еще важный вопрос – это управление и доступ к управлению. SBC изначально имеет множество интерфейсов и возможности настройки VLAN, что позволяет интерфейс управления вынести в отдельную защищенную подсеть, что делает вопрос получения доступа к нему очень сложным.
С точки зрения безопасности, стоит уделить отдельное внимание маршрутизации вызовов и проверки SIP пакетов. Важно, чтобы любой пакет был максимально доверенным. Для этого SBC имеет достаточно много инструментов. Во-первых, это проверка по различным полям. Например, вы знаете, что от оператора всегда приходит сообщение, с полем User-Agent: ITSP_SIP и еще что-то добавляет. Либо при подключении к IP АТС телефона через Интернет требуется обязательно проверять, что регистрация проходит с того телефонного аппарата, который разрешен в вашей сети. Также, требуется максимально правильно определить маршруты, на которые можно звонить, с которых можно звонить. Это так же позволяет SBC обеспечить правильный уровень безопасности.
Еще очень важный момент, который обеспечивает SBC безопасность вашей IP-АТС, это разграничение VoIP трафика в вашей сети. Он позволяет выделить отдельную подсеть для вашей IP-АТС и сделать доступ к ней только с другого физического интерфейса, тем самым обеспечив доступ к вашей VoIP сети только через Пограничный Контроллер Сессий.
А далее, это набор стандартных вещей, типа регулярного Firewall, который так же находится на SBC.
Собственно, именно эти инструменты на SBC позволяют обеспечить вам безопасность от попытки взлома системы для воровства трафика или еще каких-то действий. Конечно, SBC имеет и другие методы и способы защиты, но тут я описал скорее самые популярные и важные действия для защиты вашей VoIP сети:
a. Есть еще DoS/DDoS атаки. С одной стороны, они более безобидны, так как, только лишь отключают сервис телефонии, но есть и другая сторона этой проблемы:
b. Тут надо четко понимать, если отключается IP-АТС, то у вас пропадает вся телефония, что само по себе не приятно и может влиять на бизнес-процесс.
c. Также не маловажным фактором является то, что чаще всего эти атаки делаются с целью подбора паролей пользователей с дальнейшими действиями этого пользователя. В том числе и воровства трафика.
SBC имеет встроенный Firewall, который работает по двум принципам – статический и динамический. Первый вариант понятен и описывать его, наверное, нет никакого смысла. Второй вариант работает следующим образом. Если вы допускаете возможность регистрации SIP абонентов из сети Интернет, то теоретически он может регистрироваться с любого источника и фильтровать статически просто невозможно. Например, если ваши сотрудники улетели куда-нибудь в Китай и хотят подключиться к вашей IP-АТС, вам будет необходимо открыть полный доступ, или как минимум для всех Китайских IP адресов. Единственный способ обезопасить вашу сеть IP телефонии – это динамические списки контроля доступа, когда SBC закрывает только те IP адреса на сетевом уровне, с которых идет аномальный трафик. Причем степень аномальности вы выставляете сами.
Есть еще вопрос подслушивания и единственный способ обойти это – шифрование. Но, так как в нашей стране службы безопасности относятся к этой теме очень скрупулезно, то эту тему я оставлю без внимания. Тем более, что в России шифрование никто не предоставляет всё по тем же причинам.
2. Совместимость
Второй вопрос, который встает перед SBC, это совместимость. Все рассказывают о том, что они поддерживают SIP v2 (он же RFC 3261) и всё будет работать и так. Но как показывает практика – это не сосем так, точнее совсем не так. Я бы сказал, что вопрос совместимости является самым сложным и комплексным в VoIP сети. Почему так? А для чего делаются IP АТС и системы унифицированных коммуникаций? Как бы все не рассказывали, что они стремятся к стандартизации, на самом деле приоритет главный в другом и он полностью противоречит самой идее сделать всё по стандарту. Задача производителей АТС – это предоставить максимально интересный и полный набор сервисов и если кто-то вдруг придумал новый сервис, то никакого варианта у них нет, кроме как сделать это по-своему. (Ну а потом сделать новый RFC и всем сказать – поддерживаете). Причем слив информации работает в нашем мире хорошо (но не отлично). И если конкурент прознал, что кто-то делает новую фичу, естественно он делает такую же, правда, по-своему и стандартизирует свою версию реализации данной функции и естественно, стандартизирует её. В итоге мир получает две отличные станции с одинаковой функцией, которые работают по-разному, при этом по стандарту, но между собой не совместимы. И если с базовым вызовом проблем уже ни у кого нет, то вот с расширениями SIP вопросов всегда предостаточно. Для статистики, на данный момент в мире более 100 расширений RFC для SIP. Станция обычно поддерживает не более 20, наш SBC поддерживает более 80. И если вам требуется, чтобы вы смогли использовать весь ваш функционал при работе с оператором связи, то SBC в этом случае просто необходим.
А еще на совместимость влияет та самая безопасность. И не ваша безопасность, а безопасность оператора связи. Как правило, оператор имеет свой собственный SBC и в большинстве случаев у него стоят четкие и понятные фильтры сообщений/полей/функций при работе с клиентом. Приведу два простых и понятных примера:
a. IP АТС использует SIP Refer для перевода вызова (это когда станция говорит вышестоящей станции, что Вы переводите вызов на внешнего абонента, и пускай дальше вызов соединяет между собой вышестоящая станция. Всё хорошо, но вот момент – а кому счет выставлять. Оператор в данном случае должен замкнуть вызов между двумя не его абонентами. Счет должен быть выставлен вам, да вот вызова с вами не было. По этой причине, оператор просто блокирует такой функционал (и правильно делает). SBC в данном случае забирает на себя вопрос коммутации вызова и отработки сообщения REFER и для оператора отображается два вызова (входящий и исходящий). И всё отлично работает.
b. Переадресация вызова. Например: Абонент А позвонил абоненту Б, у которого стоит переадресация на абонента В. И вот вызов идет от абонента Б на абонента В, при этом в качестве номера вызывающего отображается номер А. И это правильно, так как вызывающий номер – это номер А, а не тот который переадресует. Это телефонный стандарт. И если в ISDN (E1) всё это четко описано, так как есть поле Redirect number, то вот в SIP номер В для правильной идентификации может быть передан с использованием History-Info, Referred-By, Diversion. И исходя из этого, операторы просто любят блокировать такие номера, ссылаясь на то, что у них биллинг не правильно работает. То есть, биллинг оператора связи противоречит стандарту SIP или просто оператор не хочет принимать переадресованные вызовы, согласно стандарту. SBC позволяет всячески преобразовывать один формат в другой или просто переносить номер из любого поля в поле From и/или P-Asserted-Identity.
Остальные примеры не столь часто встречающиеся, при этом не менее важные, так как чем реже они встречаются, тем сложнее их решить стандартными методами телефонной станции. Отдельно хочется сказать про вопросы совместимости и адаптации голосовых кодеков. Прошло то время, когда все поддерживали кодеки G.711 и G.729 и этого достаточно. Тому массу причин, а главное производители АТС стремятся улучшить качество связи, используя собственные кодеки или специализированные кодеки, типа SILK/OPUS/MS-RTA. Тут причина проста (особенно если мы говорим про систему унифицированных коммуникаций) – сейчас все компании стремятся сделать телефонию не только на IP телефоне (который можно выделить в отдельный VLAN и дать трафику приоритет), но и сделать телефонию везде – на планшетах, лептопах, смартфонах, через WiFi, публичный Интернет. И тут далеко не всегда возможно приоритезировать трафик и обеспечить надлежащее качество в общем IP потоке, а адаптивные кодеки дают лучшее качество на таких сетях, относительно G.711/G.729.
Вот тут как раз SBC помогает использовать у вас в сети тот кодек, который требуется, а с оператором стыковаться с помощью того, который он поддерживает.
Отдельно стоит вопрос DTMF и факсов, которые в VoIP среде никто не отменял. Не хочу углубляться в эту тему, могу лишь сказать, что мы на данный момент поддерживаем все варианты передачи как DTMF, так и факсов.
На самом деле писать про совместимость можно достаточно долго и можно даже сделать отдельные статьи как решить ту или иную проблему с помощью нашего SBC. Но в любом случае, даже если ваш оператор говорит, что он добьётся полной совместимости с вами, не всегда оператор добивается этого и сроки настройки этой совместимости всегда большие. SBC позволит вам уменьшить риски и сократить расходы при подключении.
3. Обеспечение и контроль качества
Ну и в заключении, немного напишу об обеспечении и контроле качества:
a. Обеспечение качества – в первую очередь это работа с голосовыми кодеками.
b. Контроль качества – SBC отслеживает все вызовы по множеству параметров, таких как Эхо/задержка/потери пакетов/Jitter/MoS и когда у вас случается проблема, вы сразу четко и быстро понимаете с какой стороны и по какой причине произошло ухудшение связи, тем самым сократив сроки исправления проблем. Также SBC позволяет самостоятельно перестроить маршрут в случае, если с одним оператором качество связи падает. Это позволит сохранить качество вызова без внешнего вмешательства.
Также, не маловажным фактором с точки зрения обеспечения качества, является правильная настройка маршрутизации с возможностью балансировки и резервирования маршрутов. В том числе, если у вас есть резервный стык с сетью Интернет, то он должен включаться в том числе для VoIP, вне зависимости от настроек сетевого оборудования.
Не могу сказать, что это все функции и задачи, которые выполняет Пограничный Контроллер Сессий (SBC), тем более, что всё перечислить крайне сложно. Я бы даже сказал, что, с точки зрения безопасности, совместимости и качества универсальных рецептов просто нет и порой каждое подключение является уникальным и особенным. Наша задача тут предоставить максимальное количество возможностей, для того, чтобы ваше использование VoIP отвечало всем вашим бизнес требованиям к системе IP телефонии.
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Что такое Session Border Controller (SBC)?
Базовый курс по Asterisk
Мы собрали концентрат всех must have знаний в одном месте, которые позволят тебе сделать шаг вперед на пути к экспертному владению Asterisk
В основном, несмотря на способность устройств поддерживать H.323, SCCP и прочие, фокус работы SBC сделан на обеспечении безопасности SIP – протокола, а так же сопряжении различных версий SIP.
Основная идея
SBC защищает от атак сеть телефонии и соответствующие сервера, выполняя роль B2BUA (back-to-back user agent), схожую по типу работы с SIP прокси – сервером. Контроллер терминирует каждую сессию (завершает), а затем заново ее инициирует, выступая в роли агентского сервера UAS (User Agent Server) и агентским клиентом UAC (User Agent Client), работая с каждым из «плеч» вызова по отдельности.
На базе собственных мощностей SBC реализует списки контроля доступа ACL, ограничение DDOS атак, а так же анализ пакетов на предмет искажения информации с целью нанести ущерб. Анализируя SIP, SBC анализирует заголовки и поле полезной нагрузки. Особенно это актуально в SDP – сообщениях, к которым может применяться множество правил модификации.
Помимо сигнальной информации, SBC обрабатывает RTP потоки, тем самым, обеспечивает не только шифрование медиа, но и выполняет функции транскодинга (преобразования потока из одного кодека в другой) в случаях, когда две стороны SIP – коммуникации не могут согласовать параметры передачи данных в сообщениях SDP. Кстати, на SBC обычно реализуют так называемый SIP forking, который позволяет дублировать сессию на третье устройство, например, такое как система записи телефонных разговоров.
В современных версиях SBC, сигнальная информация и потоки изолированы друг от друга (с точки зрения обработки устройством) – это обеспечивает высокие параметры масштабирования.
Давайте рассмотрим на примеры схемы ниже принцип работы SBC:
Базовый курс по Asterisk
Мы собрали концентрат всех must have знаний в одном месте, которые позволят тебе сделать шаг вперед на пути к экспертному владению Asterisk
Session Border Controller
Session Border Controller — это выделенный сетевой элемент, используемый для управления вызовами / сеансами связи в реальном времени по инфраструктурам VoIP (Voice over Internet Protocol) на основе SIP (протокол инициации сеанса).
Он защищает и управляет потоками IP-коммуникаций или, в упрощенном виде, определяет, каким образом вызовы инициируются, проводятся и завершаются по сети VoIP. Кроме того, Session Border Controllers защищает инфраструктуру RTC предприятий и поставщиков услуг.
Типы сеансов пограничного контроллера
SBC может быть любого типа, в зависимости от ваших требований. Он поставляется в виде:
• Аппаратного обеспечения: выделенного физического оборудования, установленного в помещении вашего предприятия.
• Программное обеспечение: виртуальное программное обеспечение SBC, работающее на вашем сервере.
• Облако: облачные решения SBC VoIP для вашего бизнеса.
Как работает Session Border Controller
SBC буквально является стеной или точкой разграничения между вашей корпоративной сетью и сетью поставщиков услуг (Интернет). Он защищает и контролирует сеть SIP, допуская (или не допуская) и направляя обмен данными между внутренним и внешним миром, например, вызов VoIP между двумя телефонами или совместную работу с видео между несколькими устройствами.
SBC развернуты по периметру сети (или на границе, как следует из названия). Так что они могут контролировать и защищать сеансы связи в режиме реального времени как для предприятий, так и для поставщиков услуг.
Ранние модели Session Border Controllers использовались для защиты и управления сетями поставщиков услуг VoIP, но сегодня они используются для регулирования всех видов связи в реальном времени в современном бизнесе. Это включает в себя телефонные звонки, обмен мгновенными сообщениями, видео и аудио совместной работы, а также общий доступ к рабочему столу.
Функции, которые выполняет SBC
1. Защита сети RTC
Пограничный контроллер сеанса защищает коммуникации в режиме реального времени от таких угроз, как мошеннические действия, DoS-атаки (отказ в обслуживании) и спуфинг, выступая в роли Back-to-Back User Agent (B2BUA) и скрывая топологию сети.
SBC также позволяет шифровать сигнализацию и мультимедиа, чтобы предотвратить нарушение связи. Кроме того, контроль допуска звонков и динамическое внесение в черный список мошеннических конечных точек позволяют избежать мошеннических действий и DoS телефонии.
2. Включение SIP-транкинга
Как упомянуто выше, SBC — это точка разграничения или оконечная точка магистрального соединения SIP в вашей сети связи. Это больше похоже на межсетевой экран SIP, который также включает в себя множество дополнительных услуг, таких как сигнализация и межсетевое взаимодействие, интеллектуальное управление маршрутизацией, отказоустойчивость и высокое качество обслуживания между различными сетевыми устройствами.
3. Взаимосвязанные сети и протоколы
SBC плавно выполняет задачи по взаимодействию и соединению, такие как работа с вариантами SIP и протоколы трансляции, между различными сетями и протоколами, работающими над ними. SIP имеет много вариантов; SBC может переводить эти варианты между устройствами, чтобы звонки проходили со всеми их функциями без изменений.
4. Контроль доступа к сессии
SBC осуществляет контроль доступа к сеансам, что в основном означает, что он проверяет и видит, кому должен быть разрешен доступ к сети, а кому нет. Для выполнения этой задачи он создает три списка: белые, черные и серые списки. При выполнении этой задачи он поддерживает QoS (качество обслуживания) в сети.
5. Интеллектуальная политика и управление маршрутизацией
Политика имеет набор правил, определяющих, как SBC обрабатывает различные виды событий VoIP. Это позволяет контролировать сигнализацию VoIP и медиа, которые проходят через SBC на уровне приложения. Мы можем установить несколько политик на одном SBC.
Итак, теперь вы знаете, что такое контроллер границы сеанса, каковы его типы и что он делает. Это некоторые очень основные функции, но они относятся к применению SBC и могут отличаться для каждой организации. Это все, что вам нужно для начала, но если вы хотите узнать больше об этом, вы можете взять бесплатную демонстрацию REVE SBC. Вы можете проверить все его функции и затем решить, является ли это правильным выбором для вашего предприятия.
Session Border Controller
Из Википедии — свободной энциклопедии
SBC (англ. Session Border Controller — пограничный контроллер сессий) — оборудование операторского класса (программное или аппаратное), являющееся частью операторских NGN сетей. Пограничные контроллеры сессий выполняют целый ряд функций, необходимых не только для успешного и безопасного функционирования операторской сети, но и для стабильного развития операторского бизнеса.
Содержание
SBC располагаются на границе операторской сети и осуществляют следующие функции: трансляция сигнальных протоколов и их диалектов, анализ качества медиа-каналов, по которым осуществляется маршрутизация голосового трафика (такие параметры как задержка, джиттер, процент потери пакетов и пр.), обеспечение качества обслуживания, оговорённого в SLA (англ. Service Level Agreement — соглашение об уровне услуг), сбор статистической информации, контроль RTP-трафика и др.
SBC является единой точкой входа-выхода в сеть оператора, благодаря чему скрывается топология сети, повышается её надёжность и отказоустойчивость (SBC отбивает DoS-атаки), упрощаются задачи конфигурирования и администрирования.
Сокрытие топологии сети позволяет, с одной стороны, обезопасить сеть от вторжения извне и попыток изменить настройки оборудования, а с другой, позволяет транзитным операторам вести бизнес, не опасаясь, что оригинаторы и терминаторы трафика исключат их из «цепочки», как ненужное звено.
Для обеспечения высокого уровня надёжности, Session Border Controller должен поддерживать шифрование сигнального (например такие варианты как SIPS (англ. SIPS ) и/или SIP поверх TLS) и медиа-трафика (SRTP, ZRTP).
Kamailio SBC или не SBC?
Возможно многие, кто по той или иной причине сталкивается VoIP, особенно с решениями с открытым исходным кодом, слышали такое выражение: «Kamailio SBC». В этой статье постараемся разобраться правильно ли приравнивать Kamailio к SBC (пограничный контроллер сессий) и можем ли мы вообще использовать Kamailio в этом качестве. Начнем с краткого обзора SIP протокола, основных функций SBC и первопричин возникновения этого устройства.
Протокол инициации сеансов (SIP), за последние 10 лет перешел от эксперимента исследователей и VoIP энтузиастов фактически в стандарт для IP телефонии. Прародителем SIP, как известно, является протокол HTTP, откуда и была унаследована клиент-серверная архитектура. Основными элементами SIP сети являются: клиент агента пользователя (UAC), сервер агента пользователя(UAS), прокси-сервер (proxy server), сервер переадресации (redirect server), сервер регистрации (registrar) и определения местоположения пользователей (location server). Все эти элементы и составляют SIP сеть, о них и способах их взаимодействия подробно описано в SIP спецификациях, однако в этих документах нет упоминания о SBC.
Термин SBC относительно неспецифичен, не стандартизирован и нигде официально не определен. Тем не менее широкой общественности он известен, во многом благодаря активному маркетингу со стороны компаний производителей, как «незаменимый» компонент VoIP сети.
С момента своего появления, SBC использовался для выполнения определенных задач, набор его функции постоянно рос и совершенствовался по мере роста набора требований.
Фактически же причиной возникновения таких устройств как SBC стали различные конструктивные недостатки протокола SIP.
Важно понимать, что, несмотря на все приложенные усилия, стандарт протокола не является идеальным и для этого существует множество причин.
Над стандартами работает много людей с различными мнениями и целями. В этой связи часто появляются обновления стандарта, различные расширения и дополнения. Весь процесс в некоторой степени похож на законодательство.
Вероятно, самой большой ошибкой в дизайне SIP было игнорирование существования NAT. Эта ошибка возникла из-за убеждения руководства IETF (инженерный совет интернета) в том, что пространство IP-адресов в скором времени будет исчерпано и потребуется глобальный переход на IPv6, который и устранит необходимость в NAT.
SIP предполагает, что NAT не существует, это предположение и оказалось неудачным. SIP просто не работает для большинства пользователей интернета, которые находятся за NAT. Это и послужило причиной появления устройства, которое начало решать данную проблему: преодоление NAT.
Многочисленные абстрактные понятия в SIP, привели к тому что разработчики ПО толковали их по-разному, хотя некоторые из этих понятий и были исправлены в более поздней версии SIP и его расширениях, но уже существующие к тому времени различные SIP устройства имели свои особенности работы. Это привело к необходимости нормализации SIP протокола.
Другая немаловажную проблема — это безопасность и скрытие внутренней топологии сети от внешнего мира. Интернет — далеко не дружелюбная среда, постоянные попытки взлома, сканеры, брутфорсеры — все это является угрозой для организации.
Все эти и другие проблемы послужили причиной возникновения устройства, которое обыкновенно находится на границе между сетями двух операторов или между сетью оператора и предприятия, а также между предприятием и оконечными устройствами пользователей, предоставляя таким образом единую точку доступа. Это устройство не имеет ничего общего с файрволами, в то же время обладает необходимыми функциями для качественного обеспечения безопасности и бесперебойного предоставления услуг передачи голоса в IP сетях.
И так, что такое SBC?
SBC — это пограничный контроллер сессий. Он бывает самых разных форм, может иметь огромное количество функции и использоваться операторами и предприятиями для разных целей. Одна и та же реализация SBC может действовать по-разному в зависимости от его конфигурации и варианта использования.
Таким образом, достаточно сложно дать точное определение SBC, которое будет применяться ко всем реализациям. Однако в целом можно определить некоторые функции, которые являются общими для большинства SBC. Например, большинство SBC реализовано как B2BUA. B2BUA — это сервер, который разделяет транзакцию SIP на две части: на стороне пользователя UAC, он действует как сервер, a на другой стороне, он действует как клиент. Тем самым SBC фактически нарушает сквозную природу соединений SIP.
Существует два сценария использования SBC это peering и access.
В первом случае SBC установлено между сетями операторов, которые обмениваются трафиком. Оператор может использовать SBC, чтобы контролировать доступ к своей сети, защищать свои шлюзы от несанкционированного использования и различных атак (DoS/DDoS), для мониторинга сигнального и медиа трафика. SBC также упрощает менеджмент внутренней сети, являясь единой точкой доступа, с которой разрешен трафик для всех внутренних устройств.
В access сценарии SBC размещен на границе между сетью доступа (внешняя сеть) и сеть оператора / предприятия (внутренняя сеть). Основные функции это контроль доступа, защита компонентов сети (медиа серверов, серверов приложений, шлюзов и т.д.) от несанкционированного использования и DoS/DDoS атак. В отличие от peering, в access сценарии SBC должен уметь обрабатывать REGISTER запросы, изменяя их таким образом, что все последующие запросы для зарегистрированного AoR проходили через SBC. Кроме того, некоторые конечные точки могут быть за NAT-ом. В этом случае SBC должен уметь решать эту проблему (far-end NAT traversal).
К вопросу о Kamailio
Является ли Kamailio SBC? Нет. Конечно, Kamailio это не SBC, по своему первоначальному предназначению. Kamailio — это SIP прокси сервер. А вот может ли Kamailio выполнять функции SBC? Это уже другой вопрос, который лучше привести к форме: можно ли реализовать SBC, взяв за основу Kamailio SIP прокси? Ответ на этот вопрос можно дать только после того, как точно известно, какие именно функции нам необходимы.
По своему опыту могу сказать, что большинство задач, связанных с реализацией “Kamailio как SBC” сводятся к конфигурации некоего SIP файрвола с функцией агрегации и балансировки трафика + медиа прокси и обход NAT для клиентов. В некоторых вариациях это может быть также WebRTC шлюз, может включать транскодирование, интеграции с различными биллинг решениями и многое другое.
Ниже я приведу описание некоторых возможностей, которые позволяют реализовать Kamailio в качестве пограничного контроллера сессий:
Безопасность (SIP FIREWALL, secfilter)
Обеспечение безопасности пользователей и бизнеса — это задачи с повышенным приоритетом. В современном мире, особенно в мире VoIP, атаки случаются 24/7. Многие наверняка знакомы с ситуацией, когда на только что установленный sip сервер сразу же начинают поступать регистрации или инвайт запросы с различных адресов.
Очень важно иметь возможность для настройки и корректировки правил безопасности, иметь гибкий механизм для мониторинга и своевременного оповещения о возникновении угрозы. Иметь возможность оперативно добавлять новые правила в зависимости от ситуации.
С Kamailio можно решать следующие задачи:
отслеживать большой объем трафика с одного и того же адреса (DoS/DDoS), обнаруживать большое количество неудачных попыток аутентификации (bruteforce), разрешать трафик только из определенных регионов, ограничивать количество активных сессий от одного пользователя или для транка, отслеживать аномалии в продолжительности и количестве вызовов и ограничивать оные.
Кроме того Kamailio можно интегрировать с IM и получать оповещение, например в слак канал.
Скрытие топологии (TOPOLOGY HIDING)
Скрытие топологии необходимо по коммерческим причинам, например транзитные провайдеры не хотят раскрывать клиентам своих поставщиков, и конечно же и из соображений безопасности. Для того чтобы скрыть топологию сети необходим B2BUA.
Kamailio может “притворятся” B2BUA с помощью модулей topoh и topos, которые используют два разных подхода к сокрытию сетевых адресов.
Оба подхода вполне справляются со своей задачей, но так как все же Kamailio по своей природе это SIP прокси, то иногда могут возникнуть случаи, когда скрытие топологии работает не совсем так, как ожидалось. В этих случаях на помощь может прийти, незаслуженно недооцененный в VoIP сообществе SEMS с его модулем sbc, который отлично справляется с данной задачей.
Регистрация пользователей (REGISTRAR)
Kamailio превосходно выполняет функции регистратора. Если в архитектуре VoIP сети предполагается концентрация большого количества регистраций на одном централизованном узле, то Kamailio это отличный выбор.
В сценариях, когда большое количество мобильных клиентов регистрируются на одном устройстве, может понадобиться так называемый «промежуточный регистратор» (mid registrar), который может уменьшать нагрузку на основной регистратор путем «поглощения» частых перерегистрации клиентов и преобразования их в менее частые.
Надо сказать, что в OpenSIPs уже есть готовая реализация данной функциональности в модуле mid_registrar. В Kamailio эту логику, при необходимости, можно написать самостоятельно.
Маршрутизация и балансировка трафика (LCR, DROUTING, etc)
Это одна из основных функций SBC. Стоит отметить, что чем больше возможностей она предоставляет тем лучше. В Kamailio для решения этой задачи есть сразу несколько модулей, работающих “из коробки”: lcr, carrierroute, drouting, pdt, dispatcher, prefix_route. Очень часто в конфигурации используется комбинация из нескольких модулей, что дает возможности для гибкой настройки маршрутизации на основе IP адресов, А и Б номеров, доступности транков, времени суток, стоимости трафика, на основе местоположения (lost модуль) и так далее.
Манипуляция SIP заголовками (TEXTOPS)
Часто возникает необходимость добавить или изменить значение в SIP заголовке, добавить свой или же наоборот удалить (скрыть) лишние заголовки. Камаилио легко справляется с этой задачей. Также имеется возможность манипулировать SDP.
Конвертация протокола и разделение сетей
В сценариях, требующих маршрутизировать SIP трафик через несколько интерфейсов, Kamailio может выполнить мостовое соединение (бридж) между различными IP-сетями (внутренними и внешними, IPv4 и IPv6) или между различными транспортными протоколами для SIP (например, динамически конвертировать UDP в TCP или TLS).
Обеспечение работы клиентов за NAT (NAT TRAVERSAL)
Если SBC используется в access сценарии и на нем регистрируются абоненты, то в большинстве случаев они будут находиться в где-то в приватной сети, за роутером или wi-fi точкой доступа, в этом случае необходима реализация обхода NAT со стороны сервера (server-side NAT traversal). Нужно упомянуть также, что существуют еще и обход NAT со стороны клиента (client-side NAT traversal), в этом случае ответственность за определение своего внешнего адреса лежит на клиенте (STUN,ICE). В Kamailio обход NAT можно реализовать с помощью модуля nathelper, расширения rport (RFC3581) и rtpengine.
Медиа прокси (RTP RELAY)
Kamailio работает с SIP сигнальным протоколом и не знает ничего о RTP. Для реализации медиа прокси нужно использовать стороннее приложение. Есть несколько на выбор, все отлично справляются со своей задачей, но на одном стоит заострить внимание это rtpengine.
Компания Sipwise занимается разработкой rtpengine уже более 10 лет. Он отличается от других RTP прокси своим богатым функционалом. Rtpengine использует пересылку пакетов в привилегированном режиме (kernel mode), это позволяет добиться передачи RTP на скорости, близкой к скорости передачи данных. Кроме того у него есть множество функций: поддержка SRTP, ICE, возможность делать записи разговоров, транскодирование и даже возможность проигрывать звуковые файлы.
Также rtpngine можно легко масштабировать, достаточно добавить больше инстансов и объединить их в кластер. Есть поддержка репликации RTP сессий в режиме реального времени с использованием redis.
Репликация данных и отказоустойчивость
О построении отказоустойчивого кластера и катастрофоустойчивости можно написать отдельную статью, нюансов здесь достаточно. Репликация данных в Kamailio реализуется с помощью модуля dmq, который качестве транспортного протокола использует SIP, может мониторить и обнаруживать новые ноды в сети, автоматически синхронизироваться после сбоя. С помощью этого модуля возможно реплицировать динамические данные, такие как: состояние активных сессий, регистрации, данные хэш таблиц, статусы присутствия клиентов (presence).
Также для репликации можно использовать SQL, например модуль db_clusterer, который является своего рода «прослойкой» между модулями и базой данных.
В заключении хочу вернутся к тому с чего я начал статью: Kamailio это не SBC, но те функциональные возможности, которые он имеет, обширный набор модулей, поддержка REST, RPC, websockets, позволяют программисту, а для написания скрипта Kamailio Вам понадобится некоторый опыт разработки ПО, реализовывать практически любые сценарии и интеграции как на нативном языке, так и с помощью KEMI на таких языках как python, lua, javascript.