Dale Worley wrote: > > All this is quite true. We had a long discussion about this > on sipx-dev some months ago -- the primary problem is getting > the failover time from a non-responding destination to be > small enough that the caller will wait for it. Currently, > the failover time is 1.5 seconds, which is short enough to > be usable. (The default time of 32 seconds is not usable, > since the user always hangs up before that.) At the time of > the discussion, nobody had found a practical use case where > an element would take more than 1.5 seconds to respond to a > request. If we are running into situations where a longer > response time is needed, documenting how long is necessary is > the first step toward making a practical fix.
Dale, We seem to have found a real case where 1.5 seconds is causing problems. We can reliably reproduce this problem when Counterpath SMC is running on a Windows PC and is left idle for a while. Then the first incoming call to the SMC has a delayed response of 2-3 seconds. It is possible that the issue is with the SMC process being swapped out onto disk and the delay might be caused by the process of swapping it in. This is a case of the SMC running on the same network as sipX. I imagine SMC deployed in a remote worker case would add extra network delays. I raised a ticket (XX-6065) to track this problem. I don't have the background for the failover discussion, but I wonder if rather then playing with protocol timers and changing them universally at the SIP stack level, perhaps there is a better solution for the failover problem implemented at the application level. Alternatively, at the SIP stack level, perhaps these timers can be set for each transaction based on the type of destination. If destination is IP address, or DNS lookup produces a single destination then failover is not needed and the timers are set to defaults, otherwise use short timers. Mark. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
