Working on a customer system I came across an interesting issue. The Polycom VVX 5.0.1 firmware does not process Normalization rules with more than 1 group (i.e. $1 and $2). It can only process rules that have a single group (i.e. just $1).
Here is an example of a rule that will not process:
^(150)(\d{4})$
+1303555$2;ext=$1$2
Ideally you would like to have the flexibility of capturing multiple groups and being able to create complex normalization rules... but for now you are limited to doing something like this instead:
^150(\d{4})$
+1303555$1;ext=150$1
There are no errors in logs, or in Lync that indicate an issue. Just the inability of the phone to connect to the number you expect.
Update: Thanks to some feedback on comments below the problem has been narrowed down even further. It appears as if the error processing the rules kicks is when $2 is used multiple times. This is usually used when you have ;ext= formats like the above example.
This rule where each group is used once will process fine
^(150)(\d{4})$
+1303$1$2
This rule although silly will also process fine
^(150)(\d{4})(150)(\d{4})$
+1303$1$2;ext=$3$4
Feel free to comment down below if you find something else..
As always thanks for reading...
Polycom phones process rules with more than 1 group. But, the ordering should be sequential. In the given rule $2 comes first and then $1 comes. So, the conversion is failing.
ReplyDeleteThe order is dictated by the match part of the rule (^(150)(\d{4})$). How you use them in the transformation part of the rule does not matter. Have you tried using a 2 group rule with VVX phones?
ReplyDeleteyes I have tried a 2 group rule and it worked fine.
ReplyDeleteI have used ^(123)(\d{2})$+1$1$2 and it worked fine for me. So, I see that the only problem is when the ordering is not sequential.
To be exact I tried ^(123)(\d{2})$ +1555$1$2;ext=$1$2 and that still didn't work
DeleteI updated the blog post above... see if my tests match with your results... Thanks!
DeleteSo I did some more testing... it appears in my testing so far that it doesn't like the ;ext= format with multiple groups. Maybe it is the use of the groups multiple times in the translation it doesn't like. I'll do more testing when time permits.
ReplyDeleteHey Jonathon, @KenLasko provided a new regex lesson to me, wondering how it would work. Qoute form Ken "The ?: means the digits in between the brackets will be ignored for regex replacement. The ? outside the bracket means the preceding is optional. For example, say I want to capture 12345 from a string 01112345 and use $1 to capture.
ReplyDelete^(?:011)?(12345)$. Because I have the ?:, I can use $1 to capture 12345. Otherwise I'd have to use $2. Makes coding a pain." Credit - http://ucken.blogspot.no/2014/02/february-2014-lync-optimizer-updates.html
Also does not appear to like an asterisk? Rule (\*7\d{2}) $1 fails. If you look at the Polycom logs, they state what fails to translate. Definitely doe not like a Capital D. Here's an example:
ReplyDelete0220102456|utilm|4|00|Failed to Convert MicroSoft Dial plan: ^\+?19125557000\D+(2\d{3})
0220102456|utilm|4|00|Failed to Convert MicroSoft Dial plan: ^(\*7\d{2})
0220102456|utilm|4|00|Failed to Convert MicroSoft Dial plan: ^9?1?([2-9]\d\d[2-9]\d{6})(\D+\d+)?
0220102456|utilm|4|00|Failed to Convert MicroSoft Dial plan: ^9?(011)?([2-9]\d{6,14})(\D+\d+)?
Very Interesting... I'm going to have to play with that to see it for myself.
DeleteJust so you're aware VVX phones have a parameter that can be set to send normalization to server, set reg.1.applyServerDigitMapLocally.
ReplyDeleteIn the case whereby a VVX is purchased for Lync it will be shipped with this parameter already set.
it's also necessary to set dialplan.digitmap="" if you wish to prevent the errors from appearing. The phone needs a null digitmap
Delete