Show correct Caller ID on blind call transfers to external

As mentioned in one of my previous blog posts, one of the advantages on using an SBC is to be able to connect any “Direct SIP Trunk” to Lync; Microsoft certified or uncertified – as long as its compatible with the SBC’s settings.

This time, I had to connect an uncertified SIP Trunk to Lync. For that, I used a Sonus SBC1000 with no optional parts or licenses other than the SIP-to-SIP licensing. Shortly after getting a positive response and during extensive testing, we found out that in specific moments, calls from Lync would be dropped or sent out with a wrong number.

To clarify this a bit more, let’s visualize the scenario:

Let’s clarify the call flow.

First, an external caller calls one of “our” users in Lync. We mark this caller as “A”, the Lync user as “B”. This user then either blind-forwards the call to another, external number (f.i. his own mobile phone), or has its call forwarding settings set to use simultaneous ring or a forward to the mobile phone.

Either way, when the inbound call is redirected to another external phone device, we’d expect to see the original callers (“A”) number. However, user “C” displays the SIP Trunk “main” number. So we don’t see the “A” or “B” number, but in most scenarios the receiver “C” expects a receptionist or colleague calling.

A lot of companies seem to have this issue, and after some search in Lync they give up and accept to “deal with it”. However this behavior is quite annoying, and is due to a simple, technical “mismatch” in the happy world of SIP.

The problem

We know the issue must be happening at the outbound call. Let’s zoom into this call. Simple enough, this call should have a “From” number of “A”, and a “to” number of “C”. The latter is correct, as the call is able to complete. The former, however, seems NOT to. Why?

A Sip Trunk provider needs to validate the incoming calls, to prevent abuse. For this to happen, most carriers choose to validate on either the FROM, PAI (P-Asserted-Identity), and DIVERSION in the SIP INVITE message.

The solution

There are different solutions to this problem, of which I will describe the ones I came on.


In Lync 2013, a new feature called “Forward Call History” is available on the SIP-Trunk configuration.

When enabled, the Sonus SBC (running a firmware of 3.0.2v242 and up) will automatically pick up this information, and push it into the DIVERSION header.

Problem solved.

SIP Message Manipulation

SIP Message Manipulation (SMM) is a solution, when there are very specific requirements to this SIP invite. In this case, the ITSP expected a FROM field of the “A’ number, but a Diversion header of the “B” number (or any of the office numbers, as long as it is one belonging in the SIP Trunk number block).
Where this might sound quite complicated, it is actually a quite simple procedure in the Sonus SBC configuration.

Where Lync is already sending out the original Callers ID “A” (when “Forward Call history” is disabled at least), we just need to add any “B” number into the DIVERSION header. This can be done in the “Message Manipulation” section of the “Settings” panel.

We will now create a very “static” rule to solve the problem: just add the office main number as the “diversion header” in any outbound call on the SIP Trunk.

1. First, create a “Message Rule Table”. In this case, we call it “Diversion Header”.
2. Now create a new rule. Choose “Header Rule”. Originally enough, I called this one “Diversion Header”.

3. Here in header action, choose “add”. In the Header Value choose “add”, and enter one of the “B” numbers.
4. Assign the “Message Manipulation” table to outbound calls on the SIP Trunk of the ITSP:

And here you go. Problem solved!

This Message Manipulation, however, could be done way more dynamic.

For example, the SMM could be used in combination with the Manipulation tables.
1. For this to happen, write the desired value (From number or “Redirecting Number”) to a User Value 1
2. use the “User Value 1” value in the Message Manipulation section instead of a “fixed” value.
More information on this can be found at Sonus’ site .

My message therefore is, with some simple adjustment and just a closer look at what actually happens, could save you a lot of pain and get your colleagues or customer a better calling, and thus “Lync” Experience.

Leave a Reply

Your email address will not be published. Required fields are marked *