Details

    • Type: New Feature New Feature
    • Status: Closed
    • Severity: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Target Release Version/s: None
    • Component/s: Core/General
    • Labels:
      None
    • Mantis ID:
      2894
    • Regression:
      No

      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.

        Activity

        Hide
        Mark Spencer added a comment -

        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.

        Show
        Mark Spencer added a comment - 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.
        Hide
        Christopher L. Wade added a comment -

        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

        Show
        Christopher L. Wade added a comment - 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
        Hide
        Christopher L. Wade added a comment -

        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.

        Show
        Christopher L. Wade added a comment - 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.
        Hide
        Mark Spencer added a comment -

        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.

        Show
        Mark Spencer added a comment - 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.
        Hide
        Russell Bryant added a comment -

        not in 1.0

        Show
        Russell Bryant added a comment - not in 1.0

          People

          • Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development