Manipulating Calling Number for Simultaneous Ring and Forwarded Calls

This is something I’ve been meaning to write since the release of Lync Server 2013. However, I’ve been waiting to have all the components I need in my lab to successfully capture all the relevant screenshots and traces, and for Microsoft to resolve a bug with the Mediation server role that was rectified with CU3 (more on that later). This article is broken into the following sections:

  • Overview
    • Terminology
    • Lync call forwarding behaviour
  • What’s the Problem?
  • What’s the Fix?
    • Configure Lync to present B Party information in Sim Ring/Call Forwarding SIP INVITE
    • Configure Sonus SBC gateway to manipulate Sim Ring/Call Forwarding SIP INVITE

NOTE: To carry out the configuration changes outlined in the fix section of this article, it is assumed that the reader has an in depth understanding of Lync Enterprise Voice configuration (particularly the Mediation server role and the SIP protocol) as well as experience configuring Sonus SBC series Session Border Controllers (SBCs).

Overview

Terminology

Before looking at the technical configuration aspects of this post, here’s a brief overview of some of the terms I’ll be using:

Called/Calling Party 

These terms refer to an endpoint that initiates a call (calling party) and an endpoint that receives the call (called party).

1

A/B/C Party

When displaying call flows for calls that are forwarded to another destination, it’s common to see the parties involved in the call flow referred to as A, B and C Party:

  • A Party:                The endpoint that initiates the call
  • B Party:                The endpoint that receives the call
  • C Party:                The endpoint the call is ultimately forwarded to

2

SIP INVITE: FROM/TO

To facilitate the setup, management and tear down of calls, the SIP protocol makes use of SIP Headers. This article is concerned with the SIP INVITE header, and how we manipulate it with the help of a Session Border Controller (SBC) to achieve a desired outcome. Within the header is a number of fields, each of which has a specific purpose to assist with communication between two endpoints (Nick Galea over at 3cx.com has a great blog post that explains the SIP HEADER in greater detail). The two fields within the header that are of interest for this article are the FROM and TO fields. The FROM field is used to identify the initiator of the request, while the TO field specifies the logical recipient of the request (simplified descriptions, but sufficient for the scope of this article).

Lync Call Forward Behaviour

When a Lync user has their client or device configured for call forwarding or simultaneous ring, the Mediation server initiates an outbound call on behalf of the user to the C Party endpoint. When constructing the SIP INVITE for this call, Lync will use the C party number in the TO field of the SIP header (called number) and the A party number in the FROM field of the SIP header (calling number).

3

The important takeaway from this is that the B Party number (the Lync user’s number) is not present in the outbound INVITE.

What’s The Problem?

The lack of B party information in the outbound SIP INVITE first started to cause problems for me on deployments once SIP Trunks (as opposed to ISDN trunks) started to become more widely adopted on Lync deployments. When deploying ISDN trunks, this issue usually remained unnoticed. Why?

If you think about a standard call from Lync to the PSTN, you have the usual called and calling parties: A Party is the internal Lync user, and B party is the PSTN number you’re dialling. Before the call is routed out to the PSTN, you will typically manipulate the called and calling numbers into a format the trunk provider is expecting. For example:

  E.164 From Lync Manipulate To
Called Number +61400734033 400734033
Calling Number +61386097221 386097221

If you get the called number manipulation wrong, the call will fail, as the Telco won’t know where to route your call. If you get the calling number manipulation wrong, and the trunk to the PSTN trunk is using ISDN, the Telco will usually replace the incorrect number with the pilot number for the trunk; for example 0386097220 (commonly, the pilot number is reception or the main Auto Attendant number). However, if the trunk to the PSTN is a SIP Trunk, some Telcos will drop the call. This is because the Telco does not recognise the B Party number as being part of the number range your organisation owns. When tracing, this is commonly represented by a 404 Not Found response from your SIP trunk provider.

Applying the above logic to Simultaneous Ring or Call Forwarded calls, you may start to see where the issue arises. If the B Party number (the Lync User’s number) does not appear anywhere in the outbound SIP INVITE, it’s impossible for me to manipulate out into the FROM field of the SIP header.

Even when working with SIP Trunk providers who do not drop the call, and treat the call the same was as ISDN (replacing Calling Number with the pilot number), it is still of benefit to know what the B Party number is for outbound calls, for a couple of reasons:

  • Better decision point for users receiving a forwarded/simultaneous ring call
    • When a user receives a simultaneous ring call on their mobile phone, the call appears to be coming from their own Direct in Dial (DID) number instead of the Pilot number for the organisation. Either someone is standing at their desk and calling them from their phone (unlikely), or they can be confident in the fact that this is a forwarded/simultaneous ring call for them, and not a call from reception.
  • Deployments with multiple area code SIP trunks deployed on a single gateway
    • For sites with a single area code SIP trunk terminated on their SBC, not knowing the B Party number and displaying the Pilot Number for forwarded/simultaneous ring calls may not be a problem. But what about deployments that have multiple area code SIP Trunks terminated on a single SBC? How would you know what pilot number to use for the Calling Number field? Knowing the B Party numbers resolves this issue.

