[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 03:23 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...
====================================================================== 

---------------------------------------------------------------------- 
 ibc - 07-23-08 03:23  
---------------------------------------------------------------------- 
Hi,  about Klaus comment:

If a reply to srcIP:viaPort fails then the UAS should perform steps in RFC
3261 (DNS NAPTR, SRV...) for the host indicated in Via. Anyway, I think
this step could be omited and I also know about other SIP stacks omiting
this step. Sincerely I think it makes no sense to receive a request via
address A and send the response via address B because a network error
sending it to address A. It's completely safe to destroy the transaction
server when the response reports a network error (at least for a stateful
proxy or for a UAS). Of course this is a personal opinion, but I think SIP
design is too much "exotic" and anti-realistic in this point.

I don't see problem in adding always "rport=SrcPort" to the Via header (so
"received" MUST also be added according to RFC 3581). In fact, in OpenSer
proxy there is an option "force_rport" and it's safe to use (we assume all
the clientes use symmetric SIP signalling).

I agree when Klaus says that "nat=never" shouldn't exist. So we just have
2 things:
- RFC 3581 ("rport" for signalling).
- Comedia mode (Asterisk sending RTP to IP:port from which it received the
audio).


Well, then "nat" options could be:

- nat=force_rport => So "rport" (and "received") is always added (even if
not present) to the request, and response is sent to "received:rport"
according to RFC 3581.

- nat=yes => Includes "nat=force_rport" and RTP is sent to the IP:port
from which audio is received (comedia mode).

- nat=no => Don't force "rport" (so just use it if present in the original
request) and don't use comedia mode.


I don't want to imagine the purpose of "nat=route". 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-23-08 03:23  ibc            Note Added: 0090597                          
======================================================================