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).