29 Mar
2023
29 Mar
'23
3:58 p.m.
In thinking about it further: the other problem is that SIP, despite its IETF heritage,
ended up in a place where network and transport-layer reachability information (in the OSI
burrito sense) is just part of protocol messages, depriving SIP of the cleaner logical
translation layer - and the resulting separation - between its logical addressing and
lower-level endpoint reachability information.
Unlike something like HTTP, SIP also has a bunch of persistent state. This makes it a lot
harder to put SIP behind generic/protocol-agnostic load balancers, deal with NAT, etc.
It’s not impossible, it’s just much harder.
Henning said it: the juice probably isn’t worth the squeeze.
I find it helpful to think of Kamailio as a piece of very low-level infrastructure more
akin to a router than something like an application gateway/server. The latter type of
network element makes sense to cluster, containerise, etc. Kamailio less so. That’s not to
say there aren’t use-cases for it — there certainly are — but this doesn’t necessarily
sound like one of them.
— Alex
On Mar 29, 2023, at 1:22 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
On Mar 29, 2023, at 12:42 PM, calvine(a)gmail.com
wrote:
It's been my understanding that Kamailio clustering would solve life behind a load
balancer? This is the part where I'm hesitant to follow guidance from ten year old
blog posts and YouTube videos and need to grok the current state of clustering. I'm
working with the presumption that call state can be stored externally, i.e. Redis, and any
node could handle any messages from any dialog. Similarly for rtpengine. "Is this the
real life? / Is this just fantasy?"
No, this contains vastly far more fantasy than reality.
Some parts are true, but not because of any clustering, but just by the very nature of
how proxies operate. For instance, Kamailio can indeed handle any in-dialog message, but
not because it stores call state somewhere; call state is just not necessary to route an
in-dialog request.
On the other hand, you can’t send a CANCEL message to any proxy, because that’s a
“hop-by-hop” request that requires transaction state (not to be confused with dialog
state/call state) to deal with, and that kind of state _cannot_ be replicated.
RTPEngine is reasonably clusterable, using Redis as an intermediary.
But no, on the whole, the idea that you can just replicate all necessary state and send
anything anywhere any time is rather fantastical. It works in bits and pieces. I wouldn’t
get overly attached to this model, it’s a bit romantic. :-)
— Alex
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800