When on a call with another extension, audio is delayed by some 500 milliseconds.
pbx is on 1gb sym fiber, ping times are in the 20s, so better then google’s, dns runs locally so zoomingly fast
Can that be reduced somehow?
Did you mean 20ms? 20s would be disastrous for VoIP.
Normal one-way delay should be about 30 ms.
Please describe the complete path:
For each extension post IP phone make/model or softphone/app name/version/platform.
What codec is being used? Encryption?
How does each extension connect to the PBX (using Ethernet, Wi-Fi, mobile data, etc.)?
If not on the same LAN as the PBX, describe the networking path.
Thanks Stewart1, so let me try:
P370 => cat7 => 1gb office connection => the internet => hosted pbx linked over 1gb symetric fiber => internet => 1gb office connection => cat7 => D80 (on the same desk)
All running on TLS, Codecs:
I wonder if maybe one should alter the priority of codecs
With a remote PBX with 20 ms ping time, I’d expect one-way audio delay between two IP phones to be ~65 ms. If yours is higher but less than say 100 ms, I wouldn’t be concerned; anything less than ~150 ms is usually not objectionable.
To measure the acoustic delay objectively, I suggest using any ‘recorder’ app on your smartphone. Call from IP phone A to phone B. Put the smartphone mic near the earpiece of phone B and start recording. Bang on the mic of phone A with e.g. a pencil. Do this a few times, a couple of seconds apart. The smartphone will hear both the source bang and the result in phone B. Upload the recording to your PC and open it in Audacity (or your favorite audio editor). On the waveform display, you can accurately measure the time between the bangs.
To measure the networking + server delay, temporarily disable encryption and force the codec to ulaw or alaw (whichever is standard for your country). Using a switch with a port mirror/monitor function (or a dumb hub, PC with 2 NICS, etc.), capture traffic from both phones. In Wireshark, look for an RTP packet from phone A and then find the RTP packet to phone B with the same payload, and note the time difference. If this is greater than what you expect from networking delay, run tcpdump on the PBX and check the response time there.
Note that some IP phones set a conservative jitter buffer when initially connecting, and gradually reduce it if there is little actual jitter. You may wish to test e.g. one minute into the call and see if the delay is much less than at the start.
If you find that the acoustic delay is much greater than the networking + server delay, use the RTP analysis tools in Wireshark (or manual inspection) to see whether high jitter is causing the receiving phone to keep a long jitter buffer. Under good networking conditions, I’d expect the acoustic delay to be only ~45 ms greater (20 ms packetization delay at the sending phone, 20 ms jitter buffer at the receiving phone, plus ~5 ms processing time).
Excellent post Stewart! I now narrowed it down using a local freepbx installation (everything within 192.168.0, no TLS, ping times minimal)
I then used the renowned pencil bang method to test between two sangoma phones next to each other and again got some 500ms of audio delay, roughly like two eights notes at 120 bpm.
Something must be wrong with my phone config… Will try the jitter buffer theory now.
The D80 has to pass audio through a lot of layers, it has more inherent delay (I don’t have a specific measurement for you) than the other telephones that we’ve built.