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