Hiding your Caller-ID in Lync 2013

An unintended feature for some...

There may be times (and it may be all the time) where you do not want you caller-id (CID) to be presented when making an outbound call. If you have moved to Lync 2013 or plan to move to Lync 2013 this featute may be available for you. The mayambiguity comes from your unknown - what SBC are you using and how is it configured. As of today, the IntelePeer SBC that is being used can make this happen...

To start, the Lync 2013 Server product introduced many new features including the ability to include P-Asserted-Identity history in the SIP signaling. This additional features is intended to allow the originator's ID to be masked with a new identity allowing forwarded calls to be 'authenticated' by the originating number but display to the receiving party as the forwarded user. This concept may be defined as follows (and may be found in RFC3325):

"Lync User" <sip:lyncuser@domain.com>
"Outside Caller" <sip:+14805551212@domain.com>
"My Cell" <sip:+16025551212@domain.com>

Outside caller calls Lync User who has call forwarding enabled on their phone. Ideally when the call is forwarded to the Lync user's cellular device it displays the caller ID of the Outside Caller, not the Lync User. This worked just fine in the past with SIP Trunk Providers and SBCs that supported Lync Server. However, if you have ever worked with a non-certified SIP trunk provider the call was typically denied as it appeared to be a call from the Outside Caller using the company’s SIP trunk (and that is not allowed). Using the P-Assert-Identity history these carriers would be able to recognize that the call was actually originating from the Lync User but the CID was simply being masked with the Outside Caller’s CID.

So how does this help us in hiding our CID you ask? Well, again, this depends on the SBC and how it interprets RFC3325. Currently IntelePeer and their SBCs interpret the RFC to mean mask ALL CID information. So, if this feature is enabled on the trunk, all CID is blocked and the recipient receives an incoming call that is shown as PRIVATE. This feature may or may not remain in effect but as of today it works. For your own SBCs, it may be an option to configure this as well.

Configuring Lync 2013 to block PRIVATE numbers is a simple task if you want it to be global. If you do not want it to be global, but perhaps for some users, additional voice policies, PSTN usages, and routes would need to be defined to create a one-off setup. To enable the option globally from the Lync Control Panel navigate to Voice Routing | Trunk Configuration.


What you display here will be different based off your configuration but the ideas and concepts are the same. If you only have a single trunk, the configuration may be in the Global Policy. If you have multiple trunks as shown then you would want to modify the policy(s) that apply to your trunk.

To modify the policies select it from the list and double-click (or select Edit | Show details…). Once in the policy you will see many new options; the one we are concerned with is Enable forward P-Assert-Identity data. Select the box to enable to feature and click OK to close the dialog.


You will need to commit the changes (Commit | Commit All) and then have a little patience. Once committed, the changes must be replicated to the Mediation Servers which may take a minute or two. If you want to see this change within the Event Viewer, search for Event ID 25091 which will look something like this:

Information       10/3/2012 5:32:27 AM    LS Mediation Server       25091   (1030)

Trunk configuration has changed
Trunk: 1-la01.intelepeer.com;trunk=1-la01.intelepeer.com
ByPass Enabled: False
Forward PAI Enabled: True
Forward Call History Enabled: True
Refer Supported: False
3pcc Refer Supported: False
SRTP Mode: NotSupported
Online Voice Enabled: False
RTP Latching Enabled: False

Once that Event Log has been logged, you may make an outbound call and check the results. If all the stars have aligned in your configuration, the recipient of the call will see the CID of the incoming call as PRIVATE and will probably not answer.

For further validation that the feature is enabled you may capture and inspect Lync Server Logs (IncomingAndOutgoingCall scenario). After you have captured the logs, open then in a text reader (such as notepad) and search for Privacy:id (not ms-privacy:id as that is always there). If you want to use Snooper to view the logs unfortunately this particular option is filtered and not shown so be aware – use a text viewer. Assuming the Privacy:id option is listed in the call setup things are configured as expected. If not, either the caller did not use the route you modified or the configuration has not replicated (Event ID 25091).

Receptionist 'Night-mode' in Lync 2010/2013

During deployments of Lync we are often asked to mimic existing PBX solutions where possible. Initially deploying Lync as near identical to the existing solution reduces adoption rate and allows new and exciting feature to be slowly introduced. One of the features that are often requested is 'night-mode' by the company's receptionist. It is not uncommon that at the end of the day the receptionist will simply dial a specific code diverting all incoming calls to the afterhours message and the reverse at the start of their business day.

A similar solution, ideally utilizing a response group for added functionality (although a simple voicemail box would work as well), can be setup within Lync. The changes are visual rather than a calling code but otherwise the solution works as it did.

The original call flow would be something like:

During Business Hours
PSTN caller à Main Number à Receptionist Phone Rings

After Business Hours
PSTN caller à Main Number à Afterhours Message/ACD

For this solution to work as expected we start with a few simple requirements:

  1. Lync 2010 is deployed with Enterprise Voice
  2. The Lync Attendant or Lync Client is utilized
  3. Exchange 2010 Unified Messaging is deployed
  4. A Lync Response Group, Exchange Auto Attendant, or Exchange Unified Messaging Mailbox is the destination when calls are not answered.

