Summary:	ASTERISK-03988: [patch] New ringing-associated time boundaries for Dial
Reporter:	cxseven (cxseven)	Labels:
Date Opened:	2005-04-26 01:43:44	Date Closed:	2011-06-07 14:05:29
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_dial
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) dialfun-diff3.txt ( 1) dialfun-diff4.txt
Description:	I added two new options I found useful for forwarding calls to my cellphone without having them answered by its voicemail. 1. R(secs) -- timeout to apply once ringing/call progress commences. Call setup can sometimes last for two or more seconds. This option specifies a timeout that starts counting from the first ring or call progress indication rather than from the moment Dial is invoked. V(ms) -- Drops call if ringing answered before ms milliseconds (ie. by eager voicemail); DIALSTATUS is set to ANSWEREDTOOFAST. Requires use of timeout or R(). I don't know about anybody else but my cellphone forwards to voicemail within 700 ms if I've turned it off. I never answer the phone that quick. Probably most people don't. This option provides a simple way to abort calls that are answered too quickly. Of course this should only be used on  the uninformed by those employing calculated recklessness. Providing the number of milliseconds spent ringing to dial macros is an alternative to adding the V() option. But this seems like a useful option and not too pollutive. ****** ADDITIONAL INFORMATION ****** Waiver faxing tomorrow morning. bkw insulted in advance
Comments:	By: cxseven (cxseven) 2005-04-26 12:01:36 Tweaked the code for a little more accuracy. If a first ring event is ever received it is used instead of the first call progress event. By: Kevin P. Fleming (kpfleming) 2005-04-26 21:04:36 I like this idea a lot, and the implementation looks sound. I do have one thought, though: does the R option really need a separate value? Can't we just use 'R' to indicate that the already-supplied timeout value should apply to post-ringing, rather than post-dial? By: cxseven (cxseven) 2005-04-26 22:16:13 Maybe a solitary R could cause that behavior so that there's still a way to specify a custom pre-ringing/progress timeout if desired. For instance, placing an 800 call through FWD: it usually times out after an eternity, but occasionally (@5am) ringing will start immediately. By: cxseven (cxseven) 2005-04-27 23:16:48 Last idea has been implemented in dialfun-diff4.txt By: Kevin P. Fleming (kpfleming) 2005-04-28 11:24:28 There was some discussion recently (maybe on asterisk-dev, maybe here, I can't seem to find it at the moment) about having a progress-only timeout (which would fire if no progress is made on the call). Can you try to locate that discussion, and roll all that work into your patch? Basically, I can see three potential timeouts: before progress is made after progress is made (ringing has begun, etc.) total time The question is, how best to specify them in the dial string... You would also get extra points for this patch if you used the new options parsing API for app_dial, removing the hardcoded parsing that's already there :-) By: cxseven (cxseven) 2005-04-28 12:21:04 There's a question of how to interpret a "total time" timeout when another timeout is present. Should the call cancel when the minimum of pending timeouts arrives or when the maximum arrives? Could total timeout be meant to cancel only the post-ring/progress phase? As the patch is now, new timeouts (even total timeouts and per-destination timeouts) may be asserted by wrapping Dials through the Local channel. I believe this encompasses all of the desired behaviors described above. Alternatively, a macro which is called at every Dial channel event, provided with current ms elapsed, and allowed to set the next timeout or abort the call would be the most flexible approach user-wise. Being my second asterisk patch, I haven't yet attained the credibility OR the knowledge to create such a patch. Option parsing also looked like a nest I didn't want to disturb.. But if you say so, after finals I could do that and I could move pre-ring timeout to its own parameter, leaving "timeout" as applying to the total length of the call - aborting the call if it comes before the next timeout. By: Kevin P. Fleming (kpfleming) 2005-04-29 10:41:57 The master 'timeout' behavior must not change, even if the other timeout(s) have been specified. If the other timeouts would allow the call to continue longer than the master timeout, that doesn't matter. By: Michael Jerris (mikej) 2005-05-23 23:24:28 cxseven.  Are kpflemings comments implemented?  Is this patch updated for current head?  Has anyone tested this? By: cxseven (cxseven) 2005-05-24 09:23:59 kpfleming: where is the new options parsing? I'm guessing it's not the ast_set2_flag() utils.h macros that were already there. The other change, preserving the meaning of the main timeout, isn't done yet but easy enough to make by adding a specific option for pre-ring timeout. By: Michael Jerris (mikej) 2005-05-24 09:46:04 You can look at the implementaiton in app_chanspy.c. By: Michael Jerris (mikej) 2005-06-20 21:43:49 cxseven-  Have you abandoned this bug?  Somone needs to take this on or it will have to be closed out due to lack of response. By: Michael Jerris (mikej) 2005-06-27 22:28:45 Closed due to no response from OP.  Re-open with updates if you are still interested in persuing this bug.