[SR-Users] RTPengine + kernel module long call RTP drops

[Anthony Joseph Messina]

On Tuesday, April 4, 2017 5:44:47 PM CDT Anthony Joseph Messina wrote:
> Recently, I've had to be on a lot of long conference calls and have noticed
> that after about 18-22 minutes, the audio on the call drops out.  There are
> no errors logged from Asterisk, Kamailio, or RTPengine.  The signalling
> portion of the call is unaffected and continues as normal.
> 
> My setup is as follows
> asterisk-14.3.0-7.gita047b25.fc25.x86_64 (14 branch)
> kamailio-5.0.0-5.git2608015.fc25.x86_64 (5.0 branch)
> kernel-4.10.8-200.fc25.x86_64 (stable Fedora kernel)
> rtpengine-5.1.1.1-9.git27af349.fc25.x86_64 (master branch)
> Yealink or Zoiper softphones
> 
> Calls are originated as follows using TLS & SRTP
> Yealink/Zoiper -> Kamailio/RTPengine+kernel -> Asterisk/DAHDI/PSTN
> 
> Related IPtables output below (generated by firewalld)
> ~]# iptables -S |grep INPUT
> -P INPUT ACCEPT
> -N INPUT_ZONES
> -N INPUT_ZONES_SOURCE
> -N INPUT_direct
> -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
> -A INPUT -i lo -j ACCEPT
> -A INPUT -j INPUT_direct
> -A INPUT -j INPUT_ZONES_SOURCE
> -A INPUT -j INPUT_ZONES
> -A INPUT -m conntrack --ctstate INVALID -j DROP
> -A INPUT -j REJECT --reject-with icmp-host-prohibited
> -A INPUT_direct -p udp -m udp --dport 30000:40000 -j RTPENGINE --id 0
> -A INPUT_ZONES_SOURCE -m set --match-set mss4 src -g IN_mss
> -A INPUT_ZONES -g IN_public
> -A IN_public -j IN_public_allow
> -A IN_public_allow -p udp -m udp --dport 30000:40000 -m conntrack \
>    --ctstate NEW -j ACCEPT
> 
> I saw https://github.com/sipwise/rtpengine/issues/102 and
> https://github.com/sipwise/rtpengine/issues/108, but do not seem to have any
> issues (that I know of) with the SRTP, though the latter ticket references
> "call that would last longer than 20 minutes".
> 
> Can you share suggestions for looking into the cause of the audio drops,
> especially as nothing appears in the logs?

After more digging, I see (from the Asterisk perspective) that after a certain 
amount of time, the "RTCP report" size gets smaller and this is the point at 
which the audio from Asterisk back to the softphone is dropped.  Again, this 
audio drop occurred around 19 minutes into the call.

I'm not sure this means anything, but perhaps it can point someone more 
knowledgeable in the right direction.

The following is debug output from Asterisk

[Apr  4 20:05:33] res_rtp_asterisk.c:4214 ast_rtcp_interpret: Got RTCP report 
of 88 bytes
[Apr  4 20:05:38] res_rtp_asterisk.c:4214 ast_rtcp_interpret: Got RTCP report 
of 72 bytes
[Apr  4 20:05:43] res_rtp_asterisk.c:4214 ast_rtcp_interpret: Got RTCP report 
of 72 bytes
[Apr  4 20:05:48] res_rtp_asterisk.c:4214 ast_rtcp_interpret: Got RTCP report 
of 92 bytes
[Apr  4 20:05:53] res_rtp_asterisk.c:4214 ast_rtcp_interpret: Got RTCP report 
of 72 bytes
[Apr  4 20:05:58] res_rtp_asterisk.c:4214 ast_rtcp_interpret: Got RTCP report 
of 72 bytes
[Apr  4 20:06:03] res_rtp_asterisk.c:4214 ast_rtcp_interpret: Got RTCP report 
of 88 bytes
[Apr  4 20:06:08] res_rtp_asterisk.c:4214 ast_rtcp_interpret: Got RTCP report 
of 72 bytes

###### This is where the audio stops ######

[Apr  4 20:06:13] res_rtp_asterisk.c:4214 ast_rtcp_interpret: Got RTCP report 
of 48 bytes
[Apr  4 20:06:18] res_rtp_asterisk.c:4214 ast_rtcp_interpret: Got RTCP report 
of 68 bytes
[Apr  4 20:06:23] res_rtp_asterisk.c:4214 ast_rtcp_interpret: Got RTCP report 
of 48 bytes
[Apr  4 20:06:28] res_rtp_asterisk.c:4214 ast_rtcp_interpret: Got RTCP report 
of 48 bytes
[Apr  4 20:06:33] res_rtp_asterisk.c:4214 ast_rtcp_interpret: Got RTCP report 
of 64 bytes
[Apr  4 20:06:38] res_rtp_asterisk.c:4214 ast_rtcp_interpret: Got RTCP report 
of 48 bytes
[Apr  4 20:06:43] res_rtp_asterisk.c:4214 ast_rtcp_interpret: Got RTCP report 
of 48 bytes
[Apr  4 20:06:48] res_rtp_asterisk.c:4214 ast_rtcp_interpret: Got RTCP report 
of 68 bytes
[Apr  4 20:06:53] res_rtp_asterisk.c:4214 ast_rtcp_interpret: Got RTCP report 
of 48 bytes

-- 
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
F9B6 560E 68EA 037D 8C3D  D1C9 FF31 3BDB D9D8 99B6
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20170404/854ea10e/attachment.sig>