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

Некоторые провайдеры, конечно подсказывают, что можно предпринять со своей стороны, в чем может быть проблема. Снимут дамп, сделают анализ и дадут рекомендации. Но таких крайне мало. Из памяти, пожалуй вспомню оператора “Мобилон”. Привет техподдержке, если читаете!

А что происходит, если провайдер не дал рекомендаций, не указал на причину?

Несомненно, у вас начнет закрадываться мысль о смене провайдера. Но решит ли это проблему? Если причина на нашей стороне, то очевидно, что проблема не решится, и качество будет также неудовлетворительным с новым провайдером. А переход, дело не простое и затратное. За такой исход событий руководство компании спасибо нам не скажет.

Можно еще обратиться к какой-нибудь аутсорсинговой фирме, которая имеет кейсы в решении подобных проблем. Но это дополнительные затраты. Да и нет никаких гарантий, что потраченные средства в итоге оправдают себя.

Что же еще можно предпринять? Казалось бы, вариантов больше не осталось...

Но может быть, все таки, разобраться самому? Возможно, это не так сложно?

“Да, дорогие друзья!” 
Отвечу я вам. Всё гораздо проще, чем кажется на первый взгляд!

Имея позитивный опыт в решении подобных проблем у разных компаний, хочу поделиться с вами способом ее диагностики и решения, не прибегая к кардинальным мерам и помощи сторонних лиц.

Для диагностики нам понадобится научиться снимать дамп сети (sniffer) с роутера и маршрутизатор Mikrotik. А также, настроить очереди (QoS) на роутере.

Для упрощения схемы, я поделил весь процесс на этапы:

1. Настроить и запустить sniffer

2. Воспроизвести проблемный вызов

3. Проанализировать sniffer в Wireshark

4. Настроить на роутере выделенную полосу (QoS) для телефонии

5. Протестировать связь

1. Настройка и запуск packet sniffer

Для того чтобы определить причину проблемы, необходимо снять dump звонка. В нем будет содержаться вся информация о состоянии сети во время вызова.

Настраиваем на Микротике packet sniffer: Tools > Packet Sniffer

На вкладке General оставляем значения по умолчанию.

Вкладка Streaming: галочки Streaming Enabled и Filter Stream, в поле Server пишем адрес, куда будем отправлять данные, собираемые сниффером.

Я отправляю на свой ПК в той же сети, поэтому прописываю его локальный адрес. Но можно слать и на удаленный сервер, тогда прописываем его внешний ip.

Вкладка Filter: здесь необходимо в поле IP Address прописать ip-адрес провайдера телефонии.

Желательно уточнить у самого провайдера адреса серверов, с каким сервером осуществляется обмен сигнальными сообщениями, а с каким - RTP.

Если не получилось выяснить адреса провайдера, то можно прописать просто 0.0.0.0/0

Но тогда в дампе будет очень много лишней информации, что затруднит анализ.

Я пообщался с техподдержкой своего провайдера, они порекомендовали прописать всю подсеть.

Сниффер на роутере запущен, теперь необходимо поймать пакеты.

На том ПК или сервере, адрес которого указали в поле Server, нужно запустить tcpdump.

На Windows:

а) нужно скачать утилиту tcpdump

Скачиваем с официального сайта версию не для коммерческого использования.

tcpdump.exe можно запустить даже с флэшки

Для этого запускаем cmd от имени администратора и проваливаемся в директорию с файлом tcpdump.exe

Вводим команду tcpdump -D

Нам отобразится список доступных интерфейсов.

Запускаем дамп в онлайн режиме, чтобы найти интерфейс, который нам нужно слушать.

Например: tcpdump -i 1 -v -n host 192.168.88.1

где 1 - это номер интерфейса, а host - адрес роутера.

У меня пакеты летят на интерфейсе под №4, его и буду слушать.

Далее запускаем команду для отлова сниффера с Микротика:

tcpdump host 192.168.88.1 -i 4 -C50 -n -v -w name_sniffer.pcap

где i - номер интерфейса, С50 - ограничение размера записываемого файла до 50Мб, n - отображать IP-адреса вместо имени хостов, v - уровень отображения получаемой информации (1-й уровень), w - записывать данные в файл.

