Для чего нужен sbc

ИТ База знаний

Полезно

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Что такое Session Border Controller (SBC)?

Продвинутый курс по Asterisk

Концентрат редких знаний, для внедрения 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

Концентрат редких знаний, для внедрения Asterisk в крупных предприятиях. Все это мы собрали в одном курсе для тебя.

Источник

Пограничные контроллеры сеансов, сертифицированные для прямой маршрутизации

Корпорация Майкрософт сотрудничает с рядом поставщиков пограничных контроллеров сеансов (SBC) и сертифицирует их контроллеры для работы с прямой маршрутизацией

Корпорация Майкрософт работает с каждым поставщиком для следующих действий:

совместная работа над протоколами межсетевого взаимодействия SIP.

выполнение интенсивных тестов в сторонней службе. Сертифицированы только устройства, которые прошли тесты.

проведение ежедневных тестов на всех сертифицированных устройствах в рабочей и предварительной средах. проверка устройств в предварительных средах гарантирует, что новые версии кода прямой маршрутизации в облаке будут работать с сертифицированными контроллерами SBC;

установка технической поддержки совместно с поставщиками SBC.

Майкрософт поддерживает телефонную систему, только если сертифицированные устройства подключены через прямую маршрутизацию. При возникновении проблем клиенту следует сначала обратиться в службу поддержки поставщиков SBC. При необходимости поставщик SBC эскалирует проблему корпорации Майкрософт через внутренние каналы. Корпорация сохраняет за собой право отклонять запросы в службу поддержки, если к телефонной системе через прямую маршрутизацию подключены несертифицированные устройства. Если корпорация Майкрософт определяет, что проблема прямой маршрутизации клиента связана с устройством SBC поставщика, клиенту необходимо будет снова обратиться за поддержкой к поставщику SBC.

Сертификация предоставляется определенным версиям встроенного ПО SBC. Любая версия встроенного ПО SBC, указанная ниже, является сертифицированной и поддерживаемой. Поддерживаются более поздние (чем указанные) версии встроенного ПО, если совпадает основной и дополнительный номер версии.

В следующих таблицах перечислены устройства, сертифицированные для прямой маршрутизации. (Сведения о том, какие поставщики SBC поддерживают оптимизацию локальных файлов мультимедиа, см. в разделе Настройка оптимизации локальных файлов мультимедиа для прямой маршрутизации.)

Дополнительные сведения о прямой маршрутизации. Если у вас есть вопросы по программе сертификации SBC для прямой маршрутизации, напишите нам по адресу drsbccertification@microsoft.com Обратите внимание: мы не принимаем новые заявки на сертификацию до дополнительного уведомления.

Сертифицированные поставщики SBC

* Поставщики услуг 911

Поддержка оптимизации локальных файлов мультимедиа

В таблице ниже описано, какие поставщики SBC поддерживают оптимизацию локальных файлов мультимедиа.

Прямая маршрутизация и взаимодействие аналоговых устройств

В следующей таблице перечислены устройства, проверенные на взаимодействие между прямой маршрутизацией и аналоговыми устройствами.

Чтобы оставить отзыв о продукте Microsoft Teams, например поделиться идеями новых функций, см. раздел UserVoice.

Корпорация Майкрософт в течение 2021 года перейдет с UserVoice на собственное решение для отзывов клиентов по продуктам. Подробнее.

Обратите внимание на сертификат, предоставленный основной версии. Это означает, что поддерживается прошивка с любым номером во встроенном ПО пограничного контроллера сеансов, следующим за основной версией.

Источник

Ранние развертывания SBC были сосредоточены на границах между сетями двух поставщиков услуг в одноранговой среде. Эта роль теперь расширилась и теперь включает в себя значительные развертывания между сетью доступа поставщика услуг и магистральной сетью для предоставления услуг бытовым и / или корпоративным клиентам.

Термин «контроллер» относится к влиянию, которое контроллеры границ сеанса оказывают на потоки данных, составляющие сеансы, поскольку они пересекают границы между одной частью сети и другой. Кроме того, пограничные контроллеры сеансов часто предоставляют средства измерения, контроля доступа и преобразования данных для вызовов, которые они контролируют.

СОДЕРЖАНИЕ

Функции

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

Приложения

