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

[Kirill Katsnelson]

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/asterisk/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.

  -kkm