5 Apr
2017
5 Apr
'17
4:33 a.m.
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