When there are ~40 simoulatensly calls on my Asterisk server, I’m using ChanSpy to spy on an active channel and the audio (RTP) is choppy; the original call has no choppy audio at all.
I installed a sniffer and saw that the high delta comes from the server.
The server is hosted with DigitalOcean, 48 dedicated CPUs, no load on the server.
I disabled all codecs on the server, allowed only alaw to make sure no transcoding is done.
I also tested the timing with asterisk -rx 'timing test’ and I’m getting 50 ticks in 1 second as supposed.
Even tried to set highprioriry=yes in asterisk.conf (and restart the asterisk ofc) but it’s still the same..
From what you’re describing, it doesn’t seem to be a server load or network issue, since the original call sounds fine and only ChanSpy is choppy. This behavior matches a known bug in older Asterisk versions, including 18, related to audiohook — which is what ChanSpy uses under the hood. I ran into the same issue, and i actually remember reporting a bug like this myself a while back, and it was great to see that it’s finally been fixed in the newer releases.
The best move is to upgrade to Asterisk 20 or even 22. Both versions have specific fixes in the audio handling that prevent this choppiness when spying on a call.
Since you’ve already tested codecs, timing, and process priority, this is probably the main culprit. If you can’t upgrade right away, at least make sure you’re on the latest 18 release, but ideally moving to 20 or 22 LTS is the cleanest solution.