[SR-Users] Re: Rtpengine: no audio after kernelization.

[Tim Bowyer]

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 
Sent: Wednesday, March 29, 2023 3:26 PM
To: Kamailio (SER) - Users Mailing List 
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 mailto:rfu...@sipwise.com>>
Sent: Friday, March 24, 2023 8:51 PM
To: sr-users@lists.kamailio.org<mailto: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
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Rtpengine: no audio after kernelization.

[Tim Bowyer]

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 
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
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Rtpengine: no audio after kernelization.

[Tim Bowyer]

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 
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.)

[r...@per01-mtp01.dev.xyz<mailto:r...@per01-mtp01.dev.xyz> blah]# cat 
/proc/rtpengine/0/list
local inet4 203.x.x.x:4
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:4
   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
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Rtpengine: no audio after kernelization.

[Tim Bowyer]

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.

[r...@per01-mtp01.dev.xyz blah]# cat /proc/rtpengine/0/list
local inet4 203.x.x.x:4
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:4
   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  On Behalf Of Michel 
Pelletier
Sent: Tuesday, 13 December 2022 10:04 PM
To: Kamailio (SER) - Users Mailing List 
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 
mailto:rfu...@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-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

Re: [SR-Users] Monitoring Dispatcher

[Tim Bowyer]

Hi Daniel,

Wow that was fast!  Really appreciate your efforts.
I'm using a docker package at the moment so will need to jump through some 
hoops to get the master build packaged for docker.

I'll keep you posted how I go.

Cheers once again and have a great weekend.

Tim Bowyer

-Original Message-
From: Daniel-Constantin Mierla  
Sent: Thursday, 7 June 2018 7:10 PM
To: Kamailio (SER) - Users Mailing List ; Tim 
Bowyer 
Subject: Re: [SR-Users] Monitoring Dispatcher

Hello,


On 07.06.18 10:04, Daniel-Constantin Mierla wrote:
> Hello,
>
> [...]
>
> For the future, I can add an rpc command to dump those numbers 
> directly from dispatcher module when using with algorithm 10.

just implemented the feature in master branch -- the active dialogs load should 
be printed in the rpc output for each destination (RUNTIME => DLGLOAD field).

Can you test and report back if it gives what you expect? If you want to test 
with older versions and backport the patch locally, the commit adding it is:

  -
https://github.com/kamailio/kamailio/commit/513a176394247a3378ee218bf9df611da7296061

Cheers,
Daniel
>
> Cheers,
> Daniel
>
> On 07.06.18 09:04, Tim Bowyer wrote:
>> Thanks for the prompt reply Alex!
>>
>> Trying to get my head around the best way to use the module.
>> By the looks I need to statically create profiles which will be used as 
>> counting groups.  
>> Since each destination is dynamically created thus named with a fairly 
>> random ID, I can't see how this could work.
>>
>> Have tried using variables but I get a heap of errors.  The process will 
>> only start if I use static profile names.
>>
>> Is there another sneaky way to get around this?  When a new container is 
>> spun up, a new entry is added to the dispatcher table and the dispatcher 
>> reloaded.
>> Likewise to trigger a container to start draining calls we remove from 
>> dispatcher then reload before waiting for all calls to finish and stop the 
>> container.
>>
>> Cheers,
>>
>> Tim Bowyer
>>
>>
>> -Original Message-
>> From: sr-users  On Behalf Of 
>> Alex Balashov
>> Sent: Thursday, 7 June 2018 10:42 AM
>> To: Kamailio (SER) - Users Mailing List 
>> Subject: Re: [SR-Users] Monitoring Dispatcher
>>
>> It sounds like the dialog module might be your best bet. 
>>
>> On June 6, 2018 10:40:38 PM EDT, Tim Bowyer  wrote:
>>> Hi All,
>>>
>>> Currently trying to work out the best way to keep track of how many 
>>> calls are being sent to any given dispatcher destination.
>>> I remember being able to do this years ago with the load balancer 
>>> module in OpenSIPS: opensipsctl fifo lb_list.
>>>
>>> Dispatching algorithm '10' seems to be the best fit for my 
>>> requirements, as I'm essentially wanting to send calls to a large 
>>> quantity of FreeSwitch docker containers acting as fax receiving nodes.
>>> Equal weight, just filling them in some balanced fashion.
>>>
>>> Any hints or ideas would be much appreciated!
>>>
>>> Kind regards,
>>>
>>> Tim Bowyer
>> -- Alex
>>
>> --
>> Sent via mobile, please forgive typos and brevity. 
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