What’s the Fix?

In the following configuration/traces, I’m using the following parameters:

A Party:                 +61 431 987 654 (Call From PSTN)

B Party:                 +61 3 8609 7222 (Lync user Patrick Bateman)

C Party:                 +61 400 734 033 (Patrick Bateman’s Mobile)

Lync 2010

The Lync Server 2010 Cumulative Update 2 (CU2) introduced a fix that allowed for B Party information to be present in the outbound call forwarding/simultaneous ring INVITE. Below is a trace of a simultaneous ring outbound SIP INVITE without the fix (note the lack of B Party information anywhere in the INVITE)

4

Applying the Fix

Lync Server 2010 Configuration

  • Ensure at least CU2 is applied across your Lync 2010 environment
  • On each Lync 2010 Server in your deployment hosting the Mediation Server role, run Notepad as an administrator and open MediationServerSVC.exe.config located in Program Files > Microsoft Lync Server 2010 > Mediation Server:

5

  • You should be presented with this:

6

  • Add in the following configuration (highlighted in red below) with one “add key” entry required per PSTN gateway in your deployment. In this example, the PSTN gateway is configured to communicate via TCP (unsecured), so the IP address of the gateway was configured in Topology Builder instead of the FQDN. Make sure you enter in the FQDN of the PSTN gateway if that’s what you have used in your deployment:

7

<?xml version=”1.0″ encoding=”utf-8″?><configuration>  <appSettings>

      <add key=”192.168.0.160.ReferredBySupported” value=”true”/>

  </appSettings>

<runtime>

<generatePublisherEvidence enabled=”false”/>

</runtime>

</configuration>

8

  •  For the change to take effect, you’ll need to restart the Mediation service (if the service fails to start, you’ve made a mistake when editing the MediationServerSVC.exe.config file. Fix the errors, and try again):

9

Looking at a call trace now, notice the addition of B Party information now contained in the REFERRED-BY Field:

10

Now that we have the B Party information we want in the SIP INVITE, the next step is to configure the SBC to take this value and use it as the Calling Number for the outbound SIP INVITE to the SIP Trunk provider. In this example, we are using a Sonus SBC1000 as our Session Border Controller.

Sonus SBC 1000 Configuration

  • First up, let’s look at the existing Lync – ITSP transformation table I had configured that did not take into account the Referred-By B Party value for the outbound INVITE:

11

  • Using this as a base, here’s a new table I created where I’ve added a new entry: Redirecting Number:

New Blog Transformation Table

  • The Input Field Type Redirecting Number will take the Referred-By value, and as shown above we are outputting to Calling Address/Number. The second Redirecting Number entry is a catch all, ensuring the route table entry is still valid for non-forwarded call that won’t have the Referred-By field present.

With this configuration in place, when an outbound SIP INVITE is received at the SBC with REFERRED-BY in the header, the B Party number is manipulated by the new transformation table and slotted into the Calling Number field on the outbound SIP INVITE to the ITSP. Looking at the trace below, you can see the Received Simultaneous Ring INVITE (Arrived 22) showing the A and C Party, followed by the INVITE that’s sent to the SIP Trunk Provider with the Called and Calling numbers we want: B Party and C Party:

15

Delving a little deeper in the logs, you can see the Successful REGEX match of the Redirecting number with the B Party number, and it being successfully manipulated ready to send out to the Telco:

Successful regex match of “tfRedirectingNumber” field for “(\+.*)” (updated “(\+.*)”) with input of “+61386097222Regex replacement output of “tfCallingNumber” field is “+61386097222Performing OPTIONAL transformation using entry Lync – ISDN: CLI (8.7(6)).Successful regex match of “tfCallingNumber” field for “\+61(\d{9})” (updated “\+61(\d{9})”) with input of “+61386097222Regex replacement output of “tfCallingNumber” field is “386097222

Finally, here’s the outbound INVITE to the SIP Trunk provider:

16

Lync 2013/Skype for Business 2015

Lync Server 2013 introduced the ability to present B Party caller info in the outbound SIP INVITE, however there was a bug within the Mediation Server role up until CU2 that prevented the information from being added to the SIP INVITE if the user’s Line URI was configured with the extension (i.e. +61386097222;ext=7222). In CU3, this issue was resolved.

Before we configure anything, below is a trace showing no B Party information in an outbound Simultaneous Ring SIP INVITE from the Mediation Server Role:

17

Applying the Fix

Lync Server 2013/Skype for Business Server 2015 Configuration

