locked
Normalisation / Dial Plan rule for +44 (0) 7777 123 456 / +44 (0)131 123 4567 RRS feed

  • Question

  • Hi was looking for a bit of assistance with a normalisation / dial plan rule I am struggling with, i'm trying to translate numbers of the the following pattern:

    +44 (0) 7777 123 456 / +44 (0)131 123 4567

    I've created the following rule, which appears to normalize the number in the correct e.164 format within the rule itself, but when stepping outside of the rule and testing it from the Dial Plan or from the Lync client it doesn't seem to be working.

    I have the following in place, any suggestions greatly appreciated!

    Pattern to Match:

    ^\+44\s*\(0\)\s*(\d+)\s*(\d+)\s*(\d+)$

    Translation Rule

    +44$1$2$3

    Wednesday, August 6, 2014 8:00 AM

Answers

  • First of all, don't worry about accounting for brackets, dashes and that sort of thing. Lync automatically parses those things out prior to normalization.  Secondly, Lync will not normalize any number that has a plus in front. The MS thinking on this (and for the record, I don't agree with it) is that any number that has a plus in front is already normalized to E.164 and it will not process any normalization rules.

    If you want to normalize numbers without the +, this should work out nicely for you:

    Pattern to match:  ^(?:44)?0?(\d+)$

    Translation Rule: +44$1

    This will translate any combination of 44 (0) 7777 123 456, (0) 7777 123 456 or 7777 123 456.

    You'll notice that the Dial plan test will fail if you put spaces and stuff in the number to test, but if you do it from the Lync client, it will work just fine (but without the +)


    Ken Lasko | Lync MVP | UCKen.blogspot.com | LyncOptimizer.com

    • Marked as answer by Wayne Ault Friday, August 8, 2014 12:33 PM
    Wednesday, August 6, 2014 2:37 PM

All replies

  • Hi,

    the most possible reason would be that, the numbers getting matched in to a normalization rule sitting above the required rule. change the order of the rule to be on top of the list and try again.


    http://thamaraw.com

    Wednesday, August 6, 2014 8:42 AM
  • Hi Thamara,

    Thanks for your reply.  I did think this myself but I do not believe it to be the order.  I get "No match exists for the regular expression you built"

    I have even built a new dial plan and copied just the above rule and get the same thing

    Thanks

    Wayne

    Wednesday, August 6, 2014 9:22 AM
  • First of all, don't worry about accounting for brackets, dashes and that sort of thing. Lync automatically parses those things out prior to normalization.  Secondly, Lync will not normalize any number that has a plus in front. The MS thinking on this (and for the record, I don't agree with it) is that any number that has a plus in front is already normalized to E.164 and it will not process any normalization rules.

    If you want to normalize numbers without the +, this should work out nicely for you:

    Pattern to match:  ^(?:44)?0?(\d+)$

    Translation Rule: +44$1

    This will translate any combination of 44 (0) 7777 123 456, (0) 7777 123 456 or 7777 123 456.

    You'll notice that the Dial plan test will fail if you put spaces and stuff in the number to test, but if you do it from the Lync client, it will work just fine (but without the +)


    Ken Lasko | Lync MVP | UCKen.blogspot.com | LyncOptimizer.com

    • Marked as answer by Wayne Ault Friday, August 8, 2014 12:33 PM
    Wednesday, August 6, 2014 2:37 PM
  • Agree with Ken.

    You also need to figure out which number range you want to use this normalization rule.

    For example, you want to normalize 440 7XX 123 456 to +440 131 123 456.


    Lisa Zheng
    TechNet Community Support

    Thursday, August 7, 2014 7:16 AM
  • Thanks Ken,

    Yes it was the + in the normalisation rule causing the issue.

    Appreciate your time and effort in replying

    Wayne

    Friday, August 8, 2014 12:34 PM