На Linux :

Необходимо установить утилиту tcpdump. Обычно она присутствует в стандартном репозитории.

Более подробно про установку можно посмотреть, например, здесь.

Запускаем команду:

tcpdump host 192.168.88.1 -i any -C50 -n -v -w /var/tmp/name_sniffer.pcap

После запуска tcpdump вы должны увидеть отсчет улавливаемых пакетов (на Linux), в поле Got. Если отсчет не идет, значит что-то сделали неверно, перепроверьте.

2. Фиксируем проблемный звонок

Теперь, когда у нас tcpdump ловит сниффер с Микротика, нужно зафиксировать проблемный звонок.

Если проблема плавающая, тогда следуют попросить сотрудников, чтобы записали время и номер телефона, когда возникнет деградация голоса.

У меня получилось зафиксировать такой пример самостоятельно с одним из сотрудников:

Как мы слышим на записи, голос идет с прерываниями.

Но может быть и так, что на записи из личного кабинета виртуальной АТС провайдера всё будет отлично, а мы слышали человека на том конце провода плохо. Это значит, что к провайдеру голос приходит хорошего качества, а уже по пути от провайдера до нашего конечного устройства голос доходит с потерей пакетов. Для того, чтобы проверить это, нам поможет сниффер.

3. Останавливаем sniffer и анализируем его в Wireshark

Проблемный вызов необходимо проанализировать. Останавливаем tcpdump (Ctrl+C) и sniffer на Микротике (нажать Stop). Создастся файл name_sniffer.pcap.

Устанавливаем программу Wireshark. Скачать ее можно бесплатно с официального сайта. А на Линуксе можно установить из стандартного репозитория.

Открываем pcap файл в Wireshark и переходим в Телефония > Вызовы VoIP

В новом окне отобразятся все вызовы, которые попали в дамп. У меня такой один.

-Выберите вызов и откройте “Последовательность потоков”, чтобы увидеть движение запросов по вашему звонку.

Здесь мы увидим, с каким сервером провайдера идет обмен сигнальными сообщениями, а с каким сервером осуществляется передача голосовых пакетов (RTP).

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

Но для анализа качества голоса, данная информация нам нужна только, чтобы увидеть адрес сервера передачи голосовых сообщений.

Далее нас интересуют RTCP пакеты.

Из всего перехваченного сниффером трафика нужно отфильтровать только RTCP пакеты. 

Прописываем фильтр:

(rtcp.ssrc.fraction>10)||(rtcp.ssrc.jitter>35)

- отобразить RTCP со значением потерь пакетов больше 10 или RTCP со значением джиттера больше 35.

Выбираем сообщение и разворачиваем RTCP > Source 1 > SSRC Contents

Здесь видим, что потеряно 50 пакетов из 256 и уровень джиттера 166 (хотя нормальный уровень это 30-70).

Так можно полистать по всем найденным сообщениям и убедиться, что деградация качества голоса возникает из-за потери голосовых пакетов на нашем интернет канале.

По каким причинам это может происходить?

1. Забивается линия выделенная вам от интернет провайдера.
   Например, у нас 3Mб/с на "внешку". Устройства в локальной сети потребляют все 3Mб/с, но если просто сёрфить в браузере, то мы не заметим нехватку канала. Так как в этом случае, используется транспортный протокол TCP. А телефония использует UDP, которому свойственно теряться в процессе передачи, если весь ваш выделенный канал занят.

2. Устройства подключены по “воздуху” (Wi-Fi).
   В таком случае будет высокий показатель джиттера.

3. У провайдера на линии есть радиоканал.

4.  Проблема с вашим маршрутизатором.

5. Проблемы на линии интернет провайдера

В этой статье, более подробно, рассмотрена причина под пунктом № 1.

По остальным скажу кратко.

Пункт № 2 - если на устройствах есть функция джиттер-буфер, то нужно установить режим “Fixed”. Если нет такой опции, то подключить устройство витой парой.

Пункт № 3 и № 5 - обратиться к интернет провайдеру, предоставив наши дампы, подтверждающие проблему.

