[asterisk-dev] PREDIGITS for WaitExten

[Timo Teräs]

Tilghman Lesher wrote:
> On Tuesday 01 April 2008 09:55:29 Timo Teräs wrote:
>> This would not work. WaitExten does not take context.
> 
> Oh, sorry.  But you can do something very similar...
> ...
> exten => _123!,n,Goto(getmoredigits,s,1)
> 
> [getmoredigits]
> exten => s,1,WaitExten(10)
> exten => _X!,1,Goto(${origcontext},${PREDIGITS}${EXTEN},1)
> exten => t,1,Goto(${origcontext},i,1)
> 
> Same idea, different code.  This will continue until your original context
> decides that the extension is complete or invalid.

Yes, I got the same idea after a while on yesterday. I'll try it out.

>> It's way cleaner to get WaitExten accept PREDIGITS. Or alternatively I
>> could write a new application that basically is
>> WaitAdditionalDigitsForExten that would wait for additional digits until
>> another extension matches or timeout comes.
> 
> I really don't think WaitExten needs to be altered in that way.
> 
>> The point is that in above example. If PBX first sent '123' it would
>> go to WaitExten. Then when additional (overlapped) digit of '1' would come
>> it would immediate match the _123[1-9]! rule and dial out. Or if the
>> overlapped digit was '0' it would wait for more digits and getting another
>> two of '0's would then match 123000. And the same rules would also work
>> if in the first place was received a full number like "1239321" or
>> "123000".
>>
>> So I would want to make _123! act as if it is known that _123 is a known
>> prefix, but it needs more digits to make a routing decision.
> 
> The way I would implement this is as an application which returned a special
> value to indicate that the extension was not yet complete and the pbx routines
> in main/pbx.c should continue waiting for more digits.  Currently, the only
> valid return values are -1, 0, '*', '#', and '0' through '9'.  Perhaps you
> could return 128 (specifically chosen, since it's the first positive integer
> after the full set of ASCII) to indicate that the extension is incomplete and
> needs more digits.

Now that I think about, a new application would make more sense. Or a flag
to WaitExten that makes it return the special value.

But if the above thingy works as expected I'm not sure if this is needed.
Adding this feature would make the dial plan more readable though.

>> Sort of what chan_zap does when overlapdial=yes and immediate=no. But it
>> should also work when the call is coming from IAX (or any other) context.
>>
>>>> I have a rough patch for this (I didn't test it), but it gives a general
>>>> idea what is needed to achieve this. If you think this would be
>>>> acceptable, I can make tested patch against 1.6 branch and/or trunk (and
>>>> sign the license stuff + send the patch to bugs db).
>>> I can't look at your patch until it's posted on the bugtracker, with the
>>> appropriate contributor license filed.
>> Ok. I'll test it a bit, maybe polish it and send it on bugtracker. I signed
>> the license earlier today.
> 
> Looking forward to seeing it.

I'll figure out if I need to change anything after all. I'll file a bug with
a patch if I come up with some code.

Thanks,
  Timo