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. >
Tony - Is it possible to get a wireshark trace along with a sipx snapshot? It looks like the called phone invited at frame 113 is registered for TCP only (see 302 contacts at frame 109). The invite is sent only over TCP and it looks like that TCP connection is closed by the other end. It would be useful to know what wireshark sees in that case. thanks, 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
