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:email@example.com;user=phone SIP/2.0FROM: "William Cooper"<sip:+14255550101;firstname.lastname@example.org;user=phone>;epid=3316DAF438;tag=861f7b5aTO: <sip:email@example.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:
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:firstname.lastname@example.org;user=phone SIP/2.0FROM: "William Cooper"<sip:email@example.com;user=phone>;epid=3316DAF438;tag=f9a5772c0TO: <sip:firstname.lastname@example.org;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.
Good to know that, thank you for the information
Thank you so much! I have been hitting my head against the wall on this one.
Great article! You saved my day! :)
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.