Один из наших клиентов использует телефонное решение для своего центра обработки вызовов 50 агентов. Они используют размещенный номеронабиратель, который совершает исходящие звонки, после установления соединения звонок передается моему клиентскому пользователю, где они выбирают соединение через телефонный интерфейс 3CX.
Довольно стандартный материал.
Хостинговые компании заявляют, что они видят задержку 100-200 мс для всех телефонов.
При тестировании TCP-обхода [tcping.exe] Я получаю менее 10 мс раз. Они блокируют ICMP. Хостинг-провайдер заявляет, что это недействительный тест, поскольку данные VOIP - это UDP.
Я понимаю, что UDP может иметь другую форму или маршрутизироваться по-другому, но это кажется маловероятным. ИТ-команда хостинга очень похожа на то, что «у нас сотни клиентов, и их задержка в порядке, это ваша проблема», что я могу понять, но это мне не очень помогает. Учитывая, что я не могу управлять прослушивателем UDP на их стороне, я не знаю, как продемонстрировать, как и где может возникнуть задержка UDP.
Оборудование на месте - это пара Cisco 2960, подключенных к Draytek Vigor. Draytek подключается к Cisco p887, предоставленным / управляемым провайдером.
Использование полосы пропускания составляет примерно 20% в течение всего периода разговора. Все тесты ICMP для внешних систем показывают хорошие результаты, обычно не превышающие 5-30 мс, в зависимости от того, куда я собираюсь.
Мысли о том, как двигаться дальше?
Хотя проблема, упомянутая здесь, перестала возникать по непонятной причине, ответ на мой первоначальный вопрос - как эффективно продемонстрировать качество сети и двусторонний трафик для SIP UDP-трафика - заключается в использовании SIP OPTIONS в качестве эхо-запроса.
Краткое обсуждение здесь: http://www.packetizer.com/in/q122.html
Тест / демонстрация Powershell здесь: http://www.lyncexch.co.uk/sip-pinger-tool/
и я реализовал это через наш существующий мониторинг PRTG (здесь: http://www.paessler.com/manuals/prtg/sip_options_ping_sensor)
К сожалению, удаленный хост не был настроен должным образом, поэтому мы получили 404, а не 200, однако мы все еще можем использовать это для демонстрации времени приема-передачи, хотя PRTG всегда показывает это как ошибку.
Если у вас есть хост Linux на каждом конце сети, вы можете установить iPerf или Thrulay для запуска теста сети. Thrulay имеет то преимущество в вашем сценарии, что во время теста отображается дрожание.
Вы также можете посмотреть статистику сети на каждом конце во время теста или реального трафика, используя этот фрагмент bash:
function watch_net()
{
/usr/bin/watch -d -n10 --no-title 'netstat -s | grep "\ \ \ [0-9]" | sort -rn'
}
watch_net