On Tue, 2009-05-12 at 16:30 -0400, Dale Worley wrote: > 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. >
Trying to figure out exactly where the timer is started is non-trivial... I think the timer really does last 100msec. For some reason, in the most downstream transactions- when the tcp branch times out, SipTransaction::findTransactionFor fails to find a matching transaction. Then the udp branch times out almost immediately, it finds a transaction, but its state is TRANSACTION_COMPLETE. not yet sure why these things happened. after that, the upstream branch (which got the 408 final response) properly rolls over to voicemail. -Kathy _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
