[Freeswitch-users] 20ms silent RTP inserted into conference call output (about 1 out of every 100 packets)

[Larry Hemenway]

We're setting up a conference bridge as follows:

(canned wav file) --> chrome --(g722)--> FreeSWITCH conference
--(linear PCM)--> c++ app

What we are seeing is that FreeSWITCH is inserting 20 ms of silence
into the linear PCM output. It does not drop any audio - it is just
inserting extra silence. On some traces we see ~1 out of every 100
output audio packet as silence. There is no regular cadence for the
insertion.

We are able to verify this in two ways:
1. When we look at the linear PCM tcpdump trace, we can identify
silence because it's all 0xff.
2. We convert both the g722 and linear PCM into wav files. This is how
we observe that no audio is dropped, just 20ms of silence added. The
linear PCM wav file adds 20ms of audio and falls behind the g722
audio.

We look at the pacing from the tcpdump and chrome is pacing every
20ms. FreeSWITCH, likewise, is also producing at 20ms intervals. We
did try turning on the jitter buffer in FreeSWITCH and now see
mitigated packets instead of silence, so that did not fix the issue.
We'll probably turn off PLC next as mitigated packets are not easily
identifiable.

After reading https://github.com/signalwire/freeswitch/issues/735 I
went back and looked at an old trace and it does appear that we see
silence in the output linear PCM ~50-70ms after getting an RTCP packet
from chrome. It's not 1:1; in the trace I looked at we had 44 rtcp
packets, but only 20 silent packets, but for every silent packet we
see an RTCP packet 50-70ms earlier. I hope to get more traces to
verify this after turning PLC off.

Environment:
FreeSWITCH version 1.10.3, running inside a container on bare metal.
This is reproducible running a single conference with two participants
- no loading.
We are turning off encryption in Chrome so we can decode the g722 (no
dtls/srtp) and feeding chrome a canned wav file, so we can compare
audio.

Has anyone else seen this issue? Any suggestions on how to start
debugging? I'm trying to trace through read_rtp_packets() in
switch_rtp.c, but am a bit lost and not sure if that is where I should
start.

This issue is severely degrading our audio quality measurements so its
causing a lot of headaches for us at the moment.