We are having an issue of “choppy” audio on recordings made using MixMonitor (actually, a queue configured with monitor-type=MixMonitor, but that’s the same thing, right?). Audio during the call is perfect, however. It’s just the recordings that are getting messed up.
On the recording, the incoming audio (which comes from an ISDN gateway) is fine, but the audio from the operators (from a SIP softphone) is “choppy”. It’s as if periods of silence are periodically inserted into the recording of the operator side of the call. It’s hard to explain.
Removing those periods of silence actually yields a good (as in, complete, non-choppy) recording of the operator side.
Looking at RTP traffic with wireshark, the audio is all there. We did notice that the Max Delta and Skew values were a bit off, when compared with values from another working instance.
Here are some sample statistics (Softphone -> Asterisk) from the misbehaving instance:
Max delta = 182.20 ms at packet no. 40337
Max jitter = 39.59 ms. Mean jitter = 34.26 ms.
Max skew = 127.30 ms.
Total RTP packets = 505 (expected 505) Lost RTP packets = 0 (0.00%) Sequence errors = 0
Duration 9.96 s (-7779 ms clock drift, corresponding to 1753 Hz (-78.08%)
And here are the statistics from a well behaved instance:
Max delta = 29.71 ms at packet no. 34190
Max jitter = 1.41 ms. Mean jitter = 0.29 ms.
Max skew = 10.00 ms.
Total RTP packets = 3290 (expected 3290) Lost RTP packets = 0 (0.00%) Sequence errors = 0
Duration 65.78 s (-249 ms clock drift, corresponding to 7970 Hz (-0.38%)
These statistics were collected using Wireshark via the Telephony->RTP->Stream analysis menu.
Using the “player” option, with the default settings, we can see that the operator channel stream has periodic gaps and it sounds choppy like in the recording. However, if we check the “Use RTP Timestamp” option, the audio comes up perfect. Likewise, if we adjust the jitter buffer option to something like 200, the audio comes up perfect.
Everything is on a Gigabit LAN, so there’s no chance of lag or packet drops. Machine load is also minimal (we have at most 18 concurrent calls, but that is incredibly rare). Memory and disk space are also not an issue.
Does anyone have any idea what could be causing this problem?