[asterisk-dev] dialplan redesign - don't forget characters (New topic)

[Olle E Johansson]

22 nov 2007 kl. 20.21 skrev Steve Murphy:

> On Wed, 2007-11-21 at 11:09 +0100, Olle E Johansson wrote:
>> 21 nov 2007 kl. 10.01 skrev Luigi Rizzo:
>>
>>> On Wed, Nov 21, 2007 at 09:28:55AM +0100, Olle E Johansson wrote:
>>>>>
>>>>> Really, this is not an area where you can afford playing and  
>>>>> putting
>>>>> in
>>>>> small patches to see how they fix one or the other problem.
>>>>> The correctness of extension matching is something that people
>>>>> really must rely on, because in the end it is directly involved
>>>>> with security, billing and so on.
>>>>>
>>>> One thing that has to be considered as well if we redesign is
>>>> alphanumeric
>>>
>>> There is nothing preventing alphanumeric extensions at least in the
>>> old matching algorithm - the only annoyance is the need to 'escape'
>>> some characters ( _ N Z X / come to mind ) as [N] [Z] etc.  to
>>> override their special meaning on asterisk patterns.
>> Well, you can't properly match Östertälje at myasterisk.com today.
>> Or give ranges like [A-Ö]xp[0-3]
>>
>>> But then, this is trivial to overcome by providing an alternative
>>> syntax for extensions (and supporting both in parallel is easy)
>>> and besides all regexp implementations have their own special
>>> characters.
>> That was our proposal. Let's find a URL so you can check it.
>> http://edvina.net/asterisk/alphanumericextensions.pdf
>>
>> May 2005 :-)
>>
>> TTT - Things Take Time...
>>
>> /O
>
> Olle-- thanks for the ref to this doc. If we agree that the  
> extensions.*
> file is in utf-8 format, I think it would not be that hard to switch  
> the
> internals to use unicode internally instead of ascii. I just need some
> good free routines to convert from utf-8 to unicode chars, and some
> simple comparison functions that work on unicode arrays instead of  
> just
> 8-bit ascii/8859 stuff. I don't think we need to resort to a new  
> config
> file variable like alphaexten; it should be pretty upwards compatible.
> -- I haven't read it thru carefully yet, but that's my gut reaction.

The issue then is that alphaexten treats the at sign (@) as a valid  
character,
normal extensions doesn't. This is requiered to fully handle proper
SIP and IAX2 URI's.

Comparing two unicode strings is not a piece of cake either. libiconv
is the library people often use, so check into that. Upper/lower case
issues get much worse, too. In order to preserve backwards  
compatibility,
which has been a guideline, Leif and I thought that implementing
another type of extension would be the simplest way forward.

Thanks for the positive feedback!

/O