Cloud PBX with PSTN Calling is one of the new features that Microsoft made available to Office365 customers on December 1, 2015. While Cloud PBX is really an umbrella term that covers multiple topologies and scenarios, the PSTN Calling feature allows user accounts registered to Skype for Business Online to utilize PSTN calling, for functions such as Direct Inward Dial assignment, 911, call management, and others, directly through Office365. For Lync Server administrators out there, you will notice there are definite similarities to on-premises voice concepts but despite those similarities, there are considerable differences as well that need to be considered.
Licensing
Licensing is always one of those difficult conversations but people always ask… I won’t provide cost breakdowns here, as Microsoft may provide you different cost structures based on your existing Enterprise Agreements, but what I will provide is some background on how the PSTN Calling feature fits in with the overall Office365 licensing structure for Skype for Business.
License Bundle Info
Option 1 – Purchase E5 licenses and voice calling plans for your end users
The Cloud PBX license is included within the E5 suite purchase but voice calling plans are not included so you will need to purchase that separately. There are two voice calling plans available – local or local/international – so you can purchase a voice calling plan that meets your business needs. Once both licenses are purchased, you can assign the E5 suite license and voice calling plan to your users, which grants them access to Skype for Business Online, PSTN Calling and any additional features available through the E5 suite.
Option 2 – Purchase Cloud PBX Add-On licenses and voice calling plans for your E3 and E1 users
If you have existing E1 or E3 suite purchases, you would need to purchase the Cloud PBX Add-On license and then purchase a voice calling plan. The voice calling plans are no different than in Option 1. Once both licenses are purchased, you can assign the E3 suite license, Cloud PBX add-on license, and voice calling plan to your users, which grants them access to Skype for Business Online, PSTN Calling and any additional features available through the E3 or E1 suites.
Option 3 – Purchase Cloud PBX Add-On licenses and voice calling plans for your Skype for Business Online Standalone Plan
This option will likely be less common, but if you have a Skype for Business Online Standalone Plan, you can purchase the Cloud PBX Add-On license and a voice calling plan for those users. The voice calling plans are no different than in Option 1. An important distinction is that the Standalone Plan must be Plan 2; Plan 3 is not supported.
Licensing Availability
Not all tenant regions can purchase the PSTN Calling feature. Microsoft will continue to add tenant regions during CY 2016, but you will need to check and see if your tenant region is currently available. Current regions include:
| Country/region |
| United States |
PowerShell Licensing
Many folks out there handle licensing of Office365 accounts through PowerShell scripts and the structure of the Cloud PBX license is a huge improvement to what is offered for the configuration of licensing for E1 or E3 or E5 suite components. While assigning the base Skype for Business Online license is done through the E-suite license, the Cloud PBX license and voice calling plan license are actually separate SKUs within your tenant. As a result, licensing AccountSkuIDs look like this:
AccountSkuID ------------ UCVNEXT:STANDARDPACK UCVNEXT:ENTERPRISEPACK UCVNEXT:MCOEV UCVNEXT:MCOPSTN1 UCVNEXT:MCOPSTN2
The MCOEV AccountSkuID is the license for the Cloud PBX Add-In.
The MCOPSTN1 AccountSkuID is the license for the local voice calling plan.
The MCOPSTN2 AccountSkuID is the license for the local/international voice calling plan.
Assigning the Cloud PBX and international voice calling plan AccountSkuIDs to a single user account within Office365 is a simple set of PowerShell commands:
Set-MsolUserLicense -UserPrincipalName [email protected] -AddLicenses "UCVNEXT:MCOEV" Set-MsolUserLicense -UserPrincipalName [email protected] -AddLicenses "UCVNEXT:MCOPSTN2"
For bulk adds, you can utilize a CSV file containing UPNs and assign licenses to your users en-masse:
Set-MsolUserLicense -UserPrincipalName $_.userprincipalname -AddLicenses "UCVNEXT:MCOEV" Set-MsolUserLicense -UserPrincipalName $_.userprincipalname -AddLicenses "UCVNEXT:MCOPSTN2"
Remember that all users receiving the MCOEV and MCOPSTN licenses must have the Skype for Business Online license previously applied to the account. Trying to assign the MCOEV license will result in failure if the account does not already have the Skype for Business Online license.
As an aside…if you aren’t handling licensing through Powershell…you should be. Stop assigning licenses through the Office365 Admin Portal and automate!
Local Number Availability
PSTN Calling is currently limited to US markets only, so obtaining numbers will be limited to DIDs available within the US. When it comes to obtaining numbers, there are two potential options:
Option 1 – Obtain new numbers directly from Microsoft
In this option you select numbers from Microsoft and assign the numbers to your end users. Microsoft currently supports local numbers in the following regions. This option can be managed directly within the Office365 Admin portal, making administration very easy, or via Powershell for your more advanced automation needs.
Option 2 – Port existing numbers from your current provider to Microsoft
In this option you select numbers from your existing telephony provider to port to Microsoft. There are two approaches to this option depending on the volume of numbers to be ported, but Microsoft includes management of this process within the Office365 Admin portal. Once the port completes you can assign the numbers to your end users just as if you had requested the numbers from Microsoft in Option 1 above.
Importance of Emergency Addresses
A critical piece of the PSTN Calling puzzle is that you must manually define emergency locations within Office365 before you can assign numbers to users for usage with PSTN calling. Each number must be assigned to an emergency location and if it is not, you will find the PSTN Calling license will be removed from the user to which the number is assigned. Despite the requirement for emergency locations, there are several significant limitations that exist – more to come on that later.
PowerShell Configuration
There are several PowerShell cmdlets that will give you additional information about PSTN Calling configuration within your tenant. Some important ones:
The TechNet articles above give examples of utilizing the cmdlets, so be sure to check them out.
Current Feature Limitations
Despite the new-fangledness of PSTN Calling, there are some limitations (some might argue “differences”) that you should consider, especially if you are coming from an on-premises Lync Server or Skype for Business Server deployment.
Dial Plans are Non-Configurable
Every Lync Server administrator has created dial plans to normalize dialed digits into E.164 format for the purposes of voice routing and authorization. With Cloud PBX, dial plans are directly tied to the UsageLocation applied to your Office365 account.
Additionally, the normalization rules within the dial plan are non-configurable. For US customers, this means you’ll be limited to 10 or 11 digit dialing, which may wrinkle the faces of some telephony administrators that utilize 7 digit dialing in locations where it is still available. Since the service isn’t available in regions such as the UK, I can’t comment on what may/may not exist within the dial plan there, but the same limitations will surely apply. While not PSTN Calling related, this also means is that creating normalization rules to handle “internal extensions” or “short dial codes” is not an option for Cloud PBX users that may exist in Hybrid Voice topologies, even though creating those normalization rules is not best practice and not recommended.
Voice Policies are Non-Configurable
Every Lync Server administrator has created voice policies to define feature enablement and call authorization. With Cloud PBX, voice policies are non-configurable and automatically handled by Office365. Every user is assigned the same voice policy with the same PSTN usages of the voice calling plan assigned to their account. Any other configuration is simply not available.
Given that only two voice policies are available it makes selection very simple but may reduce the available options for some customers that only want to provide local calling to certain users instead of providing national calling.
PSTN Usages and Routes are Non-Configurable
In order for calls to egress Lync Server there have to be PSTN usages and voice routes. With Cloud PBX, PSTN usages and voice routes are completely obscured and hidden from the end user and the administrator. You can see from the screenshot above that the PstnUsages parameter is completely blank, so the info truly is hidden away. Microsoft handles all the routing of calls, including any least cost routing configuration. Given the licensing structure around the voice calling plans, losing configuration of these items shouldn’t be a big deal but it is something to be aware of nonetheless.
E-911 Services aren’t fully mature
In my opinion, this may be the biggest limitation of them all. In on-premises Lync Server deployments, administrators had very fine grained flexibility in providing E-911 support to meet the varying requirements required by states in the US. For example, states like Illinois have very strict and complex E-911 legislation that require ELINs be utilized for 911 calls per building floor and per 40,000 sq ft of office space within the building floor. With on-premises deployments you could configure locations based on subnet, wireless BSSID MAC address, or through switchport information, allowing you to be very precise in the location of an endpoint making a 911 call. To top it all off, the IM alerts available with on-premises deployments can be very helpful in alerting security guards, receptionists, or company first responders.
With Cloud PBX, some of the advanced functionality is gone:
- Addresses created within the Office365 Admin portal or through PowerShell define only the building address, also known as the civic address. You must separately define location information, such as floor or a wing or an office ID, within the Office365 Admin portal or through PowerShell to tie the more detailed location information & civic address together so that PSAP operators receive the full info upon receipt of a 911 call.
- While the configuration of location information can be completed within the Admin portal, the user interface places no emphasis on doing so when you create addresses so it is very easy to overlook. If you don’t click on the UI element below after creating an address, you aren’t defining detailed E-911 location information.
- IM alerting functionality is not available.
- Third-party conferencing mode is not available.
- To be fair, for on-premises deployments this required a SIP-based E-911 service be implemented, but it still allowed on-premises security desks to be alerted by phone which is now not available.
- All E-911 location information is tied solely to a phone number which means that any 911 call from your number will always reference a static location configuration, even if you aren’t at that location.
- To be fair, that can potentially happen with on-premises deployments as well, but NOT if you configure E-911 correctly.
- Microsoft calls this current functionality “static E-911” and says that “dynamic E-911” will be coming soon. This may mean that you can add subnets, or wireless BSSID MAC addresses, or switchport information into Office365 at a later date, but I have doubts those features will make it into the solution.
Dynamic E-911 is a tough subject and has varying definitions depending on whom you ask, but I believe that Microsoft will instead implement an E-911 Call Screening Center, similar to what Intrado or 911-Enable uses, to answer 911 calls and transfer calls to a PSAP as necessary as their “dynamic E-911 service”. While this screening center is nice, it doesn’t help when a caller can’t talk or the line is cut and the PSAP operator can’t determine the correct address. The aforementioned scenario could be true with existing PBXs, but on-premises Lync Server can report correct civic address info when E-911 is correctly configured either through SIP-based E-911 services or ELIN gateways. For true dynamic E-911 compliance, Microsoft needs to add the ability to define locations based on what is available for on premises Lync Server deployments via subnets, wireless BSSID MAC addresses or switchport information. Employee life safety is a big deal, so make sure that the 911 services provided meet not only regulatory requirements, but any internal legal/HR requirements.
Quality of Service may not be available
For all Skype for Business Online workloads up until now, the traffic traveled directly from your corporate network across the public Internet. This means that once the traffic leaves your network, there are no guarantees to performance and could mean significant latency depending on your network design. Microsoft recently announced that ExpressRoute will support Office365 workloads, including Skype for Business Online. This means that you could deploy ExpressRoute and utilize the dedicated MPLS circuits to tag traffic and prioritize it appropriately. If QoS is a firm requirement for your organization, check out my previous post discussing it to determine your available options.
Advanced ACD Features not supported
Some of the more advanced automatic call distribution features available with on-premises deployments are not available within Office365. The biggest limitation here is Response Groups are not supported within Office365 yet. Features like team-call are supported and can replace Response Groups for simple ACD scenarios, but for true ACD implementations you may have to keep users on-premises until the feature is fully implemented within Office365.