At the end of last month we were introduced to some additional Cloud PBX functionality around Call Queues and Auto Attendants. As part of these updates we now have the ability “To protect user anonymity, by allowing users to make outbound calls on behalf of an Auto Attendant or Call Queue”, which in layman’s terms means we can change a users outbound caller ID to be the same as a number that’s associated with an Auto Attendant or Call Queue. This adds further flexibility to the caller ID control within Cloud PBX, which until this point was basically limited to ‘display my number’ or ‘don’t display my number’. Yes this type of functionality will provide user anonymity, but perhaps more importantly it will improve the callee experience; ensuring that the number they call back on for a missed or returned call isn’t going to someone who “doesn’t work on Friday”, but instead to a Call Queue that will result in a useful conversation.
With the addition of the above functionality, we now have the ability to control Cloud PBX caller ID as is most commonly required in organisations today;
Pass-Through – Allowing the users assigned telephone number to be displayed as their caller ID for all outbound calls.
Anonymous – Preventing the users assigned telephone number (or any other number) from being displayed as the caller ID for all outbound calls.
Modified – Presenting an alternate Auto Attendant or Call Queue service number as the caller ID for outbound calls. You cannot modify the caller ID to another user number, it must be a service number.
Control of these preferences is managed through CallingLineIdentity policies, with a single global policy existing by default which applies to all users. Additional Policies can be created as required and assigned to users with the New-CsCallingLineIdentity and Grant-CsCallingLineIdentity cmdlets respectively. Note that you cannot create two policies with the same settings, even if the identities and descriptions are different. Variables of note within the CallingLineIdentity policy include;
BlockIncomingPstnCallerID – When set to true, blocks the incoming caller ID. If I’m honest I struggle to find a great use case for this, and have never had inbound caller ID manipulation raised as a business requirement in the past – it’s a nice to have.
CallingIDSubstitute – Can be set to either LineURI, Service, or Anonymous. If set to LineURI, the users own assigned telephone number is displayed as the caller ID. If set to Anonymous, the caller ID is withheld. If set to Service, the number displayed in the ServiceNumber field is displayed as the caller ID.
ServiceNumber – Only relevant if your CallingIDSubstitute is set to Service, and identifies the service number that you want to appear as the caller ID. This number should be listed in the Skype for Business Online Admin Centre under Voice Phone Numbers, and should have a number type of ‘service’. Trying to assign any other number will result in an error. Note that the leading + should be dropped from the number when setting the policy. The service number that you assign does not have to be currently assigned to an Auto Attendant or Call Queue, although selecting a number that’s unassigned would be largely pointless.
*A Note on service numbers; Microsoft classify numbers as either service numbers or user numbers. Service numbers can only be assigned to services like Auto Attendants and Call Queues, user numbers can only be assigned to users. If you obtain your numbers from Microsoft then you specify how many user numbers and service number you would like. In the same vein if you port your numbers to Microsoft for use with Cloud PBX, you need to declare which of them will be user numbers and which will be service numbers. If you’re using Cloud PBX with on-premises PSTN connectivity, then you’re likely using an SBC that has far greater controller over source number manipulation and can be used to achieve your desired caller ID.
EnableUserOverride – Allows the user to toggle anonymous caller ID on or off depending on their preference. Note that if they set this to off, then the caller ID will honour either LineURI or Service Number depending on what is configured in the assigned policy. Users can access this service through the call forwarding options on their desktop client, under the ‘Show or hide my caller ID – Edit settings online’ link.
Alternately you can go directly to the Cloud PBX User Settings portal through a web browser (https://admin1e.online.lync.com/lscp/usp/pstncalling) to reach the same configuration page.
With similar syntax to all other Skype for Business Online cmdlets, creating, modifying, and assigning CallingLineIdentity policies is no dark art. As usual it will take around 2-5 minutes for any assigned policy to take affect due to the nature of Office 365;
New-CsCallingLineIdentity -Identity “Reception” -CallingIdSubstitute “Service” -ServiceNumber 441392123456 -EnableUserOverride $False -Verbose
Grant-CsCallingLineIdentity -PolicyName Reception -Identity ben@gecko-studio.co.uk
Of final note is the unrelated CallerIdPolicy pictured below. This cmdlet has since been deprecated and although the name suggests that this is the policy you’d use to control caller ID, you’ll receive an error when you try to modify or assign this policy to a user. I expect this to be removed in due course as the platform is updated.
Typically in an organisation, outbound caller ID’s are addressed in a logical fashion; either organisation wide, by department, or by role, rather than on an individual basis. The introduction of further flexibility around caller ID’s in Cloud PBX now means we can scratch off another “I’m not considering Cloud PBX because…” reason from the list, and achieve what is typically required of a traditional PBX in most cases. Yes that list is lengthy, but for a lot of organisations its getting real short real quick, and if you can’t see the end game… then you may as well go and play with some copper wire.
