[SR-Users] Re: Redundancy

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