[asterisk-bugs] [Asterisk 0012282]: Asterisk sends SIP-over-TCP INVITE to wrong port number

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12282 
====================================================================== 
Reported By:                rjain
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12282
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 110578 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             03-23-2008 08:28 CDT
Last Modified:              03-25-2008 18:06 CDT
====================================================================== 
Summary:                    Asterisk sends SIP-over-TCP INVITE to wrong port
number
Description: 
The scenario is that a SIP UA registers with Asterisk using TCP transport.
The UA puts its IP address, port number and transport=tcp parameter in the
REGISTER's Conact: header. Asterisk stores these contact parameters
correctly in its registration table. However, when it comes to sending an
INVITE to this UA, Asterisk puts a wrong port number in the destination
port number field of the TCP header. Due to this, the UA never receives the
INVITE. The TCP port number is actually correct in the SIP payload
including the Request-URI and the To: header in the INVITE, but it's not
correct in the TCP header. 

Asterisk log file and wireshark trace are attached.
====================================================================== 

---------------------------------------------------------------------- 
 putnopvut - 03-25-08 18:06  
---------------------------------------------------------------------- 
I had a look at this, and I believe I have found the problem area.
Apparently,there is a function that is called with every transmission
called sip_prepare_socket. In this, one of the first things that is checked
is if the file descriptor associated with this call is valid. If it is,
then we immediately return. While this works fine for UDP sockets, it does
not bode well for TCP connections. The problem is that the TCP connection
still operates with the stored IP address and port number when we
established the connection. In your case, this means that we're still
operating with the same IP address and port number from which we received
the REGISTER request. I strongly suspect that had your REGISTER also
contained a different IP address in the Contact header than what we had
received the request from, we would have sent the INVITE to the wrong
address too.

I have written a patch which alters the logic used here. I'm pretty
certain that this will send the INVITEs to the proper address and port.
Furthermore, I have attempted to do some necessary cleanup. What I have
done is changed the logic so that if the file descriptor is valid AND the
transport type is TCP AND the IP address and port number we have stored for
the peer are different than what we previously had associated with the
socket, then we will kill the thread associated with the current TCP
connection (which should shut down the TCP connection) and re-initialize
the socket in question. 

Unfortunately, I have no way of testing this, so I'd appreciate if you
could test and give feedback. While I have done plenty of Asterisk coding
in the past, I'll be up front and say that I have not done a lot of
chan_sip work, and so if this patch doesn't fix things, please bear with me
as I attempt to get this working properly. Thanks! 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
03-25-08 18:06  putnopvut      Note Added: 0084543                          
======================================================================