Freeswitch inserting silence in RTP stream when receiving RTCP

[lineguy]

Version: 1.10.3

Problem:

I am running into a problem where Freeswitch is regulary inserting a RTP packet with silence into the 1 side of the the RTP stream on inbound calls. This results in worse call quality.

Scenrio:

Please see the below setup.

<SIP Provider> <----> <FreeSWITCH 1> <--nat--> <FreeSWITCH 2>

A call comes into FreeSWITCH 1 from the SIP Provider, then FreeSWITCH 1 being used as a B2BUA passes the call on to FreeSWITCH 2. Shortly after the call is answered FreeSWITCH 1 begins marking 2 RTP packets every second, inbetween these marked packets there is a another RTP packet which has a payload of just 5's (Silence). After doing some packet traces I can see that FreeSWITCH 2 is sending all RTP packets to FreeSWITCH 1 to rule out any potential networking problem.

There is a NAT between Freeswithc 1 and FreeSWITCH 2 but I think this can be ruled out as part of the problem because all the packets are arriving to FreeSWITCH 1 correctly.

Additional Findings:

After looking at the packets being sent to FreeSWITCH 1 from FreeSWITCH 2, I saw that there is a pattern in the inserted silence and the rtcp packets being sent to FreeSWITCH 1.

I then adjusted the below parameters on FreeSWITCH 2 to 5000ms (5 seconds) which then made the silence occur every 5s instead every 1s.

<param name="rtcp-audio-interval-msec" value="5000"/>
<param name="rtcp-video-interval-msec" value="5000"/>

Before First Mark Packet:

RTP	216	PT=ITU-T G.711 PCMA, SSRC=0x53131740, Seq=30299, Time=1100293600	1290f81feeea1dfd9c17739d6b1792761d96f619e9eb1ef1…

First Mark Packet:

RTP 216 PT=ITU-T G.711 PCMA, SSRC=0x53131740, Seq=30300, Time=246560, Mark  555555555555555555555555555555555555555555555555…

Silent Packet:

RTP	216	PT=ITU-T G.711 PCMA, SSRC=0x53131740, Seq=30301, Time=246720	555555555555555555555555555555555555555555555555…

Second Mark Packet:

RTP	216	PT=ITU-T G.711 PCMA, SSRC=0x53131740, Seq=30302, Time=1100293760, Mark	1d90f01febe81ff49211749e6f6e9f7c1290f51ceae91fca…

[dragos-oancea]

Is there some NAT / ICE / firewall piercing involved in your setup ? What does "empty RTP" mean to you ? no payload maybe? Is there a ssrc ?

[lineguy]

@dragos-oancea I realised my initial post was pretty poor so I have updated it.

[lineguy]

After some further investigation, I discovered that rtcp-audio-interval-msec was set on FreeSWITCH 1 in my scenario. Removing this seems to have resolved the problem for me (as we are not using RTCP).

However this may still be a bug for users who that are using this feature.

[LarryHemenway]

I could be running into something similar to this. I have the following via a conference bridge:

chrome -(g722)-> FreeSWITCH conference bridge -(linear PCM)-> target c++ app

We can't figure out why FreeSWITCH is inserting 20ms of silence, but after reading this, we do note that there appears to be RTCP 50-70 ms before every silent packet sent by FreeSWITCH. For example:

Packet 1797 is the RTCP, packet 1805 is silence.

We see this same pattern for all 20 silent packets we have in our trace. The RTCP from Chrome isn't on a predictable cadence as far as I can discern and neither are the silent packets.

Any thoughts on how to debug/look into this issue? I'm trying to trace through read_rtp_packets() in switch_rtp.c, but am a bit lost and am unsure if this is where I should start.

Also, when I convert the input audio into a wav file and the output audio into a wav file, I see that 20ms of audio is inserted, but not audio appears to be lost.

[sopeters]

In our case CNG packets (AKA "silence") are inserted in video stream corrupting the stream (there no "silence" exists for video codecs). Our receiver (Tandberg device) then detects corrupted stream (not that it just missed a packet but the packet actually arrived, decrypted and contains bogus information) and expects FS to restart streaming but it does not happen (may happen sporadically after some time). Thus receiver continues to send back last good frame received which we perceive as a "freeze" (in reality stream from Tandberg continues but it is the same frame again and again).

Offending function rtp_common_read() is in https://github.com/signalwire/freeswitch/blob/master/src/switch_rtp.c#L7198 . This function is extremely complex (over 700 lines), riddled with goto statements (15 of them), plus another goto statement (another 9 times) masquerading as a function return_cng_frame() when in reality it is a macro at https://github.com/signalwire/freeswitch/blob/master/src/switch_rtp.c#L5809
#define return_cng_frame() do_cng = 1; goto timer_check
which jumps to https://github.com/signalwire/freeswitch/blob/master/src/switch_rtp.c#L7866 and then CNG is inserted at https://github.com/signalwire/freeswitch/blob/master/src/switch_rtp.c#L7870 irrespective of stream type (video or audio).

In addition FS when sending corrupted RTP packet does stand-off for 100ms (and it may happen number of times making RTP delay in hundreds millisecond).

Insertion of CNG may be triggered by arrival of RTCP packet or by such mundane thing as late delivery of UDP packet with RTP data. Notably when jitter buffer is in use (when RTP terminates on FS) it masquerades the issue making it not noticeable (effectively only people who trying to use FS as a video bridge, not as MCU, are affected). However when FS runs as a bridge it disables its jitter buffer causing RTP delays to trigger insertion of CNG packets we have observed.

Any further insights and help here would be appreciated as it currently blocks us using FreeSWITCH for our use case (video & audio bridge).