[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 09:08 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 09:08  
---------------------------------------------------------------------- 
Yeah, it's seems working just by modifying *sip_real_dst:


SVN rev 115275:
---------------------------------------------------------
static const struct sockaddr_in *sip_real_dst(const struct sip_pvt *p)
{
        if (p->outboundproxy)
                return &p->outboundproxy->ip;

        return ast_test_flag(&p->flags[0], SIP_NAT) & SIP_NAT_ROUTE ?
}
---------------------------------------------------------


Modified:
---------------------------------------------------------
static const struct sockaddr_in *sip_real_dst(const struct sip_pvt *p)
{
        if (p->outboundproxy)
                return &p->outboundproxy->ip;

        // It MUST always use "received" to reply, 
        // even if NAT or not (http://bugs.digium.com/view.php?id=12577):
        return &p->recv;
}
--------------------------------------------------------- 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
05-03-08 09:08  ibc            Note Added: 0086349                          
======================================================================