Summary:	ASTERISK-12150: fresh reboot of asterisk server, TCP sip peers get invite via UDP
Reporter:	Paul Belanger (pabelanger)	Labels:
Date Opened:	2008-06-05 11:41:39	Date Closed:	2008-07-28 16:24:32
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 20080626_issue12799_udp_for_tcp_peers.diff ( 1) chan_sip.rej.txt ( 2) configs.tar.gz ( 3) extensions.conf ( 4) messages ( 5) problems.txt ( 6) sip.conf
Description:	Weird issue, If we reboot our asterisk server (# sudo reboot), then let everything boot back up.  SIP peers configured for TCP seem to default to UDP clients.  But if we issue 'reload' from the asterisk cli or init.d script, the SIP peers will be setup back to TCP. ****** ADDITIONAL INFORMATION ****** attach is debugs, verbose, and sip trace.
Comments:	By: Brett Bryant (bbryant) 2008-06-05 11:52:43 pabelanger, can you upload a copy of your sip.conf and extensions.conf for debugging? By: Paul Belanger (pabelanger) 2008-06-05 12:34:08 Sorry, was about too, but something came up. Attached now. By: Paul Belanger (pabelanger) 2008-06-05 12:41:37 I think the issue may revolve around DNS, too.  If I replace the 'host=' in the SIP.conf file with an IP address, the issue goes away. So, here is a guess to what is happening.  Asterisk is loading before DNS is cached locally, then once DNS is cached, asterisk is still unable to resolve the hostname?  For whatever reason, this cause SIP to default to the UDP configuration. Then, we reload asterisk, it can resolve DNS, TCP get loaded properly and things are ok. By: Paul Belanger (pabelanger) 2008-06-07 10:14:30 More information. I've enabled dnsmgr (in dnsmgr.conf) in hopes that asterisk will refresh the DNS entry, but still an issue. From the cli> sip show peers and sip show peer sv0071iv both show nothing. Issuing 'module reload' clears the issue. But it does revolve around the host setting from sip.conf.  Static IPs do not have this issue, its only with hostnames. By: Brett Bryant (bbryant) 2008-06-09 13:52:10 pabelanger, after replicating your setup on 1.6.0-beta9 i can't seem to duplicate your issue. Can you give any more details about what happens when asterisk tries to send it over UDP instead of TCP? By: Paul Belanger (pabelanger) 2008-06-10 09:39:08 bbryant: Sorry for the delay on this, was traveling yesterday. I have attached .tar.gz of our asterisk configs.  Hopefully theses will help.  Also, our SIP TCP peers do not send SIP Registration messages to asterisk.  I believe this is also the key for this not to be working. I'm still digging into our setup and will post anymore information we find. By: Paul Belanger (pabelanger) 2008-06-19 15:08:16 More info: This must be related to the timing of asterisk starting and DNS getting cached locally into the system. If I add the hostnames into /etc/hosts the problem goes away. Also, forgot to mention, we're using Ubuntu 8.04 Server as the OS too. By: Brett Bryant (bbryant) 2008-06-19 16:21:39 pabelanger, is this issue still only happening after a fresh reboot of the entire server? By: Paul Belanger (pabelanger) 2008-06-19 16:26:11 Correct. By: Olle Johansson (oej) 2008-06-26 11:19:18 This is related to the way we store registrations in the astdb. The TCP/TLS implementation was never properly designed and thus have a lot of issues like this. That's why it's marked "experimental" while waiting for a re-design to do it properly. By: Brett Bryant (bbryant) 2008-06-26 13:00:49 Only registrations that are udp should have been stored in the db. I can't seem to replicate this problem locally, but I have a theory on what is happening. Asterisk doesn't know what to do if a peer that should be using a tcp session sends a response via udp or vice versa, and will stores the connection information in astdb and continue using the new transport for any further communication with that peer. With the exception of not saving this switch in the astdb, not changing the peer's transport for new dialogs, and throwing a warning for when switching from tcp or an error and failure case for when switching from tls i believe this is the correct fix for that problem. I'll have a patch up soon. pabelanger, are your peers running on the same machine, i.e. softphones or other asterisk installations in a virtual machine? By: Paul Belanger (pabelanger) 2008-06-26 13:06:31 bbryant: No, both our SIP Peers are remote system.  No local peers to our asterisk installation. By: Digium Subversion (svnbot) 2008-06-27 11:21:00 Repository: asterisk Revision: 125891 U   trunk/channels/chan_sip.c U   trunk/configs/sip.conf.sample ------------------------------------------------------------------------ r125891 | bbryant | 2008-06-27 11:20:56 -0500 (Fri, 27 Jun 2008) | 6 lines Change the way that the transport option works for sip users. transport will now take multiple arguments, the first one listed will be the one used for new dialogs, and the rest listed will be acceptable ways for that peer to contact us. This fixes a minor bug where, because SIP TCP/UDP run on the same port, could cause a TCP peer to be saved in the ast_db. There will also be warnings when a transport is changed for an unexpected reason. (issue ASTERISK-12150) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=125891 By: Russell Bryant (russell) 2008-06-30 10:52:53 pabelanger, please test to see if that change fixes it for you By: Paul Belanger (pabelanger) 2008-07-18 22:05:48 russell: sorry for the delay on this.  Is there a back port into 1.6.0-beta9?  We are unable to run trunk at this current location. By: Paul Belanger (pabelanger) 2008-07-18 22:14:02 russell: Ignore previous comment, managed to find patch for 1.6.0 branch, but failed to be applied to 1.6.0-beta9 (see attached). We'll try and compile the latest 1.6.0 trunk this weekend for a test and see what happens. By: Paul Belanger (pabelanger) 2008-07-18 22:51:36 Ok, managed to install 1.6.0 svn 132245 on your system.  But we're having problems.  It looks like chan_sip is now using the SIP PEER context as the hostname, nolonger the host setting.  See attached file. This is again, from a fresh reboot. --- [sv0071ivr] host=sv0071iv.voice port=5070 type=peer transport=tcp qualify=yes ;promiscredir=yes By: Brett Bryant (bbryant) 2008-07-28 16:06:05 pabelanger, can you post the debug output with sip debug turned on? By: Paul Belanger (pabelanger) 2008-07-28 16:19:17 bbryant: The attached (problems.txt) did have sip debug enabled, but did not get trapped cause it could not find the hostname. Either way, I _think_ we can close out this issue as the patch related to 0011843 resolved any issue we had. By: Brett Bryant (bbryant) 2008-07-28 16:24:26 The issue is resolved by the patch in issue ASTERISK-11304.