Summary:	ASTERISK-05765: [patch] Coreless Timeout and Extended Timeout Capability
Reporter:	Joshua C. Colp (jcolp)	Labels:
Date Opened:	2005-12-02 16:28:50.000-0600	Date Closed:	2011-06-07 14:03:04
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Functions/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	This exports a new dialplan function, SUPER_TIMEOUT, which allows greater control over timeouts and timeout types. It currently has 3 supported options: absolute, answer, and state. Their behavior is explained below. Absolute: This option sets the timeout to be applicable to the entire duration of the call from when SUPER_TIMEOUT(absolute) is called. This has the same behavior as the current absolutetimeout, except it's done in a separate thread inside of the function. Usage: Set(SUPER_TIMEOUT(absolute)=120) Answer: This option sets the timeout to be applicable only upon the channel reaching an up(answered) state. So for example if you are dialing a remote side and it stays in a ringing state for 10 seconds, and then is answered - the timeout counter does not begin until it's past the ringing state. Usage: Set(SUPER_TIMEOUT(answer)=60) State: This option sets a timeout on the state change. For example, if you are dialing a SIP client and the channel state does not switch to ringing or progress then the timeout can trigger and jump over the dial so you can try an alternate destination. This is the only timeout option that effects the position in the dialplan. Usage: Set(SUPER_TIMEOUT(state)=5) By default a channel can only have one type of each timeout. This is a configurable option in the source, and can be changed. A branch with this function in it is available at: http://svn.digium.com/view/asterisk/team/file/func_supertimeout I will continue to make tweaks to it, and as well any comments are appreciated. More options can be coded if people give me ideas.
Comments:	By: Tilghman Lesher (tilghman) 2005-12-03 21:47:48.000-0600 I'm wondering why you aren't using ast_channel_walk_locked to check to make sure a channel is still valid before locking it.  Otherwise, I think you have a race condition, where a channel could go away and something else could appear in that memory space before control returns to your thread. You also have another possible condition where timeout_cdr() is called, which will set timeout->channel to NULL, but when timeout_proc gets CPU time, you could dereference timeout->channel->lock and cause a segfault.  One scenario is if the caller hangs up before an answer is generated, when an ANSWER type timeout is in the list.  This seems like a straight-up bad condition, but it could also manifest itself as a race. By: Joshua C. Colp (jcolp) 2005-12-03 22:47:39.000-0600 I've commited a change so that instead of holding a pointer we use the channel name to find it in the list whenever we want to interact with it. As well this allows easier detection of channels disappearing so no more cdr-timeout needed. By: Matt O'Gorman (mogorman) 2006-01-12 17:10:02.000-0600 looks fine to me, and usefull for some people.  yay or nay? By: Kevin P. Fleming (kpfleming) 2006-02-13 17:08:13.000-0600 I don't understand how this is supposed to be better... and how could your 'answer' mode work for a channel that hasn't even gotten into the dialplan yet? Can you provide some dialplan examples of how this would be applied? By: Joshua C. Colp (jcolp) 2006-02-13 17:28:12.000-0600 Here's some examples with explanations: Absolute exten => 100,1,Set(SUPER_TIMEOUT(absolute)=120) exten => 100,2,Wait(60) exten => 100,3,Dial(SIP/jcolp) The timeout counter would start immediately when SUPER_TIMEOUT was called, and would include the waiting for 60 seconds. Thus terminating the call 120 seconds after SUPER_TIMEOUT was called. Answer exten => 200,1,Set(SUPER_TIMEOUT(answer)=120) exten => 200,2,Wait(60) exten => 200,3,Dial(SIP/jcolp) The timeout counter would start upon the channel reaching an up state when SIP/jcolp was answered. The waiting for 60 seconds would not be included. Thus terminating the call 120 seconds after SIP/jcolp picked up. State exten => 300,1,Set(SUPER_TIMEOUT(state)=5) exten => 300,2,Dial(SIP/jcolp) exten => 300,3,Dial(SIP/jcolp2) The timeout counter would start when SUPER_TIMEOUT was called and would check to see if the state of the channel had changed (ie: changed to ringing/ring, progress, or up). If the state did not change within 5 seconds (ie: the SIP party could not reached) then the next line would be executed in the dialplan. By: Joshua C. Colp (jcolp) 2006-03-20 18:40:43.000-0600 I'm going to close out this bug since I've talked to Kevin about it, and we both agreed that the existing timeout stuff is fine - this will be here for anyone to use.