[Home]

Summary:ASTERISK-02844: [patch] Add a continue option to WaitExten
Reporter:Christopher L. Wade (clwade)Labels:
Date Opened:2004-11-17 13:34:45.000-0600Date Closed:2004-11-25 10:00:47.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) app_swait.c
( 1) waitexten_pbx.c.diff.txt
( 2) waitexten_pbx.c.diff.txt
Description:Basically, add the ability to modify the behavior of WaitExten with a simple 'c' flag, ie WaitExten(5,c).  This new behavior causes WaitExten to continue in the current extension, instead of transferring to the 't' extension on timeout.

****** ADDITIONAL INFORMATION ******

This simply makes WaitExten work like Wait, meaning that it doesn't transfer to the 't' extension, but instead simply 'continues' to the next priority as though you had used Wait instead.

The difference, is that WaitExten allows you to start type extensions, Wait doesn't.  You could probably implement this backwards (in Wait), but I just thought it fit best in WaitExten.
Comments:By: Christopher L. Wade (clwade) 2004-11-17 13:38:32.000-0600

Reported only slightly too early.  Found a bug with this, fixing, shouldn't take more than a few minutes though, will upload new patch when done.  Sorry

By: Brian West (bkw918) 2004-11-17 13:46:38.000-0600

How about this.. make it goto like..

WaitExten(5|exten,pri)

bkw

By: Christopher L. Wade (clwade) 2004-11-17 13:53:00.000-0600

I like that idea, but I must say my C is so rough it'll probably crash the machine * is running on.  I'll give it a try, but it might not be a bad idea for one of the * guru's to just hack this out real quick, shouldn't take any of you more than two or three minutes to implement.

Anyway, back to coding...

By: Christopher L. Wade (clwade) 2004-11-17 13:54:48.000-0600

Quick question to the * guru's, is strtod (or similar) safe to use in *?

By: Brian West (bkw918) 2004-11-17 14:26:39.000-0600

why would you use it?  Look at Goto its very simpler.. strsep or strchr..

bkw

edited on: 11-17-04 14:26

By: Christopher L. Wade (clwade) 2004-11-17 14:43:13.000-0600

Mostly because I'm thinking about doing this patch both ways.  I like your goto style idea, but I would also like to simply be able to say 'WaitExten(10c)' to have it work like I originally planned.  strtod gobbles everything to the first non-number, leaving me with 'c' in my string.  I'll still use strchr and/or strsep for the goto style processing though.

My syntax idea is basically like this...

WaitExten(5c) = wait for five seconds, then goto pri+1
-or-
WaitExten(5|con,exten,pri) = wait five seconds, goto just like goto
-or-
WaitExten(c) = wait for 'ResponseTimeout' or 10 (default) seconds, then pri+1
-or-
WaitExten(|con,exten,pri) = wait ..., then goto just like goto

This makes the syntax nice and clean for those not need 'real' branching.  To briefly explain my need for this patch, I was using background(silence/1) for my pauses, but I discovered I needed finer control over the length of the silence, so I switched to wait(0.25), but that stops dtmf from being interpreted, finally I used waitexten(0.25), but this goes to extension 't' after 0.25.  Thus I really don't need the goto syntax, but I admit it would be nice.

Initially, I'm just gonna get the 'c' option working and stable, then I'll come back later and add the goto processing.

By: Christopher L. Wade (clwade) 2004-11-17 17:37:46.000-0600

Ok, latest version actually seems to work, haven't had it crash yet and I've pretty much thrown the book at it.  It should work EXACTLY as before without the 'c' option, with the 'c' option, it will do as the _fixed_ description says it should.

PS. made a few tiny cosmetic changes to the description for the WaitExten app.
PPS. I've thought about merging the Wait and WaitExten apps, since I would imagine quite a few people will be replacing both 'Wait' and 'Background(silence/1)' statements with this 'WaitExten(${TIMEOUT}c)' statement.  What are your thoughts on this?  We could mark 'WaitExten' deprecated (right word?) and implement a 'ignore' [dtmf] option for the new and improved 'Wait' command.  Again, thoughts?

edited on: 11-23-04 09:27

By: Christopher L. Wade (clwade) 2004-11-17 17:42:26.000-0600

And finally, back to the goto idea...

I've thought on this some more, and the more I think about it, I don't think its needed, you could simply have a goto as the next statement, unless your intentions  where simply to reduce the extensions.conf lines needed to do this (is this going to save you anything in the long run).  If so, I don't think it is such a good idea, your just duplicating logic across multiple functions with practially no benefit.

Of course I could 'execute' the goto app with the remainder of my unprocessed argument string, would this do the same thing?

I'm just thinkging out loud here, feel free to comment or ignore :)

edited on: 11-17-04 17:43

