sbc audiocodes что это

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

Полезно

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

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

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

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

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

Навигация

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

Телефония

FreePBX и Asterisk

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

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

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

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

Базовый курс по Asterisk

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

Рынок пограничных контроллеров сессий с каждым годом набирает обороты, при этом для многих в области VoIP данное устройство остаётся неким вопросом – а зачем он нужен и где его правильно применять. Собственно, хотелось бы описать те функции и задачи, которые выполняет данное оборудование и почему установка данного устройства, если не обязательно, то уж точно крайне желательно на сети VoIP.
Пойдём от простого к сложному. Для начала определим те самые три функции, которые SBC выполняет на сети заказчика.

1. Безопасность
2. Совместимость
3. Обеспечение и контроль качества

В большинстве случаев для многих сразу возникает масса вопросов, так как, казалось бы, что есть Firewall, который отлично справляется с функцией безопасности и зачем сеть VoIP защищать дополнительно. Зачем обеспечивать совместимость, если есть стандарт RFC3261 и все работают согласно этому стандарту. А качество – есть мнение, что VoIP качество больше зависит от качества сети, а не от какого-то устройства. Теперь более подробно разберёмся, в чем собственно состоит обеспечение безопасности VoIP сети, и почему совместимости по RFC3261 (SIP v2) не достаточно, что именно обеспечивает, с точки зрения качества, Пограничный Контроллер Сессий.
1. Безопасность
Для начала, надо разобраться, а от чего мы хотим защитить и что может сделать злоумышленник? Самое первое и болезненное, что может сделать злоумышленник, это воровство траффика. Злоумышленник получает доступ к тому, чтобы от вашего лица была возможность звонить на оператора связи и далее делает достаточно дорогие вызовы куда-нибудь на солнечную Кубу через вашу систему. Чем это грозит, наверное, всем понятно – большой счет со стороны оператора связи.
Как происходит воровство и какие есть механизмы его предотвращения?
Как всегда, всё должно начинаться с самого примитивного. Причем, это примитивное обезопасит вас достаточно сильно. Злоумышленники в большинстве случаев начинают с того, что просто проверяют все IP адреса по ответу на порт SIP (UDP 5060). Например, посылая сообщение OPTIONS на данный порт последовательно на все IP адреса. Таким образом он просто ищет очередную жертву. Далее происходит следующее: как только они получают ответ, то сразу злоумышленник получает массу информации о вас. А именно – он знает, что у вас SIP доступен через Интернет и в 99% случаев он знает тип вашей IP-PBX. Как именно он это делает? Легко. Когда IP-PBX отвечает на SIP запрос, она дает ответ, где указано поле User-Agent с именем и версией устройства. Например: user-agent: Asterisk 1.2.3. Сразу хочу извиниться перед всеми любителями Asterisk, буду упоминать именно её, так как она является наиболее популярной для взлома системой. Что делает SBC в данном случае: по рекомендации он использует отличный от 5060 порт и легко подменяет значение поля User-Agent. Тут мы сразу ставим злоумышленника в более сложную ситуацию – во-первых, его система не всегда определяет, что вы используете SIP, так как в большинстве случаев вы на его запросы просто не отвечаете; во-вторых, даже получив ответ, он не будет знать, что у вас за станция и каким боком к ней подступиться. Почему второе так же является очень важным. А всё просто. Например: злоумышленник определил, что у вас Asterisk версии 1.2.3, на который был баг, который позволял позвонить на внутренний номер и далее с помощью DTMF набора установить переадресацию этого внутреннего номера. А далее он звонит на этот внутренний номер, где стоит переадресация на нужный ему номер. И в целом, чем больше функционал у АТС, тем больше есть различных способов воспользоваться этим функционалом в не тех целях, для которых предназначается данный функционал.
А если уж говорить о переадресации, то она является одним из самых тонких, с точки зрения безопасности в VoIP. Так как в большинстве случаев никто не думает, как и где передавать номер, кто совершал вызов, а он просто без вариантов подменяется на номер, кто переадресовал вызов. Это тоже важно и нужно проверять, что SBC так же делает. В данной статье не буду углубляться в тему переадресации номера.
Еще важный вопрос – это управление и доступ к управлению. SBC изначально имеет множество интерфейсов и возможности настройки VLAN, что позволяет интерфейс управления вынести в отдельную защищенную подсеть, что делает вопрос получения доступа к нему очень сложным.
С точки зрения безопасности, стоит уделить отдельное внимание маршрутизации вызовов и проверки SIP пакетов. Важно, чтобы любой пакет был максимально доверенным. Для этого SBC имеет достаточно много инструментов. Во-первых, это проверка по различным полям. Например, вы знаете, что от оператора всегда приходит сообщение, с полем User-Agent: ITSP_SIP и еще что-то добавляет. Либо при подключении к IP АТС телефона через Интернет требуется обязательно проверять, что регистрация проходит с того телефонного аппарата, который разрешен в вашей сети. Также, требуется максимально правильно определить маршруты, на которые можно звонить, с которых можно звонить. Это так же позволяет SBC обеспечить правильный уровень безопасности.
Еще очень важный момент, который обеспечивает SBC безопасность вашей IP-АТС, это разграничение VoIP трафика в вашей сети. Он позволяет выделить отдельную подсеть для вашей IP-АТС и сделать доступ к ней только с другого физического интерфейса, тем самым обеспечив доступ к вашей VoIP сети только через Пограничный Контроллер Сессий.
А далее, это набор стандартных вещей, типа регулярного Firewall, который так же находится на SBC.
Собственно, именно эти инструменты на SBC позволяют обеспечить вам безопасность от попытки взлома системы для воровства трафика или еще каких-то действий. Конечно, SBC имеет и другие методы и способы защиты, но тут я описал скорее самые популярные и важные действия для защиты вашей VoIP сети:
a. Есть еще DoS/DDoS атаки. С одной стороны, они более безобидны, так как, только лишь отключают сервис телефонии, но есть и другая сторона этой проблемы:
b. Тут надо четко понимать, если отключается IP-АТС, то у вас пропадает вся телефония, что само по себе не приятно и может влиять на бизнес-процесс.
c. Также не маловажным фактором является то, что чаще всего эти атаки делаются с целью подбора паролей пользователей с дальнейшими действиями этого пользователя. В том числе и воровства трафика.
SBC имеет встроенный Firewall, который работает по двум принципам – статический и динамический. Первый вариант понятен и описывать его, наверное, нет никакого смысла. Второй вариант работает следующим образом. Если вы допускаете возможность регистрации SIP абонентов из сети Интернет, то теоретически он может регистрироваться с любого источника и фильтровать статически просто невозможно. Например, если ваши сотрудники улетели куда-нибудь в Китай и хотят подключиться к вашей IP-АТС, вам будет необходимо открыть полный доступ, или как минимум для всех Китайских IP адресов. Единственный способ обезопасить вашу сеть IP телефонии – это динамические списки контроля доступа, когда SBC закрывает только те IP адреса на сетевом уровне, с которых идет аномальный трафик. Причем степень аномальности вы выставляете сами.
Есть еще вопрос подслушивания и единственный способ обойти это – шифрование. Но, так как в нашей стране службы безопасности относятся к этой теме очень скрупулезно, то эту тему я оставлю без внимания. Тем более, что в России шифрование никто не предоставляет всё по тем же причинам.