Во многих случаях SBC скрывает топологию сети и защищает поставщика услуг или корпоративные пакетные сети. SBC завершает входящий вызов и инициирует второй этап вызова к стороне назначения. С технической точки зрения, при использовании с протоколом SIP это определяет двухсторонний пользовательский агент (B2BUA). Эффект такого поведения заключается в том, что SBC контролирует не только сигнальный трафик, но и медиа-трафик (голос, видео). В случаях, когда SBC не имеет возможности предоставлять мультимедийные услуги, SBC также могут перенаправлять мультимедийный трафик на другой элемент в другом месте сети для записи, создания музыки на удержании или других целей, связанных с мультимедиа. И наоборот, без SBC медиа-трафик проходит непосредственно между конечными точками, а внутрисетевые элементы сигнализации вызова не контролируют свой путь.

В других случаях SBC просто изменяет поток данных управления вызовом (сигнализации), задействованный в каждом вызове, возможно, ограничивая виды вызовов, которые могут выполняться, изменяя выбор кодеков и т. Д. В конечном итоге SBC позволяют операторам сети управлять вызовами, которые совершаются в их сетях, исправлять или изменять протоколы и синтаксис протокола для достижения совместимости, а также преодолевать некоторые проблемы, которые брандмауэры и трансляторы сетевых адресов (NAT) представляют для вызовов VoIP.

Когда SBC включен в путь вызова, SBC действует как B2BUA, который ведет себя как сервер пользовательского агента по отношению к вызывающему и как клиент пользовательского агента по отношению к вызываемому. В этом смысле SBC фактически завершает вызов, сгенерированный вызывающей стороной, и начинает новый вызов вызываемой стороне. Сообщение INVITE, отправленное SBC, больше не содержит четкой ссылки на вызывающего абонента. Сообщение INVITE, отправленное SBC на прокси, включает заголовки Via и Contact, которые указывают на сам SBC, а не на вызывающего абонента. SBC часто также манипулируют идентификационной информацией диалога, указанной в тегах Call-Id и From. Кроме того, в случае, если SBC сконфигурирован для управления медиа-трафиком, SBC также изменяет информацию об адресации медиа, включенную в строки c и m тела SDP. Таким образом, через SBC будут проходить не только все сообщения SIP, но и все аудио- и видеопакеты. Поскольку сообщение INVITE, отправленное SBC, устанавливает новый диалог, SBC также управляет порядковым номером сообщения (CSeq), а также значением Max-Forwards. Обратите внимание, что список манипуляций с заголовками, перечисленный здесь, является лишь подмножеством возможных изменений, которые SBC может внести в сообщение SIP. Кроме того, некоторые ИПК могут не выполнять все перечисленные манипуляции. Если не ожидается, что SBC будет управлять медиа-трафиком, тогда может не быть необходимости изменять что-либо в теле SDP. Некоторые SBC не изменяют информацию идентификации диалогового окна, а другие могут даже не изменять информацию адресации.

Полемика

Большая часть разногласий вокруг SBC относится к тому, должно ли управление вызовами оставаться исключительно с двумя конечными точками в вызове (на службе их владельцев) или должно использоваться совместно с другими сетевыми элементами, принадлежащими организациям, управляющим различными сетями, участвующими в соединении двух вызовите конечные точки. Например, если управление вызовом остается за Алисой и Бобом (двумя вызывающими абонентами), или если управление вызовом должно быть передано операторам всех IP-сетей, участвующих в соединении VoIP-телефонов Алисы и Боба вместе. Споры по этому поводу носили яростный, почти религиозный характер. Те, кто хотел неограниченный контроль только на конечных точках, также были сильно разочарованы различными реалиями современных сетей, такими как межсетевые экраны и фильтрация / регулирование. С другой стороны, операторы сети обычно озабочены общей производительностью, совместимостью и качеством сети и хотят обеспечить ее безопасность.

Законный перехват и CALEA

История и рынок

Продолжающийся рост сетей VoIP продвигает SBC все дальше и дальше, требуя адаптации по емкости и сложности. По мере роста сети VoIP и увеличения объема трафика через SBC проходит все больше и больше сеансов. Поставщики удовлетворяют эти новые требования к масштабированию по-разному. Некоторые разработали отдельные системы балансировки нагрузки, которые размещаются перед кластерами SBC. Другие разработали новые архитектуры с использованием наборов микросхем последнего поколения, предлагающих более производительные SBC и масштабируемость с помощью сервисных карт.

