Возможно многие, кто по той или иной причине сталкивается 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.
Автор: Arsen Semenov
