Hello,
I am proxying all RTP through RTPEngine. Everything works fine until about 5 seconds into the call, when rtpengine enters kernelization, after which all RTP forwarding ceases. I've checked the required iptables entries, and all looks good.
Here is a description of my environment:
# cat os-release PRETTY_NAME="Debian GNU/Linux 11 (bullseye)" NAME="Debian GNU/Linux" VERSION_ID="11" VERSION="11 (bullseye)" VERSION_CODENAME=bullseye ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/"
# kamailio -v version: kamailio 5.6.2 (x86_64/linux) 54a9c1 flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 54a9c1 compiled on 16:02:49 Dec 1 2022 with gcc 10.2.1
# rtpengine -v Version: 11.1.1.3-1~bpo11+1
Michel Pelletier
On 12/12/2022 14.53, [EXT] Michel Pelletier wrote:
I am proxying all RTP through RTPEngine. Everything works fine until about 5 seconds into the call, when rtpengine enters kernelization, after which all RTP forwarding ceases. I've checked the required iptables entries, and all looks good.
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
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 wrote:
On 12/12/2022 14.53, [EXT] Michel Pelletier wrote:
I am proxying all RTP through RTPEngine. Everything works fine until about 5 seconds into the call, when rtpengine enters kernelization, after which all RTP forwarding ceases. I've checked the required iptables entries, and all looks good.
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 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
On 13/12/2022 09.04, [EXT] Michel Pelletier wrote:
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.
Does the destination address seen in /proc match what is expected?
Any unusual network setup involved? Policy routing, network namespaces, containers, anything like that?
Cheers
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@sipwise.com wrote:
On 13/12/2022 09.04, [EXT] Michel Pelletier wrote:
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.
Does the destination address seen in /proc match what is expected?
Any unusual network setup involved? Policy routing, network namespaces, containers, anything like that?
Cheers
Kamailio - Users Mailing List - Non Commercial Discussions 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
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@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 On Behalf Of Michel Pelletier Sent: Tuesday, 13 December 2022 10:04 PM To: Kamailio (SER) - Users Mailing List 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.commailto:rfuchs@sipwise.com> wrote: On 12/12/2022 14.53, [EXT] Michel Pelletier wrote:
I am proxying all RTP through RTPEngine. Everything works fine until about 5 seconds into the call, when rtpengine enters kernelization, after which all RTP forwarding ceases. I've checked the required iptables entries, and all looks good.
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.orgmailto: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
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.comhttps://gilawa.com/
From: Tim Bowyer timbo@timbo.au Sent: Freitag, 3. März 2023 04:13 To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org 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@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.orgmailto: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.orgmailto: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.commailto:rfuchs@sipwise.com> wrote: On 12/12/2022 14.53, [EXT] Michel Pelletier wrote:
I am proxying all RTP through RTPEngine. Everything works fine until about 5 seconds into the call, when rtpengine enters kernelization, after which all RTP forwarding ceases. I've checked the required iptables entries, and all looks good.
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.orgmailto: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
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 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
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 rfuchs@sipwise.com Sent: Friday, March 3, 2023 9:10 PM To: sr-users@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.xyzmailto: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
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
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 rfuchs@sipwise.com Sent: Friday, March 24, 2023 8:51 PM To: sr-users@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
Hello Everyone,
Looks to be related to the team interface after all, which is strange. Have confirmed that after getting rid of the LACP/Team interface, media is flowing as expected after kernelization. I simply:
* removed the LAG config on the switch * disabled the team0 interface * Moved the public IP over to eno1 * moved the carrier VLAN’s over to eno1
Restarted for good measure, and made some test calls. All worked perfectly with media traversing the public and carrier interfaces as expected.
rtpengine -v1
Version: git-HEAD-5bf2c50a CentOS Stream release 8 Linux 4.18.0-373.el8.x86_64
Is it worth opening an issue in the rtpengine repo?
Cheers,
Tim
From: Tim Bowyer timbo@timbo.au Sent: Wednesday, March 29, 2023 3:26 PM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: [SR-Users] Re: Rtpengine: no audio after kernelization.
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 <rfuchs@sipwise.commailto:rfuchs@sipwise.com> Sent: Friday, March 24, 2023 8:51 PM To: sr-users@lists.kamailio.orgmailto:sr-users@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:
Hello Everyone,
Looks to be related to the team interface after all, which is strange.
Have confirmed that after getting rid of the LACP/Team interface, media is flowing as expected after kernelization.
...
Is it worth opening an issue in the rtpengine repo?
That depends on whether 1) it's reproducible, and 2) it's something that is supposed to work.
Cheers
Hi,
I finally resolved my issue, although without ever finding the cause. I am using bare-metal servers from Vultr and I was having the issue with the Debian 11 image that they provide when provisioning the server. An external consultant and myself invested several hours trying to find what could be causing this issue and we were unsuccessful. We tried everything (or so we thought), including sysctl and various network settings, to no avail. As a last resort, I then proceeded to wipe the server and reinstall Debian 11 using the standard Debian network installer in replacement of the image provided by Vultr. The problem magically went away after doing so but I would really like to know the cause.
Cheers,
Michel Pelletier
On Thu, Mar 2, 2023 at 9:45 PM Tim Bowyer timbo@timbo.au wrote:
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@per01-mtp01.dev.xyz blah]# cat /proc/rtpengine/0/list
local inet4 203.x.x.x:40000
stats: 350880 bytes, 2040packets, 0 errors
RTP payload type 0: 0bytes, 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:39302SSRC 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 *On Behalf Of *Michel Pelletier *Sent:* Tuesday, 13 December 2022 10:04 PM *To:* Kamailio (SER) - Users Mailing List 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 wrote:
On 12/12/2022 14.53, [EXT] Michel Pelletier wrote:
I am proxying all RTP through RTPEngine. Everything works fine until about 5 seconds into the call, when rtpengine enters kernelization, after which all RTP forwarding ceases. I've checked the required iptables entries, and all looks good.
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 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
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-
Henning Westerholt -
Michel Pelletier -
Richard Fuchs -
Tim Bowyer