[asterisk-bugs] [Asterisk 0017265]: NTT Japan will ignore SIP packets with ; received= set in Via SIP header

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17265 
====================================================================== 
Reported By:                MagicalTux
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17265
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   block
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.2.6 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-04-29 17:57 CDT
Last Modified:              2010-04-29 19:07 CDT
====================================================================== 
Summary:                    NTT Japan will ignore SIP packets with ;received=
set in Via SIP header
Description: 
Asterisk always sets ;received= header when reproducing a Via: header in
copy_via_headers() (near line 9099).
The source says "We should *always* add a received to the topmost via"
without giving more informations. I know for a fact that NTT Japan does not
like this in its SIP session, and will discard packets containing
;received=.

The original one-line-patch for Asterisk 1.2 was proposed on japanese
voip-info. I had to adapt the patch a bit to make it compatible with
Asterisk 1.6 and it indeed helps a lot (without it, asterisk complains it
could not transmit a critical packet when an incoming call is received -
outgoing calls not tried). I confirm that with this patch incoming calls
are working.

Reference:
http://voip-info.jp/index.php/%E3%81%B2%E3%81%8B%E3%82%8A%E9%9B%BB%E8%A9%B1_%E3%83%97%E3%83%AD%E3%83%88%E3%82%B3%E3%83%AB

Basically the patch makes copy_via_headers() think the first Via: header
is already passed so it won't add ;received= if nat=never is set.

While I'm not sure this should be implemented for nat=never (I'm not fully
aware of what this ;received= info does, except making things go wrong in
my case) I believe there should at least be a way to avoid it (maybe a
nat=never,noreceived ?).
====================================================================== 

---------------------------------------------------------------------- 
 (0121197) pabelanger (manager) - 2010-04-29 19:07
 https://issues.asterisk.org/view.php?id=17265#c121197 
---------------------------------------------------------------------- 
I direct you to http://www.ietf.org/rfc/rfc3261.txt.

18.2 Servers
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.  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.
---

We *always* add a received to the topmost via, because the RFC requires
it. That said, this is most likely an issue with your provider not
asterisk. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-04-29 19:07 pabelanger     Note Added: 0121197                          
======================================================================