By: twisted (twisted) 2004-11-17 22:52:21.000-0600

I agree with the 'c' option.  if you wanted to make it go somewhere else afterwards, I think that should be left up to the extension at pri n+1.

By: Christopher L. Wade (clwade) 2004-11-18 08:27:10.000-0600

Anybody else tested this.  Once mark, et. al., is ok with this patch and is willing to put it in CVS, I'll submit the disclaimer.

Of course this is such a small little tweak, any of you guys with the disclaimer on file (and CVS access) could hack together your own version of this and put it in place.

edited on: 11-18-04 08:30

By: Christopher L. Wade (clwade) 2004-11-22 16:44:54.000-0600

Latest file addition is a totally new take on this.  Instead of modifying the existing 'Wait'/'WaitExten'/'WaitMusicOnHold' apps, just create a new one 'SWait' [short for super wait].

Call it like this:
SWait([timeout][cim])

'c' => continue instead of 'goto(t,1)'
'i' => ignore dtmf input while waiting
'm' => play music on hold while waiting

Combine these and you can create just about any version of the afformentioned apps [plus a new one 'WaitExtenMusicOnHold' :)], all from one app.  Have fun, please test and let me know.

edited on: 11-22-04 16:45

By: Mark Spencer (markster) 2004-11-22 17:42:12.000-0600

I just convinced myself that there would be no instance where you'd do WaitExten and then have something immediately after it, so I just made it so WaitExten continues *if* there is a step n+1 and if not, goes to 't'.  Seemed really easy.

By: Christopher L. Wade (clwade) 2004-11-23 08:56:26.000-0600

I disagree that no-one will ever have a reason for having something immediately following a WaitExten.  I use WaitExten (SWait now) in the middle of all of my menus for things like pauses between langauge switches.  I also use WaitExten in my IVR's because I have autofallthrough=yes (don't use the 'c' option here on most, but do on a few').

I use WaitExten so DTMF is processed and I can adjust the delay down to the ms, something that a background(silence/1) can't do without editing the sound file itself.

[*puts on flame retardent suit*]
Mark, I understand you have a reason for having said what you said, however, just because you cannot come up with a reason for having the option, doesn't mean someone else won't.  Your statement is the EXACT reason I submitted the patch.  I use WaitExten exactly like you said nobody ever would.

I initially wanted the continue functionality to be an option (instead of the default) so that WaitExten's behavior won't change in situations where, for example, there are multiple paths of logic not seperated numerically (easy thanks to the 'n' priority and labels).  Your method would now break that logic.  I admit I haven't used WaitExten like this, but I can imagine others *might*.

[whole essay on closing bugs without asking the OP if this new patch resolved their issue or not - deleted because most people would die of old age reading it]

edited on: 11-23-04 08:57

By: Christopher L. Wade (clwade) 2004-11-23 09:26:36.000-0600

Here's a somewhat ridiculous example usage of WaitExten with the 'c' option.  You could implement this using the 't' extension, but you shouldn't have to.

exten => s,1,Answer
exten => s,n,Background(we-are-about-to-start-recording)
exten => s,n,Background(we-are-going-to-give-you-a-breif-pause-to-get-ready)
exten => s,n,Background(then-we-will-start)
exten => s,n,WaitExten(5c)
exten => s,n(record),Record(recording.gsm)
exten => s,n,Playback(thank-you)
exten => s,n,Hangup

exten => _.,1,Goto(s,record)

This example allows you to press a button (at any moment, even during prompts) if you are already prepared to start recording, otherwise, you get five seconds of prep time and then you start recording.  You could replace WaitExten(5c) with Background(silence/5), but what if you decided that 5 needed to be 25 or 24.5 or even 0.5, you would have to edit the silence sound files to create one of that size.

I realize there are other ways to skin this cat, but I want to skin it this way, why can't * accomidate that?  The 'c' option makes WaitExten work the same way it always has for everybody else, it just allows those other people (me included) to use it in the way listed above.

By the way, please look at SWait, it takes all of this discussion and pretty much just throws it away.  Have the SWait app, tell it how it work from the dialplan, and go, forget whether WaitExten is going to do the right thing or not, you've just told SWait EXACTLY what to do.

My $0.05. yeah a nickel, i'm feeling generous this morning. :)

By: Mark Spencer (markster) 2004-11-23 09:31:15.000-0600

I think the way I implemented it is easier to understand and I'll deal with the "if they happen to be numerically in order" people if they show up.  I really doubt people would have a dialplan like that.  I just think the default should be to continue if there is such a priority and if not to go to timeout.

When I think a problem is essentially resolved, I close it.  You can always reopen it if it's not the case.

By: Russell Bryant (russell) 2004-11-25 10:00:47.000-0600

not in 1.0