Телефонный провайдер клиентов, требующий высокой задержки по UDP, как я могу проверить?
Наш клиент использует телефонное решение для своего 50 агентского колл-центра. Они используют хост-номеронабиратель, который выполняет исходящие вызовы, как только соединение установлено, вызов передается пользователю моего клиента, где они принимают соединение через телефонный интерфейс 3CX.
Довольно стандартные вещи.
Хостинговая компания утверждает, что они видят задержку 100-200 мс для всех телефонов.
При тестировании TCP в оба конца [tcping.exe] я получаю sub 10ms раз. Они блокируют ICMP. Хостинг-провайдер утверждает, что это недопустимый тест, поскольку данные VOIP - UDP.
Я понимаю, что UDP может формироваться по-другому или маршрутизироваться по-разному, но это кажется маловероятным. ИТ-команда хостинга очень старается: "у нас есть сотни клиентов, и у них нормальная задержка, это ваша проблема", которую я могу понять, но она мне мало помогает. Учитывая, что я не могу контролировать слушателя UDP с их стороны, я не знаю, как продемонстрировать, как и где может возникнуть задержка UDP.
Оборудование на месте - это пара Cisco 2960, подключенных к Draytek Vigor. Draytek подключается к предоставленному / управляемому провайдеру Cisco p887.
Использование полосы пропускания составляет примерно 20% в течение всего периода вызова. Все тесты ICMP для внешних систем показывают хорошие циклы, обычно не более 5 мс-30 мс, в зависимости от того, куда я иду.
Мысли о том, как двигаться вперед?
2 ответа
Хотя упомянутая здесь проблема перестала возникать без видимой причины, ответ на мой первоначальный вопрос - как эффективно продемонстрировать качество сети и двустороннюю передачу трафика 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