locked
Unable to place calls using tel: URL RRS feed

  • Question

  • We are in the process of building up Lync and one of our testers pointed out an issue with the tel: URL.  The user receives an e-mail when they miss a call, which has a URL to easily return the call, such as tel:+5551112222, but if they click the link, the call fails.  If the user types in the number manually (as +5551112222), you can see the number automatically translate to the appropriate outbound number +315551112222, and the call is successful.

    The client log shows:

    ms-diagnostics: 12004;reason="The user is not authorized to call the specified number.";source="Lync1.company.org";appName="OutboundRouting"

    What are we doing wrong?


    It worked for me.


    • Edited by one0 Tuesday, September 23, 2014 4:39 PM added log message
    Tuesday, September 23, 2014 4:27 PM

Answers

  • I'm pretty sure when you dial from a tel: link Lync wont do any normalization. You will probably need to make sure that when the missed call notifications are received, that the numbers are already in correct E164 format e.g. +313331112222. To do this make sure that your global and user normalization rules correctly normalize inbound numbers to include full E164 number including country code.

    Andrew Morpeth
    Lync Server Specialist - Auckland, NZ
    Blog - http://www.lync.geek.nz

    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"

    Andrew Morpeth MVP

    • Marked as answer by Eason Huang Monday, October 6, 2014 2:20 AM
    Tuesday, September 30, 2014 3:20 AM

All replies

  • Is the user actually manually typing in +5551112222 or just 5551112222 and it normalizes to +315551112222?  My guess is they aren't typing in the +?

    In the world of Lync, a + means the number is "normalized" and a global phone number and will ignore any normalization rules, etc.  In this case, you would need to have a route/pstn usage for +5551112222 but my guess is your routes/pstn usages are all for +315551112222. You can check out this post for a bit more on routing behavior:

    http://masteringlync.com/2013/04/07/understanding-voice-routing-dialing-behaviors/

    So the real issue is that in Exchange you need to make sure your numbers are getting normalized so the correct Line URI or you have the Address Book Normalization file setup correctly to deal with this type of behavior.

    Thanks,

    Richard


    Richard Brynteson, Lync MVP | http://masteringlync.com | http://lyncvalidator.com

    • Proposed as answer by Holger Bunkradt Tuesday, September 30, 2014 10:39 AM
    Tuesday, September 23, 2014 4:58 PM
  • I added a normalization rule to handle the +, and tested with both.  For example:

     

    When a call comes in to the desk phone, it shows as 315551112222 , however when it comes in to Lync, it shows as +5551112222.  The missed call URL would then be tel:+5551112222.  If the user clicks the link and clicks the button in Lync, the call fails.  If the user opens Lync and types in +5551112222 with or without the leading +, the call succeeds.

    We use DID so our AD telephone field is only populated with the extension (last four digits).  If User1 is assigned extension 1234, their actual phone number is 555-111-1234.  Their internal Lync extension might then be 2234.

    I will look into the Address Book Normalization in the meantime.


    It worked for me.

    Tuesday, September 23, 2014 7:06 PM
  • I'm pretty sure when you dial from a tel: link Lync wont do any normalization. You will probably need to make sure that when the missed call notifications are received, that the numbers are already in correct E164 format e.g. +313331112222. To do this make sure that your global and user normalization rules correctly normalize inbound numbers to include full E164 number including country code.

    Andrew Morpeth
    Lync Server Specialist - Auckland, NZ
    Blog - http://www.lync.geek.nz

    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"

    Andrew Morpeth MVP

    • Marked as answer by Eason Huang Monday, October 6, 2014 2:20 AM
    Tuesday, September 30, 2014 3:20 AM