2. Совместимость
Второй вопрос, который встает перед SBC, это совместимость. Все рассказывают о том, что они поддерживают SIP v2 (он же RFC 3261) и всё будет работать и так. Но как показывает практика – это не сосем так, точнее совсем не так. Я бы сказал, что вопрос совместимости является самым сложным и комплексным в VoIP сети. Почему так? А для чего делаются IP АТС и системы унифицированных коммуникаций? Как бы все не рассказывали, что они стремятся к стандартизации, на самом деле приоритет главный в другом и он полностью противоречит самой идее сделать всё по стандарту. Задача производителей АТС – это предоставить максимально интересный и полный набор сервисов и если кто-то вдруг придумал новый сервис, то никакого варианта у них нет, кроме как сделать это по-своему. (Ну а потом сделать новый RFC и всем сказать – поддерживаете). Причем слив информации работает в нашем мире хорошо (но не отлично). И если конкурент прознал, что кто-то делает новую фичу, естественно он делает такую же, правда, по-своему и стандартизирует свою версию реализации данной функции и естественно, стандартизирует её. В итоге мир получает две отличные станции с одинаковой функцией, которые работают по-разному, при этом по стандарту, но между собой не совместимы. И если с базовым вызовом проблем уже ни у кого нет, то вот с расширениями SIP вопросов всегда предостаточно. Для статистики, на данный момент в мире более 100 расширений RFC для SIP. Станция обычно поддерживает не более 20, наш SBC поддерживает более 80. И если вам требуется, чтобы вы смогли использовать весь ваш функционал при работе с оператором связи, то SBC в этом случае просто необходим.
А еще на совместимость влияет та самая безопасность. И не ваша безопасность, а безопасность оператора связи. Как правило, оператор имеет свой собственный SBC и в большинстве случаев у него стоят четкие и понятные фильтры сообщений/полей/функций при работе с клиентом. Приведу два простых и понятных примера:
a. IP АТС использует SIP Refer для перевода вызова (это когда станция говорит вышестоящей станции, что Вы переводите вызов на внешнего абонента, и пускай дальше вызов соединяет между собой вышестоящая станция. Всё хорошо, но вот момент – а кому счет выставлять. Оператор в данном случае должен замкнуть вызов между двумя не его абонентами. Счет должен быть выставлен вам, да вот вызова с вами не было. По этой причине, оператор просто блокирует такой функционал (и правильно делает). SBC в данном случае забирает на себя вопрос коммутации вызова и отработки сообщения REFER и для оператора отображается два вызова (входящий и исходящий). И всё отлично работает.
b. Переадресация вызова. Например: Абонент А позвонил абоненту Б, у которого стоит переадресация на абонента В. И вот вызов идет от абонента Б на абонента В, при этом в качестве номера вызывающего отображается номер А. И это правильно, так как вызывающий номер – это номер А, а не тот который переадресует. Это телефонный стандарт. И если в ISDN (E1) всё это четко описано, так как есть поле Redirect number, то вот в SIP номер В для правильной идентификации может быть передан с использованием History-Info, Referred-By, Diversion. И исходя из этого, операторы просто любят блокировать такие номера, ссылаясь на то, что у них биллинг не правильно работает. То есть, биллинг оператора связи противоречит стандарту SIP или просто оператор не хочет принимать переадресованные вызовы, согласно стандарту. SBC позволяет всячески преобразовывать один формат в другой или просто переносить номер из любого поля в поле From и/или P-Asserted-Identity.
Остальные примеры не столь часто встречающиеся, при этом не менее важные, так как чем реже они встречаются, тем сложнее их решить стандартными методами телефонной станции. Отдельно хочется сказать про вопросы совместимости и адаптации голосовых кодеков. Прошло то время, когда все поддерживали кодеки G.711 и G.729 и этого достаточно. Тому массу причин, а главное производители АТС стремятся улучшить качество связи, используя собственные кодеки или специализированные кодеки, типа SILK/OPUS/MS-RTA. Тут причина проста (особенно если мы говорим про систему унифицированных коммуникаций) – сейчас все компании стремятся сделать телефонию не только на IP телефоне (который можно выделить в отдельный VLAN и дать трафику приоритет), но и сделать телефонию везде – на планшетах, лептопах, смартфонах, через WiFi, публичный Интернет. И тут далеко не всегда возможно приоритезировать трафик и обеспечить надлежащее качество в общем IP потоке, а адаптивные кодеки дают лучшее качество на таких сетях, относительно G.711/G.729.
Вот тут как раз SBC помогает использовать у вас в сети тот кодек, который требуется, а с оператором стыковаться с помощью того, который он поддерживает.
Отдельно стоит вопрос DTMF и факсов, которые в VoIP среде никто не отменял. Не хочу углубляться в эту тему, могу лишь сказать, что мы на данный момент поддерживаем все варианты передачи как DTMF, так и факсов.
На самом деле писать про совместимость можно достаточно долго и можно даже сделать отдельные статьи как решить ту или иную проблему с помощью нашего SBC. Но в любом случае, даже если ваш оператор говорит, что он добьётся полной совместимости с вами, не всегда оператор добивается этого и сроки настройки этой совместимости всегда большие. SBC позволит вам уменьшить риски и сократить расходы при подключении.

3. Обеспечение и контроль качества
Ну и в заключении, немного напишу об обеспечении и контроле качества:
a. Обеспечение качества – в первую очередь это работа с голосовыми кодеками.
b. Контроль качества – SBC отслеживает все вызовы по множеству параметров, таких как Эхо/задержка/потери пакетов/Jitter/MoS и когда у вас случается проблема, вы сразу четко и быстро понимаете с какой стороны и по какой причине произошло ухудшение связи, тем самым сократив сроки исправления проблем. Также SBC позволяет самостоятельно перестроить маршрут в случае, если с одним оператором качество связи падает. Это позволит сохранить качество вызова без внешнего вмешательства.
Также, не маловажным фактором с точки зрения обеспечения качества, является правильная настройка маршрутизации с возможностью балансировки и резервирования маршрутов. В том числе, если у вас есть резервный стык с сетью Интернет, то он должен включаться в том числе для VoIP, вне зависимости от настроек сетевого оборудования.

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

Источник

Производительность AudioCodes SBC

Всем добрый день! AudioCodes имеет определенное количество моделей SBC, каждая из которых имеет определенную производительность. Я не буду переписывать наши брошюры, где описаны характеристики, так как эта информация есть в свободном доступе на нашем сайте. В данной статье подробно рассмотрю результаты тестирования AudioCodes независимой компанией Miercom, которая специализируется на проведении независимых тестирований. Данная компания провела тестирование почти всех ведущих производителей SBC. Обзор результата тестирования читайте под катом.

Под тестирование попали наиболее производительные модели SBC, а именно: Mediant 4000 (поддерживает до 5000 одновременных соединений), Mediant 9000 (он же программный SBC, поддерживающий до 24 000 одновременных соединений) и Виртуальный SBC (поддерживающий до 6000 одновременных соединений). Виртуальный SBC работал на платформе VMWare. Результаты тестирования в оригинале на английском языке доступны по ссылке.

На сайте Miercom данный результат доступен только для зарегистрированных пользователей

На альтернативном источнике (не требует регистрации): ссылка на скачивание

Тестирование проводилось не только по количеству сессий, но и по многим параметрам производительности:
Количество одновременных соединений с манипуляцией заголовков SIP, преобразования SIP UDP SIP TCP, шифрование, транскодинг различных кодеков, WebRTC и т.д.

Первый тест производился по производительности по сигнальным сессиям без учёта проксирования голосового трафика. Результат данного теста: максимальная производительность с преобразованием SIP + преобразование SIP UDP SIP TCP Mediant 9000/VE составляет 32000 сигнальных сессий + 500 CPS (Call Per Seconds – попыток вызовов в секунду. У Mediant 4000 значение ниже, а именно 5000 сигнальных сессий + 120 CPS. Но тут надо сразу отметить, что под сигнальными сессиям понимается один вызов без проксирования голосового трафика. Собственно, из-за этого у Mediant 9000/VE результаты получились выше того, что мы пишем официально, так как во всех брошюрах указаны данные по производительности с учётом проксирования голосового трафика. Надо отметить, что во время тестирования SBC делал следующие манипуляции: удалял поле SIP, добавлял поле SIP, модифицировал поле SIP и преобразовывал SIP UDP в SIP TCP и наоборот.

Отдельным пунктом является тестирование наибольшей загрузки. Идея в том, что при нормальном приросте трафика (для Mediant 4000 – 120 CPS), внезапно на 10 секунд идёт слишком большая нагрузка (в тесте на Mediant 4000, это была 500 CPS). Результат тестов показал, что при такой внезапной нагрузке, SBC способен обработать до 190 CPS. Для Mediant 9000/SE данное значение достигло 500 CPS, при повышении производительности до 2000 CPS. Причем данное тестирование было сделано как для Mediant 9000, так и для виртуального SBC и результаты не отличаются.

Далее идут тесты по транскодингу. Причем тесты достаточно интересные, так как учитывают не просто преобразование G.711 20 ms в G.729 20 ms, а также преобразование G.711 в SILK и OPUS. SILK – это кодек, который используется в решении Skype и уже достаточно давно подтвердил, что является отличным кодеком для передачи голоса на сложных IP каналах, таких как Интернет в гостиницах и т.п. Кодек OPUS является открытым кодеком, который продвигает компания Google. Данный кодек за основу передачи голосовой информации берет кодек SILK, но так как он является универсальным кодеком, который так же предназначен для сохранения медиа информации, то работа с ним является более сложной. Если смотреть с практической точки зрения, то кодек SILK используется в решениях Skype For Business компании Microsoft, а кодек OPUS используется в решении WebRTC. Если рассматривать конкурентные решения, то далеко не все SBC поддерживают данные кодеки, а нагрузочные тестирования никто, кроме нас, не проводил.

При проведении тестирования учитывалось не только количество сессий, но и качество транскодинга по шкале MOS. Качество при транскодировании в кодек G.729 падает до уровня 3.88 (стандартное качество G.711 – 4.2). Это обусловлено особенностью кодека G.729, который сам по себе не может обеспечить лучшее качество. Если говорить о преобразовании кодеков SILK и OPUS, то качество остается на уровне 4.2. То есть качество голоса не ухудшается при преобразовании из G.711. При транскодировании более качественных HD кодеков в SILK и/или OPUS качество будет выше, так как оригинальный кодек имеет более высокое качество, нежели G.711. Как итог данных тестов – AudioCodes соответствует заявленным характеристикам по преобразованию голосовых кодеков, при полном сохранении качества голоса. Более подробную информацию о количестве сессий транскодинга, можно узнать из Release Notes.

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

Данные результаты обеспечиваются встроенной системой IDS (Intrusion Detection System), которая обеспечивает обнаружение атак злоумышленников и обеспечивает динамическую блокировку адресов злоумышленников и с периодической проверкой данных адресов. Также система дает по SNMP информацию о атаке, таким образом помогая максимально быстро принять необходимые меры для остановки данной атаки. Исходя из результатов данных тестов, можно смело говорить, что SBC полноценно обеспечивает защиту голосовой сети от различного типа атак.
Отдельно хочется упомянуть, что AudioCodes один из первых производителей SBC, который успешно прошёл Miercom тестирование на DDoS атаки для Виртуальных SBC с Virtual Function Virtualization.

Отказоустойчивость
Отдельное тестирование было проведено с точки зрения отказоустойчивости системы. Тут проводилось два типа тестов. Оба теста проводились при условии полной загрузки SBC с проксированием голосового RTP трафика в кодеке G.711.

Архитектура Mediant 4000/9000 (так же, как и другой линейки аппаратных SBC) такова, что все интерфейсы дублируются и работают в режиме active/standby. Сделано это для того, чтобы SBC можно было подключать к различным коммутаторам в одной сети. Если что-то происходит с одним из коммутаторов, то SBC определяет падение данного канала и автоматически переключается на второй порт. Первый это тест на проверку работы интерфейса в режиме active/standby. Был отключен активный сетевой интерфейс, через который шел голосовой RTP трафик. Результат скорости переключения и начала работы в двустороннем режиме второго сетевого интерфейса: Mediant 4000 – 10.3 msec., Mediant 9000 – 10.2 msec. Все вызовы сохранились. В обоих вариантах данный перерыв сервиса не отображается на качестве вызова. По оценке MOS, в обоих случаях качество оставалось на уровне 4.2.

Второй тест более сложный. А именно, когда оборудование установлено в режиме HA (High Availability) и в момент полной загрузки устройства, основной SBC просто отключается. При данном сценарии, все типы SBC отработали корректно. Поясню. Все существующие соединения переехали на резервный SBC и остановки сервиса не произошло. Новые вызовы начали успешно устанавливаться на резервном SBC. Единственный момент – вызовы, которые находились в момент переключения в состоянии соединения (то есть вызов уже инициирован, но соединения не произошло, например, вызов в процессе дозвона) оборвались, но переключение данных соединений согласно архитектуре, не предусмотрено.

WebRTC
Дополнительный тест не на производительность, а на функциональность. WebRTC – это стандарт, который разрабатывается как открытый стандарт для связи между Web браузерами и мобильными приложениями, который использует простой API самих браузеров. На данный момент WebRTC поддерживается следующими платформами/браузерами – Google Chrome, Android Chrome, Mozilla Firefox, Opera. По данной тематике на хабре было написано достаточно много статей (например тут: http://habrahabr.ru/post/187270/), все они в основном описывали сценарий звонков между двумя Web-браузерами. В данном случае, одним из клиентов выступает не Web-браузер, а AudioCodes SBC. Цель данного теста заключается в том, чтобы убедиться, что AudioCodes SBC может принимать на себя WebRTC и транслировать его в стандартный SIP. Схема тестирования WebRTC представлена ниже:

AudioCodes SBC принимает на себя WebRTC вызовы с кодеком OPUS и транслирует их в сторону Skype For Business сервера с использованием стандартного SIP и кодека G.711. В данном случае вместо Skype For Business сервера, можно использовать любую АТС, поддерживающую SIP или любой софтсвич. Также SBC проверяет корректность номера через LDAP, таким образом обеспечивая дополнительный контроль над сессиями, в случае использования данного решения в рамках предприятия. Так же, как вариант, можно подключить и к TDM АТС через поток E1. Результаты теста показали, что AudioCodes SBC полноценно терминирует на себе WebRTC с использованием таких протоколов как: DTLS, ICE Light, SIP over Secure Web Socket, RTP и RTCP multiplexing, и транскодирования широкополосного кодека OPUS в кодек G.711 или любой другой, который требуется.

Источник