| < Previous by Date | Date Index | Next by Date > |
| Thread Index | Next in Thread > |
Hi,
We have a situation where an INVITE sent on an existing TCP connection 'disappears', probably
because the connection has been broken by a firewall somewhere between the endpoints.
The system in question uses version 1.3.4 of the stack on Windows (2003 server, I think).
This is what the stack logs look like (message contents and IDs scrubbed):
13:15.22.46-529: SipGw_SIP: Resiprocate: (level=7)
13:15.22.46-529: SipGw_SIP: Looking up dns entries for sip:xxx;maddr=10.190.194.10;transport=tcp;user=phone;x-nt-redirect=redirect-server
13:15.22.46-529: SipGw_SIP: Resiprocate: (level=7)
13:15.22.46-529: SipGw_SIP: Found connection for tuple [ V4 10.190.194.10:5060 TCP target domain=10.190.194.10 mFlowKey=0 ]
13:15.22.46-529: SipGw_SIP: Resiprocate: (level=7)
13:15.22.46-529: SipGw_SIP: Looked up source for destination: [ V4 10.190.194.10:5060 TCP target domain=10.190.194.10 mFlowKey=0 ] -> [ V4 172.26.1.21:0 TCP target domain=10.190.194.10 mFlowKey=0 ] sent-by= sent-port=0
13:15.22.46-529: SipGw_SIP: Resiprocate: (level=7)
13:15.22.46-529: SipGw_SIP: Transmitting to [ V4 10.190.194.10:5060 TCP target domain=10.190.194.10 mFlowKey=0 ] tlsDomain= via [ V4 172.26.1.21:5060 TCP target domain=10.190.194.10 mFlowKey=0 ]
13:15.22.46-529: SipGw_SIP: INVITE sip:xxx;maddr=10.190.194.10;transport=tcp;user=phone;x-nt-redirect=redirect-server SIP/2.0
13:15.22.46-545: SipGw_SIP: Resiprocate: (level=7)
13:15.22.46-545: SipGw_SIP: Adding message to tx buffer to: [ V4 10.190.194.10:5060 TCP target domain=10.190.194.10 mFlowKey=0 ]
13:15.22.46-545: SipGw_SIP: Resiprocate: (level=7)
13:15.22.46-545: SipGw_SIP: Processing write for [ V4 10.190.194.10:5060 TCP target domain=10.190.194.10 mFlowKey=0 ]
13:15.22.46-545: SipGw_SIP: Resiprocate: (level=7)
13:15.22.46-545: SipGw_SIP: Found connection for tuple [ V4 10.190.194.10:5060 TCP target domain=10.190.194.10 mFlowKey=0 ]
13:15.22.46-545: SipGw_SIP: Resiprocate: (level=7)
13:15.22.46-545: SipGw_SIP: Writing INVITE
13:15.22.46-560: SipGw_SIP: Resiprocate: (level=7)
13:15.22.46-560: SipGw_SIP: Creating buffer for CONN_BASE: 00C6C2B8 [ V4 10.190.194.10:5060 TCP target domain=10.190.194.10 mFlowKey=1632 ]
13:15.22.46-560: SipGw_SIP: Resiprocate: (level=6)
13:15.22.46-560: SipGw_SIP: Some other error
13:15.22.46-560: SipGw_SIP: Resiprocate: (level=6)
13:15.22.46-560: SipGw_SIP: Failed read on 1632 Unknown error
13:15.22.46-560: SipGw_SIP: Resiprocate: (level=6)
13:15.22.46-560: SipGw_SIP: Connection reset
13:15.22.46-560: SipGw_SIP: Resiprocate: (level=7)
13:15.22.46-560: SipGw_SIP: ConnectionManager::process() read=-1
13:15.22.46-560: SipGw_SIP: Resiprocate: (level=7)
13:15.22.46-560: SipGw_SIP: Closing connection bytesRead=-1
13:15.22.46-560: SipGw_SIP: Resiprocate: (level=7)
13:15.22.46-560: SipGw_SIP: ConnectionBase::~ConnectionBase 00C6C2B8
So, it seems that when the message is sent the read side detects that the connection is down (with a code that
is unrecognised by TCP, but decoded as WSAECONNRESET in Transport::error), but it doesn't appear as if our
application is notified.
This may be kind of a grey area; RFC 3261 (18.4) specifies that if the result of sending a request
is a connection failure, the transport user SHOULD be informed, and 17.1.4 says the the TU SHOULD
be notified. I believe our application takes the role of the TU, and is responsible for further actions.
Is this situation covered by "the result is a connection failure"? I think it can be argued that it is.
The problem from our point of view is that it takes a long time (transaction timeout) before the application
finds out about the failure. Is there anything we can do to avoid this?
Regards,
Mats