--
Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- 
www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Monitoring Dispatcher

[Tim Bowyer]

Thanks for the prompt reply Alex!

Trying to get my head around the best way to use the module.
By the looks I need to statically create profiles which will be used as 
counting groups.  
Since each destination is dynamically created thus named with a fairly random 
ID, I can't see how this could work.

Have tried using variables but I get a heap of errors.  The process will only 
start if I use static profile names.

Is there another sneaky way to get around this?  When a new container is spun 
up, a new entry is added to the dispatcher table and the dispatcher reloaded.
Likewise to trigger a container to start draining calls we remove from 
dispatcher then reload before waiting for all calls to finish and stop the 
container.

Cheers,

Tim Bowyer


-Original Message-
From: sr-users  On Behalf Of Alex Balashov
Sent: Thursday, 7 June 2018 10:42 AM
To: Kamailio (SER) - Users Mailing List 
Subject: Re: [SR-Users] Monitoring Dispatcher

It sounds like the dialog module might be your best bet. 

On June 6, 2018 10:40:38 PM EDT, Tim Bowyer  wrote:
>Hi All,
>
>Currently trying to work out the best way to keep track of how many 
>calls are being sent to any given dispatcher destination.
>I remember being able to do this years ago with the load balancer 
>module in OpenSIPS: opensipsctl fifo lb_list.
>
>Dispatching algorithm '10' seems to be the best fit for my 
>requirements, as I'm essentially wanting to send calls to a large 
>quantity of FreeSwitch docker containers acting as fax receiving nodes.
>Equal weight, just filling them in some balanced fashion.
>
>Any hints or ideas would be much appreciated!
>
>Kind regards,
>
>Tim Bowyer


-- Alex

--
Sent via mobile, please forgive typos and brevity. 

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Help detecting t.38 and routing accordingly

[Tim Bowyer]

Hi Daniel,

Thanks for the prompt reply!
Correct - this may not even be possible? (I've read this strange task may be 
possible leveraging the b2bua module in OpenSIPS but I don't want to go down 
that path!!)

Cheers,

Tim


Subject: Re: [SR-Users] Help detecting t.38 and routing accordingly


Hello,
to be sure I understand correctly, do you want to re-route a call to another 
freeswitch when re-INVITE has t.38, even the initial INVITE was sent to a 
different freeswitch?

Cheers,
Daniel
On 22.06.17 08:08, Tim Bowyer wrote:
Hi All,

Trying to work out a way to detect and re-route inbound calls which negotiate 
or contain t.38 SDP to answer/process faxes efficiently.
Plan is to put Kamailio in front of a quantity of FreeSwitch servers - most 
virtual, others physical.
Virtual servers will handle inbound faxes which negotiate t.38, and physical 
servers will answer ulaw/alaw faxes with mod_spandsp.

The bulk of inbound faxes negotiate t.38, but in order to scale our inbound 
system we need some way to work out which way to send the calls prior to the 
dispatcher.

Many thanks for your help in advance,

Tim




___

Kamailio (SER) - Users Mailing List

sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>

https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



--

Daniel-Constantin Mierla

www.twitter.com/miconda<http://www.twitter.com/miconda> -- 
www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda>

Kamailio Advanced Training - www.asipto.com<http://www.asipto.com>

Kamailio World Conference - www.kamailioworld.com<http://www.kamailioworld.com>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Help detecting t.38 and routing accordingly

[Tim Bowyer]

Hi All,

Trying to work out a way to detect and re-route inbound calls which negotiate 
or contain t.38 SDP to answer/process faxes efficiently.
Plan is to put Kamailio in front of a quantity of FreeSwitch servers - most 
virtual, others physical.
Virtual servers will handle inbound faxes which negotiate t.38, and physical 
servers will answer ulaw/alaw faxes with mod_spandsp.

The bulk of inbound faxes negotiate t.38, but in order to scale our inbound 
system we need some way to work out which way to send the calls prior to the 
dispatcher.

Many thanks for your help in advance,

Tim
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users