On Sat, 2009-07-04 at 12:59 -0400, Mark Gertsvolf wrote: > sipX seems to be configured with rfc3261 T1 timer set to 100msec instead > of the recommended default of 500msec. > Client INVITE transaction generates INVITE request, which is > retransmitted only 3 times - after 100msec, 200msec and 400msec. > Then sipXproxy kills the transaction branch only 1.5 seconds after the > original INVITE was sent. > When far end finally responds with Trying and Ringing and possibly with > 200OK, sipX drops all of these responses of the floor. > > The above means that any outgoing INVITE over UDP, which takes more then > 1.5 seconds to produce provisional response is doomed. > > Standard INVITE transaction with T1 of 500msec as prescribed by RFC3261 > section 17.1.1.2 lasts for 32 seconds and should cause 7 > retransmissions. > > This might be particularly problematic for remote worker deployments, > where network delays could be significant.
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 _______________________________________________ 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/