Unlike the 2010 fix, there’s no need to update any Mediation Server config files. First up:

  • If you are still on Lync Server 2013, ensure at least CU3 has been applied across your Lync 2013 environment
  • From the Lync Control Panel, open Voice Routing > Trunk Configuration and tick Enable forward call history

18

  • Wait for replication across your Lync environment

19

20

  • Now that we’ve enabled forward call history, here’s a trace showing B Party information in the outbound SIP INVITE from Lync. Note that the B Party information is found in the HISTORY-INFO field, not the REFERRED-BY field as it was in the Lync 2010 fix:

21

Sonus SBC 1k2k Configuration

The following table will capture B Party information if it’s present (i.e. a Forwarded or Sim Ring call). Note the inclusion of the second entry for Redirecting Number. This allows us to use a single table for all outbound calls from Lync, regardless of whether or not HISTORY-INFO is present or not. This negates the need to use two separate tables. This is possible, as regex (.*) on a Sonus gateway means “something or nothing”. If it’s not there, it still matches, and passes through nothing:

New Blog Transformation Table


 

I hope you have found this blog post useful. If you would like to know more about Lync and Sonus integration, would like a demo or would like to talk more about a solution that’s right for you, feel free to get in touch: damien.margaritis@insynctechnology.com.au.

26 thoughts on “Manipulating Calling Number for Simultaneous Ring and Forwarded Calls

  1. Pingback: Manipulating Calling Number for Simultaneous Ring and Forwarded Calls | dmunified | JC's Blog-O-Gibberish

  2. Great article, should be put on Nexthop… oh sorry, that blog has been doomed 😦
    Nevermind.

    I am curious whether the ;ext=XXXX syntax -used in the Lync Lineuri parameter- can cause issues if call sent over a
    1) ISDN trunk
    2) SIP trunk

    In case #1, the caller number transformation rule will contain the ;ext=XXXX part? Or, -unless you add a transformation entry “caller extension” – Sonus completely removes that part from the caller number when sending to the ISDN trunk? As I dont think there there is any ISDN field for such “extension” parameter in the TDM world.
    In case #2 I would have an expectation that it may cause troubles, as over SIP the SBC can send that part of the Lineuri without any issues.

    • Hi Soder, great to hear you like the article 🙂

      Regarding your query, yes you will need to use “calling extension” to strip off the extension field before routing out to a SIP Trunk provider. On older versions of Sonus (NET) firmware the calling number field would take care of this, but somewhere late in the version 2 code releases cycle the logic changed to need to manipulate the extension separately. I haven’t got my lab gateway up to test for you, but to err on the side of caution I would strip off the extension field as a matter of house keeping regardless if the destination is an ISDN or SIP trunk.

      Damo

  3. Hello Damien, I’m trying to apply this great article to my infrastructure, but in the history-info, I still have the C party, not the B one; so the rules are not applied. Is there anything to modify on the lync side regarding the history info to have the right info (because having the C party in this field is not really useful) ? Thanks for your answer

  4. Do you find your “C party” requesting the CLID of “A party” be delivered instead of “B”? That seems quite a common request up here in the great white north…hard to provision due to SIP trunk restrictions from most carriers.

  5. Hi Damo,

    A nice tip on the above subject – you no longer need use a SIP Header rule with this behaviour on the Sonus. Simply using the “Redirecting Number” field will suffice for capturing the B Party’s CLI and changing the A Party’s Calling Number details.

    I’ve added this to most of my default Lync to ITSP rules (without requiring a dedicated “SimRing” routing rule) as an optional translation rule and it saves the additional config.

    As always, a great write up.

    Cheers,
    Dan.

    • Hey Dan, you are correct. As of one the more recent code releases (couldn’t tell you the exact one), the built in Redirect field will also work with Lync 2013, when the B Party number is contained in History-Info. Update pending

  6. Hi,

    I am on cu3 and I see the History-Info in my request, however the number that is showing up there is the forwarded call(party C) and not the party B number. So basically my To and History-info are the same. Any suggestions? Appreciate your help! Thanks

      • Thank you for your reply. I have been searching this issue and i think many people have the same problem. Do you know if there is a way to customize the sip header?

      • Looks like Nico in this post (one of the above comments) is having the same problem. I have a second trunk configured and not using the Global trunk. Could this be the issue?

      • I regularly use pool or site level trunk configuration to ensure the correct configuration on a per gateway basis. Send me details of your A,B and C parties, along with all relevant traces, happy to cast my eyes over them.

      • Hi Damien,

        I am also facing same issue, do you find any fix for this.

        Awaiting for your kind information.

        Your help would be really appreciable,

        Thanks
        Varun

  7. Yes having same issue we are using radius billing and we do not need history info header I have upgraded to Lync Server 2013 5.0.8308.920 so we do not need history info header but still coming. Please help we have had issues since upgrading to CU3 and CU4. Need help.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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