Lync 2013 E.164 CLI and carriers (It’s that Plus sign!)


If you’re using Lync properly, you must have all your numbers in accordance with the E.164 format, as recommended by Microsoft and as often preached by Ken Lasko.

There are many benefits for using E.164, but – like any good thing – it comes with some flaws. One of these flaws when using Lync 2013 is that Lync will cease normalizing numbers that are prefixed with +.
The moment you add the ‘+’ sign to your number, Lync will consider it already normalized and will not process any more rules.

This can cause issues with some providers that require us to remove the leading ‘+’ sign from the number.
The work around for dialled numbers (Or as Lync describes it “Called Numbers”) is to use the Set-CsTrunkConfiguration command to remove ‘+’ sign at the trunk level by adding the parameter -RemovePlusFromUri $true.

This is all good for numbers Called – but what about numbers Calling? How can we manipulate the “Source” number?
If we look at a trace from Lync we can see that the destination number is stripped from it’s leading ‘+’, but the source number still has that annoying sign, although I have a rule that says it’s removing it:

With plus

The SIP invite shows the issue:
INVITE sip:3531891170170@MediaGateway.y0av.local;user=phone SIP/2.0
FROM: <sip:+35314396804;;user=phone>;epid=3DFA3756A7;tag=1e448bc93
TO: <sip:3531891170170@MediaGateway.y0av.local;user=phone>

As you can see in the image above, the ‘+’ sign is removed from the destination number, but it’s still there on my source number.
This might result on certain carriers dropping the call since they’re expecting the CLI with no ‘+’.

The workaround:

If you’re working with a gateway or a SBC, you’ll usually be able to work around this issue by stripping the ‘+’ there, simple as this.

If you’re working with Lync only and using a direct SIP trunk to your provider – it’s easy too!
The numbers are not normalized due to Lync’s lack of ability to ignore the rest of the data in the FROM line; when we’re creating normalization rules within Lync, we will usually be looking at numbers and specific characters, not the entire weird string.
The workaround then, is to treat the entire string as… a string.
I add the following rule for my “Calling Numbers” manipulation in the trunk:


This rule says that whenever a number starts with a plus and has at least 8 characters (ANY character) following it, we should ignore the ‘+’ and send only the characters:
Pattern to match: ^\+(.{8,})
Translation rule: $1
Of course, you can change that to look for more numbers if you have other rules there.

Once the rule has been placed and committed, traces look like this now:

Without Plus

The SIP Invite shows the difference:
INVITE sip:3531891170170@MediaGateway.y0av.local;user=phone SIP/2.0
FROM: “Yoav Barzilay”<sip:35315267877;;user=phone>;epid=3DFA3756A7;tag=c9b24cf3b
TO: <sip:3531891170170@MediaGateway.y0av.local;user=phone>



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s