Hello, Thank you for your reply. I checked the versions and they look good. xt_RTPENGINE is 11.1.1.3 and the daemon is 11.1.1.3-1~bpo11+1. Looking at /proc/rtpengine/0/list I see the packet and byte counters incrementing normally with 0 errors. In wireshark, capturing on any, I see the stream coming in on the private network interface but nothing going out through the public network interface. Everything is good until 5 seconds into the call when the kernelization happens. Michel Pelletier On Mon, Dec 12, 2022 at 2:19 PM Richard Fuchs <rfuchs(a)sipwise.com> wrote:

Hi, The destination address and port match with what is expected. I don't have policy routing nor network namespaces. I do have containers, including for Kamailio, but all are using host networking. I am also using gre tunnels which might be causing the issue. I am still investigating that possibility. Cheers. Michel Pelletier On Tue, Dec 13, 2022 at 8:09 AM Richard Fuchs <rfuchs(a)sipwise.com> wrote:

Hello, normally the rtpengine should setup the proper firewall rules automatically when kernelizing the audio stream. There is no need for firewalld or similar tools. Does it work (e.g. on a test system) with a more simple network setup for you in kernel mode? Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com<https://gilawa.com/> From: Tim Bowyer &lt;timbo(a)timbo.au&gt; Sent: Freitag, 3. März 2023 04:13 To: Kamailio (SER) - Users Mailing List &lt;sr-users(a)lists.kamailio.org&gt; Subject: [SR-Users] Re: Rtpengine: no audio after kernelization. Hi Everyone, I’m having the same issue but believe it’s related to my network topology. I have multiple carrier-facing NIC’s and an internal NIC on each media proxy. Is this configuration supported? I have the named ‘public / providerA / providerB’ rtpengine interfaces setup and working correctly – media flows as expected when running rtpengine without the kernel module. When kernel module is in use I get a few seconds of 2-way audio initially before it drops out in one direction usually. [root(a)per01-mtp01.dev.xyz blah]# cat /proc/rtpengine/0/list local inet4 203.x.x.x:40000 stats: 350880 bytes, 2040 packets, 0 errors RTP payload type 0: 0 bytes, 0 packets RTP payload type 8: 350880 bytes, 2040 packets SSRC in: 65aa31af output #0 src inet4 10.y.y.y:40000 dst inet4 203.x.x.x:39302 SSRC out: I was also looking to find some config to make this working using firewalld rules, fishing through the Sipwise repos I stumbled across some firewalld rules as part of their automated builds but didn’t have any luck with them If somebody had some rules I could try would be much appreciated! Cheers, Tim From: sr-users <sr-users-bounces@lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>> On Behalf Of Michel Pelletier Sent: Tuesday, 13 December 2022 10:04 PM To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> Subject: Re: [SR-Users] Rtpengine: no audio after kernelization. Hello, Thank you for your reply. I checked the versions and they look good. xt_RTPENGINE is 11.1.1.3 and the daemon is 11.1.1.3-1~bpo11+1. Looking at /proc/rtpengine/0/list I see the packet and byte counters incrementing normally with 0 errors. In wireshark, capturing on any, I see the stream coming in on the private network interface but nothing going out through the public network interface. Everything is good until 5 seconds into the call when the kernelization happens. Michel Pelletier On Mon, Dec 12, 2022 at 2:19 PM Richard Fuchs <rfuchs@sipwise.com<mailto:rfuchs@sipwise.com>> wrote: On 12/12/2022 14.53, [EXT] Michel Pelletier wrote: Inspect /proc/rtpengine/0/list while a call is running, in particular paying attention to the packet and byte counters. Also double check that the version of the rtpengine daemon matches the version of the kernel module (and that the module has been reloaded if there have been any upgrades - `dmesg` or `kern.log` are good places to check that). Cheers __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Evening! I ditched firewalld and swapped to configuring iptables manually… I’ve also made some basic calls with media going in/out of the same interface and I’m still seeing the audio stop completely or become one-way once kernelized. On the two different interfaces, I get no-way audio once kernelized. Weird! Could this be related to the kernel module being unsigned (running CentOS 8 Stream)? kernel: xt_RTPENGINE: loading out-of-tree module taints kernel. kernel: xt_RTPENGINE: module verification failed: signature and/or required key missing - tainting kernel kernel: Registering xt_RTPENGINE module - version git-HEAD-5bf2c50a systemd-modules-load[781]: Inserted module 'xt_RTPENGINE' Have been pulling my hair out! [root@blahblah zgadmin]# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination rtpengine udp -- anywhere anywhere ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere //cut// Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain rtpengine (1 references) target prot opt source destination RTPENGINE udp -- anywhere anywhere RTPENGINE id:0 Cheers, Tim From: Richard Fuchs &lt;rfuchs(a)sipwise.com&gt; Sent: Friday, March 3, 2023 9:10 PM To: sr-users(a)lists.kamailio.org Subject: [SR-Users] Re: Rtpengine: no audio after kernelization. On 02/03/2023 22.13, [EXT] Tim Bowyer wrote: I’m having the same issue but believe it’s related to my network topology. I have multiple carrier-facing NIC’s and an internal NIC on each media proxy. Is this configuration supported? This should work fine as long as it's "just" normal IP routing and doesn't involve network namespaces or cgroups or things like that. (Source-based routing should work, but other policy routing options might not.) [root@per01-mtp01.dev.xyz<mailto:root@per01-mtp01.dev.xyz> blah]# cat /proc/rtpengine/0/list local inet4 203.x.x.x:40000 stats: 350880 bytes, 2040 packets, 0 errors RTP payload type 0: 0 bytes, 0 packets RTP payload type 8: 350880 bytes, 2040 packets SSRC in: 65aa31af output #0 src inet4 10.y.y.y:40000 dst inet4 203.x.x.x:39302 This looks like the kernel module is receiving packets just fine and is sending them out (or trying to). It should work as long as the kernel is able to route packets from the 10.x address to the 203.x address. I was also looking to find some config to make this working using firewalld rules, fishing through the Sipwise repos I stumbled across some firewalld rules as part of their automated builds but didn’t have any luck with them If somebody had some rules I could try would be much appreciated! There's two things here. One is the necessary "-j RTPENGINE" iptables rule, which is needed to pass the packets to the kernel module to process. The bundled systemd startup scripts are in charge of adding and removing that. However, if you have separate firewall scripts which may override or remove this rule in some way, then this needs to be taken into account, so you don't lose this rule. But from your /proc output it's obvious that this rule is in place. The other thing is that rtpengine is able to manage firewall rules for individual ports directly, opening and closing the firewall rules as individual ports are opened and closed. This is entirely optional, and needs to be enabled explicitly, and is in fact not recommended usage. Cheers

