locked
Lync 2010/Exchange 2010 UM with user Extensions RRS feed

  • Question

  • I have a working setup of Lync 2010 and Exchange 2010 with voicemail working for users, however the current test users are all set up with just an extension as a lineURI (ex: +1004). This should work as I intend to have only one DID the hits a response group and all users just being internal extensions.

    After reading around it seems that the proper method is to use the full DID with ext set for each user (ex:+15555555555;ext1004).  I tried setting this for a test user in both Lync and AD, then created a new normalization rule to translate that specific extension to the full format (1004 > +15555555555;ext1004).  When I log on to another user in Lync the client does display the translation correctly: +1 (555) 555-5555 X1004.  However, when I dial the number I get a "Call was not completed or ended" message in the client and "Forbidden" - "ms-diagnostics: 12004;reason="The user is not authorized to call the specified number"" from looking at the SIPStack logs.

    Am I missing something in setting up users in the "proper" E.164 format?  Is the original method of using straight extensions as URI's the better way to go?

    Thursday, April 21, 2011 1:30 AM

Answers

  • If you think of it, Subscriber Access is meant to provide access to email, voice mail etc. to users while away from office, typically via PSTN. In this scenario, E.164;ext=xxxx is not an option. This number should be E.164 only. While signed from office (or via edge), we have many different methods accessing voicemail (Lync client, Phone edition device) and so, I don’t understand the desire of some folks to make Subscriber Access part of a workflow etc. Imagine calling your insurance company regarding a claim and you have an option “To access your email, press x…”. SA must be public routable telephony number, distributed to employee only.

    Having said that, dial plan can have one or more pilot numbers, i.e. we could have more than one SA numbers. In this case, use one E.164 to assure outside access and another, for example “+0101” for internal access. Add normalization rule to prepend “+” when “0101” is dialed and there you have it…

     

    Drago


    http://www.lynclog.com
    • Marked as answer by Rowen-Xu Monday, May 2, 2011 9:19 AM
    Sunday, May 1, 2011 10:35 PM

All replies

  • In Lync you have to work with the E.164 format.

    For Exchange you have to work with the 4 digit extension.

    If you setup Exchange with the gateway an exchucutil.ps1 and Lync with the OCSUMutil for the Systemattendant everything is working fine.


    regards Holger Technical Specialist UC
    Sunday, April 24, 2011 8:42 AM
  • Think I have this working...

    The next question is how should a subscriber access number be formatted in the UM dial plan if you are using E.164 format with extensions?  +15555555555;ext=1111 is too long (20 char limit)  as is +15555555555X1111.

    Friday, April 29, 2011 4:08 PM
  • If you think of it, Subscriber Access is meant to provide access to email, voice mail etc. to users while away from office, typically via PSTN. In this scenario, E.164;ext=xxxx is not an option. This number should be E.164 only. While signed from office (or via edge), we have many different methods accessing voicemail (Lync client, Phone edition device) and so, I don’t understand the desire of some folks to make Subscriber Access part of a workflow etc. Imagine calling your insurance company regarding a claim and you have an option “To access your email, press x…”. SA must be public routable telephony number, distributed to employee only.

    Having said that, dial plan can have one or more pilot numbers, i.e. we could have more than one SA numbers. In this case, use one E.164 to assure outside access and another, for example “+0101” for internal access. Add normalization rule to prepend “+” when “0101” is dialed and there you have it…

     

    Drago


    http://www.lynclog.com
    • Marked as answer by Rowen-Xu Monday, May 2, 2011 9:19 AM
    Sunday, May 1, 2011 10:35 PM