[asterisk-bugs] [Asterisk 0008855]: nat=no is not RFC 3261 compliant regarding sending responses

[noreply at bugs.digium.com]

email_notification_title_for_status_bug_ready_for_testing 
====================================================================== 
http://bugs.digium.com/view.php?id=8855 
====================================================================== 
Reported By:                mikma
Assigned To:                oej
====================================================================== 
Project:                    Asterisk
Issue ID:                   8855
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     ready for testing
Asterisk Version:            SVN 
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!): 51305 
Disclaimer on File?:        Yes 
Request Review:              
====================================================================== 
Date Submitted:             01-19-2007 14:32 CST
Last Modified:              04-03-2008 11:30 CDT
====================================================================== 
Summary:                    nat=no is not RFC 3261 compliant regarding sending
responses
Description: 
A note should be added to sip.conf.sample that using nat=no makes Asterisk
send responses to the address in the "sent-by" value instead of using the
source address of the request. This doesn't comply with RFC 3261 section
18.2.1 and 18.2.2.


   RFC 3261 section 18.2.1 Receiving Requests

   If the host portion of the "sent-by" parameter
   contains a domain name, or if it contains an IP address that differs
   from the packet source address, the server MUST add a "received"
   parameter to that Via header field value.  This parameter MUST
   contain the source address from which the packet was received.  This
   is to assist the server transport layer in sending the response,
   since it must be sent to the source IP address from which the request
   came.


   RFC 3261 section 18.2.2 Sending Responses.

         Otherwise (for unreliable unicast transports), if the top Via
         has a "received" parameter, the response MUST be sent to the
         address in the "received" parameter

====================================================================== 

---------------------------------------------------------------------- 
 putnopvut - 04-03-08 11:30  
---------------------------------------------------------------------- 
I noticed this issue and wrote a quick patch that might take care of the
issue. The way this patch works is that when it attempts to determine where
to send the packet, it uses the same rules as we use for NAT if the packet
is a SIP response. In other words, we send the packet back to the address
from which we received the packet. 

I ran a few quick tests to be sure I didn't introduce any terrible
regressions, but I'd appreciate further testing to be certain that this
fixes the issue reported. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
04-03-08 11:30  putnopvut      Note Added: 0085000                          
04-03-08 11:30  putnopvut      Status                   assigned => ready for
testing
======================================================================