Hi,
I have 2 kamailio instances behind a load balancer. The problem I have is that the load balancer can only track TCP connections, but not UDP. So one Kamailio instance might send a request using UDP, while the corresponding UDP reply arrives on the other. This doesn't play well with the (stateful) TM module. Is there a way to synchronize the TM module accross Kamailio instances using DMQ?
Cheers,
Michel Pelletier
There is not.
You could look to an Anycast example of handling this type of situation: https://github.com/kamailio/kamailio/blob/master/misc/examples/mixed/kamaili...
Regards,
Fred Posner p: +1 (352) 664-3733
But I should add: do you actually need state? All replies can be routed back based on the content of SIP headers alone -- that is to say, statelessly. Most simple load balancers remain stateless for this very reason.
I don't think the anycast example is going to get you out of this problem entirely.
Hi,
I agree. But the example puts me on the right track. It tells me that what I need to do is bounce the reply off to the other nodes(s) if TM doesn't recognize it. Having a DMQ option for the TM module would be great though.
Cheers,
Michel Pelletier
On Tue, Oct 10, 2023 at 4:22 PM Alex Balashov via sr-users < sr-users@lists.kamailio.org> wrote:
Yes, but this is not helpful if trying to mitigate an outage of the node that actually holds the transaction state.
Unfortunately, from a technical point of view, replicating TM state is not as straightforward as it sounds, or it would have been done already. It's not just a matter of serialising the transaction information and shipping it across and reconstituting it, timers and all. There are hooks deep into other runtime state, connection state, etc. which either aren't exposed for easy deserialisation/hydration, or are not possible to replicate altogether because it would require integration with the OS network stack (e.g. connection info).
All to say, even if such a thing were developed, it would be an extremely flawed and imperfect process, and--perhaps I can take a bit of liberty on behalf of the core development team--the project doesn't like to support half-assed features.
A more stateless, fault-tolerant design is, by comparison, a significantly lower engineering lift in most cases where replicating TM would be useful.
-- Alex
It would seem the best solution is to use something that can use the SIP protocol for making routing decisions - for example, Kamailio acting as a stateless load balancer, either as a replacement for your load balancer or between your layer4 load balancer (just doing pure round-robin of received packets) and your stateful SIP endpoint. A simple deterministic algorithm (like modulo over a hash of the called) will ensure that a CANCEL will reach the same stateful SIP endpoint as the INVITE.
-----Original Message----- From: Alex Balashov via sr-users sr-users@lists.kamailio.org Sent: Tuesday, October 10, 2023 12:31 PM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Alex Balashov abalashov@evaristesys.com Subject: [SR-Users] Re: Using DMQ to sync the TM module.
CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
But I should add: do you actually need state? All replies can be routed back based on the content of SIP headers alone -- that is to say, statelessly. Most simple load balancers remain stateless for this very reason.
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com/ Tel: +1-706-510-6800
__________________________________________________________ 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:
-
Alex Balashov -
Ben Kaufman -
Fred Posner -
Michel Pelletier