Источник

Зачем нужен SBC на границе сетей

Постараемся в этой статье собрать и подытожить основные данные и факты, известные широкой и узкой общественности по поводу того, зачем же нужен Контроллер Пограничных Сессий (SBC) операторам и корпоративным заказчикам. Банальный запрос в поисковиках выдает не так много информации и она не всегда претендует на простоту и доступность изложения материала.

Растущая заинтересованность в виртуализации приложений и сетевой функциональности только добавляет вопросов типа «возможно ли развернуть SBC в виртуальной среде и не проиграть в функциональности».

Как видно из названия, SBC (Session Border Controller, пограничный контроллер сессий) – это оборудование (или ПО), устанавливаемое на границе сетей и что-то контролирующее.

Контроль, который обеспечивает SBC, в первую очередь касается именно голосового трафика (сигнального и медийного), объемы которого растут в силу перехода от TDM к IP, набирающего обороты день ото дня. Сразу отметим, что этот тип оборудования ничего общего не имеет с файерволами и системами безопасности, работающими на уровне IP в обычных сетях СПД. Скорее наоборот, он дополняет и покрывает те участки, где даже самый продвинутый файервол ничего проконтролировать и тем более защитить не сможет.

Для начала и с целью упрощения понимания задач, которые решает SBC, я хотел бы напомнить читателям, что в теме пакетного голоса информация об IP адресах конечных элементов, участвующих в установлении соединения, находится в нескольких (разных) местах сигнального сообщения. Т.е. это не только IP адрес на третьем уровне, но и на более высоких уровнях, да и не в одном месте, и не только в заголовках пакетов и сообщений. Из этого следует, что оборудование, контролирующее голосовой тип трафика, должно знать, понимать и анализировать всю специфику передачи пакетного голоса на всех уровнях, начиная с третьего (IP).

Приступим к рассмотрению основных функциональных задач SBC. После каждой озвученной задачи буду давать короткое пояснение.

1. Скрытие внутренней топологии вашей сети от внешнего мира.
Под внутренней топологией понимается любая информация о сетевых настройках (IP адреса), устройствах и версиях ПО, пути прохождения голосового трафика, использовании трансляции адресов (NAT) и пр. Чтобы исключить вопросы и удивление, которое обычно испытывает руководство верхнего уровня операторов и корпоративных заказчиков, перефразирую так: да, такую деликатную информацию о вашей внутренней сетевой инфраструктуре, частично или полностью, достаточно легко можно получить путем простого анализа голосового трафика с помощью бесплатных анализаторов трафика. Это совсем не шутка. Такая информация по крупицам легко собирается из разных полей и заголовков сообщений сигнального и медийного голосового трафика. Часть специалистов инженерных служб заказчика на этом этапе успешно парируют: наши сетевые устройства (CPE, роутеры и тд и тп) используют функциональность ALG (Application Layer Gateway), которая помогает нам с этими проблемами. Отчасти это так, но только в совсем мизерной части. Чтобы завершить обсуждение различных ALG, которые исходя из моего многолетнего опыта работы в области пакетного голоса, зачастую только добавляют проблем в нормальной передаче трафика, приведу простую таблицу сравнения ALG и SBC.

Видно, что SBC производит полный анализ всех пакетов информации на любом уровне и должен уметь обрабатывать голосовой трафик так, чтобы исключить передачу деликатной информации наружу по любым стыкам.

Теперь поедем дальше, обсуждая только SBC и вычеркнув из рассмотрения всяческие ALG.

2. Разделение доверенных (внутренних) и недоверенных (внешних) сетей по различным физическим сетевым интерфейсам (разделение сетей на физическом уровне)
Защита передачи информации – это не только настройка различных фильтров, аксесс листов и других правил обработки и анализа трафика. В большинстве случаев применения рекомендуется физическое разделение внутренней и внешней сети путем разнесения стыков по разным физическим интерфейсам. Зачастую количество таких интерфейсов превышает два и определяется в зависимости от схемы включения. Как правило, имеет смысл как минимум говорить о разделении по разным физическим интерфейсам внутреннего и внешнего трафика, а также трафика управления.

