5 Apr
2017
5 Apr
'17
9:54 p.m.
On Wednesday, April 5, 2017 2:24:12 PM CDT Richard Fuchs wrote:
On 05/04/17 02:53 PM, Anthony Joseph Messina wrote:
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
--
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6
On Wednesday, April 5, 2017 8:55:36 AM CDT
Richard Fuchs wrote:
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. On 04/04/2017 09:33 PM, Anthony Joseph Messina
wrote:
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). 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.