В этой статье мы попытаемся собрать и обобщить основные данные и факты, известные широкой и узкой общественности о том, зачем операторам и корпоративным клиентам нужен Session Border Controller (SBC).
Банальный запрос в поисковых системах не выдает много информации и не всегда претендует на простоту и доступность подачи материала.
Растущий интерес к виртуализации приложений и функциональности сети только добавляет вопросов типа «можно ли развернуть SBC в виртуальной среде и не потерять функциональность».
Как следует из названия, SBC (пограничный контроллер сеанса) — это аппаратное (или программное обеспечение), установленное на границе сетей, которое что-то контролирует.
Контроль, который обеспечивает 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. Защита сети Сокрытие топологии — лишь один из многих аспектов, которые возникают при обсуждении темы защиты голосовых сетей.
В большинстве случаев, если не всегда, вопрос организации правильной стратегии безопасности упирается в стандартную дилемму – защитить сеть, не нанеся вреда сервису/бизнесу.
Любой трафик можно зажать в жёсткие правила обработки и анализа, главное обеспечить разумную и корректную работу всех сервисов и не дать повода абоненту/заказчику перейти к вашему конкуренту, который более грамотно настроил свою сеть.
и предоставил возможность пользоваться расширенным спектром услуг.
Я упоминаю об этом здесь потому, что на практике часто встречаются сетевые администраторы, которые не соблюдают этот баланс либо из-за недостатка знаний, либо из-за отсутствия достаточного внимания к этому вопросу.
И надо честно признаться, что профессиональных специалистов в области передачи голоса не так уж и много.
Обозначу основные моменты, на которые следует обратить внимание при решении вопросов защиты.
а) Защита от несанкционированного доступа Это самое первое, что приходит на ум при обсуждении вопросов защиты.
Перечислю от простого к сложному несколько пунктов, которые часто используются при взломе.
- Банальное сканирование используемых портов, а также специализированными сканерами голосовых приложений и решений;
- проверка реакции вашего оборудования на стандартные сигнальные сообщения с целью узнать подробности о вашей сети (даже минимальных данных достаточно для определения следующего шага взлома);
- определение отдельных видов услуг (например, перенаправление);
- подбор SIP логинов и паролей;
- сканирование сетевого трафика и анализ пакетов;
- попытки звонков от имени зарегистрированных/незарегистрированных абонентов;
- спуфинг (маскировка под законного абонента);
- подмена доверенных пакетов и попытка взлома установленной легитимной сессии.
Любой нормальный SBC должен знать и уметь разобраться со всем вышеперечисленным и многим другим.
А без детального анализа голосового трафика такая борьба бессмысленна.
Вы должны понимать, что администратор сети также должен знать, как правильно настроить SBC для корректной работы.
Для этого помимо знаний должны быть все возможности на SBC для настройки множества различных критериев, например, количество неудачных попыток регистрации, обнаружение подозрительного трафика (не только вышеперечисленные пункты, но и например , анализ длины SIP-сообщений) и многое другое.
б) DoS/DDoS VoIP-атаки Взломать незащищенное голосовое оборудование несложно, нужно лишь желание.
И поверьте, способов это сделать масса, даже если вы используете супер-пупер фаерволл данных.
И опять же проблема в том, что никакое оборудование СПД не защитит, например, от безумного количества регистраций, отправленных от имени корректного и легитимного абонента.
Или от невероятного количества попыток установить звонок легитимному абоненту.
А все дело в том, что любой межсетевой экран ДОЛЖЕН пропускать весь этот трафик без ограничений, потому что он предназначен для абсолютно легитимного абонента, а значит, его необходимо обрабатывать.
Вот лишь малая часть критериев, которые можно проанализировать: количество попыток регистрации в секунду, превышение установленного количества отправленных диалогов в секунду, одновременных установленных звонков в секунду или попыток установления звонков в секунду.
Или, например, менее очевидные вещи: занятая конкретным абонентом полоса пропускания (подсчет и ограничение пропускной способности по количеству одновременных разговоров давно перестал быть корректным, особенно с появлением адаптивных кодеков, способных изменять занимаемую полосу пропускания во время разговора).
разговор, без сверки информации СМИ).
в) Неправильные голосовые пакеты
Отправка неправильных голосовых пакетов может означать несколько разных неприятных моментов, например:
— отправка длинного пакета и сигнального сообщения;
— формирование длинных полей и значений заголовков сигнальных сообщений;
— попытки вклиниться (и впоследствии перенаправить трафик не туда) в установленную сигнальную сессию, подменяя пакеты от легитимного абонента сторонними, но тоже легитимными пакетами;
— отправка сигнальных сообщений в измененном порядке
Думаю, не нужно объяснять, что все эти и некоторые другие неприятности могут стоить дорого, так как могут привести к нестабильной, некорректной работе голосового сервиса или вообще к потере работоспособности.
г) Неправильные, но не нарушающие правила SIP-сообщения.
Повторюсь, при обычном межсетевом экране такие пакеты и сообщения должны проходить свободно, поскольку их можно отправлять на правильные разрешенные адреса и адресовать легитимным абонентам.
Однако они могут причинить вред и неудобства оператору, поскольку могут повлиять на производительность услуги.
д) Звонки для незарегистрированных абонентов Из вышесказанного становится понятно, что посредством банального выбора и с разрешенными звонками незарегистрированным пользователям организовать «слив» трафика за счет оператора становится не просто, а довольно просто.
Комично в ситуации то, что существует довольно много решений, претендующих на серьёзность и позволяющих делать такие вещи.
Трагедия ситуации в том, что многие люди используют такие «решения» дома, подвергая себя крайнему риску.
е) Возможность устанавливать произвольные правила для анализа и проверки (классификация трафика) Обычный SBC должен уметь и позволять настраивать не только шаблоны, часто используемые правила анализа трафика, но и любые разумные «хотелки/чекеры».
В качестве примера, немного утрируя, приведу вот такое «идиотское» правило проверки: если входящий INVITE содержит более двух заголовков Via, а третий заголовок Via содержит IP-адрес вида 172.х.
х.
100, и Поле From в пользовательской части имеет набор букв XYZ, то разрешите (или запретите) обработку такого трафика.
Надеюсь, понятно, что эта функция добавляет гибкости при использовании SBC. ж) Динамические черные/белые списки и списки доступа.
Вполне стандартный функционал.
SBC должен иметь возможность анализировать трафик и «автоматически» определять его легитимность.
Любой подозрительный трафик, не соответствующий указанным критериям, блокируется.
В идеале защита должна поддерживаться по настраиваемым критериям, например, количеству неудачных попыток регистрации, количеству попыток регистрации в секунду, превышению заданного количества отправленных пакетов в секунду, обнаружению подозрительного трафика (например, длине Сообщения SIP, попытки подделать сообщения SIP и вклинивания в ранее установленный активный сеанс SIP) h) Статические черные/белые списки и списки доступа.
Ну а что же мы могли без этого сделать? Пример.
Вы обнаружили вредоносный трафик, имеющий характерные характеристики и наносящий вред вашей сети.
Например, потому, что ваш администратор «забыл» или не догадался настроить и установить поведение 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.x.x и другие.
Таким образом, 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-трафика, при котором контекст сигнализации SS7 передается на часть SDP, что может существенно повлиять на корректную обработку некоторых сервисов, например, переводов/переадресаций или даже прохождения базового вызова.
на границе двух операторов.
Для корректного решения этих задач необходимо иметь возможность изменять некоторые поля в части SDP во время транзитного звонка, либо правильно конвертировать SIP-I в обычный SIP. И это абсолютно точно функционал профессиональных SBC, особенно если вспомнить количество различных вариантов и стандартов сигнализации ISUP. И именно об этом мы говорим, когда говорим о передаче контекста SS7 по SIP. 9. SIPREC для взаимодействия с внешними системами регистрации трафика.
Кажется, здесь все просто.
Есть задачи, когда требуется запись разговоров.
Сразу оговоримся, что это не СОРМ (хотя иногда его можно использовать как обходной путь СОРМ).
Это запись разговоров.
И речь здесь идет об интерфейсе со специализированными системами и решениями, выполняющими такую задачу.
Это выполняется с использованием протокола записи сеанса (SIPREC).
Подробности можно найти Здесь .
Эта тема важна для некоторых бизнес-задач.
Сложность заключается в том, что задачи записи сеанса имеют уникальные требования, которые не отражены в существующих спецификациях протокола SIP. Речь идет о некоторых технических особенностях реализации решения, а также вопросах безопасности и сохранности персональных данных.
Кроме того, существует требование уведомить абонента о том, что его разговор записывается.
SIPREC был разработан для решения всех этих проблем.
Не все это реализовали.
10. Разделение типов трафика по разным интерфейсам Я уже немного писал об этом.
Сформулируем по-другому.
Вариантов реализации может быть много.
Разделение внешнего и внутреннего трафика по разным физическим интерфейсам — это лишь часть процесса.
Иногда необходимо разделить разные типы трафика по разным физическим интерфейсам.
Например, сигнализация на одном, медиа на другом, контроль на третьем.
Или, может быть, вам нужно совместить.
В общем, вариантов много.
Полная поддержка добавляет гибкости.
11. Обеспечение IPv4 <-> Совместимость IPv6 Здесь вроде все просто, особых комментариев не требуется.
Уже существуют реализации IPv6, и чем дальше, тем больше.
Поскольку SBC находится на границе голосовых сетей, выполнение преобразования является его прямой обязанностью.
12. Транскодирование Тема большая и на самом деле очень важная.
От этого функционала зависит многое.
В большинстве случаев под транскодированием понимается исключительно преобразование одного голосового кодека в другой.
Однако это лишь верхушка айсберга.
Гораздо больше скрыто под водой.
Если говорить о виртуальных решениях, то при обсуждении вопросов транскодирования нужно одновременно обсуждать производительность аппаратных серверов.
а) Преобразование TCP <-> UDP, TCP <-> ТЛС, UDP <-> TLS, динамическое изменение протокола транспортного уровня.
SIP поддерживает больше, чем просто UDP. Есть другие варианты.
На стыке сетей часто возникает задача такого преобразования.
И конечно удобно, если это будет сделано не только в фиксированной конфигурации, что чаще всего встречается при подключении SIP-транка, но и динамически.
Ну вот представьте себе абонентов, которые регистрируются на вашей голосовой платформе.
Некоторые используют UDP, другие — TCP или даже TLS. Как заранее узнать, что делать с конкретным абонентом? Конечно, лучше выполнять эту задачу динамически.
б) РТП <-> SRTP-преобразование Это тоже понятно и довольно распространено.
Преобразование RTP в SRTP и наоборот несомненно необходимо.
в) Конверсия Т.
38 <-> Г.
711 Классика жанра.
Все уже давно кричат о смерти факсимильной связи.
Но это далеко от реальности.
Этот вид связи использовался и продолжает использоваться.
Конечно, современные системы в большинстве случаев уже экономят бумагу и отправляют факс на электронную почту в виде файла.
Но это не меняет механизм передачи факса.
Два наиболее распространенных формата передачи несовместимы друг с другом и требуют преобразования, если две стороны отправляют друг другу факсы разными методами.
г) транскодирование DTMF (RFC2833 <-> внутриполосный <-> SIP-ИНФОРМАЦИЯ) Тоже классическая проблема.
Сигналы DTMF могут передаваться разными способами.
Это зависит от настроек и возможностей/функциональности конкретного абонентского оборудования и голосового решения, предоставляющего конечный сервис.
Но дело в том, что DTMF должен идти из конца в конец.
Что на пути и какой метод используется – больной вопрос.
Преобразование между различными методами чрезвычайно важно.
д) Транскодирование кодека Современный мир телекоммуникаций движется вперед очень быстро.
Ну и вот пример некоторых типов кодеков, довольно распространенных в последнее время: Г.
723; Г.
729; Г.
728; НЕТКОДЕР; GSM-FR; GSM-ЭФР; УПП; EVRC-QCELP; Г.
727; ИЛБК; ЭВРК-Б; УПП-ВБ; Г.
722; ЭГ.
711; МС_РТА; ШЕЛК; СПЕЭКС; ОПУС.
На межоператорском интерфейсе вопрос транскодирования в основном ограничивается транскодированием G.711 и G.729, хотя есть и более экзотические случаи.
Но при подключении корпоративных клиентов или небольших операторов часто возникает совершенно нетривиальная задача, связанная с использованием так называемых «тяжелых» кодеков, используемых в конкретных сервисах.
Использование современных веб-сервисов или некоторых мобильных приложений также требует использования кодеков, отличных от общепринятых.
f) Транскодирование Ptime. Правильнее было бы назвать это по-другому, поскольку собственно перекодирования здесь нет как такового.
Происходит изменение времени пакетирования в пределах одного и того же кодека.
Ответ на вопрос «зачем» очень прост – экономия пропускной способности канала.
Для некоторых приложений это очень важная задача и решается таким образом, экономя пропускную способность и вычислительную мощность оборудования.
13. Поддержка REST Многим это не нужно и даже не заморачиваются на эту тему.
Однако поддержка REST API позволяет гибко и очень просто решать множество задач.
Интеграция со сторонними решениями, управление и безболезненная перенастройка системы осуществляется очень быстро и не вызывает затруднений.
В технологии NFV (виртуализация сетевых функций) протокол REST используется подавляющим большинством оркестраторов с целью мониторинга и управления элементами NVF (элементами сетевых виртуальных функций).
14. WebRTC и поддержка так называемых веб-кодеков (например, OPUS) WebRTC — это тоже отдельная тема, позволяющая оператору добавлять множество новых современных сервисов и захватывать те ниши, на которые он раньше даже не думал обращать внимание.
По своей сути WebRTC — это бесплатная технология открытого проекта для совершения звонков, видео, чатов, передачи файлов в Интернет без установки дополнительного оборудования или программного обеспечения (например, флеш-плееров, плагинов и т. д.), непосредственно из браузера персонального компьютера.
компьютер, используя API Javascript. Привлекательность и применимость очевидны.
Техническая реализация требует использования шлюза WebRTC, поскольку SIP здесь вообще не используется.
Сам по себе шлюз WebRTC — это возможность терминировать трафик WebRTC и конвертировать его из WebSocket (заменяющего HTTP) в обычный SIP. А передача медиатрафика требует медиапроксирования, так как два абонента за симметричным NAT не смогут общаться друг с другом.
Но такой шлюз не выполняет задачу обеспечения безопасности такого преобразования, а также не решает задачи защиты от DoS/DDoS-атак, использования различных политик, контроля доступа вызовов, учета, биллинга, устранения неполадок, диагностики.
и многое другое.
Поэтому эта задача ложится на плечи 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. Контроль допуска вызовов, ограничения по количеству сессий, пропускной способности, другим параметрам.
Ну а этот функционал очень часто граничит с задачей экономии денег.
Ну потому что необходимо и важно контролировать ресурсы вашего решения, практически грамотно и рационально ограничивая вашего клиента или абонента от «поглощения» всех или большей части доступных ресурсов, ограничивая и контролируя нагрузку на ядро сети (SIP-сервер, софтсвитч и т. д.) 19. Балансировка трафика Функциональность важна, когда сложность сети позволяет организовать и построить гибкие схемы обработки услуг и трафика.
И это работает в обе стороны.
У некоторых есть, например, резервные каналы и их использование приветствуется для организации не только отказоустойчивых схем, но и для распределения нагрузки на сеть или распределения сервисов между элементами ядра сети.
20. Сбор и хранение CDR. Тоже все ясно.
SBC, поскольку он расположен на границе сети, также может использоваться в качестве точки биллинга или интерфейса с биллинговой системой.
Здесь важно понимать, что текстовый формат записей CDR является наиболее предпочтительным.
21. Возможность обеспечения одновременной обработки трафика для режимов доступа (доступ с регистрацией на услуги типа виртуальная АТС) и пиринга (обеспечение соединений по SIP-транкам) Часто можно столкнуться с таким ограничением, когда SBC может работать только в одном режиме.
Либо только пиринг, либо только доступ.
Иногда использование только одного из режимов фактически определяется конструкцией и назначением приложения SBC. Но возможность работы только в одном режиме накладывает существенные ограничения на планирование и работу сервисов в сети, вынуждая покупать второе устройство для реализации полноценной схемы одновременного использования SIP-транков и абонентского трафика с регистрацией абонента на сети.
SIP-сервер.
Поэтому важна возможность работать в двух режимах одновременно.
Поскольку о тренде виртуализации говорилось в самом начале статьи, сразу скажем, что все описанное в статье относится и к виртуальным решениям.
Таким образом, вопрос о способности виртуальных SBC заменить специальные аппаратные комплексы должен отпасть сам собой.
Конечно, в этом вопросе есть тонкие моменты; Я планирую отдельную статью на эту тему.
Теги: #SBC #voip #voip #виртуализация приложений #голосовая связь #безопасность #передача пакетов #информационная безопасность #asterisk #Разработка систем связи
-
Когда Создавать Сайты Для Небольшой Компании
19 Dec, 24 -
Они Только Что Осуществили Свою Давнюю Мечту
19 Dec, 24 -
Топ-10 Фильмов Об It
19 Dec, 24 -
Подкаст Appleinsider.ru [20]
19 Dec, 24 -
Смс Против «Зеленой Змеи»
19 Dec, 24 -
Федерация Медиа Зарабатывает Миллион В Месяц
19 Dec, 24
