Kamailio как SBC (Пограничной контролер сессии)

Опубликовано в Kamailio

Session Border Controller

 SBC - это термин, который имеет много различных значений для разных людей в различных контекстах. Чтобы ответить на этот вопрос, необходимо:

  • разобрать правильное понимание "SBC".
  • определить, понимаем ли мы правильную концепцию построение сетей IMS/NGN.
  • оцените, в какой степени Kamailio может выполнять эту роль.

Я думаю, можно с уверенностью говорить, по моим наблюдениям, что существует два основных понимания концепции SBC:

Простое определение: SBC выступает точкой входа в сеть провайдера и выполняет функции сокрытия топологии сети, защита ее от DDoS атак, дополнительно выступая в роли SIP маршрутизатора на основные элементы сети провайдера (Asterisk, FreeSwitch, Yate и др.).

Когда большинство клиентов приходят и спрашивают нас: «Вы можете развернуть Kamailio для нас как SBC?". Часто оказывается, что они просто ищут точки агрегации соединения конечных точек IP к одной конечной точке сигнализации, для того, чтобы взаимодействовать с клиентом. Многие другие клиенты ищут LCR (маршрутизации с наименьшей стоимостью) функциональности шлюза, или какой-либо другой тип межсетевой интеллектуальной маршрутизации. Они тоже почему-то решили поставить "SBC" ярлык на него, потому что это то, что маркетинг производителей научил их делать  SBC все, что стоит на границе сети.

Это совсем не SBC по крайней мере, не то что подразумевается в профессиональной VoIP архитектуре.

Профессиональное определение: устройство с SIP B2BUA (back-to-back user agent) ядром, как правило, в состоянии сделать некоторую комбинацию контроля доступа на основе политик, транскодирования, топологии сокрытия, учета вызовов (обычно через RADIUS), QoS, качество статистики вызовов и т.д.

Наиболее исчерпывающий и правильный перечень возможностей SBC:

  • Способность корректно определять источник и обезвреживание DDoS атак из интернета;
  • Трафик из многочисленных VRFs (например 10.0.0.1 клиента А не является таким же, как клиент Б 10.0.0.1);
  • Преодоление NAT;
  • Транскодирование медиа потоков;
  • Демультиплексирование SIP транков (так, чтобы каждый SIP "путь" мог прийти из другого IP-адреса и порта);
  • Ограничения, как звонков в секунду или параллельных звонков;
  • Отказоустойчивость от одного SBC к другому;
  • Балансировка  и распределение нагрузки между медиа серверами;
  • Поддержка 802.1Q VLAN Tagging;
  • Поддержка перехода на другой ресурс в избыточности регистратора BroadWorks-style (где регистраторы-сервера имеют различные IP-адреса);
  • Управление SNMP;
  • Межсетевого взаимодействия SIP / UDP и SIP / TCP;
  • Jumbo SIP (SIP дейтаграммы более 1300 байт, из соответствии с RFC 3261);
  • SIP / TLS и SRTP, и дешифрование их;
  • Управление медиа потоком (освободить медиа сокеты когда это возможно, направить его через SBC, когда нет).

Более совершенные SBC обычно уже включают, по крайней мере на ASIC (application-specific integrated circuit) RTP проксирование и транскодирование, для достижения более высокой плотности портов.

Kamailio не удается войти в рамки B2BUA, который, кажется, является требованием концепции SBC.B2BUA - принимая один логический вызов “A”, создавая новый, логически не связанный вызов “B”, и мост сигнализации событий между ними.  ТО прокси сервер Kamailio получает логический вызов “А”, и толкает вызов дальше выполняя функцию SIP прокси сервера; а выходе мусор в мусоре.

Есть относительно несколько вещей, которые SIP прокси Kamailio может изменять в  SIP запросе или ответе. Проще говоря он может изменить запрос URI и несколько других полей сообщения, еще может присоединить пользовательские заголовки. Тем не менее, критически, он не может переписать или принципиально регенерировать запрос или ответ, как B2BUA сервер. Это делает его довольно плохим посредником, касающейся взаимодействия и целей-безопасности среди конкурентов SBCs.

Тем не менее Kamailio имеет некоторые хаки и модули, которые позволяют ему пойти немного за пределами этих ограничений, в нарушение его норм-предписанной роли прокси элемента, например, способность модуля переписать заголовок From и To сообщения UAC также сокрытие топологии выявления деталей в заголовке параметра Record-Route. Тем не менее, они должны быть поняты, какие они есть: хаки и модули с ограничениями-ограничений, которые B2BUA не имеет.

Kamailio можете использовать rtpproxy передавая RTP через свой сервер (Linux), который в делает это гораздо проще, умеет преодолевать NAT (модуль nathelper) и выполнять сокрытие топологии сети (в сочетании с topoh).

С некоторым усилием, Kamailio можно настроить для преодоления SIP сигнализации между несколькими сетевыми интерфейсами, и rtpproxy может работать в режиме "bridging mode", который позволяет ему сделать, то же самое. Однако реализация этого - является сложной задачей, и не обеспечивает гибкость серверу SBC; это, по своей природе, жестко запрограммированный установки, и если вы планируете, поддерживать этот SBC в полдюжины подсетей, вы настраиваете себя на мир мук.

В целом, можно развернуть Kamailio в некоторой роли SBC, но вероятность достаточно высока, что "SBC" действительно не то, что имеется в виду, когда этот термин подразумевается.

Kamailio включают в себя:

  • прохождение NAT-шлюзов;
  • балансировки нагрузки;
  • регистрация;
  • элементы безопасности на прокси;
  • агрегации трафика прокси;
  • интеллектуальные шлюзы маршрутизации для голосовых приложений;
  • маршрутизация по наименьшей стоимости шлюзы;
  • 4 класс кабельных каналов внешних интерфейсов.

Итог: Kamailio не SBC, вовсе нет. Это прокси при работе с некоторыми особенностями SIP сервера внутри. Однако, в зависимости от того, что вы на самом деле ищете…

Коментарии:

VoIPLabБаза знанийKamailio (OpenSER)Kamailio как SBC (Пограничной контролер сессии)