Пункт № 4 - диагностировать или заменить роутер.

Но в первую очередь, рекомендую всегда сначала проработать пункт № 1.

4. Настраиваем выделенную полосу для ip-телефонии

Необходимо в вашей локальной сети обеспечить для ip-телефонии отдельную полосу пропускания (QoS), чтобы трафик других устройств не мешал.

Для начала, измерьте фактическую скорость интернета на "внешку".

Я измеряю через speedtest.net. Можно еще с помощью 2ip.ru или утилитой iperf.

На speedtest.net я выбираю Change Server город отличный от моего, чтобы исключить вероятность замера скорости в пиринге.

У меня на загрузку скорость 11Мб/с, на отдачу 14Мб/с. Хотя по договору должно быть 15М в обе стороны. Поэтому и рекомендую измерять, какая у вас скорость по факту, а не по бумагам. Это поможет корректно настроить очереди на роутере.

Для настройки очередей открываем на Микротике Queues

Cоздаем правила в разделе Simple Queues.

На вкладке General задаем ограничение по скорости для всей локальной сети.

Я устанавливаю максимальные значения лимита меньше на 2М, чем полученные при замере. 

Почему 2М? Беру с запасом, так как скорость может быть не постоянной и в моменте меняться как в большую, так и в меньшую сторону.

В Advanced выставить Queue Type распределение по pcq (это делается для того, чтобы устройства не мешали друг другу и равномерно использовали трафик).

Сохраняем это правило и создаем еще одно, для SIP.

Прописываем ip-адрес (можно всю подсеть) провайдера ip-телефонии. 

Максимальные лимиты устанавливаем, как заявлено по договору интернет провайдера.

В Advanced устанавливаем Limit At. Это позволит для телефонии оставлять 1Мб/с в любом случае, даже если идет максимальная нагрузка на канал другими устройствами.

Сохраняем и устанавливаем правило SIP на верхнюю позицию.

ВНИМАНИЕ!

1. Чтобы очереди (QoS) начали работать, необходимо деактивировать правило Fasttrack в IP > Firewall > Filter Rules.

2. Учитывайте порядок настроенных правил. Обработка осуществляется сверху вниз. Поэтому обязательно правило SIP поднимаем на самый верх.

Пояснение по настроенным QoS:

• весь трафик, который идет на ip-адреса отличные от адреса voip-провайдера, ограничивается 12Мб/с на загрузку и 9Мб/с на отдачу

• весь остаток от этого до 15Мб/с оставляем для телефонии

• и на тот случай, что если даже трафик проскочит выше лимитов, для телефонии отведен 1Мб/с принудительно

Далее проверяем ходит ли вообще трафик в настроенных QoS.

Нужно открыть настройки очереди и перейти на вкладку Traffic.

На вкладке Statistic можно увидеть, количество “дропнутых” пакетов и распределенных по pcq.

Также можно проверить, как отрабатывают очереди, с помощью утилиты iperf.

5. Тестируем связь

Теперь, когда QoS настроены, нужно протестировать связь.

Ставим дамп и делаем несколько тестовых звонков.

Я сделал несколько вызовов сотрудникам, и мы вместе убедились, что теперь прерываний не наблюдалось.

Вот пример одного из звонков. 

В дампе этого вызова потерь пакетов не наблюдается.

Единственное, можно заметить, что уровень джиттера выше нормы.

Это обусловлено подключением voip-устройства через Wi-Fi. И, так как устройство позволяет настроить джиттер-буфер, качество голоса не страдает.

Вы можете также и сами наглядно всё это увидеть в моих дампах. Скачать можно здесь:

> Дамп звонка до настройки QoS
> Дамп звонка после настройки QoS

Итог:

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

В некоторых организациях в локальной сети может находиться большое количество устройств с разными категориями. Например, помимо ip-телефонии еще ip-камеры, которые также используют udp протокол для передачи данных. Следовательно для ip-камер тоже необходимо выделять QoS.

Вам не обязательно настраивать очереди точно также, как у меня. Главное, что я хотел показать, это логику решения проблемы с качеством голоса.

Более подробно про QoS можно изучить еще в этой статье.