In the series of Cloud PBX Skype academy videos this is Cloud PBX using on-premises PSTN connectivity using Cloud Connector Edition (CCE). This is where you don’t have an existing Lync or Skype for Business Server deployment so greenfield but you have the requirement to use your existing PSTN connection with Cloud PBX.
CCE is a smaller footprint on premises deployment than deployed a full server deployment. Users are all homed online and CCE is used to connect to your on premises PSTN for Cloud PBX users.
Brian nice, principal program manager in Skype product group at Microsoft.
This is based on CCE version 1.4.1 release
What is Cloud Connector and Architecture
Cloud Connector is an extension to SfB Online Service
provides PSTN interconnect for SfB Online users.
Users are homed in SfB Online but PSTN is coming via the on premises Cloud Connector. User still leaves in the cloud but interconnect for PSTN is deployed on-premises.
Cloud connector is a dedicated hypervisor running Hyper-V that has set of sealed virtual machines (4), the VMs perform discrete functions such as Edge, Mediation server, domain controller and CMS.
This is a dedicated appliance and the components work in tandem with each other. The Active Directory deployed in CCE is for the its own environment it has NO communication or integration with an existing on premises active directory. Its its own forest.
The appliance has sip trunks to PSTN Gateways, dial plans is assigned online based on where the user is located. There are options online to restrict internally dialling.
External DNS (SRV and lyncdiscover) is pointed to SfB online not on premises! (There are External DNS records required for CCE but client discovery is pointed to SfB Online)
Key to note in version 1.4.1 there is no support for co-existence with an existing on premises Lync or SfB Servers. Key to note.
There is no media bypass so media always flows via the mediation server!
Users can be created on premises or created in the Cloud. Most organisations will have AD sync via Azure AD connect so users are synced to online.
Below Johns signing in to Skype for Business Online, his SfB client talks to SfB online when John makes a PSTN call now the call signalling is routed from SfB online down to Cloud connector. The call signalling from SfB Online infrastructure to CCE edge to CCE mediation to CCE PSTN GW.
Media traffic will flow via CCE Edge as John is external and on the internet then from CCE Edge to CCE Mediation then from CCE Mediation to PSTN GW.
Media bypass cant be used as discussed earlier
Deployment Planning – MOST CRITIAL STEP HANDS DOWN
Follow TechNet documentation using the link below
Also worth checking is Skype operations framework
Capacity and PSTN connectivity types are key as these can be different at each site.
Firewall – make sure all required ports are open.
Make sure you have your office 365 Administrator credentials.
Critical one to start with no existing on premises deployment of Lync or Skype for Business server deployed on premises. The current version does not support co-existence!
Qualified PBX / SIP trunk / SBC / Gateway for a full list go here
Dedicated hardware is required for hyper v. the hardware is dedicated for CCE.
Capacity is key and with two different flavours based on hardware specs.
- Large – typically 500 calls per cloud connector
- Small – 50 calls per cloud connector (Great for Proof of concepts or smaller call concurrency site requirements)
Hardware spec from above URL
The necessary hardware to support installation of the 4 VMs for each Cloud Connector Edition in your deployment.
The following configurations are recommended: (Large 500 simultaneous calls)
64-bit dual processor, six core (12 real cores), 2.50 gigahertz (GHz) or higher
64 gigabytes (GB) ECC RAM
Four 600 GB (or better) 10K RPM 128M Cache SAS 6Gbps disks, configured in a RAID 5 configuration
Three 1 Gbps RJ45 high throughput network adapters
If you choose to deploy the smaller version of Cloud Connector Edition that supports up to 50 simultaneous calls, you will need the following hardware:
Intel i7 4790 quad core with Intel 4600 Graphics (no high end graphics needed)
32 GB DDR3-1600 non ECC
2: 1TB 7200RPM SATA III (6 Gbps) in RAID 0
2: 1 Gbps Ethernet (RJ45)
General guidelines, you can up to four Cloud Connecters per PSTN site.
PSTN site is defined in cloud connector when registering. If you have N+1 model with 500 per CCE and 3 active and one idle that gives 1500 simultaneous calls.
N+1 allows for one CCE to fail and still keep 1500 simultaneous call. You could go for all 4 CCEs active and have max 2000 but if one failed you will lose 500 straight away and there’s a risk.
With smaller CCE you can do the same but call capacity is lower with 50 calls per cloud connector, with N+1 again 50 * 3 = 150 simultaneous calls.
Host server runs Hyper-V and require internet access, public DNS resolutions and remote PowerShell.
GPO required to prevent forceful unload of user registry at logoff.
Base VM requires internet access and public dns resolutions
External DNS records are required for CCE Edge server and with HA if you have 3 CCEs in one site in HA then you have to have that edge name listed three times. External DNS is critical.
External certificates are required, certificate requests and have certificate available in .pfx format so it can be imported as part of the installation process of CCE. Details available here
CloudConnector.ini – CCE Configuration file
The CloudConnector.ini is critically important and controls almost everything.
IP Addresses, small or large CCE.
Don’t mess this up if there is a mistake is a start over job.
There a deployment checklist, this is printable and recommended to be printed so all details can be written and ensured.
There isn’t a CloudConnector.ini file by default but you can generate one as noted above using export-ccConfigurationsamplefile.
You have to have this file updated before you create a base VM and you need the values for the base VM and the base VM needs internet access.
There’s alot of settings in the .ini recommended to visit here
HA and Multi side Planning considerations
Really important if designing with HA and multi site in mind that you consider the information above. Some parts are the same and some are not with multisite.
Single site with HA (Multiple CCEs up to 4)
Shared folder – same shared folder on all CCEs instances
Virtual machine domain – same across instance
SIP domains – same
Site name – same as they are in the same site
External FQDN – (Access edge) same across all CCEs instance in the same site
External IP – different across instances
Hybrid tenant – peer destination is where a call exits office 365 it needs to know where to send the traffic to the edge single site. Multisite you can set failback as multiple sites.
Firewall Requirements – Internal
When deploy CCE appliance these are deployed in a DMZ as they need to allow connections from Internet and also be able to communicate with internal network.
Usually there will be an internal firewall protecting internal networks this table is for the internal firewall. so mediation server to PSTN Gateway.
Talk across internal firewall to internal network.
Default port range marked by * above this the default port range on mediation 4 ports required per call. These can be adjusted.
Gateway port is an example could be 5060 or 5061 this needs updating as required.
You can limit port ranges as well.
Firewall Requirements – External (Minimum)
There are the minimum ports required for external side of CCE this is between the internet and the external firewall. If you follow the minimum there may be some hair pinning issues.
Firewall Requirements – External (Recommended)
Here you can see the Cloud Connector Edge external interface is different, this allows for optimal media flow.
Following the planning is time to prepare the first host appliance and follow the steps above. Items in bold are required for first appliance only.
The share needs permissions for all CCEs in the same site.
Windows server 2012 iso is required to generate the base vhdx. this can be copied and pasted and used for other appliances.
Public certificate required upfront.
All appliances will be registered prior to deploying them, this registers with Office 365 so Office 365 is aware of all appliances in the site.
Last of all configure the PSTN gateways.
Deeper dive in to deployment
Who do we register ?
Management and HA.
i can view the PSTN sites and then view access edge for each site and if auto update is enabled.
All appliances need to know about each other for HA, by registering the appliance we know all the mediation servers on all appliance in a PSTN site.
Two different appliances with two different mediation server.
You can export this information as well and view
You can have up to 4 Cloud Connector per one PSTN calling site.
Calls are distributed in random order between the cloud connectors. In the image below CC 1 and CC 2 are two different appliances.
Capacity planning is key, Large 500 per CCE 4 * 500 = 2000 with N+1 = 3 * 500 = 1500 allowing for one CCE to fail
Johns signs into Office 365, johns calls a pstn number, this call will be routed to the PSTN via CCE, johns account is assigned to a PSTN site so when call does out the online infrastructure will route out to one of the CCE edges then from edge to mediation to PSTN GW.
Media is sent edge to mediation and mediation to PSTN GW.
Second user signs into Office 365 and this time the call is routed to CCE 2 on the same site and signalling and media flow is the same.
Manage HA Mediation Pool
First you register then install and all is working, all mediation knows about each other.
But now i want to add more and add a third
so i register, the third appliance knows about all of them but the first two don’t. On the first and second appliance we need to update their configuration by running publish-ccappliance cmdlet and this instructs existing appliances to update their topology and it will show a third was added.
What happened if i need to remove one we now unregister from Office 365 and again we need to publish and ensure the remaining appliances know one has been removed.
Media flow – outbound PSTN call from internal user
Dave is on internal network, he signs into Office 365, now he makes external pstn call, when the call reaches Office 365 first it does reverse number lookup to check if its a number for a sfb user, its not so the call is routed to Cloud Connector so its routed to Dave sites Edge, then mediation then gateway.
Media – Dave is inside the network so the media can be sent to the mediation server direct. Dave cant send his media direct to PSTN gateway as media bypass is not supported.
Media flow – Inbound PSTN call to internal user
Inbound call comes into the PSTN GW and into the mediation server then to the edge server then to SfB Online and then SfB online looksup the number and finds this is Dave and send an invite and can answer the call.
The media will go PSTN gateway to CCE Mediation then to Dave as he’s internal.
On premises you have M:N one mediation pool can talk to multiple gateway and multiple gateways can talk to multiple mediation servers.
Same with Cloud Connector, All PSTN GWs can talk to all Mediations, PSTN GW chosen is round robin, If GW1 cant accept call it can be rerouted. With HA CC you need multiple GWs.
For planning you also need to consider PSTN GW and PSTN capacity.
Multi site scenario
Multiple Cloud Connectors with multiple sites.
Above Seattle (PSTN Site 1) within this site it has two Cloud Connector appliance deployed this provides HA
Secondary site Amsterdam (PSTN Site 2) also with multiple Cloud Connectors deployed.
Here we can assign users to specific sites. John is assigned to PSTN site 1 and Komanal is assigned to PSTN site 2.
Johns calls will go via PSTN site 1 and Kormmels via PSTN site 2
There is NO DR between sites. In the event Amsterdam (PSTN Site2) goes offline there’s no automatic failover so calls go out the US (PSTN Site1). This is manual DR but considerations for inbound calls are required.
You can change the users site associated to PSTN site 1 but this would work only for outbound as inbound relies on Sites 2 PSTN connections. Also remember calls will be routed out of another country which could have legal implications and network latency may not be optimal.
Once all appliances are deployed and ready to go, you configure your tenant and enabled sharesipaddress space and set peer destionation and useonpremdialplan to false.
Best practice to assign users to PSTN sites but –peer destination is a failback.
New in 1.4.1 is auto updates, this automatically update the hosted and machines and Cloud Connector edition, auto updates takes care of this.
You need to configure a time windows for these updates to occur in. As improvements are made to the SfB Online service auto update will keep CCE inline as well.
It builds a new set of VMs in the background side by side and then drain active traffic and switch to new VMs. Existing VMs remain in place incase we need to switch back to them.
Thinks of the VMs as sealed VMs so don’t add antivirus or customise them as they will be replaced. Host can have AV but vm are sealed.
Post Deployment – Auto Update Configuration
Check its enabled and then check when its enabled for.
You can create custom autoupdate time windows and defines days and week and time.
you can have up to 20 custom time windows
You need to assign the custom update time window to the PSTN site.
Post Deployment – Configure Users
Now for user you need to assign cloud PBX licence and enable users.
Dial in conferencing is from the service you cant bring a conferencing number with Cloud Connector. It comes from PSTN Conferencing from SfB online only.
Voicemail is provided by Azure Voicemail, Exchange UM does not provided voicemail services, but the client wants part of Exchange UM enabled.
Assign user to PSTN Site (Case sensitive) this is where you associate user to cloud connector site.
You can restrict international calls as well.
Cloud Connector has a management service for auto recovery, auto update and event viewer has CceManagementService
The management service can show errors on remote PowerShell sessions
Above you can see Registration status is showing error and then an error message is displayed RTCSRV not found or not running
The management service can try and recover these and below its fixed it.
Updating to version 1.4.1
Recommended to upgrade to version 1.4.1 if your running an older version, 1.4.1 would be the last manual upgrade method.
You need to uninstall older version from host and install the new version.
You need to get new .ini file version and make sure its updated with your information on each cloud connector. The upgrade process is straight forward. start download, register and install with upgrade switch.
With existing HA do one at a time.
You can update credentials as well.