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

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=8855 
====================================================================== 
Reported By:                mikma
Assigned To:                kpfleming
====================================================================== 
Project:                    Asterisk
Issue ID:                   8855
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): N/A  
SVN Revision (number only!): 51305 
Disclaimer on File?:        Yes 
Request Review:              
====================================================================== 
Date Submitted:             01-19-2007 14:32 CST
Last Modified:              07-23-2008 01:20 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...
====================================================================== 

---------------------------------------------------------------------- 
 klaus3000 - 07-23-08 01:20  
---------------------------------------------------------------------- 
Hi Kevin!

The standard is a little bit more complicated:

RFC 3261 defines that responses are sent to (source IP address of the
request):(port indicated in via header). If this fails (e.g. ICMP error
message is received, TCP connection breaks down), the client may retry
using (IP address indicated in Via header, if domainname follow RFC
3263):(port indicated in via header). The received= parameter is actually
only needed when the UA proxies requests stateless, to know the source IP
of the request when relaying the response, nevertheless adding will not
harm and is indeed very useful for debugging at the client side.

RFC 3851 defines that: received= must be added to Via header (although
this would not be needed as Asterisk is not a proxy it might be useful for
the SIP client to detect the public IP address). Further, it defines the
replies are sent to (source IP address of the request):(source port of the
request).

Thus reagarding SIP signalling. As Asterisk uses symmetric SIP signaling
it should not be a problem to add rport always to any outgoing SIP request,
regardless of nat=.... (if for some reason the rport should be ommited IMO
there should be a separate config option as there is a difference between
NAT traversal of peers/users and its own NAT traversal).

For incoming requests IMO Asterisk should always be standard conform. This
means even if nat=no route according to the standards: no
rport->srcIP:viaPort, rport->srcIP:srcPort

And with nat=yes, IMO Asterisk should behave like rport is always present
(thus send back symmetrically)

Regarding RTP: IMO with nat=no Asterisk should send media to the IP:port
announced in the SDP. With nat=yes Asterisk should send media to the
IP:port from which it received the audio.

Any currently I do not see a reason for nat=never or nat=rfc3851. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-23-08 01:20  klaus3000      Note Added: 0090592                          
======================================================================