Share via

Issue with Calling Number Translation Rules and E.164 Extensions

  • Article

I came across this issue while troubleshooting dialing issues at a customer.  When a Lync 2013 user placed an outbound call to the PSTN, the call failed.  On the gateway we could see that the calling party's number wasn't being translated properly.  The interesting thing was that we already had a trunk configuration setup with a calling number translation rule configured:

The above rule should be translating the calling party's number to:

However, looking at the gateway, we can see that this isn't happening:

INVITE sip:94255550105@mp114-red.lab.deitterick.com;user=phone SIP/2.0
FROM: "William Cooper"<sip:+14255550101;ext=0101@lab.deitterick.com;user=phone>;epid=3316DAF438;tag=861f7b5a
TO: <sip:94255550105@mp114-red.lab.deitterick.com;user=phone>

 

For some reason the full E.164 phone number is being sent to the gateway.  The reason this was happening was because when the user's line URI was configured, it was configured with an E.164 extension (;ext=0101).  The calling number translation rule we configured is explicitly looking for 12 digits.  If you enter the full E.164 phone number including the extension, which is what Outbound Routing is sending, no match is found:

 

The solution is really simple, you just need to account for the E.164 extension in the calling number translation rule:

The pattern to match is:

^\+1(42555501\d{2})(;ext=\d{4})?$

As you can see I've added the E.164 extension to the pattern to match string.  I've also added the ? after it.  This means that this rule will also apply if the calling party's number doesn't have an E.164 extension assigned.  Now when testing the rule, you can see that it succeeds using both formats:

Now when the gateway receives the call, the calling party's number is properly formatted properly: 

INVITE sip:94255550105@mp114-red.lab.deitterick.com;user=phone SIP/2.0
FROM: "William Cooper"<sip:4255550101@lab.deitterick.com;user=phone>;epid=3316DAF438;tag=f9a5772c0
TO: <sip:94255550105@mp114-red.lab.deitterick.com;user=phone>

 

If you are including the E.164 extension on your Lync 2013 users and you need to apply calling number translation rules, remember that you'll need to account for the extensions when building your rules.

Comments

  • Anonymous
    April 21, 2013
    Good to know that, thank you for the information

  • Anonymous
    January 31, 2014
    The comment has been removed

  • Anonymous
    March 18, 2014
    Great article! You saved my day! :)

  • Anonymous
    April 04, 2014
    This was very helpful! Thank you! Only problem we're finding now is that this rule is somehow getting ignored when asking Lync to call us on another phone for meetings. In other words, if I call someone from Lync, I currently have the rule translate the number to an extension that our PBX understands. When joining a meeting, if I ask Lync to, say, call my work number (desk phone) for the audio portion of the meeting, the caller ID appears to be the E.164 number of the Lync user joining the meeting instead of just the extension.

  • Anonymous
    January 28, 2015
    .* also works, for example:

    ^+441234567890.*$

  • Anonymous
    January 05, 2016
    After installing the July 2013 update to the Lync 2013 client, we've found that a user running Lync 2013 CU2 homed to a Lync 2013 pool is unable to transfer files to a user running Lync 2013 CU2 homed to a Lync 2010 pool. The error is "Error during transfer". Shares results here: http://goo.gl/Y8KCDb