[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:                putnopvut
====================================================================== 
Project:                    Asterisk
Issue ID:                   12282
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
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:              06-20-2008 15:50 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 - 06-20-08 15:50  
---------------------------------------------------------------------- 
I've been taking a further look at this today. Before I dive back into
coding, I've been looking through RFC 3261 to try to determine under what
conditions a TCP connection should be re-used and under what other
conditions a new TCP connection should be established. The information is
all there, and I think I have most of it down.

What I obviously broke in the first patch was what is specified in section
18.2.2.
<pre>
      o  If the "sent-protocol" is a reliable transport protocol such as
         TCP or SCTP, or TLS over those, the response MUST be sent using
         the existing connection to the source of the original request
         that created the transaction, if that connection is still open.
         This requires the server transport to maintain an association
         between server transactions and transport connections.  If that
         connection is no longer open, the server SHOULD open a
         connection to the IP address in the "received" parameter, if
         present, using the port in the "sent-by" value, or the default
         port for that transport, if no port is specified.  If that
         connection attempt fails, the server SHOULD use the procedures
         in [4] for servers in order to determine the IP address and
         port to open the connection and send the response to.
</pre> 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-20-08 15:50  putnopvut      Note Added: 0089032                          
======================================================================