asterisk users - Oct 2008 - Matching *, + and # in the dialplan

In several places online, and in the Asterisk F.O.T. book, there is a
warning against using '_.' saying: 
"[it] should probably never be used".

However, the need often arises act on numeric extensions that begin with
*'s and #'s, and '+', and of course _X. does not match 

I have tried  exten => _[0-9*#+]. but that seems to be the functional
equivalent to _X. ignoring the addition of +,* and #.

Can someone suggest the best way to deal with this without resoring to a
highly repetitive/iterative dialplan?

Thanks in advance!

-Karl

On Monday 06 October 2008 14:58:09 Karl Fife wrote:
> In several places online, and in the Asterisk F.O.T. book, there is a
> warning against using '_.' saying:
> "[it] should probably never be used".
>
> However, the need often arises act on numeric extensions that begin with
> *'s and #'s, and '+', and of course _X. does not match
>
> I have tried  exten => _[0-9*#+]. but that seems to be the functional
> equivalent to _X. ignoring the addition of +,* and #.
>
> Can someone suggest the best way to deal with this without resoring to a
> highly repetitive/iterative dialplan?
Leif and I discussed something like this at Astricon 2008, and we came up with
this patch:
http://bugs.digium.com/view.php?id=13632

-- 
Tilghman

Tilghman Lesher wrote:
>> Can someone suggest the best way to deal with this without resoring to
a
>> highly repetitive/iterative dialplan?
>>     
> Leif and I discussed something like this at Astricon 2008, and we came up
with
> this patch:
> http://bugs.digium.com/view.php?id=13632
Nice!  For those of us still using the old dialplan code versus AEL, 
this could potentially make the readability of extensions.conf much easier!

Are there any plans to include this in a future release of Asterisk?

On Wednesday 08 October 2008 02:20:38 Rob Hillis wrote:
> Tilghman Lesher wrote:
> >> Can someone suggest the best way to deal with this without
resoring to a
> >> highly repetitive/iterative dialplan?
> >
> > Leif and I discussed something like this at Astricon 2008, and we came
up
> > with this patch:
> > http://bugs.digium.com/view.php?id=13632
>
> Nice!  For those of us still using the old dialplan code versus AEL,
> this could potentially make the readability of extensions.conf much easier!
>
> Are there any plans to include this in a future release of Asterisk?
Since 1.6.1 is already feature-frozen, it could potentially make its way into
1.6.2, once it makes its way through initial testing.  You can help its way
along this path by testing the patch and giving feedback on the issue.

-- 
Tilghman

I have to eat crow here guys.  I was completely wrong about the use of
dialplan wildcards and non numerics such as *,# and +.
My test was invalid and I drew the wrong conclusion.  So to summarize:

A single dialplan extension that matches
'3129842314' or
'*989' or
'+13129842314'
BUT NOT 
'i' nor
'h' nor 
'james'
is in fact simply something like:

exten => _[0-9*#+]X.,1,NoOp(*** match ***)

-Karl

On Thursday 16 October 2008 10:46:51 Olivier wrote:
> Is Incomplete() application an acceptable work around for ISN ?
If you could explain what ISN is, that might help.

-- 
Tilghman

On Thu, 16 Oct 2008 11:47:15 -0500, "Tilghman Lesher"
<tilghman at mail.jeffandtilghman.com> said:
> 
> If you could explain what ISN is, that might help.
an ISN, stands for ITAD Subscriber Number, which in turn stands for
'Internet Telephony Administrative Domain Subscriber Number'. 
Essentially it is a very clever way of resolving numeric strings (easily
be entered on a twelve-key numeric keypad) to full SIP uri's. 

for example 1234 at sip.ucla.edu would be hard to enter on a telephone
keypad.  ISN (available through Freenum.org) offers a solution.  

sip.ucla.edu is assigned the resolvable numeric string '269'.  The
extension '1234' is already numeric.  The @ sign in the SIP uri is
replaced by *.  

1234*296 is dialed on the keypad, which resolves to 1234 at sip.ucla.edu. 
The call is completed bypassing the PSTN. 

Back to the main idea:

The ISN is unambiguous.  There are no other dial strings that have a
single * somewhere between position 2 and length-3

It seems silly and kludgey to have to use an ISN prefix to recognize the
ISN, so that it can be sent to the resolver, so that it can be routed,
but I suspect that there's no way to differentiate that format with the
parser as it currently functions.

-Karl

2008/10/17 John Todd <jtodd at digium.com>
> At 5:46 PM +0200 2008/10/16, Olivier wrote:
> >
> >Is Incomplete() application an acceptable work around for ISN ?
> >
>
> It is impossible to determine the full sequence of digits for an ISN
> number ahead of time (well, I shouldn't say "impossible"
because one
> could create a really nasty hack...) because the number of digits
> isn't known until the user indicates they are done dialing.  To
> determine if the subscriber and/or the ITAD are valid, one must
> perform a lookup and possibly a connection attempt to the remote
> system for determination.
>
> Both the subscriber number (the stuff to the left of the "*") and
the
> ITAD number (the stuff to the right of the "*") are not bounded
by a
> particular pattern.  Therefore, it is not reasonable to create
> regexps other than "does this string contain at least one but maybe
> more digits, followed by the "*" sign, followed by at least one
but
> maybe more digits".
>
> So, 1234*256 is a valid ISN sequence, as is 12345*2567.  (Though only
> the first one of the two is actually active at the moment.)
>
> See http://www.freenum.org/ for more details on what makes up an ISN.
> It's free to participate, and Asterisk incorporates ISN-style dialing
> as a default in the ENUMLOOKUP routines.  Accepting inbound calls is
> easy as well - it's just SIP inbound calling, no magic there.
>
> JT

Writing this :

exten => _XXX*,1,Incomplete()
exten => _XXXX*,1,Incomplete()
exten => _XXXXX*,1,Incomplete()

would work to catch 3 to 5 digits private extensions, but it would remains
difficult to catch the ITAD number, right ?


>
>
> --
> John Todd
> jtodd at digium.com        +1-256-428-6083
> Asterisk Open Source Community Director
>
> _______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20081017/23846b66/attachment.htm