Voice delay, wrong buffering

[Nixxis-Oli]

The issue is related to a 3PCC setup with voice on one leg being delayed by a few seconds. The issue appeared after using asterisk 20.5 instead of asterisk 1.8 (of course there were a few dialplan changes to ensure asterisk 20 support). The asterisk and controller are hosted by AWS.

x.x.11.124 the controller application (handling SIP only, not RTP flows)

x.x.1.235 asterisk 20.5

x.x.53.142 softphone (registered on asterisk)

x.x.233.1 and x.x.233.4 an external provider (for SIP and RTP respectively)

Here is the global flow:

There is no issue with the signalling (Whatever the asterisk version, the signalling remains the same). The green call is the controller calling the asterisk to reach the softphone. The orange call is the resulting call of the asterisk to the softphone.

When the softphone has been picked up, the controller calls the asterisk to reach an external phone number: this is the pink call. The yellow call is the asterisk trying to reach the external provider.

During the establishment of the call, the green leg is retransmitting the “200 OK”; this is expected as we need the SDP of the external call to include it in the ACK of the green leg…

The issue is related to RTP flows highlighted in green and dark grey. The green flow is received from the external provider without presenting any anomaly. The grey flow is the one generated by the asterisk and should be a “copy” of the green flow, but it presents incorrect RTP packets at start and a continuous delay during all call duration.

Here is a view of the audio related to the two same flows:

The red box marks the transition from the ring back to the established voice (happens when the “200 OK” is received from the provider).

Here is a capture of the beginning of the green flow during the initial ring back:

Please note that initial timestamp is 320.

The green RTP shows a timestamp jump (from 17600 to 6731720) with mark=true when transitioning from ring back to voice. Here is a section of the related part:

Here are beginning the issues…

When voice is connected, we see that the grey flow is starting (with timestamp 10080). A bit later, we see a gap in sequence for that flow, jumping from 29381 to 29400. We also see at that time the timestamp jumping to 6732040, to synchronize with incoming green flow. It seems not too bad, except if we look a bit later. There we see that the asterisk mixes the RTP with copies of initial packets (coming from ringback time: look at packet 420, the time stamp is 320 (the one of the first packet received!).

At some time, packets mixing stops, leaving only the packets with smaller time stamps, causing the perceived 2 seconds’ delay.

I suspect some kind of buffering being incorrectly done by asterisk under certain conditions but I don’t know what can be done about it. Any idea would be appreciated.

[gjoseph]

There’s so much going on in your scenario and so much we can’t see. I’d suggest simplifying the scenario and dialplan as much possible to see if you can create a reproduceable scenario we can look at.

[Nixxis-Oli]

Thanks for the answer!

I will try to simplify the scenario but it is not so easy. I was expecting that looking at the mixing of RTP flows would trigger some hints on possible cause (or possible changes in PJSIP config) …

[david551]

The message sequence chart is almost unreadable.

You have an edge case of an edge case. Delayed offer isn’t much used outside the Cisco world, and delaying the ACK in such a case goes against how callees normally expect to handle a call, as they would normally start speaking as soon as they went off hook, and the caller normally waits for that, but your delay means that either their greeting could be lost, or there would have to be much more jitter buffering than phones normally provide.

Incidentally, I don’t see how there could be valid inband ringback tone in this scenario, as Asterisk doesn’t know where to send it until it is too late to be useful.

[Nixxis-Oli]

Thanks for your reaction. I understand what you say. In this scenario, something else than ringback is normally broadcasted for the user (to avoid leaving it without any feedback). I have slightly modified the scenario to simplify that part (and even, I understand it is not simple enough).

Even, if it is an edge case, I would expect that the RTP would be transmitted when the ACK is given and RTP packets received before that ACK would be ignored (they are in the past)…

Sorry for the bad image quality. I uploaded a new one here (readable on my machine), hoping the quality will be better.