Jump to content

Dial plans driving my crazy


Recommended Posts

Hi everyone, hopefully someone can help me make head or tail of what's going on.... and before anyone says, I've already been through https://doc.vodia.com/domain_dialplans and I find it very lacking and inaccurate.

So I have a dial plan with pattern *, with the replacement field empty - this works fine. I dial 07299999999 and the call routes to the telco as 07299999999 and the call is successful. However I don't want a wildcard pattern.

So I try changing the pattern to 07* - to allow calls to numbers beginning 07. I leave the replacement field empty - which according to  https://doc.vodia.com/domain_dialplans  "If the replacement field is empty, then the dialed number is not touched as it is sent to the set trunk."

However, the call gets passed to telco as 0099999999 - so much for not touching the number...??? And obviously the call fails. For some reason, the PBX is prepending 00 and stripping 072 (or prepending 0 and stripping 72). Why?

I've tried adding * to the replacement field, dial 07299999999, same output = 0099999999.

I've tried adding \1 to the replacement field, dial 07299999999, 00 is the output.

I've tried changing pattern to (07)* leaving replacement empty, dial 07299999999, output = 007

What on earth is going on?

 

 

Link to post
Share on other sites

I've just added the (07[0-9]{9})@.* as the pattern, and sip:\1@\r;user=phone as the replacement, and this works. (07[0-9]*)@.* as the pattern also works.

But could somebody explain why the "Simplified Pattern Matching" doesn't work as I would expect, and why the number is replaced even when the replacement field is empty? I see no reason why the more complex "Extended Pattern Matching" needs to be used to achieve something very simple?

Thanks

Link to post
Share on other sites

Well the dial plan is a very old feature and that is where the extended regular expressions are from. They are powerful, but at times hard to understand. The "simplified" rules used to be sugar coating for the ERE until we gave up on that and made the simplified rules a separate feature in the dial plan. So much about the history. 

For debugging dial lans the best is to turn on logging for trunks on level 9 and just try. Then you can see how the system runs the rules. 

Another thing to keep in mind is what the PBX feeds into the dial plan rules. By default it is using the domains country code representation, but you can also choose different presentations now. This is to abstract from what the user has entered, so that there is no need for separate rules for +12121234567, 12121234567 or 2121234567 or even 1234567 if the area code is 212.

Link to post
Share on other sites

Hi, and thanks for the reply.

FYI I found out that our telco was appending the 00 their end, and do so if a number is passed to them that doesn't begin with a zero - their assumption here is that without the leading zero, it must be an international call, so they prefix 00 which is the international dial code for the UK. I'll therefore ignore the 00 displayed at the telco's end when troubleshooting this issue. This however still doesn't explain why the number being passed to the telco seems to get stripped when I wouldn't expect it to...

I set logging to 9 for trunks, with a pattern of (07*) and replacement of \1 (and also tried \1*), and when dialing 07299999999, no number is passed to the telco (the whole number is stripped?), and the following is logged:

[9] 17:43:00.374 TRUN: Dialplan: Evaluating !(07*)!\1*!i against 07299999999@localhost

I'm wondering if the !i is having any bearing on what's actually being passed to the telco, and maybe the cause of the stripping? Is this possible?

With a pattern of 07* and replacement empty, 072 is stripped, and only 99999999 is passed to the telco, and log shows:

[9] 17:49:00.541 TRUN: Dialplan: Simple match begin of 07299999999 to 07*
[9] 17:49:00.541 TRUN: Last message repeated 2 times
[9] 17:49:00.541 TRUN: Dialplan: Evaluating 07* against 07299999999@localhost

I'm guessing that the lack of brackets in the pattern signifies to Vodia that this is supposed to be a simple match? I'm also wondering if the first three digits (072) are being stripped due to the simple pattern being three digits long? Is this the case, but if so why? I've just changed the pattern to 072*, and found that indeed 4 digits are now stripped from the beginning of the number instead of just 3...?

To clarify, when you say "The 'simplified' rules used to be sugar coating for the ERE until we gave up on that and made the simplified rules a separate feature in the dial plan" - does this mean simplified rules don't actually work? And where is this 'separate feature' found in the dial plan?, assuming I've not completely misunderstood you?

Thanks for you help and clarifications on these dial plans.

Link to post
Share on other sites

(07*) means in ERE "0" and then 0, 1, 2 or more "7" characters. I guess you wanted to use ^(07[0-9]*) instead? You should actually use the ^ at the beginning to require that the string starts with 07 and not just random match somewhere in the middle (It becomes clear why we need the simple patterns). 

The simple match magic is that is just tries to make sense of the pattern as a simple pattern, and if that fails it uses the ERE logic. 

IMHO this should be a simple case where all you need to do is use the simple 07* and then on the trunk make sure you present the number as "rest of world".

Link to post
Share on other sites

I've been through this in the UK the hard way!  I identify international calls with 00* in the pattern and 00* in the replacement.

To match an 11 digit number beginning 01 - 08 it's ^0([1-8]{1}[0-9]{9}) in the pattern and sip:\0\1\2@\r in replacement.

Therefore if you want to identify 07 numbers the pattern should be ^0([7]{1}[0-9]{9}) and sip:\0\1\2@\r in replacement.

Bear in mind though that although all mobile numbers in the UK start with 07 not all 07 numbers are mobile numbers. Those starting 070 are personal numbers so you really need to block them. I have a comprehensive UK dial plan covering emergency numbers, barring premium rate etc we use for all out customers if you want to get in touch

Link to post
Share on other sites
On 2/17/2021 at 3:16 PM, rtl said:

Bear in mind though that although all mobile numbers in the UK start with 07 not all 07 numbers are mobile numbers. Those starting 070 are personal numbers so you really need to block them. I have a comprehensive UK dial plan covering emergency numbers, barring premium rate etc we use for all out customers if you want to get in touch

Good catch, I hadn't thought about personal numbers. I've DMed you re your default dial plan, thanks!

On 2/16/2021 at 11:25 AM, Vodia PBX said:

(07*) means in ERE "0" and then 0, 1, 2 or more "7" characters. I guess you wanted to use ^(07[0-9]*) instead? You should actually use the ^ at the beginning to require that the string starts with 07 and not just random match somewhere in the middle (It becomes clear why we need the simple patterns). 

The simple match magic is that is just tries to make sense of the pattern as a simple pattern, and if that fails it uses the ERE logic. 

IMHO this should be a simple case where all you need to do is use the simple 07* and then on the trunk make sure you present the number as "rest of world".

I did try 07* originally, but when I did that, keeping the replace field blank, 07299999999 was being sent as 99999999? Is that because of "rest of world" you mentioned?

Link to post
Share on other sites
51 minutes ago, Lyndon said:

I did try 07* originally, but when I did that, keeping the replace field blank, 07299999999 was being sent as 99999999? Is that because of "rest of world" you mentioned?

This is because the * matches only the part after the prefix. If you out 07* into the replacement it should work the way it should.

Link to post
Share on other sites
Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...