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:56Date Closed:2008-01-15 15:51:09.000-0600
Versions:Frequency of
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.


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?


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)



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)