Pages

Friday, July 22, 2011

Lync Bug with Incoming E.164 Phone Numbers?

If your company uses internal extensions instead of DIDs for your users, you may have come across my blog post on how to best setup Lync Enterprise Voice for internal extensions.

There appears to be an issue with using my method of using the main office number as a base for all internal extensions in certain circumstances. The issue seems to arise when the incoming phone number coming from the PSTN is prepended with a plus sign (a properly formatted E.164 phone number). When Lync sees an incoming call that starts with a +, it assumes the number is properly formatted and does not apply any translation rules. Since my method relies on a translation rule to add a ;ext=<ext> to ensure the incoming call is going to a unique number, Lync will return a 485 Ambiguous (because there are many numbers with the main number as a base) and drop the call.
This only occurs in situations where incoming calls are prepended with a plus sign. This will typically occur when using SIP providers or PSTN gateways (AudioCodes, Dialogic etc) that prefix incoming calls with a +.  I verified this with a client that has both a PSTN connection via a Dialogic (that doesn't add a + to incoming calls) and a SIP provider that does add a + to incoming calls).
There are several workarounds:
  1. If you are using a Direct SIP provider, they may be able to not send the + to your Lync server. Call your provider and ask if this is an option.
  2. If you are using a PSTN gateway or IP-PBX that is sending a +, you should be able to easily modify the incoming rule to drop the + sign (as your rule is most likely explicitly adding a +)
I've confirmed that this behaviour is by design.  I've brought up these cases as an example to the proper people, so maybe we'll see this changed in a future release.  

15 comments:

  1. Is there an update to this? We currently have two interactive voice groups with their own number. The problem is all the users under each group have the same number with a unique extension.

    When a calls come to +4412345 in Group A, Lync sends out the 485 Ambiguous error as the group and all the users assigned to the same number of the group all have the same number so Lync doesn't know where to route the call and just drops it.

    What we have done for now is get our SIP provider to set up two extra numbers to whom the main numbers redirect to. These extra numbers are then set up within the Interactive Groups. When a call comes in now, +4412345 redirects to +4498767 which is a unique number within the Lync Environment and forwards it to just the group.

    While this is a workaround, I heard there was a fix on the horizon for this, due in CU4, but not sure how true that is.

    Anyone confirm?

    ReplyDelete
  2. I've actually just heard that there will definitely be a fix coming in CU4, whenever that comes out.

    Ken

    ReplyDelete
  3. Unified Communications Systems The issue seems to arise when the incoming phone number coming from the PSTN is prepended with a plus sign (a properly formatted E.164 phone number).

    ReplyDelete
  4. Hi,
    I have installed the CU4 and it looks like the problem is still there... I just asked our SIP Trunk provider if they can or not remove the + sign in the incoming feed... We'll see...

    Chris

    ReplyDelete
  5. Ken - I'm running in to this issue as well, with CU4 installed. I have a Sangoma PSTN gateway. That said, I modified the rules to drop the plus, but I can no longer get lync to match the "to" portion of the SIP call. It says "User not found". Do I need to change the Line URI attributes to drop the + sign as well?

    Thanks,

    Brandon

    ReplyDelete
  6. Brandon,
    Don't change the LineURI attribute to drop the +. Make sure your dial plan have rules that will normalize the incoming phone numbers to E.164. What format are inbound calls from the PSTN gateway?

    Ken

    ReplyDelete
  7. We are having this problem as well.. We can dial out or dial in but not both. How to do we drop + on going outcalls only? We have Lync 2010 Cu4 with a direct sip and a mediation server. Is there any workarounds for this?

    ReplyDelete
    Replies
    1. Use trunk translation rules to drop the + on outgoing calls. Alternatively, you can use the command Set-CSTrunkConfiguration yourtrunkname -RemovePlusFromURI:$TRUE

      Ken

      Delete
    2. I working with PBX that doesn't support the plus sign (or maybe the people who supoort it, just dont know how). Anyway, my big issue is when I making an outbound call from Lync to PBX, the "From" send the + signal. On the display phone that connects to the PBX they get the + sign. The problem begins when they press redial. The PBX doesn't reach to numbers with plus sign.

      How can I manipulate the "From" to drop the + sign.
      If I drop it from line URI, it makes me other problems.

      Any help will appriciated.

      Delete
    3. Hi Anonymous,
      You can make Lync drop the + on all outbound calls including the From: by running the following command: Set-CsTrunkConfiguration -Identity -RemovePlusFromURI:$TRUE.

      I'm considering setting this value by default in future releases of the Lync Optimizer.

      Ken

      Delete
    4. wow.... thanks alot, I'm about to do that. many thanks.

      Delete
    5. Just noticed that the rule didn't transcribe correctly....

      Set-CsTrunkConfiguration -Identity trunkname -RemovePlusFromURI:$TRUE

      Delete
  8. Thank you for this post. This helped me for a Lync 2013 deployment also.

    ReplyDelete
  9. In wpf application i'm able to make an outbound call to a telephone or any mobilephone(by adding participant to the conversation), but the outbound call is hitting mediation server. Is there any way to route the outbound call to mspl and mediation server.

    ReplyDelete

Note: Only a member of this blog may post a comment.