Прерывается голос, слышу эхо… Проблема качества связи ip-телефонии. Как можно решить самостоятельно?

    Источник: ЯндексКартинки
    Источник: ЯндексКартинки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Открываем настройку Packet Sniffer
    Открываем настройку Packet Sniffer

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

    Прописываем адрес хоста куда слать сниффер
    Прописываем адрес хоста куда слать сниффер

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

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

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

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

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

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

    Прописываем адрес провайдера ip-телефонии
    Прописываем адрес провайдера ip-телефонии
    Packet Sniffer запущен-
    Packet Sniffer запущен-

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

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

    На Windows:

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

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

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

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

    Запускаем tcpdump на Windows
    Запускаем tcpdump на Windows

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

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

    Выводим список доступных интерфейсов
    Выводим список доступных интерфейсов

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

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

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

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

    Запускаем tcpdump online
    Запускаем tcpdump online

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

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

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

    Запустили tcpdump для отлова Packet Sniffer
    Запустили tcpdump для отлова Packet Sniffer

    На Linux :

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

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

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

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

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

    Запустили tcpdump для отлова Packet Sniffer
    Запустили tcpdump для отлова Packet Sniffer

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

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

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

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

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

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

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

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

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

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

    Открываем pcap файл для анализа
    Открываем pcap файл для анализа

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

    VoIP-вызов в дампе
    VoIP-вызов в дампе

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

    Дамп движения запросов звонка (последовательность потоков)
    Дамп движения запросов звонка (последовательность потоков)

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

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

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

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

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

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

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

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

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

    Анализ RTCP по звонку
    Анализ RTCP по звонку

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

    Настраиваю speedtest.net для замера скорости
    Настраиваю speedtest.net для замера скорости
    Выбираю Change Server
    Выбираю Change Server
    Результаты измерения скорости интернета
    Результаты измерения скорости интернета

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

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

    Queues
    Queues

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

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

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

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

    Настройки на вкладке General
    Настройки на вкладке General

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

    Настройки на вкладке Advanced
    Настройки на вкладке Advanced

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

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

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

    Настройки General для SIP
    Настройки General для SIP

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

    Вкладка Advanced при настройке QoS для SIP
    Вкладка Advanced при настройке QoS для SIP

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

    Порядок QoS правил
    Порядок QoS правил

    ВНИМАНИЕ!

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

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

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

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

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

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

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

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

    График трафика local QoS
    График трафика local QoS
    График трафика sip QoS
    График трафика sip QoS

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

    Статистика local QoS
    Статистика local QoS

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

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

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

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

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

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

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

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

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

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

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

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

    Итог:

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

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

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

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

    Комментарии 16

      0
      Пакетной маркой резать не лучше? Там параметром для маркировки гораздо больше.
        0
        Да. такой вариант пробовали. Но, как показала практика, с sip это неэффективно.
          0

          Что-то мне подсказывает (а опыта у меня достаточно для этого), что вы не умеете его готовить.
          Безусловно, выцепить SIP и RTP задача довольно хитрая, но я вполне её успешно решаю в своих проектах в mangle маркировке, и нет нужды знать расположение SIP и RTP серверов провайдера для QoS. Нужен в основном только SIP, чтобы прикрыть свою АТС от ботов.
          Также тупо выдавать n мбит на телефонию — расточительно. Вполне можно посчитать, что 84*(число одновременных разговор) вполне достаточно для большинства случаев.

            0
            В своём методе я уверен на 100%, а в вашем нет.
            Если вы уверены и можете подтвердить это на практике, как я, тогда напишите статью. Такую, которая будет понятна даже самым начинающим.
            На своем пути неоднократно наблюдал и наблюдаю такую картину, что только 1 из 100 специалистов знают, что на качество голоса может влиять забивка канала. А как это диагностировать и поправить, кроме как расширить тариф, совсем редкость.
            А как об этом люди узнают, если не рассказать и не показать. Пусть наш вклад «капля в море», но всё же.
              0

              Прошу, читайте:
              https://m.habr.com/en/post/331544/
              И вообще, по теме QoS на habr.com много статей, моя тут не одна лежит годами, в то время как молодые авторы пишут что-то свое, не проверив, а стоит ли. Есть куча статей, которые нуждаются в работе сообщества, но молодые редко используют поиск или не умеют его использовать.

                0
                по теме QoS на habr.com много статей

                но не слова о методах анализа голосового трафика и его фикса
                  0
                  Вот об этом и надо писать.
                0
                В своём методе я уверен на 100%, а в вашем нет.

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


          +1
          Коль беретесь рекомендовать Mikrotik для VoIP, потрудитесь объяснить в статье, как отключить MNDP на прошивках 6.48.x, иначе могут появиться проблемы с качеством у владельцев аппаратов Gigaset. На всякий случай: IP — Neighbors — Discovery Settings — убрать галочку MNDP, либо в консоли:
          /ip neighbor discovery-settings set protocol=cdp,lldp
            +1
            Коль беретесь рекомендовать Mikrotik для VoIP

            «Рекомендовать» это громко сказано. Я лишь показал какими инструментами пользуюсь для анализа voip трафика и настройки QoS.
            потрудитесь объяснить в статье, как отключить MNDP

            Подскажите, каким образом данный протокол оказывает влияние на качество голоса?
            Ранее никогда не сталкивался с подобными проявлениями.
              0
              В прошивке 6.48 и 6.48.1 какой-то баг с MNDP, в итоге есть проблемы как с регистрацией аппаратов, так и с качеством голоса-большая потеря пакетов. Данная тема обсуждалась и на официальном форуме: forum.mikrotik.com/viewtopic.php?t=171035
                –1

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


                  • за демонстрацию способов оценки качества связи

                  • из правильных данных сделано много неправильных выводов

                  • идея упрощённой настройки QoS для простых случаев, где не требуется развёрнутая приоритезация.

                  • реализация идеи плохая, что делать будете делать если VOIP провайдер разрешит прямой RTP трафик со своими партнёрами?

                  • плохая проработка первоисточников, применены топорные методы маркировки целевого трафика в связи с непониманием всех механизмов.

                0

                Вся фирма в гигасетах. И шлюз микрот 2011, никаких проблем нет.

                  0
                  Это не значит, что бага нет
                0
                Думается, высказывание «У меня на загрузку скорость 11Мб/с, на отдачу 14Мб/с. Хотя по договору должно быть 15М в обе стороны» не совсем корректно. По договору на Ваш канал выставлено ограничение в 15М — это все что пройдет сквозь канал. При измерении скорости «измеритель» покажет скорость с которой в канале идут ДАННЫЕ, служебный трафик и заголовки пакетов учтены не будут (если «измеритель» не накинет процент на ДАННЫЕ что бы все выглядело красиво). Поэтому, при измерении скорости канала полученное значение не может быть равно скорости по договору. ИМХО.

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

                Самое читаемое