Isn't it this something that part of TGREP attempts to solve? Are you trying to specify something similar to the RAI feature in H323?
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, March 12, 2008 8:51 AM To: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Fallback between gateways? From: "Vikram Chhibber" <[EMAIL PROTECTED]> I am not very sure of the need for this as in my opinion SIP already has ways to achieve this. If the gateway sends say 503, the proxy can try another gateway. The gateway can itself redirect to the new gateway by sending 302 response. It is true that a sufficiently intelligent gateway could direct the proxy. But that requires that the gateways be quite intelligent, and also requires that the gateways know what the other gateways are. It also requires that the fallback process be the same for all calls, or that the gateways know what the different cases are. It is much safer to confine that knowledge to the proxy (or whatever the element is that does the distribution of calls). E.g.: At one of our customers, they have two gateways to two PSTN carriers. Normally one gateway is used for "local" calls and one is used for "long distance" calls, based on which carrier offers the lower rates for each type of call. But in either case, the customer wants to use the less-preferred gateway as the fallback for the more-preferred gateway, since either carrier can route calls to all destinations. Putting this logic in the gateways would require that each gateway be able to distinguish the two cases. The underlying problem is determining whether a failed fork failed because it reached the UAS and failed there (e.g., busy) or whether it failed because of a transport problem (e.g., gateway has no free channels). This mechanism should be SIP-standard, as the failure may be deep in a SIP carrier network, and the proxy that knows how to make alternative routing may be many steps upstream of the failure point. Unfortunately, the current set of response codes is not sufficiently well-defined and not used consistently enough to supply this information. (In the most annoying case, both "destination busy" and "gateway has no free channels" are often reported as 486.) The proxy can get multiple gateway addresses by some proprietary routing mechanism or say from the redirect server sending 300 response or DNS/ENUM procedures. Then, the proxy can try sequentially these gateways if the gateway in question does not respond in time. We aren't addressing the provisioning problem (yet). But remember that when using SIP transport, the failure may be several proxies "downstream" of the proxy that knows of the alternative route. The only concern is that if the gateway being tried is down, the proxy need not wait for 408 (T1*64 sec.) which I believe is too long. Here I see a need for introducing some standard timer say "inter-fork-terminal" timer. The key to avoiding this problem is to detect that the gateway is down at the IP level, so the SIP application code promptly receives a transport error and the RFC 3263 process continues with the next available destination. Dale _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
