Pull to refresh
0

Корпоративный сервер IP телефонии на dedicated хостинге? Почему бы и нет

Reading time 4 min
Views 13K

О чем?


Размещение отдельных IT сервисов у хостинг провайдеров идея далеко не новая,
и сегодня я расскажу о тестировании решения вынесенного в заголовок.
Сервер, с установленной IP АТС, находится в одной из наших стоек в Нидерландах,
ширина канала сервера в мир составляет 1Гбит/с.
Офис компании N располагается в России, канал в мир 40Мбит/с.



Методика тестирования


  • Подключимся к одному из VoIP провайдеров России(в данном случае я использовал «Мультифон» от оператора «Мегафон»), проверим качество связи.
  • Сымитриуем большое количество «реальных» звонков утилитой sipp, проконтролируем качество.
  • Определим количество потерь и jitter при момощи утилиты iperf.
  • Выясним пиковое значение количества единовременных вызовов в разрезе использованного сервера и сценария sipp.


ОС, ПО, железо


  • Аппаратную составляющую обеспечит Dell 860 c 4Гб ОЗУ и Soft RAID 1.
  • В роли IP АТС солирует Asterisk 11.8.1.
  • ОС — Debian GNU/Linux 7.4 (wheezy).



Тесты


«Мультифон»

Как и ожидалось, на данном этапе не было и намека на какие-то проблемы.
Зарегестрировал «Мультифон» на Asterisk и создал пару внутренних пиров.
Затем установил софтфон Linphone, подключился к IP АТС с компьютера компании N, как внутренний абонент, и произвел несколько вызовов.
Качество звука замечательное, никаких искажений голоса ни я ни мои собеседники не заметили.

Нагрузим систему «реальными» звонками

Скриншот перед стартом:
сверху слева — загрузка сетевого интерфейса сервера,
справа — нагрузка на сервер,
снизу слева — консоль Asterisk,
справа — команда запуска sipp(подробности далее).


Тест инициирует компьютер компании N в России.
Команда для тестирования и её описание
./sipp 188.42.243.252 -s 2005 -i 89.189.163.20 -d 120s -l 120 -aa -mi 89.189.163.20 -rtp_echo -nd -r 10 -m 1000 -trace_screen -bg

где
188.42.243.252 — IP адрес сервера IP АТС Asterisk
-s 2005 — номер на который будет звонить sipp
-i 89.189.163.20 — устанавливает этот IP для заголовков 'Contact:','Via:', и 'From:'
-d 120s — длительность вызова 2 минуты
-aa — автоматически отсылать 200 OK на INFO, UPDATE и NOTIFY сообщения
-mi 89.189.163.20 — указываем IP для RTP
-rtp_echo — имитация диалога, отсылаем назад каждый rtp пакет
-nd — отключает стандартное поведение в неожиданных ситуациях(sipp будет прерывать звонки в случае получения неправильных SIP сообщений)
-r 10 — 10 звонков в 1 секунду
-m 1000 — завершить проверку по совершении 1000 звонков
-trace_screen — сохраняем лог
-bg — sipp будет запущен в фоне

Согласно диалплану Asterisk, для каждого позвонившего на 2005 проигрывается звуковой файл из MOH.
Экстеншен 2005:
exten => 2005,1,Answer()
same => n,Playback(/var/lib/asterisk/moh/reno_project-system)
same => n,Hangup(

Тест запущен.
Посмотрим какую нагрузку создал используемый сценарий sipp.



Как видно на скриншоте, sipp прогрузил сеть на ~10Мбит/с в обе стороны, CPU используется на 31%, а LA ~ 1,7.
Слева внизу видим подключеных пиров — это Мультифон и софтфон подключеный через 3G со смартфона.

Результаты работы sipp:




Все звонки завершились успешно, среднее время отклика во всех вызовах уложилось в пределы 100 — 150 мс.

Во время тестирования я произвел вызов с Linphone установленного на смартфоне, качество голоса ничуть не изменилось, слышимость замечательная.
Дополнительно я переодически подключался к текущим «диалогам» через ChanSpy для контроля качества, на данном этапе проблем не обнаружено.

Потери и jitter

Протестируем канал при помощи утилиты iperf.
Проверка с сервера IP телефонии на компьютер компании N.


А теперь с компьютера на сервер.


В этих тестах серверная часть iperf слушает UDP сокет и выводит информацию раз в 30 секунд.
Клиентская часть в течении 3-х минут отправляет на сервер UDP пакеты размером 172 байта, скорость выставлена в 10Мбит/с.
*10Мбит/с — это как раз около 120 звонков(G711), для подсчета удобно воспользоваться Asterisk Bandwidth Calculator

Размер пакета в 172 байта взят исходя из дампа во время тестирования sipp.


Результаты хороши и говорят сами за себя:
наблюдаются мизерные потери пакетов в направлении сервер -> компютер, jitter в обоих направлениях очень маленький.

Газу до отказу. Нарузим сервер по полной

Увеличим количество единовременных звонков до 400.


Сеть прогрузилась до ~33Мбит/с, CPU нагружены практически «в полку», LA ~9.
Но и при такой нагрузке я успешно совершил звонок через 3G со смартфона(все тем же Linphone).
Наблюдение «диалогов» через ChanSpy так же не обнаружило искажений звука.

Результаты работы sipp при 400 звонках.


Все вызовы вновь завершились успехом.
Среднее время отклика в 999-и из них уложилось в 100 — 150 мс, и в 1-ом вызове в 150 — 200 мс.

Некоторые хрипы, провалы и прочие неприятности в слышимости, а так же ругань в консоли Asterisk, появились при количестве единовременных звонков >=450.
Пиковым для этого сервера стало значение в 501 вызов.

Заключение


Как показал тест, размешать на хостинге можно не только web проекты, но и такие сервисы как IP АТС.
Резервный канал в Интернет в офисе компании N обеспечит отказоустойчивость канала до сервера,
а должным образом настроеное QoS, на пограничном маршрутизаторе, нужный урочень качества передачи голоса.

Если у вас найдется интересный сценарий для теста, то ждем вас в комментариях!
Благодарю за внимание!

Полезные ссылки:
1. sipp.sourceforge.net/doc/reference.html
2. www.voxlink.ru/kb/asterisk-configuration/asterisk-test-sipp
3. www.pbxware.ru/wiki/testirovanie_nagruzki_na_asterisk_server_pri_pomoshchi_sipp

Автор: fessaectan
Tags:
Hubs:
+6
Comments 14
Comments Comments 14

Articles

Information

Website
serverclub.com
Registered
Founded
2010
Employees
11–30 employees
Location
Нидерланды