On Wednesday, April 5, 2017 2:54:08 PM CDT Anthony Joseph Messina wrote:
Signed by amessina@messinet.com,webmaster@messinet.com,admin@messinet.com. Show Details On Wednesday, April 5, 2017 2:24:12 PM CDT Richard Fuchs wrote:
On 05/04/17 02:53 PM, Anthony Joseph Messina wrote:
On Wednesday, April 5, 2017 8:55:36 AM CDT Richard Fuchs wrote:
On 04/04/2017 09:33 PM, Anthony Joseph Messina wrote:
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.
A good place to start is to inspect /proc/rtpengine/0/list and check the packet and byte counters for the respective local ports. This way you can check if incoming packets are actually arriving at rtpengine.
Thanks, Richard. I am amidst a call right now which shows it's kernelized. The output from cat /proc/rtpengine/0/list shows nothing changing throughout the call (after repeating the command).
That means your iptables rule isn't effective. Packets don't get delivered to the RTPENGINE iptables target. That doesn't explain audio stopping but that's the first thing you should fix.
Richard, thank you for pointing me in the right direction. firewalld's direct rule was in fact the problem in my case. As the direct rule
INPUT_direct -p udp -m udp -j RTPENGINE --id 0
was after
INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
it was not allowing the calls to actually kernelize, and at some point the audio would just drop (still not sure why this would happen).
For the rest of you using firewalld, having the following in /etc/firewalld/ direct.xml works for me.
<?xml version="1.0" encoding="utf-8"?> <direct> <!--unrelated direct rules here--> <passthrough ipv="ipv4">-I INPUT -p udp -m udp --dport 30000:40000 -j RTPENGINE --id 0</passthrough> <passthrough ipv="ipv6">-I INPUT -p udp -m udp --dport 30000:40000 -j RTPENGINE --id 0</passthrough> </direct>
I've now had several calls last nearly an hour (a first in a long time). I don't know how I didn't put this together with firewalld upstream reports:
https://github.com/t-woerner/firewalld/issues/44 https://github.com/t-woerner/firewalld/issues/191
Thanks again. -A
You are correct about that. firewalld inserts
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
as the first rule in the INPUT chain, so it never got to my
-A INPUT_direct -p udp -m udp -j RTPENGINE --id 0
The following works at least for the kernel module part... firewall-cmd --permanent --direct --passthrough ipv4 -I INPUT -p udp -m udp -j RTPENGINE --id 0
firewall-cmd --permanent --direct --passthrough ipv6 -I INPUT -p udp -m udp -j RTPENGINE --id 0