3. Защита сетей
Скрытие топологии – это только один из многих аспектов, о которых приходится говорить во время обсуждения темы защиты голосовых сетей. В большинстве случаев, если не всегда, вопрос организации правильной стратегии защиты наталкивается на стандартную дилемму – защитить сеть и при этом не навредить сервису/бизнесу. Зажать в строгие правила обработки и анализа можно любой трафик, главное при этом обеспечить разумную и корректную работу всех сервисов и не дать повода абоненту/заказчику уйти к вашему конкуренту, который более грамотно настроил свою сеть и обеспечил возможность пользоваться расширенным набором сервисов. Я упоминаю здесь об этом потому, что на практике сплошь и рядом встречаются администраторы сетей, которые такой баланс не соблюдают либо в силу недостаточности знаний, либо по причине отсутствия достаточного внимания этому вопросу. Да и надо честно признать, что профессиональных специалистов в области передачи голоса не так много.

Обозначу основные моменты, на которые стоит обратить внимание при решении вопросов защиты.

a) Защита от взлома
Это самое первое, что приходит в голову при обсуждении вопросов защиты. Перечислю от простого к сложному несколько моментов, которые применяются сплошь и рядом при взломах.

b) DoS/DDoS VoIP атаки
Задосить незащищенное голосовое оборудование можно легко, нужно только желание. И поверьте, есть масса способов сделать это, даже если применяется супер-пупер дата-файерволл. И снова проблема в том, что никакое СПД-шное оборудование не защитит, например, от безумного количества регистраций, посланных от имени корректного и легитимного абонента. Или от неимоверного количества попыток установления вызова на легитимного абонента. А все дело в том, что любой файерволл ОБЯЗАН пропусть весь этот трафик без ограничений, потому что он предназначается абсолютно легимному абоненту, а значит, должен быть обработан.

Вот только малая часть критериев, которые можно анализировать: количество попыток регистрации в секунду, превышение установленного количества посылаемых диалогов в секунду, одновременных установленных вызовов в секунду или попыток установления вызовов в секунду. Или вот, например, менее очевидные вещи: полоса, занимаемая конкретным абонентом (считать и ограничивать полосу по количеству одновременных разговоров давно уже перестало быть правильным, особенно с появлением адаптивных кодеков, способных менять занимаемую полосу в процессе разговора, без пересогласования медийной информации).

c) Некорректные голосовые пакеты
Под посылкой некорректных голосовых пакетов можно понимать несколько разных неприятных моментов, например:

— отправка длинного пакета и сигнального сообщения;
— формирование длинных полей и значений заголовков сигнальных сообщений;
— попытки вклиниться (и впоследствии перенаправить трафик не туда, куда нужно) в установленную сигнальную сессию, подменяя пакеты от легитимного абонента сторонними, но тоже легитимными пакетами;
— отправка сигнальных сообщений в измененном порядке

Думаю, не нужно пояснять, что все эти и некоторые другие неприятности могут дорого стоить, поскольку способны привести к неустойчивой, некорректной работе голосового сервиса, или к потере работоспособности вовсе.

d) Некорректные, но ничего не нарушающие сообщения SIP
Повторюсь, обычным файерволом такие пакеты и сообщения должны быть свободно пропущены, поскольку могут направляться на правильные разрешенные адреса, могут адресоваться легитимным абонентам. Однако могут причинить вред и неудобства оператору, потому что могут повлиять на работоспособность сервиса.

e) Звонки для незарегистрированных абонентов
Из вышесказанного становится понятно, что путем банального подбора и при разрешенных звонках на незарегистрированных пользователей организовать «слив» трафика за счет оператора становится не просто, а совсем просто. Комичность ситуации в том, что существует достаточно много решений, претендующих на серьезность и позволяющих делать такие вещи. Трагичность ситуации в том, что многие используют такие «решения» у себя, подвергая себя крайнему риску.

