Calling Number Translation in Lync Server 2013

Lync Server 2013 has made life a little easier for Lync engineers and telephony administrators by enhancing its call routing options. With its new calling number translation feature, you can define a translation rule in the Lync dial plan to change the format of a Lync caller's phone number. You can even use this feature to display a different number on the recipient's caller ID. To understand how this new Enterprise Voice capability works, it's helpful to look at how phone number translation works in Lync Server 2010 compared with Lync Server 2013. After this comparison, I'll show you how to configure calling number translation. 

Lync Server 2010 Phone Number Translation

Let's start at the beginning. Lync Enterprise Voice requires that all dial strings be normalized to the E.164 dialing format for the purpose of performing reverse number lookups. This enables the Lync server to route calls in a more efficient manner and look up Lync clients based on their unique phone number.

Within Lync Server 2010's trunk configuration, you can modify the format of the dialed phone number using an outbound translation rule to ensure the format matches the type required by the PBX. Unfortunately, you can't do the same with the caller's phone number in Lync Server 2010.

For example, suppose a caller needs to make an outbound call from Lync to an IP-PBX by means of a Session Initiation Protocol (SIP) trunk to a Public Switched Telephone Network (PSTN). The reason there's a SIP trunk is that the SIP peer is an IP-PBX instead of a legacy Time Division Multiplexing (TDM) PBX, which would require a PSTN gateway between the Lync Mediation server and the PBX.

In this scenario, IP-PBXs prefer that the phone numbers they receive be in a format that they can recognize—and this format isn't always E.164. Most IP-PBXs prefer numbers without the plus sign (+). For this example, let's say the Lync caller's phone number is +14255558585 (i.e., the calling number) and this person is dialing the phone number +14253451212 (i.e., the called number), as Figure 1 shows. After the normalization rule is applied and reverse number lookup is performed, the called number is translated to 14253451212. Notice that the plus sign has been removed from the called number. This is an example of the called number being translated into a format that the IP-PBX prefers. What Lync Server 2010 wasn't able to do was to manipulate the calling number (+14255558585).

Figure 1: Understanding Phone Number Translation in Lync Server 2010

Lync Server 2013 Phone Number Translation

Lync Server 2013 provides a way to have translation rules support calling numbers. As I mentioned previously, the PBX (i.e., the trunk peer) might require that numbers be in a specific dialing format. To translate numbers from the E.164 format to another format, you can define one or more translation rules to manipulate the request Uniform Resource Identifier (URI) before you route it to the trunk peer.

Figure 2 illustrates how this works. The caller, whose phone number is +14255558585, calls the phone number +14253451212, with normalization and reverse number lookup taking place. Because of the outbound routing translation that's within the Lync dial plan for the called party, the called number has been formatted to 14253451212 (same number but no plus sign) for the PBX. Now comes the interesting part: The called party will see the caller ID of +14253455000. Notice that the last seven digits of the caller's Direct Inward Dialing (DID) number have changed. (Note that in Figure 2, I highlighted the last four digits instead of the full seven digits of the calling number to show the area that most organizations would consider changing with the calling number translation feature.)

Figure 2: Understanding Phone Number Translation in Lync Server 2013

How to Configure the Calling Number Translation Feature

To take advantage of the calling number translation feature, you need to configure a calling number translation rule. To do so, open the Lync Control Panel, go to Voice Routing, and select Trunk Configuration. Go to the trunk you want to configure, click Edit, and select Show details. In the Edit Trunk Configuration pane, click the New option in the Calling number translation rules section. Next, specify a name for the rule, the pattern to match, and the translation pattern. For example, Figure 3 shows a fairly straightforward calling number translation rule named Test Rule. It looks for any calling number that contains 10 digits and begins with +1. Calling numbers that match this pattern will be displayed as 14253455000 on the recipient's caller ID (or in the next hop of the Lync Mediation server). Notice that this time I chose not to include the plus sign with the calling number.

Figure 3: Configuring a Calling Number Translation Rule in the Lync Dial Plan

To save the calling number translation rule, click the OK button at the top of the pane. In the Trunk Configuration section, you can test the translation rule by entering the phone number that's to be dialed by the user in the normalized state. So, as Figure 4 shows, the phone number +14255558585 is how the number would be displayed in its normalized format for the Lync client. By selecting the Calling number option, you can see that the calling number translation rule:

Figure 4: Validating the Calling Number Translation Rule

Notes to Take Home

The recent changes made to phone number translations in Enterprise Voice can make life easier for PBX and Lync Server 2013 administrators alike. The ability to configure and design dial plans that involve masking call routes from the Mediation server to the next hop, which can be either a PBX or a PSTN gateway, will allow more options for Lync administrators. Keep in mind that the calling number translation feature is an improvement that might not be needed in some organizations' existing Lync 2013 deployments if those organizations are already implementing this capability through their current telephony infrastructure. But the good news is, going forward, organizations will be able to configure these changes on the Microsoft side of the house, taking one less responsibility off the shoulders of the PBX or PSTN gateway administrator.