Asterisk DTMF Causing High Jitter on TCPDump/Wireshark Voip Call Analysis

Asterisk Asterisk SIP
1

Hi Asterisk Community,

I have an asterisk sitting like a B2B User Agent using PJSIP.

On one end asterisk is talking to a SIP trunk, on the other end to a IVR/Call Center Solution. Both ends using SIP via PJSIP. No registration, just sip options.

RTT to both endpoints, <5ms.

Consider an inbound call,

SIP Trunk -> Asterisk -> CallCenter

After the call is established if I send multiple DTMFs I start to see some call performance numbers going low on wireshark captures. If I go bursting DTMF like when I was 10-12 years old at the arcade, the wireshark voip call stats show massive packet drop (+30%) and mad jitter(8000sec).

If I dont dial any DTMF during the call, the values are all ok as expected, jitter <30ms, packet loss <1%. I have tried different DTMF modes: rfc4733, INFO both same result.

I tested with 1 call only, there is hardly any load on asterisk and network is all free. I see no reason for any packet drop. Also tried g711a and g711u and g729. All had the same result.

To me this makes no sense, the jitter is absolute bonkers, how can jitter go that high (8000 seconds) and massive packet drops and why?

Made me wonder, is wireshark even a reliable tool? I have yet to confirm when wireshark/tcpdump reports high jitter, if the user experience is actually affected or not.

1 silly theory, negotiated SDP packet size is 20ms however DTMF duration varies from 80ms to 200ms. Could this packet loss report on wireshark be a problem with wireshark calculation due to packet size and DTMF duration difference? If wireshark is expecting 20ms packet size as negotiated; after each DTMF there will be some RTP missing due to DTMF duration.

Is there anything I can check or I am missing something?

2

How does the actual call audio sound? If there’s no problems I would not worry about it.

Also as far as I’ve seen, with rfc4733 the DTMF signals are sent using a separate RTP stream.

You might also have issues where the receiving end ends up negotiating inband DTMF, which requires Asterisk to generate the tones and mix them into the audio stream. Listening to the RTP stream in Wireshark would easily reveal this.

Also when using Asterisk in a B2B configuration, avoiding transcoding should be a goal, setup Asterisk to allow only 1 codec, which should result in no audio processing at all.

I would also have a look at the load of the machine, both in terms of CPU load in percent, and the load avg. using some sort of realtime monitoring option like htop