Audio delay in downstream direction for terminating calls

I am currently experiencing a very strange behavior on terminating calls. When I call my PBX from another fixed or mobile number I am experiencing a 3s audio delay, but only on the incoming audio. However, when calling the exact same number from my PBX the audio is fine and there is no delay at all. I already switched codecs around and thought, that maybe there is some transcoding happening, but that does not seem to be the case. In both scenarios G.722 is supported network wide and is also established.

I also tested the connection to the provider by directly registering my phone with the provider. In this scenario audio works perfectly fine. So I would conclude, that the problem is introduced by the PBX and is not network related.

I performed traces and analyzed the RTP streams. The delays and Jitter are okay and do not differ above the expected normal variation for the “no delay” and the “delay” scenario.
I attached you some pictures of the RTP stream analysis. What I did for testing was speaking into the callee and caller phone at the same time to identify the propagation delay.
The is the PBX, is the IP Phone that terminates the call and the is the provider. As you can see there, the delay exists on the incoming stream and is not directly caused by the processing on the PBX.

PBX to provider, provider to PBX

Here you can clearly see the delay between the down- and upstream direction of the stream, considering the scenario, since I spoke into both phones at the same time.

I am actually kind of desperate right now. I have no idea what could possibly be going wrong that matches the behavior I can observe.

Downstream, provider to PBX, PBX to phone

Barely any noticable delay added by the PBX

Upstream, phone to PBX, PBX to provider

Barely any noticable delay added by the PBX

I’d start troubleshooting with the Jitter Buffer. Having said that, though, I can’t go on that journey with you. Three seconds isn’t enough for a DNS problem, and your machine is working fine since there are times when it works correctly.

I’d start looking through the logs and checking for jitter getting set. You may also want to check your trunk and extension configurations to make sure you haven’t added a Jitter Buffer (if you force one, it will always be there, and a 3000 ms JB has to be filled before it will move forward, delaying your traffic by about 3 seconds).

Having said that, though, I am admittedly out of my depth at this point. I’ve never used or played with Jitter Buffers: I only read about them and looked into them when I was working on a satellite based arctic phone network once about a million years ago.

Hi @cynjut thank you very much for your reply. I checked all Jitter buffer configuration and was not able to find anything alarming. Additionally, looking at my RTP traces again I do not think, that the call server actually adds the delay, since the forwarding of the Audio Data happens with packaging of G.711A into G.722 in basically no time, as shown in the “downstream” picture.

Since I was not able to figure out anything on my end yet and it seems to be related to only calls, that are terminating and are originated from a mobile phone, I might have to reach out to my provider in order to analyse this.

1 Like

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.