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.
We certainly could make the timer and/or retry count values configurable, but it would be a bit of a pain, since many components would have to be modified to read the values in and down to the stack. To be clear - 3261 does not mandate 500 milliseconds. It says that T1 is an estimate of the round trip time. The value of 100 milliseconds we chose is a much more realistic estimate of round trip times on the modern internet (to say nothing of intranets); at the time we made that change, we measured round trips well under that between Massachusetts USA and Bangalore India over paths with hops in the high teens. The 6 or 7 retransmissions are, in practice, ridiculous - no one will wait 32 seconds for a phone to ring; this is a classic example of spec authors not paying attention to the real world. > This might be particularly problematic for remote worker deployments, > where network delays could be significant. The problem case you've found is really not a network delay problem at all - it's an application problem. If we're going to allow for any change to make this better (and I'd suggest that a closer look at the reason for the delay on the softphone before we consider doing anything in the stack), I would tune the number of retries rather than the T1 value. _______________________________________________ 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/
