Summary:	ASTERISK-16033: NTT Japan will ignore SIP packets with ;received= set in Via SIP header
Reporter:	Mark Karpeles (magicaltux)	Labels:
Date Opened:	2010-04-29 17:57:03	Date Closed:	2011-06-07 14:05:28
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Interoperability
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
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 ?). ****** ADDITIONAL INFORMATION ****** The patch itself consists of adding the following line at the beginning of the copy_via_headers() function, just before the for(;;): if(ast_test_flag(&p->flags[0], SIP_NAT) == SIP_NAT_NEVER) copied++;
Comments:	By: Paul Belanger (pabelanger) 2010-04-29 19:07:14 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. By: Paul Belanger (pabelanger) 2010-04-29 19:19:19 Either way, we are going to need SIP traces to see what is going here. http://svn.digium.com/svn/asterisk/trunk/doc/HOWTO_collect_debug_information.txt By: Mark Karpeles (magicaltux) 2010-04-29 19:23:00 According to the part of the RFC copied in note 0121197, this requirement only applies if the received packet contains a domain name, or an IP address which is not the same as the packet source address. In the current case the received packet has an IP address and it matches the packet source address. Depending on how the RFC text is interpreted, adding "received" in this case is not a requirement. I guess then I should try to make a patch that will check this condition (origin is IP and matches origin of packet) before deciding to add ;received= or not, however my knowledge of Asterisk internals is fairly limited so it might take some time. EDIT: I will collect SIP logs within 24 hours, when I'll be able to interrupt phones without causing any problem to anyone. By: Leif Madsen (lmadsen) 2010-05-11 10:47:48 Note: there is nothing we can do here without a SIP trace. Our policy is to close issues that do not provide the required information to be moved forward within about 10 business days. By: Leif Madsen (lmadsen) 2010-05-25 14:57:01 Issue suspended due to lack of response from the reporter.