Re: [asterisk-users] Matching *, + and # in the dialplan
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 -- John Todd [EMAIL PROTECTED]+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
Re: [asterisk-users] Matching *, + and # in the dialplan
2008/10/17 John Todd [EMAIL PROTECTED] 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 = _*,1,Incomplete() exten = _X*,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 [EMAIL PROTECTED]+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 ___ -- 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
Re: [asterisk-users] Matching *, + and # in the dialplan
On Friday 17 October 2008 10:15:22 Olivier wrote:
2008/10/17 John Todd [EMAIL PROTECTED]
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 = _*,1,Incomplete()
exten = _X*,1,Incomplete()
would work to catch 3 to 5 digits private extensions, but it would remains
difficult to catch the ITAD number, right ?
There's no need to do anything like that. You're not seeing the
possibilities:
exten = _X.,1,Set(main=${CUT(EXTEN,*,1)})
exten = _X.,n,Set(itad=${CUT(EXTEN,*,2)})
exten = _X.,n,GotoIf($[${itad}=]?incomplete) ; or some other test
exten = _X.,n,Dial(...)
exten = _X.,n+1000(incomplete),Incomplete()
--
Tilghman
___
-- 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
Re: [asterisk-users] Matching *, + and # in the dialplan
Is Incomplete() application an acceptable work around for ISN ? ___ -- 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
Re: [asterisk-users] Matching *, + and # in the dialplan
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 ___ -- 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
Re: [asterisk-users] Matching *, + and # in the dialplan
On Thu, 16 Oct 2008 11:47:15 -0500, Tilghman Lesher [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 ___ -- 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
Re: [asterisk-users] Matching *, + and # in the dialplan
On Thu, 2008-10-16 at 13:59 -0500, Karl Fife wrote:
On Thu, 16 Oct 2008 11:47:15 -0500, Tilghman Lesher
[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
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.
Since our pattern matching algorithms can't do trailing context,
then you can't do something simple like the RE X+\*X+ where X= [0-9],
but you can do:
X[*]XX.{Set(num=${EXTEN:0:1}; Set(isn=${EXTEN:2};
Dial(...); }
XX[*]XX. {Set(num=${EXTEN:0:2}; Set(isn=${EXTEN:3};
Dial(...); }
XXX[*]XX. {Set(num=${EXTEN:0:3}; Set(isn=${EXTEN:4};
Dial(...); }
[*]XX. {Set(num=${EXTEN:0:4}; Set(isn=${EXTEN:5};
Dial(...); }
X[*]XX.{Set(num=${EXTEN:0:5}; Set(isn=${EXTEN:6};
Dial(...); }
XX[*]XX. {Set(num=${EXTEN:0:6}; Set(isn=${EXTEN:7};
Dial(...); }
XXX[*]XX. {Set(num=${EXTEN:0:7}; Set(isn=${EXTEN:8};
Dial(...); }
[*]XX. {Set(num=${EXTEN:0:8}; Set(isn=${EXTEN:9};
Dial(...); }
X[*]XX.{Set(num=${EXTEN:0:9}; Set(isn=${EXTEN:10};
Dial(...); }
XX[*]XX. {Set(num=${EXTEN:0:10}; Set(isn=${EXTEN:11};
Dial(...); }
XXX[*]XX. {Set(num=${EXTEN:0:11}; Set(isn=${EXTEN:12};
Dial(...); }
(I hope I have my numbers right!)
OR, you could use: ReadExten or WaitExten, maybe, depending on how they
react to *, which might collide with a def in features.conf, or
where-ever the
features like # (xfer) are defined.
The above might seem dorky, but, it's not that bad. Some folks define
their dialplans with thousands of numbers, and nobody thinks anything of
it!
murf
--
Steve Murphy
Software Developer
Digium
smime.p7s
Description: S/MIME cryptographic signature
___
-- 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
Re: [asterisk-users] Matching *, + and # in the dialplan
On Thursday 16 October 2008 13:59:46 Karl Fife wrote: On Thu, 16 Oct 2008 11:47:15 -0500, Tilghman Lesher [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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. In that case, yes, the Incomplete app could be used for that purpose. -- Tilghman ___ -- 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
Re: [asterisk-users] Matching *, + and # in the dialplan
On Tue, 2008-10-14 at 19:59 -0500, Karl Fife wrote: QUESTION: Is there a way to do just that? As in: match: one more of the preceding character or expression (a variation on '.') zero more of the preceding character or expression (a variation on bang) No, there's currently nothing in the Asterisk pattern matching syntax to constrain one digit to be related in any fashion to the preceding digit. -- Jared Smith Training Manager Digium, Inc. ___ -- 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
Re: [asterisk-users] Matching *, + and # in the dialplan
On Wed, 2008-10-15 at 09:06 -0400, Jared Smith wrote:
On Tue, 2008-10-14 at 19:59 -0500, Karl Fife wrote:
QUESTION: Is there a way to do just that? As in: match:
one more of the preceding character or expression (a variation on '.')
zero more of the preceding character or expression (a variation on bang)
No, there's currently nothing in the Asterisk pattern matching syntax to
constrain one digit to be related in any fashion to the preceding digit.
Jared is correct.
What you really want is the RE *, +, and maybe even () features.
Not to mention '?'...
Some RE features would be easy to implement in the trie, but
the real killer is trailing context... for instance...
XX[58]*ZZ
If you give it the pattern 3358, it has to decide that
the [58]* part is empty and the 58 is matched by ZZ.
And this makes the whole algorithm pretty hairy.
The current notation lends itself to a fast left-to-right
evaluation, without multiple recursive attempts to find
a path that would lead to a match.
But, if you are willing to forego trailing context,
and make it so any *,+, {x,z}, or ? is at the end of an expression,
like . is now, this could be implemented fairly straightforwardly in our
current pattern matchers.
See my previous conversations in the dev mailing list, back in aug
2007...
let's see:
http://lists.digium.com/pipermail/asterisk-dev/2007-August/028844.html
http://lists.digium.com/pipermail/asterisk-dev/2007-August/028846.html
http://lists.digium.com/pipermail/asterisk-dev/2007-August/028858.html
murf
--
Steve Murphy
Software Developer
Digium
smime.p7s
Description: S/MIME cryptographic signature
___
-- 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
Re: [asterisk-users] Matching *, + and # in the dialplan
On Wed, 15 Oct 2008 14:22:09 -0600, Steve Murphy [EMAIL PROTECTED]
said:
the real killer is trailing context... for instance...
XX[58]*ZZ
If you give it the pattern 3358, it has to decide that
the [58]* part is empty and the 58 is matched by ZZ.
And this makes the whole algorithm pretty hairy.
The current notation lends itself to a fast left-to-right
evaluation, without multiple recursive attempts to find
a path that would lead to a match.
But, if you are willing to forego trailing context,
and make it so any *,+, {x,z}, or ? is at the end of an expression,
like . is now, this could be implemented fairly straightforwardly in our
current pattern matchers.
So how would one route calls differently if they're ISN formatted i.e.
'6565*696'. I can't get my head around any way to do that using the
existing rules.
Freenum.org suggests an ISN Prefix such as _012. to disambiguate ISN's
this is a total kludge because ISN-formatted numbers are already
perfectly unambiguous (not to mention the obvious limitation that
DIALING an ISN from a given system would first involve an query to the
admin).
The obvious problem is that the disambiguating character is located
anywhere between the second and fourth-from-last character. (one or more
digits followed by *, followed by three or more digits). Cursed
trailing contexts!
The only thing I can think of is to categorically exclude it from all
other possiblities: for example:
_NXX local number
_1NXXNXX non-local number
_011XX. international
_*XX supplemental service codes
_+XX. international
_X. ISN ???
...if that would even work.
Is there a better way to do this?
Is how 'expensive' would it be to disambiguate based on the unique
characteristics of an ISN?
It seems like there should be a inexpensive, non-recursive, one-pass way
to do it, but without getting my head inside the parser like Steve
has...
Thanks!
-Karl
___
-- 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
Re: [asterisk-users] Matching *, + and # in the dialplan
Steve Murphy [EMAIL PROTECTED] writes: Other than the above, we could invent a slightly different syntax for pcre type expressions; and you'd have to invent some sort of disambiguation for when multiple extensions might be matched, to choose the 'best' one. I'd just use strict ordering from the file. It would make my life a lot easier if Asterisk could do that. I'm constantly adding dummy contexts that I can include so that Asterisk gets the order right. You'd have to forever stick with the 'check against every extension in the context for the best one' sort of algorithm, which is OK when the extension list is fairly short, but if you end up with more than 100 or so extensions in a context, you'd best go with the fast pattern matcher if you have to/want to deal with heavy call loads. You can turn the RE's into a finite state machine. Implementing it would be a lot of fun actually, I wish I had the time. /Benny ___ -- 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
Re: [asterisk-users] Matching *, + and # in the dialplan
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 ___ -- 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
Re: [asterisk-users] Matching *, + and # in the dialplan
Karl Fife [EMAIL PROTECTED] writes: is in fact simply something like: exten = _[0-9*#+]X.,1,NoOp(*** match ***) As long as you're happy to match *9foo and not match **123, then yes, that will work. /Benny ___ -- 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
Re: [asterisk-users] Matching *, + and # in the dialplan
On Wed, 15 Oct 2008 01:54:40 +0200, Benny Amorsen [EMAIL PROTECTED] said: Karl Fife [EMAIL PROTECTED] writes: is in fact simply something like: exten = _[0-9*#+]X.,1,NoOp(*** match ***) As long as you're happy to match *9foo and not match **123, then yes, that will work. Thanks Benny. Please correct me if I'm wrong but I think that _[0-9*#+]X. would match *9foo but not **123 because of the 'X 'after the '[0-9*#+]' however you bring up a good point, which is that . means one or more of ANYTHING including alpha etc (and not one or more of the preceding character or expression as would '*' in a regex). QUESTION: Is there a way to do just that? As in: match: one more of the preceding character or expression (a variation on '.') zero more of the preceding character or expression (a variation on bang) Thanks! -Karl ___ -- 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
Re: [asterisk-users] Matching *, + and # in the dialplan
On Sat, 2008-10-11 at 10:09 +0200, Benny Amorsen wrote: Tilghman Lesher [EMAIL PROTECTED] writes: exten = [0-9*#+].,... If that does not work, that is a bug and needs to be reported as such. Sadly that matches *james and 9foo... It would be nice if you could use normal regexes (e.g. with the pcre library) in extensions.conf. Full RE's are not really a good choice for extension pattern matching in the asterisk environment. People have voiced this before; but the cut-down version of RE's that the matching algorithms allow are fairly fast, both in the new and the old pattern matching algorithms. Using pcre would not be good in the dialplan. It would cut the speed of matching an extension to a fraction of what is now. It would be incompatible with the current dialplan algorithms, so you'd have to use some sort of alternate syntax. I've written at length why we use the algorithm we use now, and why pcre type implementations might seem nice, but they preclude using the current matching algorithms. Look around in the dev list archives over the last 2 years from me... Other than the above, we could invent a slightly different syntax for pcre type expressions; and you'd have to invent some sort of disambiguation for when multiple extensions might be matched, to choose the 'best' one. You'd have to forever stick with the 'check against every extension in the context for the best one' sort of algorithm, which is OK when the extension list is fairly short, but if you end up with more than 100 or so extensions in a context, you'd best go with the fast pattern matcher if you have to/want to deal with heavy call loads. I've previously offered to expand the current pattern matchers to include some useful notation available in RE's. Some constructs could be done in the current regime, but depending on which ones, will complicate the current algorithms, but are possible. Some RE features are simply incompatible with the current algorithms. murf /Benny -- Steve Murphy Software Developer Digium smime.p7s Description: S/MIME cryptographic signature ___ -- 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
Re: [asterisk-users] Matching *, + and # in the dialplan
Steve Murphy [EMAIL PROTECTED] wrote: People have voiced this before; but the cut-down version of RE's that the matching algorithms allow are fairly fast, both in the new and the old pattern matching algorithms. Steve Your explanation is clear and it seems like a good design choice to exclude support for regular expressions, but what seems odd (maybe a bug in fact) is the specific exclusion of characters +, # and *. It sounds like you're saying: exten = [0-9*#+].,... is invalid, therefore not a bug, and that only numeric parameters such as: exten = [0-6].,... would be valid. If this is correct could you please explain the proper way to match any extension beginning with + such as '+13129842314' without also matching: 'i' Thanks for your input Steve! -Karl What extension the following: '3129842314' '*989' '+13129842314' BUT does not match: 'i' 'james' I'd like to see a wildchard character that matches Can support for those characters be added without ___ -- 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
Re: [asterisk-users] Matching *, + and # in the dialplan
exten = +13129842314,1,Noop(Happy match!) or exten = _+1NXXNXX,1,Noop(Happier match!) Karl Fife wrote: Steve Murphy [EMAIL PROTECTED] wrote: People have voiced this before; but the cut-down version of RE's that the matching algorithms allow are fairly fast, both in the new and the old pattern matching algorithms. Steve Your explanation is clear and it seems like a good design choice to exclude support for regular expressions, but what seems odd (maybe a bug in fact) is the specific exclusion of characters +, # and *. It sounds like you're saying: exten = [0-9*#+].,... is invalid, therefore not a bug, and that only numeric parameters such as: exten = [0-6].,... would be valid. If this is correct could you please explain the proper way to match any extension beginning with + such as '+13129842314' without also matching: -- Consulting and design services for LAN, WAN, voice and data. Based near Birmingham, AL. Now accepting clients worldwide. Contact me for Tellabs echo canceling systems. Also see http://www.fnords.org/skillslist.html ___ -- 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
Re: [asterisk-users] Matching *, + and # in the dialplan
Tilghman Lesher [EMAIL PROTECTED] writes: exten = [0-9*#+].,... If that does not work, that is a bug and needs to be reported as such. Sadly that matches *james and 9foo... It would be nice if you could use normal regexes (e.g. with the pcre library) in extensions.conf. /Benny ___ -- 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
Re: [asterisk-users] Matching *, + and # in the dialplan
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? ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Matching *, + and # in the dialplan
On Tuesday 07 October 2008 21:58:31 Karl Fife wrote: So that leaves only one question: exten = ? What extension the following: '3129842314' '*989' '+13129842314' BUT does not match: 'i' 'james' is this possible? I think you already described it in your original post: exten = [0-9*#+].,... If that does not work, that is a bug and needs to be reported as such. -- Tilghman ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Matching *, + and # in the dialplan
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 ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Matching *, + and # in the dialplan
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 ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Matching *, + and # in the 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 That's a great idea. Good work. Also, nice work with the new CDR stuff in 1.6! So that leaves only one question: exten = ? What extension the following: '3129842314' '*989' '+13129842314' BUT does not match: 'i' 'james' is this possible? Thanks for your input! -Karl ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] 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 ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
