[asterisk-bugs] [Asterisk 0012577]: Asterisk MUST add VIA "received" parameter always and send replies there even if "nat=no"

[noreply at bugs.digium.com]

The following issue has been RESOLVED. 
====================================================================== 
http://bugs.digium.com/view.php?id=12577 
====================================================================== 
Reported By:                ibc
Assigned To:                kpfleming
====================================================================== 
Project:                    Asterisk
Issue ID:                   12577
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     resolved
Asterisk Version:           1.4.19 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
Resolution:                 duplicate
Duplicate:                  8855
Fixed in Version:           
====================================================================== 
Date Submitted:             05-03-2008 06:26 CDT
Last Modified:              07-22-2008 18:06 CDT
====================================================================== 
Summary:                    Asterisk MUST add VIA "received" parameter always
and send replies there even if "nat=no"
Description: 
Hi, Asterisk SIP doesn't respect RFC 3261 section "18.2.1 Receiving
Requests":

 18.2.1 Receiving Requests

   When the server transport receives a request over any transport, it
   MUST examine the value of the "sent-by" parameter in the top Via
   header field value.  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.


But if Asterisk listening in a public IP receives a message like this:

  # U 211.55.130.197:60262 -> ASTERISK_PUBLIC_IP:5060
  REGISTER sip:asterisk.domain.com SIP/2.0
  Via: SIP/2.0/UDP 192.168.0.129;rport;branch=z9hG4bKnfztfitc

Then Asterisk will reply to 211.55.130.197 **just** in case that peer is
defined as "nat=yes". If not Asterisk will reply to the private IP
192.168.0.129.

This is completely wrong since replying to the public source IP is
mandatory as it's explained above.

I understand that the "nat=yes" can be useful to enable comedia mode for a
peer so it doesn't matter if it behind NAT and indicates a private IP in
the SDP. Also it's valid for sending in-dialog messages to the source
public IP instead of the uri indicated in "Contact" header than would be
private so unreachable by Asterisk. And also it can ve useful to assume
"rport" and sending the transaction reply to the port of the public source
IP instead of the port indicated in "sent-by" field.

But for sending a transaction response to the received public IP it MUSN'T
be neccesary at all to set "nat=yes", it's completely RFC 3261
non-compliant.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
duplicate of        0008855 nat=no is not RFC 3261 compliant regard...
has duplicate       0013008 [patch] chan_sip ignores rport and does...
====================================================================== 

---------------------------------------------------------------------- 
 kpfleming - 07-22-08 18:06  
---------------------------------------------------------------------- 
This is clearly a duplicate of issue 8855; let's keep all the discussion
there, instead of having it in three places. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-22-08 18:06  kpfleming      Assigned To               => kpfleming       
07-22-08 18:06  kpfleming      Note Added: 0090583                          
======================================================================