[asterisk-dev] Regression: dash a not a character any more?

[Richard Mudgett]

On Tue, Jan 17, 2017 at 3:40 PM, Kirill Katsnelson <kkm at smartaction.com>
wrote:

> On 170117 1232, Richard Mudgett wrote:
>
>> On Tue, Jan 17, 2017 at 2:03 PM, Kirill Katsnelson <kkm at smartaction.com>
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170117/29021591/attachment.html>