Home / server / Questions / 641093
Accepted
Patrick
Asked: 2014-11-01 01:46:04 +0800 CST

Clients phone provider claiming high latency over UDP, how do I test?

  • 772

A client of our uses a hosted phone solution for his 50 agent call centre. They use a hosted dialer who make the out going calls, once the connection is made the call is passed to my clients user where they pickup the connection on a 3CX phone interface.

Pretty standard stuff.

The hosting company are claiming that they are seeing 100-200ms latency for all the phones.

On testing a TCP round trip [tcping.exe] I'm getting sub 10ms times. They block ICMP. The hosting provider are saying that this isn't a valid test as the VOIP data is UDP.

I understand that UDP could be being shaped differently or routed differently but it seems pretty unlikely. The hosting IT team are very much 'we have hundreds of customers and their latency is ok, this is your problem' which I can understand but it doesn't help me much. Given that I can't control a UDP listener on their side I don't know how to demonstrate how and where the UDP lag might be coming in.

Equipment on site is a pair of Cisco 2960's connecting to a Draytek Vigor. The Draytek connects to the ISP provided/managed Cisco p887.

Bandwidth use sits at roughly 20% throughout the calling period. All the ICMP tests to external systems show good round trips, generally not beyond 5ms-30ms depending where I'm going to.

Thoughts on how to move this forward?

tcp

2 Answers

  1. Best Answer

    Although the issue mentioned here stopped happening for no obvious reason the answer to my original question - how to effectively demonstrate network quality and roundtrip for SIP UDP traffic - is to use a SIP OPTIONS as a ping.

    Brief discussion here: http://www.packetizer.com/in/q122.html

    Powershell test/demonstration here : http://www.lyncexch.co.uk/sip-pinger-tool/

    and I implemented this via our existing PRTG monitoring (here : http://www.paessler.com/manuals/prtg/sip_options_ping_sensor)

    Unfortunatly the remote host wasn't properly configured so we received a 404 and not a 200, however we could still use that to demonstrate round trip time, although PRTG always shows this as error.

    • 1

  2. If you have a linux host on each end of the network, you can install iPerf or Thrulay to run a network test. Thrulay has the advantage in your scenerio of showing jitter during the test.

    You can also watch some network stats on each end during your test or real traffic using this bash snippet:

    function watch_net()
{
/usr/bin/watch -d -n10 --no-title 'netstat -s | grep "\ \ \ [0-9]" | sort -rn'
}
watch_net
    • 0