Summary:	ASTERISK-04996: [patch] option_maxcalls option will cause hung sip channels if you are over the limit when the invite comes in.
Reporter:	Brian West (bkw918)	Labels:
Date Opened:	2005-09-05 16:03:56	Date Closed:	2008-01-15 15:51:09.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) call-limit.txt
Description:	I tested this with the limit set at 25.  call 26,27,28,29 came in from a test machine.. they were in state Ring and NEVER disappeared.
Comments:	By: Olle Johansson (oej) 2005-09-06 01:49:15 Funny enough, I was planning to test this. You beat me to it. Will look at it. By: Olle Johansson (oej) 2005-09-06 02:01:20 Confirmed the problem By: Olle Johansson (oej) 2005-09-06 03:41:58 Test this patch. Disclaimer on file. The chan_sip patch works as expected on my system´now. I haven't been able to test chan_iax2 changes, so please do and confirm. Someone that knows other channels should check how they behave in this regard. By: Brian West (bkw918) 2005-09-06 10:57:40 sip fix is correct.  iax2 fix leaves hung/locked channels in ringing state on the receiving end. /b By: Olle Johansson (oej) 2005-09-06 11:05:03 Ouch. Someone that understands chan_iax2 needs to look at that... Thank you for confirming the chan_sip fix. kpfleming: I am not proud over this solution, but found no other way to signal from the new thread that died to the channel... We might have to implement a callback to be really sure of what happened without having to wait and see... At least this improves the situation. By: Olle Johansson (oej) 2005-09-08 14:22:27 This patch for is ready and tested - but not the IAX2 part... Let someone that understands IAX2 fix that channel. By: Brian West (bkw918) 2005-09-10 23:50:29 the iax2 part doesn't work.  Don't you need to destroy tmp before pointing it to NULL? /b By: Russell Bryant (russell) 2005-09-13 12:12:45 I just posted issue ASTERISK-5074. This feature is going to be subject to the same problems as option_maxcalls.  Because of this, the fix to indicate the fact that the pbx was not able to be started on the channel will have to be a bit more generic. However, option_maxcalls needs to be fixed before 1.2, while my code won't be going in until after 1.2. By: Kevin P. Fleming (kpfleming) 2005-09-13 18:01:11 Why was this issue 'assigned' to me with an untested patch in it? I don't understand... In any case, I'm putting a better solution into the PBX core as I type this; it will check the call limit before even trying to launch a PBX thread, so the channel drivers can get immediate notification that the call could not be started. Please re-do the chan_sip portion of this patch to use the new return values (and no more usleep() is needed, nor is any global flag), but don't post a patch for chan_iax2 unless you think it will work properly :-) By: Kevin P. Fleming (kpfleming) 2005-10-13 21:20:10 Fixed in CVS HEAD for chan_sip only (implemented new method). By: Digium Subversion (svnbot) 2008-01-15 15:47:53.000-0600 Repository: asterisk Revision: 6568 U   trunk/include/asterisk/pbx.h U   trunk/pbx.c ------------------------------------------------------------------------ r6568 | kpfleming | 2008-01-15 15:47:53 -0600 (Tue, 15 Jan 2008) | 2 lines check call limit in ast_pbx_start(), instead of waiting until background thread has been launched (needed for issue ASTERISK-4996) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=6568 By: Digium Subversion (svnbot) 2008-01-15 15:51:09.000-0600 Repository: asterisk Revision: 6788 U   trunk/channels/chan_sip.c ------------------------------------------------------------------------ r6788 | kpfleming | 2008-01-15 15:51:08 -0600 (Tue, 15 Jan 2008) | 2 lines make chan_sip able to deal with PBX-level call limit being reached (issue ASTERISK-4996) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=6788