Большие скачки джиттера при небольшом проценте вызовов VoIP
Примерно в 5% вызовов наших клиентов мы наблюдаем большие всплески джиттера и высокие значения дельты, которые оказали заметное слышимое влияние на качество связи. (Заикание / Разрывы / Роботизированное аудио). Мы знаем это из статистики качества звонков, которую мы получаем через наш сервер Homer, а также из протоколов PCAP, полученных как на стороне LAN, так и на стороне WAN. См. https://imgur.com/a/IoVe8Zr для получения более подробной статистики по rtp. Проблема носит невероятно спорадический характер, но полученные нами отчеты говорят нам, что это происходит при нескольких вызовах одновременно.
Снимки экрана:
Очень высокие числа джиттера (вероятно, не настоящие), которые где-то вводятся
PCAP от зеркального порта на клиентском коммутаторе (зеркальное отображение порта коммутатора на телефон Polycom VVX)
RTP Stats from VMWare Router
Другой пример RTPStats из нашего VMWare Router
Предпосылки:
PBX : система Asterisk 11 работает на CentOS 6.5 в VMWare (ESXi 6.5, виртуальное оборудование v13, управляемое через vCloud Director как выделенный хост), размещенный в нашем центре обработки данных. 8 ядер - 32 ГБ ОЗУ. Очень низкая нагрузка> в среднем 0,07, но у нас изрядное количество звонков (~ 2000 звонков в день). Это одна из многих подобных систем в этой инфраструктуре (многие из которых также работают с VoIP / Asterisk) ... остальные работают безупречно, некоторые с гораздо большим объемом.
Сеть : Трафик доставляется на Cisco ASA заказчика. через прямую сеть Ethernet 1G DIA (AT&T) на наш сайт. Все наши внутренние маршруты, по которым проходит трафик, проходят по каналам 1G, и трафик имеет надлежащий приоритет.
Конечные точки : Polycom VVX, а также некоторые программные телефоны Bria
Наша первоначальная мысль заключалась в том, что это было введено на LAN, но pingplotter / MTR и различные другие тесты вернулись к нашей инфраструктуре полностью в открытом виде. В конечном итоге мы сделали зеркальное отображение порта на входе нашего маршрутизатора в VMWare ... мы обнаружили, что джиттера не было, когда он входил в VMWare, но джиттер присутствовал на всех этапах за пределами нашей инфраструктуры VMWare. В настоящее время это заставляет нас думать, что виновником является либо VMWare, либо наша конфигурация Asterisk, но тот факт, что у нас есть более 50 других клиентов, размещенных в той же инфраструктуре, заставляет меня указывать пальцем на нашу систему asterisk. Может быть, какая-то проблема CPUWait, из-за которой пакеты не загружаются в сеть своевременно?
Кроме того, мы в целом смогли распознать, что эти всплески дрожания происходят, когда набирается группа звонков, которая имеет высокий количество агентов (сразу звонило около 25 агентов). Наш менеджер колл-центра отказывается отступать от этой конфигурации. У нас есть и другие группы с похожими настройками, но не такие большие. Я также вижу некоторые из того, что, по моему мнению, является искаженным числом джиттера для некоторых вызовов (с джиттером в миллионы миллисекунд - примеры включены со скриншотом выше). Я не уверен, где это вводится, и имеет ли это отношение к нашей проблеме.
Что мы пробовали:
Полная реализация QoS на всем сетевом уровне
Установка Asterisk для работы с высоким приоритетом
Изменение джиттербуферов UDP и Asterisk (что, казалось, имело некоторые незначительные преимущества)
Установка VMWare Tools, а также настройка виртуальной машины на чувствительность "High Latency"
Изменены параметры питания системы в зависимости от производительности (я подумал, что это было это точно, так как это очень похоже на проблему, описанную здесь: Причины дрожания RTP на сервере , но не повезло.)
Заменено несколько переключателей в среде
Отключено SIP ALG
Реализация кодека G729 (по сравнению с нашим стандартным G711)
- Vmotion'd на новый хост
Мы также хотели бы сегментировать голос и данные в их сети как отдельные VLAN, но не получили соответствующей покупки - от поставщика сети для этого еще ... на данный момент мы находимся в тупике.
Если вы были на моем месте, каковы были бы ваши следующие шаги? Есть ли какие-то дополнительные углы этой проблемы, которые мне следует рассмотреть? Или очевидный тест, который я пропустил?
Приветствуем любую помощь!
Похоже, вы потратили время. У меня есть опыт, и лучшее, что я могу сказать, это
я играл с гипервизорами на microsft/vmware/kvm и многие из них до сих пор работают. В конце концов, работа на твердом металле, кажется, устраняет все эти проблемы.
Примечание: я бы также попробовал gsm-кодеки..
У меня большие и маленькие офисы. Виртуальные машины, на которых я сейчас запускаю телефонные системы, находятся в небольших офисах на 2-3 человека и, как правило, на чем-то большем, особенно по количеству звонков. Я только что перестал делать это на виртуальной машине с гипервизором! У меня был хороший опыт работы с Openvz, использующим asterisk в качестве контейнера, он, кажется, немного лучше распределяет ресурсы.
Это сложный вариант, но после борьбы с хорошим оборудованием и, в конечном итоге, запуска на каком-то старом оборудовании в качестве тестов (более одной компании, которую мы перепрыгнули в мир виртуальных машин). Запуск его на собственном реальном оборудовании, похоже, решает проблемы. . Так что я бы согласился с любым, кто заявляет, что нужно связаться с вашей гипервизорной компанией VMware, это выглядит... но, в конце концов, хард-металл!