f) Возможность задавать произвольные правила анализа и проверки (классификация трафика)
Нормальный SBC должен уметь и позволять настраивать не только шаблонные часто использующиеся правила анализа трафика, но и любые разумные «хотелки/проверялки». В качестве примера, немного утрируя, приведу такое «идиотское» правило проверки: если входящий INVITE содержит более двух заголовков Via, а третий заголовок Via содержит IP адрес вида 172.х.х.100, и при этом поле From в части user part имеет набор букв XYZ, то разрешить (или запретить) обработку такого трафика. Надеюсь, понятно, что такая возможность добавляет гибкости при использовании SBC.

g) Динамические черные/белые списки и access листы
Достаточно стандартная функциональность. SBC должен уметь анализировать трафик и «автоматически» определять его легитимность. Любой подозрительный трафик, не удовлетворяющий заданным критериям, блокируется. В идеале должна поддерживаться защита по настраиваемым критериям, например, количество неуспешных попыток регистрации, количество попыток регистрации в секунду, превышение установленного количества посылаемых пакетов в секунду, обнаружение подозрительного трафика (например, длина SIP сообщений, попытки подделки SIP сообщений и вклинивания в установленную ранее активную SIP сессию)

h) Статические черные/белые списки и access листы
Ну а как же без этого? Пример: вы обнаружили злокачественный трафик, имеющий характерные признаки и причиняющий вред вашей сети. Например потому, что ваш администратор «забыл» или не подумал сконфигурировать и задать поведение SBC для какого-то сценария. Для быстрой блокировки просто закрываете поток зла, сразу весь, возможно и с частью полезного трафика. А потом начинаете думать и создавать то самое правило, которого не хватало.

Наверняка можно привести еще много примеров и задач, связанных с темой защиты. Мы рассмотрели самые основные. Для большинства ситуаций описанных возможностей SBC должно хватить.

4. Манипуляция с SIP заголовками, манипуляция с SDP
Способность модифицировать проходящие через SBC сообщения важны. В качестве самого простого примера, описывающего необходимость, вспомним о том, что уже обсудили выше – скрытие внутренней топологии сети. Модификация сигнальных сообщений на уровне SDP позволяет убрать из заголовков информацию, которую не нужно светить наружу. Другой пример – необходимость добавить или изменить информацию в сигнальных сообщениях, от которой зависит работоспособность сервиса. Вспомните, что в SIP бывают такие услуги, которые технически могут работать с использованием различных методов. И на ответной стороне вашего SIP транка метод может отличаться от того, какой применяется на вашей сети. Поэтому модификация необходимых полей позволяет обеспечивать работоспособность одинаковых сервисов, которые работают по-разному.

В добавление к вышесказанному остается сказать, что функциональность модифицировать сигнальные сообщения относится не только к заголовкам и содержимому SIP сообщений, то также и к SDP-части этих сообщений. Это важно, поскольку от SDP напрямую зависит корректность согласования и работоспособность передачи медийного трафика.

5. Нормализация SIP
Разные SIP клиенты, число которых бесконечно велико, могут иметь свои особенности работы. Зачастую эти особенности заключаются в том, что при работе этих клиентов используются нестандартные или некорректно сформированные заголовки и параметры SIP сообщений. Нормализация SIP сообщений при прохождении через SBC подразумевает приведение основных и обязательных SIP-заголовков к стандартному виду. Это означает стабилизацию работы при использовании разных SIP клиентов.

6. Обеспечение работы абонентов за NAT (NAT Traversal)
Эта тема заслуживает отдельного внимания. Во-первых, потому что использование и распространенность услуг так называемых виртуальных АТС значительно выросло. Во-вторых, в подавляющем большинстве случаев предоставление голосовых сервисов розничным абонентам (физлицам) происходит по схеме с регистрацией абонентов в ядре голосовой сети. Под ядром понимается оборудование, предоставляющее голосовые сервисы (софтсвитчи, SIP сервера, IMS и прочее). Регистрация SIP-клиентов в таких схемах включения в подавляющем большинстве случаев производится с устройств (роутеры, CPE, wifi точки доступа и пр), или из-за устройств, на которых включена функция трансляции адресов, потому что SIP-клиент имеет приватные немаршрутизируемые адреса типа 192.168.х.х и другие. Таким образом, NAT в таких схемах нельзя назвать методом, упрощающим предоставление голосового сервиса. Потому что трансляция адресов происходит на IP уровне, оставляя неизмененными адреса на более высоких уровнях. И согласование и прохождение SIP сигнализации от конечного SIP клиента до ядра сети в таких случаях подвержено трудностям. А кроме сигнального трафика есть еще и медийный. А IP адреса медийного трафика как раз передаются там, где никакой NAT их не заменит, да и не всякий ALG это умеет. Это приведет к тому, что медиа-трафик может быть направлен на немаршрутизируемые адреса. Последствия очевидны и крайне нежелательны – односторонняя слышимость как минимум, не говоря о других, менее очевидных особенностях и последствиях работы NAT. Поэтому способность SBC решать такие проблемы крайне важна. И важно, чтобы эти проблемы в идеале решались автоматически, не требуя индивидуального подхода в настройках к каждому конкретному подключению SIP абонента.

