Всем добрый день! 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 и результаты не отличаются.

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

1. При проксированиии наиболее часто используемом кодеке G.711 20 ms:
   
   • Mediant 4000 – поддержка до 5000 одновременных вызовов
   • Mediant 9000 – поддержка до 24000 одновременных вызовов
   • Mediant VE (Виртуальный SBC) – поддержка до 6000 одновременных вызовов
2. При преобразовании IPv4 <-> IPv6
   
   • Mediant 4000 – поддержка до 5000 одновременных вызовов
   • Mediant 9000 – поддержка до 24000 одновременных вызовов
   • Mediant VE (Виртуальный SBC) – поддержка до 6000 одновременных вызовов
3. При преобразовании RTP <-> SRTP
   
   • Mediant 4000 – поддержка до 5000 одновременных вызовов
   • Mediant 9000 – поддержка до 16000 одновременных вызовов
   • Mediant VE (Виртуальный SBC) – поддержка до 4000 одновременных вызовов

Далее идут тесты по транскодингу. Причем тесты достаточно интересные, так как учитывают не просто преобразование 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 поддерживают данные кодеки, а нагрузочные тестирования никто, кроме нас, не проводил.

Результаты тестов ниже:

Mediant 4000	Mediant VE
G.711 <-> G.729: 5000 одновременных соединений G.711 <-> SILK: 4050 одновременных соединений G.711 <-> OPUS: 3850 одновременных соединений	G.711 <-> G.729: 420 одновременных соединений G.711 <-> SILK: 400 одновременных соединений G.711 <-> OPUS: 320 одновременных соединений

Mediant 9000 в данном тестировании не участвовал.

При проведении тестирования учитывалось не только количество сессий, но и качество транскодинга по шкале 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 на прирост регистраций. Первый тест просто показывает максимальное количество регистраций от удаленных устройств. Результаты следующие:

1. Mediant 4000: 20 000 регистраций
2. Mediant 9000: 120 000 регистраций
3. Mediant VE: 30 000 регистраций

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

1. Mediant 4000: 67 секунд (то есть около 300 регистраций в секунду)
2. Mediant 9000: 75 секунд (то есть 1600 регистраций в секунду)
3. Mediant VE: всего 20 секунд (то есть 1600 регистраций в секунду, так же как и Mediant 9000)

Ну а теперь те самые тесты на DoS/DDoS атаки, про которые любят спрашивать различные операторы связи. Естественно, для операторов связи это наиболее актуально, так как различные DoS/DDoS атаки, с целью взлома (подбора паролей) или просто вывода сервиса из строя, являются неотъемлемой частью жизни любого оператора. А тут важно даже во время атак продолжать предоставлять сервис. Под такого рода атаки, как правило попадают те операторы, или клиенты, кто разрешают подключение по VoIP из публичного интернета. Как пример, это может быть подключение смартфонов или программных телефонов по SIP из интернета для сотрудников компании, кто часто путешествует и находится в командировках. В данном случае нужно, с одной стороны, сэкономить деньги компании на роуминге, с другой стороны, обеспечить защищенное подключение без возможности взлома.

Теперь о результатах и методике тестирования. Тестирование проводилось с помощью признанного лидера рынка генератора трафика Ixia, подключенного через один коммутатор к SBC (Часть тестов проводилась с помощью Open-source решения генерации SIP трафика – PROTOS). Тестировались 15 тип различных атак, в тот момент, когда на SBC параллельно шёл максимальный трафик, как с точки зрения количества сессий, так и с точки зрения прироста соединений. Продолжительность каждой атаки составляла 5 минут:

• ARP Flood
• Evasive UDP
• Land Attack
• Ping-of-Death
• Ping Sweep
• RST Flood
• TCP Scan
• TearDrop
• Surf Attack
• SYN Flood
• UDP Flood
• UDP Scan
• Unreachable Host
• Xmas Tree Attack

Схема тестирования представлена ниже:


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

Атака	Описание атаки	Результат Mediant 4000	Результат Mediant 9000
SYN Flood	44 000 TCP SYN пакетов в секунду (pps) направленных на сигнальный порт 5060. Данный тест проводился при установлении соединения без проксирования RTP, так как проверялась только сигнализации SIP.	Никак не влияет на работу, при том, что SBC находился под нагрузкой 5000 одновременных соединений и приросте вызовов 122 в секунду	Никак не влияет на работу, при том, что SBC находился под нагрузкой 32 000 (Mediant 9000) одновременных соединений и приросте вызовов 500 в секунду
UDP FLOOD	50 000 UDP pps, что составляет около 400 Mbps, направленные на сетевой порт SBC.	Никак не влияет на работу, при том, что SBC находился под нагрузкой 5000 одновременных соединений и приросте вызовов 122 в секунду. При том, что значение MOS голосового трафика не упало и осталось на уровне 4.2 (стандартно для кодека G.711).	Никак не влияет на работу, при том, что SBC находился под нагрузкой 24 000 (Mediant 9000) одновременных соединений. При том, что значение MOS голосового трафика не упало и осталось на уровне 4.2 (стандартно для кодека G.711).
Unknown address	18 000 (56 000 для Mediant 9000/VE) SIP сообщений в секунду (200 Mbps для 18 000 пакетов), направленных на SBC с неизвестных адресов	Никак не влияет на работу, при том, что SBC находился под нагрузкой 5000 одновременных соединений и приросте вызовов 122 в секунду	Никак не влияет на работу, при том, что SBC находился под нагрузкой 32 000 (Mediant 9000) одновременных соединений и приросте вызовов 500 в секунду.
SIP Fuzzing	18 000 некорректных сообщений в секунду (Mpbs), не соответствующим стандарту RFC	Никак не влияет на работу, при том, что SBC находился под нагрузкой 5000 одновременных соединений и приросте вызовов 122 в секунду	Никак не влияет на работу, при том, что SBC находился под нагрузкой 32 000 (Mediant 9000) одновременных соединений и приросте вызовов 500 в секунду.
ICMP Flood	52 000 ICMP pps (200 Mbps), направленных на голосовые порты SBC	При полной загрузке в 5 000 одновременных соединений, данная атака никак не отражается на качество связи. Значение MOS для кодека G.711 остается на уровне 4.2, что является стандартом для G.711	При полной загрузке в 24 000 (6000 для VE) одновременных соединений, данная атака никак не отражается на качестве связи. Значение MOS для кодека G.711 остается на уровне 4.2, что является стандартом для G.711

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

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

Характеристика	Mediant 500	Mediant 800	Mediant 1000	Mediant 2600	Mediant 3000
Количество сессий	250	250	150	600	1008
Транскодинг	—	30	96	600	1800
Отказоустойчивость	+	+	—	+	+
Количество регистраций	800	800	600	8 000	3 000
Поддержка WebRTC	—	+	—	+	—
Наличие TDM интерфейсов	FXO, FXS, E1	FXO, FXS, E1	FXO, FXS, E1	—	E1, STM-1