On Tue, Jan 17, 2017 at 3:40 PM, Kirill Katsnelson <[email protected]> wrote:
> On 170117 1232, Richard Mudgett wrote: > >> On Tue, Jan 17, 2017 at 2:03 PM, Kirill Katsnelson <[email protected]> >> wrote: >> >> A change from 1.8 to 13 broke us in some other aspect, and I am trying to >>> figure out whether this is a bug or things work as expected. In short, >>> the >>> '-' character is converted to nothing in extension "numbers" >>> >>> Here's a snippet that demonstrates the problem: >>> >>> extension.ael: >>> >>> context test { >>> foobar => Hangup(); >>> foo-bar => Play(foo-bar); >>> } >>> >>> *CLI> ael reload >>> [2017-01-17 11:45:47.688] WARNING[57864]: pbx.c:6987 add_priority: Unable >>> to register extension 'foo-bar' priority 1 in 'test', already in use by >>> aliased extension 'foobar' >>> *CLI> dialplan show test >>> [ Context 'test' created by 'pbx_ael' ] >>> 'foobar' => 1. Hangup() >>> [pbx_ael] >>> >>> -= 1 extension (1 priority) in 1 context. =- >>> >>> "dialplan debug" shows the '-' is not in the trie trace at all. >>> >>> In 1.8, ael reloads completes without a warning, and >>> >>> *CLI> dialplan show test >>> [ Context 'test' created by 'pbx_ael' ] >>> 'foo-bar' => 1. Play(foo-bar) >>> [pbx_ael] >>> 'foobar' => 1. Hangup() >>> [pbx_ael] >>> >>> -= 2 extensions (2 priorities) in 1 context. =- >>> >>> Was the change intentional? Will you accept a patch that reintroduces the >>> old behavior (with an option perhaps?). The '-' is so deeply embedded >>> into >>> all our Asterisk infrastructure (autogenerated files, AMI controllers >>> etc.) >>> that it is not realistic at this point to attempt to change the separator >>> character. >>> >>> >> The '-' dash has always been eye-candy and means nothing when matching >> extensions. >> Otherwise you would not be able to dial something like 18005551212 if you >> had this as an exten: >> >> exten = 1-800-555-1212,1,NoOp() >> same = n,Playback(tt-weasels) >> same = n,Hangup() >> >> Inconsistencies in the treatment of '-' were intentionally removed so >> extensions will always match. >> > > Thanks, interesting. It worked for us somehow, but possibly for a wrong > reason then! > > I see where the change is coming from: https://github.com/asterisk/as > terisk/commit/7f0bfe536fdf3856dfbaf7303f5af28dad88e78e; ASTERISK-19205 > really highlights a lot of past inconsistencies. So it's a good thing it > was fixed, only a bad thing is that broke our code... > > Is it documented anywhere what characters are considered legal in an > extension name, and what are reserved? Perhaps we should bite the bullet > and replace the separating symbol with something else; wondering what > characters would be safe then. I don't think there is an explicit list of what characters are reserved. You could use '_' underbar instead of '-' dash except as the first character where it indicates the extension is a pattern [1]. It depends upon if your extensions normally are numeric or alpha-numeric. exten = foo_bar,1,NoOp() exten = bar_none,1,NoOp() Beware of alpha-numeric extension names in a pattern: exten =_bar_none,1,NoOp() The above extension does not match what you may think because of the two n's in the extension. The 'n' represents a character set of '2' through '9'. See [1]. If you really want the n's in the extension you have to do this: exten = _bar_[n]o[n]e,1,NoOp() Richard [1] https://wiki.asterisk.org/wiki/display/AST/Pattern+Matching [2] https://wiki.asterisk.org/wiki/display/AST/Contexts%2C+Extensions%2C+and+Priorities
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