Appreciate the help Richard! Media is traversing the team0 link <> one of the two carrier vlan’s as per: team0: connected to Team connection 1 "team0" team, 50:9A:4C:XX:XX:XX, sw, mtu 1500 ip4 default inet4 203.x.x.x/27 route4 203.x.x.x/27 metric 350 route4 default via 203.x.x.x metric 350 carrierX180: connected to carrierX180 "carrierX180" vlan, 50:9A:4C:XX:XX:XX, sw, mtu 1500 inet4 10.x.x.x/28 route4 10.x.x.x/28 metric 401 route4 202.x.x.x/27 via 10.x.x.x metric 401 route4 10.x.x.x/30 via 10.x.x.x metric 401 inet6 fe80::xxx/64 route6 fe80::/64 metric 1024 carrierY178: connected to carrierY178 "carrierY178" vlan, 50:9A:4C:XX:XX:XX, sw, mtu 1500 inet4 10.x.x.x/28 route4 10.x.x.x/28 metric 400 //CUT// inet6 fe80::xxx/64 route6 fe80::/64 metric 1024 Cheers, Tim From: Richard Fuchs &lt;rfuchs(a)sipwise.com&gt; Sent: Friday, March 24, 2023 8:51 PM To: sr-users(a)lists.kamailio.org Subject: [SR-Users] Re: Rtpengine: no audio after kernelization. On 22/03/2023 08.19, [EXT] Tim Bowyer wrote: Evening! I ditched firewalld and swapped to configuring iptables manually… I’ve also made some basic calls with media going in/out of the same interface and I’m still seeing the audio stop completely or become one-way once kernelized. On the two different interfaces, I get no-way audio once kernelized. Weird! Could this be related to the kernel module being unsigned (running CentOS 8 Stream)? kernel: xt_RTPENGINE: loading out-of-tree module taints kernel. kernel: xt_RTPENGINE: module verification failed: signature and/or required key missing - tainting kernel kernel: Registering xt_RTPENGINE module - version git-HEAD-5bf2c50a systemd-modules-load[781]: Inserted module 'xt_RTPENGINE' No, that is expected and perfectly fine. Have been pulling my hair out! [root@blahblah zgadmin]# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination rtpengine udp -- anywhere anywhere ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere //cut// Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain rtpengine (1 references) target prot opt source destination RTPENGINE udp -- anywhere anywhere RTPENGINE id:0 That looks fine. How about the actual network setup? Any network namespaces, policy routing, or other unusual setup in place? Cheers

On 17/04/2023 02.55, [EXT] Tim Bowyer wrote: That depends on whether 1) it's reproducible, and 2) it's something that is supposed to work. Cheers