Issue with Calling Number Translation Rules and E.164 Extensions

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;user=phone SIP/2.0
FROM: "William Cooper"<sip:+14255550101;;user=phone>;epid=3316DAF438;tag=861f7b5a
TO: <;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;user=phone SIP/2.0
FROM: "William Cooper"<;user=phone>;epid=3316DAF438;tag=f9a5772c0
TO: <;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.