7. Совместимость с любыми сторонними решениями
Выше уже об этом упоминалось. Подключения и интерконнект с внешними сетями прогнозировано имеет дело с согласованием сигнализации SIP. Ну хотя бы потому, что несмотря на то, что SIP называют стандартом, свободную интерпретацию документов RFC разными производителями никто законодательно не отменял. Ну и вспомним, что самих «разновидностей» SIP RFC насчитывается сейчас более восьмидесяти. Теперь наверняка станет понятнее, что понимается под совместимостью. Совместить и возможность выполнить сопряжение оборудования разных производителей зачастую становится трудновыполнимой или невозможной задачей. Справиться с такими задачами могут далеко не все SBC, а только самые продвинутые.

8. Взаимодействие с сетями, имеющими стык с SS7 (поддержка SIP-I/SIP-T)
Тоже важная тема. Особенно сейчас, когда становится все более доступной возможность организации прямых межоператорских стыков с использованием SIP. Да и при подключении корпоративных клиентов тема тоже остается весьма актуальной, поскольку требуется конвертация SIP-I в обычный SIP.

Здесь речь идет о способности обрабатывать SIP трафик, в котором в SDP части передается контекст сигнализации ОКС-7, который может существенно повлиять на корректность отработки некоторых сервисов, например трансферов/форвардов, или даже прохождению базового вызова на границе двух операторов. Чтобы корректно решать эти проблемы, требуется возможность модификации некоторых полей в SDP части при прохождении транзитного вызова, или корректная конвертация SIP-I в обычный SIP. И это уже абсолютно точно функциональность профессиональных SBC, особенно если вспомнить количество различных вариантов и стандартов сигнализации ISUP. А как раз о ней и идет речь, когда мы говорим о передаче контекста ОКС-7 через SIP.

9. SIPREC для стыка с внешними система записи трафика
Тут вроде как все просто. Бывают задачи, когда требуется запись разговоров. Сразу оговоримся, что это не СОРМ (хотя иногда может применяться как workaround для СОРМ). Это запись разговоров. И речь тут о стыке со специализированными системами и решениями, которые такую задачу выполняют. Выполняется она посредством протокола Session Recording Protocol (SIPREC). Детали можно найти здесь.

Эта тема важна для части бизнес-задач. Сложность в том, что в задачах записи сессий существуют уникальные требования, которые не решены в существующих спецификациях протокола SIP. Речь идет о некоторых технических особенностях реализации решений, а также о вопросах безопасности и сохранения личных данных. Кроме этого, есть требование извещать абонента о том, что его разговор записывается. Для решения всех этих вопросов и был разработан SIPREC. Реализован далеко не у всех.

10. Разделение типов трафика по различным интерфейсам
Немного писал уже об этом. Сформулируем по-другому. Вариантов внедрения может быть много. Разделение внешнего и внутреннего трафика по различным физическим интерфейсам – это только часть. Порой нужно чтобы разный тип трафика был разделен по разным физическим интерфейсам. Например, сигнализация на одном, медиа на другом, управление на третьем. А может, нужно комбинировать. В общем, вариантов много. Полная поддержка добавляет гибкости.

11. Обеспечение взаимодействия IPv4 IPv6
Тут все вроде бы просто, особых комментариев не требуется. Внедрения IPv6 уже есть, чем дальше, тем больше. Раз уж SBC стоит на границе голосовых сетей, то это его прямая обязанность – выполнять конвертацию.

