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

Asterisk Bug Tracker noreply at bugs.digium.com
Fri Jun 26 15:19:54 CDT 2009


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=8855 
====================================================================== 
Reported By:                mikma
Assigned To:                file
====================================================================== 
Project:                    Asterisk
Issue ID:                   8855
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.6.1-rc1 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!): 51305 
Request Review:              
====================================================================== 
Date Submitted:             2007-01-19 14:32 CST
Last Modified:              2009-06-26 15:19 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

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
has duplicate       0012577 Asterisk MUST add VIA "received&qu...
has duplicate       0013008 [patch] chan_sip ignores rport and does...
related to          0013071 [patch] OPTIONS response on default port.
====================================================================== 

---------------------------------------------------------------------- 
 (0107053) svnbot (reporter) - 2009-06-26 15:19
 https://issues.asterisk.org/view.php?id=8855#c107053 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 203735

U   trunk/CHANGES
U   trunk/channels/chan_sip.c
U   trunk/configs/sip.conf.sample

------------------------------------------------------------------------
r203735 | file | 2009-06-26 15:19:49 -0500 (Fri, 26 Jun 2009) | 6 lines

Fix the 'nat' option to actually do RFC3581 as expected and extend the
configurable values for finer control.

(closes issue https://issues.asterisk.org/view.php?id=8855)
Reported by: mikma
Tested by: klaus3000, file

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=203735 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-06-26 15:19 svnbot         Checkin                                      
2009-06-26 15:19 svnbot         Note Added: 0107053                          
======================================================================




More information about the asterisk-bugs mailing list