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

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12577 
====================================================================== 
Reported By:                ibc
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12577
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
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:              
====================================================================== 
Date Submitted:             05-03-2008 06:26 CDT
Last Modified:              05-03-2008 06:35 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.
====================================================================== 

---------------------------------------------------------------------- 
 ibc - 05-03-08 06:35  
---------------------------------------------------------------------- 
Sorry, in the last phrase I mean:

About this I don't know if Asterisk should always assume "rport" even if
there is NOT "rport" in request Via header (as OpenSer can do with
"force_rport" function), or if Asterisk should reply to public port only in
case of "nat=yes" for that peer.


The standard behaviour is:

* If a client behind NAT adds "rport" parameter in Via header then the UAS
transport layer should add in received request Via header:
- "received=PUBLIC_SOOURCE_IP"
- "rport=PUBLIC_SOURCE_PORT"
And the reply must go there.

* If a client behind NAT sends the request without adding "rport" in Via
header then the UAS transport layer should add in Via:
- "received=PUBLIC_SOOURCE_IP"
In this second case replies from UAS would go to
PUBLIC_SOURCE_IP:Port_indicated_in_original_sent-by_or_5060_by_default so
it would be lost in the NAT device, this is why RFC 3581 exists but a
client MUST add "rport" parameter first case to work. If not, mayeb the UAS
forces it (OpenSer "force_rport" or Asterisk "nat=yes"). 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
05-03-08 06:35  ibc            Note Added: 0086346                          
======================================================================