Is it me?

[UKenGB]

I am testing a dial plan and becoming increasingly unable to fathom the matching logic. As an example:-

 

xx[2345678] matches 358 as it should, but not 359. Again, correct.

 

But

 

[2345678]xx does NOT match 358 which it obviously should.

 

Can someone explain what's going on here?

 

Also, where is the full explanation of Regular Expression Matching? Since this can vary between implementations, it would be good to have an exact description of how it works in snomONE. I'd like to know what I can and cannot expect to work. E.g. [^8] should match anything except 8 in 'most' regex, but doesn't work in snomONE. I can work with such differences, but would appreciate some documentation to explain this, rather than make me simply test everything to see if it works.

[Vodia PBX]

I believe that the automatic detection of extended regular expressions is the problem here. xx[2345678] is not a simple expression, that is why the PBX switches to complex mode. The expression is a valid ERE expression, and it says two digits followed by 2-8, ANYWHERE in the string. The input is in the format user@domain.

 

Maybe you wanted to use this one: ^([0-9][0-9][2-8])@.*

[UKenGB]

I believe that the automatic detection of extended regular expressions is the problem here. xx[2345678] is not a simple expression, that is why the PBX switches to complex mode. The expression is a valid ERE expression, and it says two digits followed by 2-8, ANYWHERE in the string. The input is in the format user@domain.

 

Maybe you wanted to use this one: ^([0-9][0-9][2-8])@.*

Isn't there some way to force the PBX to use ERE or not? If we don't have this control, it makes configuration that much more complex since we have to always guess at how the PBX will actually interpret the pattern. Hardly ideal.

 

You say the input format is user@domain. Can you explain this. As far as I am concerned, the user enters a number on the telephone keypad and I want to control how that number is maybe modified and then used. I assumed any SIP stuff was added later. Are you saying that after the number is entered, the SIP stuff is added and THEN it is matched to the dial plan?

 

Is there somewhere a full and complete and accurate explanation of dial plan operation that I can access and read? What I have found so far is woefully inadequate at explaining it all, meaning I have to keep asking. I can deal with Regular Expressions if I have all the details. Right now I feel I'm blundering around in the dark with no documentation to enable me to see the light.

[pbx support]

Did the above mentioned pattern work for you?

[Vodia PBX]

There is still the good old "kiwi" available at http://kiwi.pbxnsip.com/index.php/Domain_dial-plans, take a look.

[UKenGB]

Did the above mentioned pattern work for you?

No idea as it doesn't do what I actually need.

 

I have several problems with this. The first is that if you use square brackets and 'x's in the same pattern, it only works when the square bracket expression is at the end, but NOT the other way around. This would appear to be contrary to any sensible pattern matching algorithm.

 

Here's what I want to do: match any 6 digit number that begins with 2,3,4,5,6,7 or 8. In the end I used "^[2-8][0-9]{5}@" which works as I have forced it to used ERE rather than it being just a simple expression and I figured for myself that the SIP stuff IS added prior to attempting matching.

 

None of this is rocket science, but when coming to it anew, decent documentation is essential. There are so many omissions and errors in all the snomONE docs I've seen it's not funny.

 

Anyway, now I have a better understanding of how snomONE does its pattern matching and I ought to be able to achieve what I need to do with dial plans.

 

However, here's an idea. Cascading Dial Plans. IOW an extension can specify several dial plans which run in the specified order. In this way, you could have a standard dial plan that was used by several extensions for some basic matching, then if that 'fails' it rolls over to the next dial plan which is maybe specific to that particular extension. This makes it easier to plan and maintain as any modifications to the common dial plan are instantly implemented for ALL extensions that use it. Currently, if you have a lot of similar matching in many dial plans used by many extensions, if you need to modify any of the basic initial matching, having established what needs to be done, you then need to update each and every dial plan that uses those same patterns.

 

I like this more object oriented approach with maximum re-use of 'code'.

[Vodia PBX]

You can at least use the text-form for the dial plan to speed things up. It is not cascading, but at least if you have a lot of dial plans, it does speed things up.