Yes to all of that. :-) — Sent from mobile, apologies for brevity and errors.
> On Dec 16, 2022, at 10:25 AM, Jawaid Bazyar <baz...@gmail.com> wrote: > > Hi Alex, > > Thanks for your (as usual) thorough reply. > > So, if I understand correctly what you're saying, as an example: > > INVITE to 200 OK is one transaction > > BYE to OK is a different transaction. > > And there is nothing that would prevent successful operation if each of these > transactions were handled by different proxies. > > > In the CANCEL scenario you mention, if CANCELs are lost I presume eventually > the other party will figure out something isn't right and terminate its > branch from the other direction? > > Cheers, > > Jawaid > > > > On 12/14/22, 8:30 PM, "Alex Balashov" <abalas...@evaristesys.com> wrote: > > Hi, > > As a starter for your exploration, a few key points: > > (1) When we talk about stateful proxies, we (and the standards) mean that > they are transaction-stateful, not something like "dialog-stateful". > > A transaction consists of a SIP request and 0 or more provisional replies > (where applicable) and a final dispositive reply (2xx - 6xx), although ACK is > a little special. > > This is what a stateful proxy has memory of, and, aside from conferring a > slight performance benefit[1], it is needed to implement things like failover > timers. Can't have a timeout if you aren't tracking something. > > (2) Neither transaction state, nor dialog state, nor any other kind of > state, is required to route a SIP message, with the exception of a CANCEL > (see below). > > Thus, this formulation is actually quite incorrect: "then use stateful > responses to direct client back to same node for subsequent messages in a > dialog." > > You do not need state to route in-dialog requests to the correct place, as > these are routed via the Route/RR set in the SIP request body itself. You do > not need state to route replies to the correct place, whether to in-dialog > requests or any other kind of request, because this is done through the 'Via' > header stack. > > So, everything that is needed to route SIP requests and replies within > some sort of context that persists for some amount of time (SIP calls this a > dialog) can actually be found in the content of SIP messages themselves. > > You can easily show this by using a stateful-only (i.e. TM) configuration > and restarting Kamailio in the middle of a pending or established call. Try > it and watch the capture. You will see that every message you expect to have > delivered, whether request or reply, will make it exactly where you think it > should, even though Kamailio has lost all transaction state[2]. > > A firm grasp of this is very important to any redundancy ruminations. > > (3) The exception to this is a CANCEL, and that is because a CANCEL is a > so-called "hop-by-hop" request. > > Whereas most requests and replies pass through the proxy, the proxy is > actually an independent party to CANCEL requests. That is to say, when a > party CANCELs an INVITE, it actually asks the proxy to CANCEL it, and the > proxy asks any upstream branches to CANCEL separately. This is to make the > forking behaviour of proxies possible. > > The consequence of this is that when a proxy receives a CANCEL request, it > needs transaction state in order to know which upstream branches to match it > up to. If it is lost, it won't know what to do with the CANCEL. > > This is the primary obstacle to anycast setups, from my point of view. You > can count on any proxy to relay requests statelessly in a correct fashion, > but you can't count on any proxy to process a CANCEL correctly. So, if a > CANCEL goes to a different place than the INVITE to which it corresponds, > it'll be dropped on the floor. > > ... > > Otherwise, and notwithstanding transparent approaches like anycast, the > methods you're contemplating are all variations of a common idea: the > redundancy and failover is provided on the client side, in principle. Actual > choice of method here is usually dictated by what the concrete clients in > questio support. For example, not all clients support DNS-based failover, or > may not implement it in the way you want. If you're offering a service to > many different kinds of clients or devices, you'll have to take that into > account. > > -- Alex > > [1] At a memory cost, but this isn't really a factor in modern computing. > > [2] Where it exists. An established call (200 OK + e2e ACK, no BYE yet) > will actually not have any transaction state, since all transactions involved > in establishing it have been terminated and no further transactions, e.g. to > hang it up, have been created. > >> On Dec 14, 2022, at 6:56 PM, Jawaid Bazyar <baz...@gmail.com> wrote: >> >> Hi, >> I am exploring different redundancy / load-balancing models for a Kamailio >> cluster. When I say cluster, I mean, a number (N) of Kamailio nodes acting >> as stateful proxies. >> Each node is configured the same as the others, and all have access to the >> same lookup data to make routing decisions. >> I would appreciate any advice or experience any of you can share on these >> different models. >> Overall model: >> >> • Direct to proxies >> • Redirect servers first, which redirect to proxies >> Selecting the first node to talk to. Each model could use either type of >> selection. >> >> • DNS-based (SRV or NAPTR, client makes call to dns name) >> • Anycast with ECMP (equal-cost multi-path routing) >> • Cluster with a mobile IP and service-down detection (this would just >> provide 1:1 protection) >> Have clients make calls through the proxy using a DNS record containing an >> SRV record for each node (or, alternatively, done with NAPTR). Would rely on >> the client to switch nodes in the event of a node failure mid-call. (Is that >> even possible?) >> Anycast would only work with UDP signaling. Use Anycast to find the first >> proxy, then use stateful responses to direct client back to same node for >> subsequent messages in a dialog. >> So for anyone who has tried any of these methods, I would love to hear the >> pros and cons.. >> Thanks in advance! >> Jawaid >> __________________________________________________________ >> 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: > > > -- > Alex Balashov | Principal | Evariste Systems LLC > > Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) > Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ > > __________________________________________________________ > 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: > > > __________________________________________________________ > 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: __________________________________________________________ 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:
