Примерно в 5% звонков наших клиентов мы наблюдаем большие всплески джиттера и высокие значения дельты, которые оказали заметное слышимое влияние на качество звонков. (Заикание / Расставания / Роботизированное аудио). Мы знаем это из статистики качества звонков, которую мы получаем через наш сервер Homer, а также из протоколов PCAP, полученных как на стороне LAN, так и на стороне WAN. Видеть https://imgur.com/a/IoVe8Zr для более подробной статистики по rtp. Проблема носит исключительно спорадический характер, но в полученных нами отчетах говорится, что это происходит одновременно с несколькими вызовами.
Скриншоты:
Очень высокие числа джиттера (вероятно, не настоящие), которые где-то вводятся
PCAP от зеркального порта на клиентском коммутаторе (зеркальное отображение коммутатора на телефонную трубку Polycom VVX)
Статистика RTP от маршрутизатора VMWare
Еще один пример RTPStats от нашего маршрутизатора VMWare
Задний план:
АТС: Система 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
Наша первоначальная мысль заключалась в том, что это внедряется в локальной сети, но pingplotter / MTR и различные другие тесты вернулись в нашу инфраструктуру полностью в открытом виде. В итоге мы зеркалировали порт на входе нашего маршрутизатора в VMWare ... мы обнаружили, что джиттера не было, когда он входил в VMWare, но джиттер присутствовал на всех этапах за пределами нашей инфраструктуры VMWare. В настоящее время это заставляет нас думать, что виновником является либо VMWare, либо наша конфигурация Asterisk, но тот факт, что у нас есть более 50 других клиентов, размещенных в той же инфраструктуре, заставляет меня указывать пальцем на нашу систему asterisk. Может быть, какая-то проблема CPUWait, из-за которой пакеты не загружаются в сеть своевременно?
Кроме того, мы смогли в целом признать, что эти всплески дрожания происходят, когда набирается группа звонков с большим количеством агентов (всего около 25 агентов звонят одновременно). Наш менеджер колл-центра отказывается отступать от этой конфигурации. У нас есть и другие группы с похожими настройками, но не такие большие. Я также вижу некоторые из того, что, по моему мнению, является искаженными числами джиттера для некоторых вызовов (с джиттером в миллионы миллисекунд - примеры включены со снимком экрана выше). Я не уверен, где это вводится и имеет ли это отношение к нашей проблеме.
Что мы пробовали:
Полная реализация QoS на всем сетевом уровне
Установка Asterisk для работы с высоким приоритетом
Изменение джиттербуферов UDP и Asterisk (что, казалось, имело незначительные преимущества)
Установка VMWare Tools, а также настройка виртуальной машины на чувствительность "High Latency"
Изменены настройки питания системы на производительность (я думал, что это точно, так как это очень похоже на проблему, описанную здесь: Причины джиттера RTP на сервере однако не повезло.)
Заменен ряд переключателей в окружении
Отключен SIP ALG
Реализация кодека G729 (против нашего стандартного G711)
Мы также хотели бы сегментировать голос и данные в их сети как отдельные VLAN, но пока не получили для этого соответствующего согласия от поставщика сети ... на данный момент мы находимся в тупике.
Если бы вы были на моем месте, что бы вы сделали дальше? Есть ли какие-то дополнительные аспекты этой проблемы, которые мне следует рассмотреть? Или очевидный тест, который я пропустил?
Любая помощь высоко ценится!
Звуки для меня вы вложили в время. У меня есть опыт и лучшее, что я могу сказать, это
Я играл с гипервизорами на microsft / vmware / kvm, и многие из них до сих пор работают. В конце концов, использование твердого сплава, похоже, решит все эти проблемы.
обратите внимание, я бы также попробовал кодеки GSM ..
Я управляю маленькими и большими офисами. Виртуальные машины, на которых я запускаю телефонные системы, сейчас находятся в небольших офисах на 2-3 человека, и обычно все, что больше, особенно в отношении объема звонков, я просто перестал делать это на виртуальной машине с гипервизором! У меня был хороший опыт работы с Openvz, запускающим звездочку в качестве контейнера, он, кажется, немного лучше разделяет ресурсы.
Это сложный вариант, но после борьбы с хорошим оборудованием и, в конечном итоге, запуска на каком-то старом оборудовании в качестве тестов (более одной компании, которую мы использовали в мире виртуальных машин), запуск его на собственном реальном оборудовании, похоже, решает проблемы. Так что я был бы согласен со всеми, кто заявляет, что обращаться к вашей компании-гипервизору VMware, похоже ... но в конце концов твердый металл!