locked
Lync client display the normalization rule resultat RRS feed

  • Question

  • Hi,

    In my Dial plan i have several Normalization Rules which modified the called number adding for example a prefix used for routing. The problem is that on the Lync Client when you dial the number, the client display the resultat of the Normalization Rules . How can i hide this to the User Lync ?

    Ex:

    Dial Plan have the Normalization Rules adding +0000 to all dialed number starting by 2 .

    If the User lync "Alan" dial on his client Lync the number "299901" , he will see on his client that the number is in fact +000299901


    Wednesday, August 19, 2015 7:04 PM

Answers

  • Is this Lync 2010 or 2013?  Is the issue that you want to hide the normalization from the user, or you can't use E.164?  If it's that you can't use E.164 and you're not using a supported iPBX, you may need to do the translation on the iPBX side or get a supported gateway to connect the systems that can do this for you.

    Please remember, if you see a post that helped you please click "Vote As Helpful" and if it answered your question please click "Mark As Answer". SWC Unified Communications

    This forum post is based upon my personal experience and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    • Marked as answer by Eason Huang Monday, September 7, 2015 3:28 AM
    Thursday, August 20, 2015 5:49 PM

All replies

  • That's by design, you can't hide that as far as I know.  In rare cases where I didn't want the client to see it (they dialed a paging system for example that I didn't want them to see the outside phone number for), I wouldn't normalize it within Lync, but rather normalized it in the trunk configuration or on the IP gateway/SBC. 


    Please remember, if you see a post that helped you please click "Vote As Helpful" and if it answered your question please click "Mark As Answer". SWC Unified Communications

    This forum post is based upon my personal experience and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    • Proposed as answer by Eason Huang Thursday, August 20, 2015 1:47 AM
    Wednesday, August 19, 2015 7:12 PM
  • Hi,

    In Lync Server, it is recommended to use E.164 format for tel number, also for Address Book. It is recommended to set the tel number on AD to be E.164 format. If not, you still need to normalization it on Lync Server side.

    So when you dial a tel number on Lync client, it will perform reverse number lookup to check if the number assigned to anything in Lync (if the dialed number is E.164 format, it will pass this step), then it will show the number with E.164 format on Lync client.

    Best Regards,
    Eason Huang


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Eason Huang
    TechNet Community Support

    Thursday, August 20, 2015 1:56 AM
  • Translation on the Trunk Configuration is alternative solution but limited because the translation is associated to the Trunk not to the user Lync . So i cannot apply different translation for users lync on the same Site with the same outgoing trunk (except if you have a solution :) ).

     
    Thursday, August 20, 2015 7:36 AM
  • Is this Lync 2010 or 2013?  Is the issue that you want to hide the normalization from the user, or you can't use E.164?  If it's that you can't use E.164 and you're not using a supported iPBX, you may need to do the translation on the iPBX side or get a supported gateway to connect the systems that can do this for you.

    Please remember, if you see a post that helped you please click "Vote As Helpful" and if it answered your question please click "Mark As Answer". SWC Unified Communications

    This forum post is based upon my personal experience and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    • Marked as answer by Eason Huang Monday, September 7, 2015 3:28 AM
    Thursday, August 20, 2015 5:49 PM