On Tue, 2009-05-12 at 15:58 -0400, keccles wrote: > I don't agree. > > Without compiling for transaction debug, it's not completely clear, > but I think the timeout actually occurs on the branch > z9hG4bK-sipXecs-005d18d17fae0a8fc21a92020a7ec9900e27 > > When this branch times out, it should roll to the UDP value returned > by SipSrvLookup::servers. > > The 408 seen at sipXproxy.log::8878 is the final response on the > branch Dale mentions but it is _not_ the branch that actually timed > out.
Ugh, yes, the 408 we see is the end of the *destination* transaction of the messages on the branch I described, which is the transaction which is the *source* of the branch z9hG4bK-sipXecs-005d18d17fae0a8fc21a92020a7ec9900e27. It doesn't roll over to UDP because the sending is controlled by this header: X-Sipx-Nat-Route: 65.247.227.196:2878;transport=TCP But if an attempt to send via TCP fails, it's supposed to attempt to resend via TCP about 4 times. That's gross, but it ensures that if the current TCP connection has been terminated at the far end, it will be cleared away and a new TCP connection created. But the whole process is over in about 70 msec, which is much faster than the send timeout values (100 msec +). As far as I can tell, the stack isn't attempting to resend at all. 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