12. Транскодинг
Тема большая и на самом деле очень важная. От этой функциональности зависит многое. В большинстве случаев под транскодингом понимается исключительно конвертация одного голосового кодека в другой. Однако это только верхняя часть айсберга. Под водой скрыто существенно больше. Если говорить про виртуальные решения, то при обсуждении вопросов транскодинга нужно параллельно обсуждать и производительность аппаратных серверов.

a) Конвертация TCP UDP, TCP TLS, UDP TLS, динамическое изменение протокола транспортного уровня.
SIP поддерживает не только UDP. Существуют и другие варианты. На стыке сетей сплошь и рядом встает задача такой конвертации. И конечно же удобно, если это выполняется не только в фиксированной конфигурации, которая чаще всего встречается при подключении SIP транка, а и динамически. Ну представьте хотя бы абонентов, которые регистрируются на вашей голосовой платформе. Одни используют UDP, другие – TCP или вообще TLS. Как вы заранее поймете, как поступать с конкретным абонентом? Конечно лучше выполнять эту задачу динамически.

b) Конвертация RTP SRTP
Тут тоже понятно и достаточно часто встречается. Конвертация RTP в SRTP и наоборот нужна несомненно.

d) DTMF транскодинг (RFC2833 inband SIP INFO)
Тоже классическая проблема. Сигналы DTMF могут передаваться по-разному. Это зависит от настроек и возможностей/функциональности конкретного абонентского оборудования и голосового решения, предоставляющего конечный сервис. Но факт, что DTMF должен дойти из конца в конец. А что на пути и какой метод используется, это больной вопрос. Конвертация между различными методами крайне важна.

e) Транскодинг кодеков
Современный мир телекома движется вперед очень быстро. Ну вот пример некоторых типов кодеков, которые достаточно часто встречаются в последнее время:

G.723; G.729; G.728; NETCODER; GSM-FR; GSM-EFR; AMR; EVRC-QCELP; G.727; ILBC; EVRC-B; AMR-WB; G.722; EG.711; MS_RTA; SILK; SPEEX; OPUS.

На межоператорском стыке вопрос транскодирования в основном ограничивается транскодингом G.711 и G.729, хотя бывают и более экзотические случаи. Но при подключении корпоративных заказчиков или небольших операторов зачастую возникает задача совсем нетривильная, связанная с использованием так называемых «тяжелых» кодеков, применяющихся в специфических услугах и сервисах. Использование современных веб-сервисов или некоторых мобильных приложений также предполагает использование кодеков, отличных от общепринятых.

f) Ptime транскодирование.
Его правильнее было бы назвать по-другому, поскольку собственно транскодинга тут и как такового нет. Есть изменение времени пакетизации в рамках одного и того же кодека. Ответ на вопрос «зачем» очень прост – экономия полосы в канале. Для некоторых применений это очень важная задача и решается таким способом, позволяя экономить полосу и вычислительные мощности оборудования.

13. Поддержка REST
Многим это не нужно и они даже не заморачиваются на эту тему. Однако поддержка REST API позволяет гибко и очень просто решать многие и многие задачи. Интеграция со сторонними решениями, управление и безболезненная переконфигурация системы проводится очень быстро и не вызывает сложностей. В технологии NFV (Network Function Virtualization) протокол REST используется подавляющим большинством оркестраторов для целей контроля и управления NVF-элементов (Network Virtual Function element).

14. WebRTC и поддержка так называемых web-кодеков (например, OPUS)
WebRTC – также отдельная тема, позволяющая добавлять оператору много новых современных услуг и захватывать те ниши, на которые ранее и даже мысли не приходило обращать внимание. В основе своей WebRTC — это бесплатная open-project технология выполнения звонков, видео, чатов, передачи файлов в интернет без установки дополнительного оборудования или программного обеспечения (типа flash плейра, плагинов и пр.), напрямую из браузера персонального компьютера, с помощью Javascript API. Привлекательность и применимость очевидна. Техническая реализация требует использования WebRTC шлюза, поскольку применяется тут вовсе не SIP.

