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

[Anthony Joseph Messina]

On Wednesday, April 5, 2017 2:54:08 PM CDT Anthony Joseph Messina wrote:
> Signed by
> amessina at messinet.com,webmaster at messinet.com,admin at 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

-- 
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/20170405/33622746/attachment.sig>