Summary:	ASTERISK-21163: pjproject raises an assert failure when creating TURN socket while adding ICE candidates to RTP session
Reporter:	Private Name (falves11)	Labels:
Date Opened:	2013-02-25 13:58:27.000-0600	Date Closed:	2014-09-16 06:14:16
Priority:	Critical	Regression?
Status:	Closed/Complete	Components:	Resources/res_rtp_asterisk
Versions:	11.3.0	Frequency of Occurrence	Constant
Related Issues:	is duplicated by ASTERISK-21206 Crashes contstantly in chan_motif
Environment:	red hat 1.6.4 2.6.32-279.22.1.el6.x86_64	Attachments:	( 0) bt_full.txt ( 1) crash.txt ( 2) crash.txt ( 3) crash.txt ( 4) crash.txt ( 5) motif.conf ( 6) sip.conf ( 7) thread_all_bt.txt ( 8) xmpp.conf
Description:	Asterisk 11 crashes with very little load every 10 to 30 minutes.
Comments:	By: Joshua C. Colp (jcolp) 2013-02-25 14:03:43.745-0600 Out of curiosity... why are you using a TURN server with your Asterisk server? By: Matt Jordan (mjordan) 2013-02-25 14:28:29.490-0600 On a slightly different note. While I appreciate your filing Jira issues - and you do report a lot, which we are thankful for - please go read the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines]. While a backtrace is important and useful, there's a lot of information that could be provided that would be useful, that you should be used to collecting by now. Things like: * Where did it crash? What were you doing? A summary of 'crash' tells no one who looks at this issue anything about what is going on. * What are the configuration files on the system? What modules were in use when it crashed? ** If you provided a backtrace, *look* at the backtrace before attaching it. That should give you some hint of where it crashed. ** Hint: on this issue, it's in res_rtp_asterisk. _Already I could now set the component field and provide a more useful summary._ * What version are you running? Is it *really* trunk? ** If you are running an unreleased version of Asterisk, why? You may want to contact developers in #asterisk-dev before filing an issue, as things in trunk are sometimes unstable (hopefully for short periods of time) ** If you are running trunk, was there a version where it did not crash? That can help developers pinpoint the commit that broke trunk. Reporting issues is always appreciated, however, requiring bug marshals to ask the same questions over, and over, and having to re-update the information in an issue makes them spend time interpreting information that you could have already provided, and reduces the amount of time they have in solving the issue. By: Private Name (falves11) 2013-02-25 18:23:53.051-0600 a) I thought Asterisk 11 was released. But from your comments I infer that it is not. Should I stay in Asteris 1.8? I need the Motif channel. b) I download the version like this: svn co http://svn.digium.com/svn/asterisk/branches/11 asterisk and then every day I do an "svn up". Is this called Trunk or "11" c) If I stayed in the tried-and-true version, how would Asterisk ever get debugged and the problems discovered? I am taking risks for the sake of getting a better software for the future. By: Matt Jordan (mjordan) 2013-02-25 20:53:48.688-0600 {quote} a) I thought Asterisk 11 was released. But from your comments I infer that it is not. Should I stay in Asteris 1.8? I need the Motif channel. b) I download the version like this: svn co http://svn.digium.com/svn/asterisk/branches/11 asterisk and then every day I do an "svn up". Is this called Trunk or "11" c) If I stayed in the tried-and-true version, how would Asterisk ever get debugged and the problems discovered? I am taking risks for the sake of getting a better software for the future. {quote} No, SVN refers to trunk. If you're running the latest check out from the branch, that would correspond to the current unreleased version of that branch - in this case 11.3.0. (Issue updated to reflect that) That should answer the rest of your questions: Asterisk 11 is released; it is supported; it should not crash. All of that aside, please assist the bug marshals attempting to assist you by providing as much information as possible when you create an issue. "Asterisk 11 crashes with very little load every 10 to 30 minutes." tells a bug marshal nothing about your system, what you're doing on it, what SIP message traffic is causing the crash, or anything else. It doesn't help us reproduce it or debug the problem. It doesn't provide us your configuration to help us figure out what is causing the crash. And all of these points are listed out in the [Asterisk Issue Guidelines page|AST:https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines#AsteriskIssueGuidelines-Submittingthebugreportinformationrequirements] - which is linked when you create an issue with a check box that says "Yes, I have read the issue guidelines". SO. Please provide your {{sip.conf}}, the dialplan that your SIP calls are executing, and preferably a DEBUG log containing the sip traffic leading up to the crash. I've updated the issue with what appears to be happening in your backtrace, but that will help us determine more about what is causing the problem. By: Private Name (falves11) 2013-02-25 21:03:13.447-0600 The issue is clear, ice support crashes Asterisk. I changed to icesupport=no and it has not crashed in 7 hours. By: Private Name (falves11) 2013-02-25 21:05:19.314-0600 If a bug marshall wishes to log into my box and turn ice support on and capture more info from the crashes, please contact me for credentials. By: Joshua C. Colp (jcolp) 2013-02-26 06:54:44.158-0600 I'm still interested in knowing why you are using TURN support. It should be very rarely of need. By: Private Name (falves11) 2013-03-05 03:23:20.624-0600 I disabled icesuppoort=-no in sip.conf, bute nevertheless it keeps crashing, and it seems related By: Private Name (falves11) 2013-03-05 07:25:28.418-0600 I did a svn up to version 382410 and it keeps crashing. Please take a look. By: Private Name (falves11) 2013-03-05 07:26:15.166-0600 Please kindly look at the attached files. It keeps crashing  even after updated to version 382410. By: Private Name (falves11) 2013-03-05 10:03:17.768-0600 bt, ft full and thread apply all bt By: Private Name (falves11) 2013-03-05 10:07:47.107-0600 sip.conf By: Joshua C. Colp (jcolp) 2013-03-05 10:09:49.730-0600 I asked this previously - why are you using TURN? By: Private Name (falves11) 2013-03-05 10:15:53.931-0600 motif.conf By: Private Name (falves11) 2013-03-05 10:16:10.613-0600 xmpp.conf By: Private Name (falves11) 2013-03-05 10:19:08.764-0600 I am not using Turn. How do you get that idea? I don't see that in my configuration files. I am sorry if I am missing it By: Joshua C. Colp (jcolp) 2013-03-05 10:21:04.979-0600 The code you mentioned will only be executed if the TURN settings have been configured in rtp.conf - this should very rarely be required. By: Private Name (falves11) 2013-03-05 10:21:53.044-0600 I found the Turn option and removed it. Let's watch if it keeps crashing. By: Private Name (falves11) 2013-03-06 04:41:01.201-0600 I confirm that without TURN support, it is stable. So the bug is in the code that supports TURN. I was also using icesupport, but it does not seem to matter. My turn server was a free one my rtp.conf icesupport = no rtpstart=5000 rtpend=62767 dtmftimeout=3000 strictrtp=no stunaddr = stun.l.google.com:19302 turnaddr=numb.viagenie.ca turnusername=wwwww@zzzz.com turnpassword=xxxxx By: Private Name (falves11) 2013-03-13 09:00:04.954-0500 I stopped using TURN, but it keeps blowing up in ICE. I need ICE because my box has two IP addresses, one private and one public. The public is for SIP and the private is for Google Voice. Calls come in via SIP and leave via Google. Please advice any workaround By: Private Name (falves11) 2013-09-23 21:24:16.063-0500 Closed due to giving up By: Matt Jordan (mjordan) 2013-09-24 07:47:07.927-0500 Other people have run into this issue. While you may have given up, it is still a potential problem. Reopening. By: Matt Jordan (mjordan) 2014-07-10 06:53:34.233-0500 Falves/CDR/Private Name: please stop closing this issue. As I said in my prior comment, others have reported this issue and while you may have "given up", this is still a valid issue for them. Your abuse of the issue tracker - ignoring comments, closing issues when they've been re-opened, filing issues as blockers when asked not to do so - is certainly noticed. Please follow the requests bug marshals have made of you. Participating in this project in an antagonistic fashion is unlikely to yield the results you'd like.