"Lync/Skype for Business will not attempt to normalize a number that already has a plus sign at the beginning"There are signs that this is no longer true, at least for customers running Skype for Business Server 2015 and the Skype for Business 2016 client (and even the Lync 2010 client). I was messing around with normalization rules last night and realized that my Skype for Business 2016 client (version 16.0.7030.1021 32-bit) WAS normalizing numbers that started with a plus sign. I later validated this with a Lync 2010 client against the same Skype for Business 2016 server. And a commenter below said he's pretty sure he did this with Lync Server 2013. So this means that either it has ALWAYS worked this way and I never realized it, or its something relatively new on the server-side.
I should clarify here and state that the normalization rule in question was specifically constructed to include a plus sign in the normalization pattern (as highlighted below):
^\+?(?:011)?(1|7|2[07]|3[0-46]|39\d|4[013-9]|5[1-8]|6[0-6]|8[1246]|9[0-58]|2[1-689]\d|3[578]\d|42|5[09]\d|6[789]\d|8[035789]\d|9[679]\d)(?:0)?(\d{6,14})(\D+\d+)?$This DOES NOT mean that the Skype for Business client will suddenly normalize all numbers that start with a plus. If your normalization rules do not include a plus sign, it will not normalize a number with a plus sign.
This has all sorts of ramifications, all of them positive. That means that http://googledoodlenewstoday.blogspot.com /2016/03/trunk-prefixes-in-skype4b.html" target="_blank">dealing with improperly formatted click-to-dial numbers in Internet Explorer is much simpler. We can now fix this with a simple normalization rule, instead of doing it in a trunk translation rule or route.
This also means that dialing contact phone numbers from Outlook can also be much more reliable, especially if an extension is entered. Before, if a user entered a contact phone number with an extension in Outlook using the "Phone number builder", it would format the number like "+1 (212) 555-1212 x 345". If you clicked this number, Lync would parse the "x" as a "9" and the number would come out in Lync like "+121255512129345" and would likely fail.
I have no idea how long this new behaviour has been available. It works on a Skype for Business Server 2015 environment with both Skype for Business 2016 clients and Lync 2010 clients. I don't have a Lync 2013 or older environment to test with. I tried to see if this behaviour extended to server-side normalization scenarios with no luck. I tried to change the destination phone number on an incoming call that started with a plus sign. It didn't work, which implies that this is a client-only thing. The http://googledoodlenewstoday.blogspot.com /2012/02/re-routing-incoming-calls-to.html" target="_blank">MSPL workaround is still required.
If this is only new to me, then I apologize for wasting everybody's time. I've incorporated my new findings into the Lync Optimizer (as you would expect), because it does allow for several dialing scenarios to work better than before.
If anybody has any information on this or can test other versions of Lync server/client, drop me a line.
UPDATE (2016-Aug-24): Updated to clarify that a normalization rule has to explicitly look for a plus sign for this to work. Original post implied that any valid, matching normalization rule would be applied to a number that had a plus sign on the front. Also made changes based on further observations with older clients.
Posting Komentar