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 <[email protected]> wrote: > > >> On Mar 29, 2023, at 12:42 PM, [email protected] 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 > -- 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 [email protected] Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