WebRTC шлюз сам по себе это возможность терминации WebRTC трафика и конвертация его из WebSocket (заменяющего HTTP), в обычный SIP. Да и передача медиа трафика требует проксирования медиа, поскольку два абонента за симметричным NAT не смогут поговорить друг с другом. Но такой шлюз не выполняет задачи по обеспечению безопасности такой конвертации, а также не решает задачи защиты от DoS/DDoS атак, применение разных полиси, Call Admission Control, accoutnting, биллинг, траблешутинг, диагностику и многое другое. Поэтому такая задача ложится на плечи SBC. Т.е. сам по себе SBC должен иметь встроенную функциональность WebRTC шлюза. Ну и поддержка OPUS, поскольку этот кодек основной для применения в WebRTC. Конечно, не забудем и G.711, он также специфицирован для применения. Но на практике не применяется, поскольку не дает никакого качества в открытом интернете, слишком восприимчив к потерям пакетов и другим параметрам, определяющим качество голоса.

15. Маршрутизация SIP трафика на основе IP адресов, А и Б номеров, времени суток, доступности оборудования, стоимости минуты трафика и т.д. и т.п
О необходимости выполнять гибкую маршрутизацию на SBC можно говорить долго. Она нужна, и чем гибче возможности, тем больше выгоды для оператора, особенно для тех, кто использует I-SBC для пиринга. Для A-SBC задача гибкой маршрутизации также важна, особенно в случае предоставления услуг виртуальной АТС.

16. Возможность перемаршрутизации трафика на основе ответа оконечного оборудования
Эту задачу выделил отдельно, для I-SBC при пиринге она критически важна.

17. QoS для приоритезации трафика на определенном IP направлении или для определенного пользователя/клиента
Функциональность тоже, на мой взгляд, не требует детального описания и обсуждения. Подключаемые клиенты и операторы вправе заботиться о качестве и часто просят его обеспечить. А некоторые, так вообще требуют отчетов по качеству передаваемого трафика. В итоге побеждает тот, у кого качество выше.
В идеале, конечно, выигрывает тот, чей SBC умеет сохранять статистику о качестве любого звонка, которые он обработал. Это такие параметры как джиттер, потери пакетов, задержки, эхо, MOS, причины завершения вызова, инициатор завершения вызова, и многое другое. Иными словами, SBC одновременно выступает в качестве пробника трафика на сети.

18. Call Admission Control, ограничения по количеству сессий, полосы пропускания, др. параметрам
Ну а эта функциональность очень часто граничит с задачей экономии денег. Ну потому что нужно и важно контролировать ресурсы своего решения, практически грамотно и рационально ограничивая вашего заказчика или абонента от «поглощения» всех или большей части доступных ресурсов, ограничивая и контролируя нагрузку на ядро сети (SIP сервер, софтсвитч и т.д.)

19. Балансировка трафика (load balancing)
Функциональность важна, когда сложность сети позволяет организовывать и выстраивать гибкие схемы отработки услуг и трафика. Причем работает в обе стороны. У кого-то есть, например, резервные каналы и их использование приветствуется для организации не только отказоустойчивых схем, но и для распределения нагрузки на сеть или распределения сервисов по элеменам ядра сети.

20. Сбор и хранение CDR
Тоже все понятно. SBC, поскольку стоит на границе сети, может применяться в том числе и как точка биллинга или стыка с биллинговой системой. Тут важно понимать, что наиболее предпочтительным является текстовый формат CDR записей.

21. Возможность обеспечения одновременной обработки трафика для режимов access (доступ с регистрацией для услуг типа виртуальной АТС) и peering (обеспечение стыка по SIP транкам)
Часто можно встретить такое ограничение, когда SBC может работать только в каком-то одном режиме. Или только пиринг, или только на доступе. Иногда применение только одного из режимов на самом деле обусловлено схемой и задачей применения SBC. Но возможность работы только в одном режиме накладывает существенные ограничения на планирование и работу сервисов на сети, вынуждая покупать второе устройство для реализации полной схемы для одновременного использования SIP транков и абонентского трафика с регистрацией абонентов на SIP сервере. Поэтому возможность работать одновременно в двух режимах важно.

Раз уж в самом начале статьи упомянут тренд на виртуализацию, давайте сразу говорить и о том, что все описанное в статье, касается и виртуальных решений в том числе. Таким образом вопрос о возможности виртуальных SBC заменять специальные аппаратные комплекcы должен отпасть сам собой. Конечно, в этом вопросе есть тонкие моменты, я планирую по этому поводу отдельную статью.

Источник