Постараемся в этой статье собрать и подытожить основные данные и факты, известные широкой и узкой общественности по поводу того, зачем же нужен Контроллер Пограничных Сессий (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) Защита от взлома
Это самое первое, что приходит в голову при обсуждении вопросов защиты. Перечислю от простого к сложному несколько моментов, которые применяются сплошь и рядом при взломах.

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

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

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 и наоборот нужна несомненно.

c) Конвертация T.38 <-> G.711
Классика жанра. Давно и долго кричат все про смерть факсимильной связи. Но это далеко от реалий. Этот вид связи как использовался, так и продолжает использоваться. Конечно, современные системы уже в большинстве случаев экономят бумагу и отправляют факс на электронную почту в виде файла. Но от этого механизм передачи факса не меняется. Два самых распространенных формата передачи несовместимы друг с другом и требуется преобразование, если два абонента посылают факс друг другу, используя разные методы.

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ы должен отпасть сам собой. Конечно, в этом вопросе есть тонкие моменты, я планирую по этому поводу отдельную статью.

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