Summary:	ASTERISK-21824: SIP INVITES from Telphin broke in 1.8.21
Reporter:	Arcadiy Ivanov (arcivanov)	Labels:
Date Opened:	2013-05-26 15:26:36	Date Closed:	2013-05-29 09:45:48
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:	1.8.21.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	Linux pbx1.home.ivanovy.net 2.6.18-348.6.1.el5 #1 SMP Tue May 21 15:34:22 EDT 2013 i686 i686 i386 GNU/Linux	Attachments:	( 0) tcpdump.log
Description:	Upgraded from 1.8.20 to 1.8.21. All SIP invites from Telphin no longer processed and are nowhere to be found in console with "sip set debug on", "core set verbose 999" and "core set debug 999". Other providers (Voicepulse and Gafachi) work fine. Out of all providers used in this system Telphin is the only one that has Record-Route in its invites. I highly suspect the issue may be with r379392 that changed the way Record-Route is parsed right after 1.8.20 was released. Attached is the tcpdump on the Asterisk box of the incoming SIP INVITES that are dropped silently.
Comments:	By: Arcadiy Ivanov (arcivanov) 2013-05-26 15:29:05.389-0500 Tcpdump of failed invites By: Michael L. Young (elguero) 2013-05-28 14:55:02.510-0500 That is weird that you are not even getting the incoming invites displayed through the console.  If the changes to the parsing of the RR was the cause of this, I would think you would still get the incoming invite appearing on the screen or some sort of message in your logs. I added the RR headers to the unit test and then ran the test.  The test is passing.  So, initially, parsing the RR headers doesn't seem to be the problem. Just wanted to add this tid bit of info in order to help. By: Arcadiy Ivanov (arcivanov) 2013-05-28 20:43:00.166-0500 Ok... The REGISTER and OPTIONS packets go back and forth no problem. What could be a possible cause of a packet not even being printed by Asterisk? Anything I can turn on to confirm Asterisk actually received a packet in its socket? By: Michael L. Young (elguero) 2013-05-28 22:16:00.986-0500 To be honest, I am not sure why it wouldn't at least capture or at least mention that it received some sort of packet in the debug messages.  Since all you did was upgrade from one minor version to another without changing anything configuration wise, I am at a loss right now. Perhaps this would help give us some clues: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Walter Doekes (wdoekes) 2013-05-29 07:12:02.063-0500 Arcadiy: have you tried downgrading? Do you get the sip debug in the old version? My first guess would be a firewall that drops fragmented packets. Those would show up in tcpdump but not in in asterisk. By: Arcadiy Ivanov (arcivanov) 2013-05-29 07:50:18.814-0500 @Walter, That's an interesting thought. I had problems with pf on the firewall dropping fragmented UDP packets without reassembly exclusively from Telphin, but since I switched to IPFW the problem is gone. The tcpdump was taken on the pbx1 machine behind the firewall, i.e. the packets have arrived into the eth0 interface and I have confirmed that what arrives on WAN iface of the fw is what arrives onto the eth0 of the pbx1 (which has its own iptables to only accept connections from specific SIP peers). Let me fiddle with the iptables on pbx1, and I'll post an update. Importantly, though, I haven't changed iptable rules in years. By: Arcadiy Ivanov (arcivanov) 2013-05-29 09:44:53.241-0500 This is a successful invite packet from Voicepulse: 10:37:18.735826 00:15:17:85:7b:a3 > 00:0c:f1:74:f7:ff, ethertype IPv4 (0x0800), length 1370: (tos 0x20, ttl  53, id 0, offset 0, flags [DF], proto: UDP (17), length: 1356) 64.61.93.190.5060 > 192.168.157.42.5060: [udp sum ok] SIP, length: 1328 This is an invite packet from Telphin: 10:37:30.806243 00:15:17:85:7b:a3 > 00:0c:f1:74:f7:ff, ethertype IPv4 (0x0800), length 1514: (tos 0x20, ttl  46, id 35257, offset 0, flags [+], proto: UDP (17), length: 1500) 213.170.92.166.5068 > 192.168.157.42.5060: [bad udp cksum 45f6!] SIP, length: 1472 Things to note: 1) Telphin packet is 14 bytes larger than MTU. 2) Telphin has a bad checksum probably due to frag reassembly. I suspect the udp checksum offload/reassembly isn't working correctly on FreeBSD firewall for fragmented UDP packets. At any rate, this is not an Asterisk issue. By: Arcadiy Ivanov (arcivanov) 2013-05-29 09:45:48.158-0500 UDP packets arriving are trash. Not an Asterisk issue.