That’s it! Nothing too fancy! Now we get to configuring the client.

We will the assumption that there is a Lync Response Group that exists to field unanswered calls to the main number. This RGS is configured as follows:

Internal caller à Main RGS à Decision Tree à Exchange Unified Messaging

Alternatively we could use an Exchange Auto Attendant or a Lync Announcement Service but for this example we will stick with the Lync RGS.

To create the Lync RGS we start with the Lync Control Panel and J work Right-to-Left.


The Group may contain one or more ‘real’ users but as long as it contains a user this will work. I typically will provision a dummy user – an EV enabled user without a TEL URI that I can place in this group. The purpose of the dummy user is to simply have them always signed out so that the RGS moves through its logic quickly.

We start by clicking on the Response Group section within the Lync Control Panel, then Group, the New.


Select the Application Server that the Group will be hosted on and click OK. Within our new Group we must give it a name and configure the settings. For this example we will configure it with a name of NightModeGroup with a dummy agent.


We then move to then next tab on the left and create a Queue. The Queue defines what happens when a call is received in the Queue, to whom, timeouts, and next hops. Again we start by clicking New on the Queue tab, selecting the same Application pool we selected when making the Group and clicking OK.

We called the Queue NightModeQueue but you can name it whatever you wish. Click select under Groups to bring up the dialog box with the groups and select NightModeGroup. Because we want the call to eventually terminate somewhere we have enabled the queue time-out and selected voice mail as the destination. A previously Unified Messaging enabled mailbox would need to be setup and in this case I have identified the mailbox as Main (sip:main@domain.com;opaque=app:voicemail). As shown below.


Now that our Group and Queue have been created we can move to the Workflow or RGS itself. Moving along the tabs at the top to the left we select Workflow and then click Create or edit a workflow (you can bookmark and go directly to this link). This selection launches a web browser where the workflow is actually created. Again, make sure the application pool that is selected is the same pool where the Group and Queue were created.

The Response Group Configuration Tool is where workflows are created, modified, and removed. A fancy Interactive workflow could be created but for the purposes of this example we are going to do a simple hunt group. Click Create next to Hunt Group to launch the wizard.


The Hunt group can be used to play a message and hold music while it attempts to locate a person. In our use, the person in question is offline so it will immediately flow to voicemail after the 10 second timeout. Had this been an Interactive it could have presented options for calling someone by name (passing the call to Exchange Unified Messaging), ringing a department, or even an afterhours operator.

We filled out the form with basic information giving the TEL URI a non-DID so that it could not be reached from the outside, and placed our main number as the Display Number. Remember, do NOT use the main number here as that number will be assigned to an account name receptionist – this workflow is only a rollover number.


Next we select our main language and configure a Welcome Message. Ideally the welcome message is a pre-recorded WAV file but in this example we are utilizing the text-to-speech engine. You may also skip this step and simply record the message on the Voice Mailbox if that is where the call is going.


You will also notice we left our business hours as working 24x7. This is important as we want the workflow to run anytime it is reached and it should never be reached unless we are unavailable. Because of this, we can also skip the holiday hours settings moving us to the queue selection.


From the drop down select the NightModeQueue and click Deploy to create the RGS. The process is near immediate, but may take up to 5 minutes to become functional. If the number you entered was not a valid routable number you can call the number by normalizing the number manually within Lync – simply enter +5000 within Lync and you should be able to call into the queue.

Now that we have the afterhours destination configured we can move to the client settings. There are two main configurations that we will want to make within the Receptionist client. As a reminder the receptionist account has the following properties:

  1. Usually a shared account that all users who cover the front desk know how to login/out OR the computer the Receptionist is logged into is never logged out.
  2. The computer where the Receptionist is logged into with Lync is dedicated. This is especially true when the Lync Attendant Console is used
  3. The main number is set to the Receptionist within Lync Control Panel

The configuration for the night mode is completed under the call forwarding section of Lync. This can be accessed in multiple ways but the simplest is to simply click the drop-down Call forwarding settings here and select Call Forwarding Settings.


With call forwarding turned off, we want to set the unanswered calls to the RGS previously created. To do so, simply click the hyper-link next to Unanswered calls and select new Number or Contact. Enter +5000 as the new number and click OK. The default timeout is 20 seconds or approximately 4 rings – adjust as necessary. With this setting, should the Receptionist not get to her phone within the 20 second timeout, it would ring to the afterhours number. This also ensures that if the evening forwarding is forgotten calls will still reach the afterhours greeting (with an additional 20 second delay).

With the +5000 number being entered as the unanswered number it is now quickly available for forwarding. This allows the Receptionist, at the end of the day to simply quickly select the Night Mode from the call forwarding settings. Simple drop down the call forwarding option, select forward calls to and select +5000. In the morning, selecting Turn Off Call Forwarding turns off the ‘Night Mode.’

There are all types of scenarios that can be addressed with Microsoft Lync when it comes to voice and the PBX replacement – knowing the features and maximizing their options is where things are key. In this example we used the power of call forwarding, Response Groups, and Exchange Unified Messaging. Remember, Interactive Response Groups and the Announcement Service could be used as well as a simple forwarding to a voice mailbox.