Mark, You are right that the failover is an application issue not SIP issue. That's why I said as your business need.
Changing retries: I meant to sent CANCEL after 2 secs to the original INVITE and send a new INVITE to other Proxy/B2BUA. Dan, You may try to fork the call to multiple proxies in the first place. After receiving 200 OK from any one of the Proxy, CANCEL all other request (provided you receive 100 Trying from those). -----Original Message----- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Mark R Lindsey Sent: Wednesday, July 08, 2009 9:26 AM To: Uttam Sarkar Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] SIP UDP timeout with multiple proxies There are three issues here: (a) Don't try to solve your application failover problems by monkeying with SIP. Your need to failover is specific to your application; it's not a SIP issues. If you want to failover within 2 seconds to your second, then do it at a higher layer. I.e., send your INVITE, and if your call isn't in progress fast enough to suit you, then CANCEL your call. Quoth Linus Torvalds: solve problems at the highest layer possible. (b) Tuning T1. I agree with Uttam Sarkar that T1 timeout selection is important. T1 should be "an estimate of round trip time" (RFC 3261 section 17.1.1.1). (c) Changing the number of retries seems fundamentally evil; suddenly you're not even trying to follow the SIP specification. Have you analyzed everything else in the RFC to confirm you're not going to break something else? And since you can always change T1, why change the number of retries, when the two numbers are multiplied? On Jul 8, 2009, at 8:51 AM, Uttam Sarkar wrote: > Dan, > You are right as per RFC 64*T1 should be the wait time before one can > cancel/fail a transaction. > RFC recommends 500 ms is the value for T1 timer. > You may choose your own value (less than 500 ms) in order to detect > failure and try the call through another proxy to meet your business > need. > We even changed our number of re-transmission (INVITE) from 7 to 2 for > 911 calls. If we don't get 100 Trying within 2 seconds then we try the > call through another proxy. We can't wait for 32 secs before we try > with > another proxy. > Hope this helps. > > -----Original Message----- > From: sip-implementors-boun...@lists.cs.columbia.edu > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of > Dan > Mongrain > Sent: Wednesday, July 08, 2009 8:32 AM > To: sip-implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] SIP UDP timeout with multiple proxies > > Hi all, > > RFC 3261 basically mentions that UAC can fail a transaction in the > case > of no response after 64*T1 (retransmitting every 2*T1). With the > default T1 being 500ms, 32 seconds is a long time to wait especially > when there are multiple proxies available to process a request. Is > there a RFC that specifies the behaviour of a UAC when there are > multiple proxies in order to accelerate failed proxy detection in > order > to rapidly fallback to another proxy? > > Thanx, > Dan > _______________________________________________ > 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 Mark R Lindsey lind...@e-c-group.com +12293160013 http://e-c-group.com/~lindsey _______________________________________________ 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
