Tag Archives: Enterprise Voice

Skype for Business Cloud Connector Edition Public DNS, IP and Certificates requirements

Skype for Business Cloud Connector Edition deploys multiple VMs which allows users to connect with on-premises PSTN Infrastructure. As it contains Edge Server role, then obviously it requires Public DNS, IP and Certificates to function properly.

Let’s discuss internal things first.

Internal IP Addresses: Each CCE VM required one internal IP address, it means, you need four internal IP address for every CCE deployment. Make sure these IPs are from dedicated subnet, must not use existing subnets.

Internal DNS records: As each CCE deploys one ADDS, therefore all the internal dns records will point to deployed CCE internal dns.

Internal Certificates: Each CCE domain controller deploys certificate services with directory services, therefore all the internal certificate will be issued by internal certificate server.

Internal requirement looks simple but there are many more things which you need to plan in well advance to make the deployment successful.

Now let’s focus on external requirements which are very important to work CCE correctly.

External IP Addresses: One public IP address is required for external interface of edge server. This IP will be used by Access Edge and Media Relay Edge. You can use either direct public IP address or NAT IP address, if it is NAT IP address then specify both address. If it is NAT IP address then specify public IP address of the NAT device (one more parameter: “ExternalMRPublicIPs”) for media relay edge.

External DNS Records: External DNS records are mandatory for CCE employment. Onmicrosoft.com suffix is not supported for external DNS entries. You need to create external DNS record for access edge. In single site HA deployment, you need one dns record with multiple ip address and for multisite deployment, you need multiple dns records with multiple IP addresses.

Public Certificates: Public certificate require for each Edge component in CCE deployment. Certificates must have an exportable private key to copy between Edge components. Before you request public certificate, must plan for it properly.

You can have two different scenarios:

  1. Single SIP Domain
  2. Multiple SIP Domain

While choosing certificate, you can choose either SAN certificate with multiple entries or wildcard certificate.

Therefore, now you can have four different options;

First option: Single SIP domain with multiple SAN entries.

SN = <site1-accessedgepool>.sipdomain.com, SAN = sip.sipdomain.com, <site1-accessedgepool>.sipdomain.com, <site2-accessedgepool>.sipdomain.com

Second option: Single SIP domain with wildcard entry.

SN = sip.sipdomain.com, SAN = sip.sipdomain.com, *.sipdomain.com

(Note: With the above configuration, you must not create any sip.sipdomain.com entry in external DNS because this name belongs to the Office 365 deployment)

Third Option: Multiple SIP domain with multiple SAN entries.

SN = <site1-accessedgepool>.sipdomain1.com, SAN = sip.sipdomain1.com, sip.sipdomain2.com, <site1-accessedgepool>.sipdomain1.com, <site2-accessedgepool>.sipdomain1.com, <site1-accessedgepool>.sipdomain2.com, <site2-accessedgepool>.sipdomain2.com

Fourth option: Multiple SIP domain with wildcard entry.

SN = sip.sipdomain1.com, SAN = sip.sipdomain1.com, sip.sipdomain2.com, *.sipdomain1.com, *.sipdomain2.com

I hope this blog post will help you to plan IP addressing, subnets, dns records and certificates for CCE deployment.

Skype for Business Cloud Connector Infrastructure Requirements Part II

This blog post is a 2nd part of my preceding blog post. Part I covers H/W & S/W requirements and basic of DNS, certificates and permissions etc. In this post, I’ll cover the Ports and Protocols requirement for cloud connector edition deployment.

Below illustration shows high level logical deployments scenario with Cloud Connector Edition. Maximum 4 cloud connector can be deployed with one PSTN site. As shown in the diagram, cloud connector edition is deployed in perimeter network. Once you deploy cloud connector edition in perimeter network, required ports and protocol should be open to make it functional.


Below illustration shows the ports and protocol which should be open in internal firewall.

Below illustration shows the minimum ports and protocol which should be open in external firewall.

Below illustration shows the recommended ports and protocol which should be open in external firewall.

This solution will not work if the user end point is behind a symmetric NAT.

For more detailed information, please refer https://technet.microsoft.com/en-us/library/mt605227.aspx

Skype for Business Cloud Connector Infrastructure Requirements Part I

My preceding blog post discuss about different version on Cloud Connector Edition. Cloud connector edition comes with two different versions which support small to large number of calls. Single small version of cloud connector supports 50 simultaneous calls while large version supports 500 simultaneous calls.

3+1 configuration of cloud connectors provide scalability and high availability, 150 simultaneous PSTN calls can be supported in small version and 1500 simultaneous calls in large version.

Both the versions contains 4 VMs and can be downloaded from here.

Hardware requirements to deploy Skype for Business Cloud Connector Edition:


Small Version

Large Version


Intel i7 4790 quad core with Intel 4600 Graphics (no high end graphics needed)

64-bit dual processor, six core (12 real cores), 2.50 gigahertz (GHz) or higher


32 GB DDR3-1600 non ECC

64 gigabytes (GB) ECC RAM


2: 1TB 7200RPM SATA III (6 Gbps) in RAID 0

Four 600 GB (or better) 10K RPM 128M Cache SAS 6Gbps disks, configured in a RAID 5 configuration


2: 1 Gbps Ethernet (RJ45)

Three 1 Gbps RJ45 high throughput network adapters

Host Operating System

Windows Server 2012 R2 Data Center

Windows Server 2012 R2 Data Center




Guest Operating System

Windows Server 2012 R2 Standard / Data Center

Windows Server 2012 R2 Standard / Data Center


Qualified PBX/Trunk or qualified SBC/Gateway (a minimum of two gateways is recommended)

Qualified PBX/Trunk or qualified SBC/Gateway (a minimum of two gateways is recommended)


Apart from all of the above H/W requirements, you have to meet following requirements which are mandatory for Cloud Connector Edition deployment.

Local Server Administrator account for Hyper-V hosts

Domain Administrator information will be asked for new Active Directory to create Domain credential and assign required permissions.

External DNS records will be required for Access Edge per PSTN site and must add all the Edge Servers ip addresses of that particular PSTN site.

Public certificate required for external edge access.

Internet access required for all cloud connectors VM.

Required firewall ports and protocol should be open to execute the cloud connector edition deployment.

Part II of this blog post covers firewall requirements in detail.

Skype for Business Cloud Connector Supported Topology

Skype for Business Cloud Connector is an option for those organizations who have existing telephony infrastructure in-place but not using Skype for Business on-premises or Hybrid infrastructure. With the help of cloud connector customer can opt for Skype for Business Online while they still can leverage their telephony infrastructure for PSTN connectivity.

Let me clarify one thing: Organizations can use either Cloud PBX with PSTN calling service or Skype for Business Hybrid infrastructure to get most/all of the features and functionalities.

Cloud Connector only comes in picture where organizations are not using Lync Server / Skype for Business. When it comes to topology, it again only applicable to Sites which have PSTN infrastructure which needs to be connected with Skype for Business online. Cloud connector edition provides scalability as well as high availability.

Scalability: Multiple instance of cloud connector can be deployed with one or more PSTN sites. Maximum 200 sites can be deployed associated to one Skype for Business online tenant.

High Availability: Up to 4 cloud connector edition can be deployed in 3+1 configuration to provide high availability. In 3+1 configuration, you may get up to 99.8% availability while with 2+2 configuration you may get 99.9% availability.

Cloud Connector comes in two versions:

  1. Small Version (Supports up to 50 simultaneous calls)
  2. Large Version (Supports up to 500 simultaneous calls)

Let me describe multiple supported topologies through illustration:

Single instance of cloud connector with single PSTN site

Multiple instance of cloud connector with single PSTN site

Multiple instance of cloud connector with multiple PSTN sites

As cloud connector is an option for PSTN calls then number of PSTN calls will become a key selective area. Single PSTN site can be configure for up to 150 simultaneous call with small version while large version can support up to 1500 simultaneous calls. If you need more than 1500 simultaneous call in a single site then you can deploy multiple PSTN site in the same location to scale it up.

Skype for Business Cloud Connector Components

This blog post is a continuation of my preceding post “Skype for Business Cloud Connector” and deep dive into the Cloud Connector Edition Components. Cloud Connector Edition deploys a set of VMs which help Skype for Business online to connect and use on-premises telephony infrastructure. It comes with four major components which enable Skype for Business online to talk to the on-premises telephony infrastructure. It encompasses Edge server role components, Mediation server role components, central management store (CMS) and Domain Controller. Let me go in reverse order and explain all of these components.

Domain Controller: It deploys one Domain Controller which is very unique to the respective cloud connector. Let me make it more descriptive; whenever a cloud connector get deploys, it install Active Directory Domain Services and Active Directory Certificate Services. Deployed, ADDS will be part of the new forest and there should not be any connection to the production Active Directory. ADDS is required to store all the global configuration and groups necessary to deploy cloud connector components while ADCS will be installed to generate internal certificates for cloud connector configuration.

Central Management Store: Here CMS consist of two things, CMS role and CMS replica. CMS role store the topology configuration and includes CMS file transfer while CMS replica synchronizes configuration information from the global CMS DB on the CMS role server.

Mediation Server Component: Meditation role components include SIP and other media protocols which are required for PSTN connectivity between Skype for Business and telephony infrastructure. Mediation role also keep and replica of the CMS database which replicates from the global CMS database.

Edge Server Role: Edge server role enables the communication between on-premises topology and the online services which goes through the Edge component. This role consist of following components:

    Access Edge: Enables SIP routing between On-premises topology and Online Services.

    Media Relay: It enables media routing between mediation components and other media endpoints.

    Media Relay Authentication Service (MRAS): It generates tokes to access for media relay.

One more component, outbound routing plays a vital role here. Outbound Routing enables routing to gateways based on policies for outbound PSTN numbers and adhere only global policies.

If you are deploying or integration more than one cloud connector edition in your infrastructure then all the components will be deployed again. Therefore it indicates, all these components are unique to the specific cloud connector.

Skype for Business Cloud Connector

Cloud connector is a unique product from Microsoft which can leverage your existing telephony investment and provide advanced PBX capabilities by using Skype for Business Online and Cloud PBX. SfB cloud connector is an option for those customers who are not using Lync Server 2013 or Skype for Business Server 2015 on-premises infrastructure. Cloud Connector is nothing but a set of VMs which can be deployed on-premises to connect Cloud PBX to implement on-premises PSTN connectivity.

Cloud connector edition deploys a set of VMs which contain a minimal Skype for Business server topology. Each Cloud Connector contains following VMs:

  • Edge Component
  • Mediation Component
  • Central Management Store (CMS)
  • Domain Controller

While planning for Cloud Connector make sure below you considered below points:

  • You should have Office 365 tenant that includes Cloud PBX.
  • You should have existing supported PBX setup running on-premises.
  • All the user will be homed online.
  • You don’t need Skype for Business On-premises deployment but you need virtualized infra to deploy cloud connector. You can’t co-exist cloud connector with on-premises Lync Server 2013 / Skype for Business Server 2015.
  • Cloud Connector is available worldwide.
  • If you want to provide dial-in conferencing to users hosted on Cloud Connector, you can purchase PSTN conferencing from Microsoft or from audio conferencing provider (ACP) partners.


If you have existing Lync Server 2013 / Skype for Business Server 2015 on-premises deployment with telephony setup, then you opt for different options except cloud connector.

Plan your Cloud PBX solution in Skype for Business 2015 or Lync Server 2013

Plan Cloud PBX with on-premises PSTN connectivity in Skype for Business Server 2015 or Lync Server 2013

Skype for Business Cloud PBX

Skype for Business has opened a new era of real time communication with Cloud PBX and Cloud Connector. There are many vendors exist in the market who provide Voice and Video as a service but now with Skype for Business Server, organizations and consumers both will get a new style of collaboration. Skype for Business is an only application which can be fully integrated with other (Microsoft) messaging & collaboration products either on-premises, cloud or in hybrid environment. By using Office Servers and Services (Exchange, Skype for Business, SharePoint & Office 365 etc.), any size of organization can take a full benefit of advanced unified communication and collaboration.

What do you think about Cloud PBX?

Many of us will think about Private Branch Exchange which exist in Microsoft Cloud so that O365 users can make VOIP and PSTN calls. You are correct to some extent, let me explain it.

Cloud PBX is a technology which enables PBX capabilities in the Office 365 cloud which offers Voice over IP within your organization and call control functionalities such as placing, receiving, transferring, muting and unmuting calls etc. With all these functionalities any organization can save opex which occurs in long distance calls. Users can make and receive calls from multiple devices such as desktop/laptop with headset, Lync/SfB phone and mobile device etc. These functionalities could be part of native cloud deployment or in a hybrid environment. Cloud PBX doesn’t mean, users will get PSTN calling services. PSTN calling service is add-on which can be taken on top of Cloud PBX. Below diagram illustrate high level architecture of On-premises, Cloud and Hybrid environment.


Enterprise voice calls can be implemented in two different ways with Cloud PBX:

  1. Organizations can opt for Microsoft PSTN Calling Services.
  2. Organization can integrate Microsoft Cloud PBX with on-premises PSTN infrastructure using Cloud Connector.

Office 365 provides simplify Tenant console for everything including PSTN calling, messaging, collaboration and so on.

Skype for Business online E5 plans cover Cloud PBX while PSTN calling can be taken as an add-on service.

Lync Server 2013 – Location Based Routing: Part II

In part I Lync Server 2013 – Location Based Routing aka LBR, I discussed about the basic fundamentals, benefits, capabilities and routing methodologies. To extend the same, part II will cover implementation steps and test cases. As discussed in part I, LBR is a set of rules which handle your PSTN calls to comply with regulations of specific countries such as India. In telephony terms, it prevents toll bypass by blocking or modifying the routes of PSTN calls. Organizations can define the scope for LBR such as specific region, International calls, specific gateways or PBX and set of users. LBR policies can be based on user’s location or PSTN gateways location. LBR applies rules on different scenarios.

To test the LBR scenario, Single Site is deployed with asterisk PBX to generate voice calls. Test scenario will consider enterprise voice calls which are generated by Lync user located @ office and located @ home

Let’s start with deployment process:

1. Process start with Enterprise Voice deployment

Create dial plans and configure Normalization rules

Create and configure trunks, voice policies and define voice routes

2. Test Enterprise Voice setup

3. Create Network Region and Sites, define subnets based on your Lync infra.

4. Create Voice Routing Policy.

New-CsVoiceRoutingPolicy –Identity “Site1VoiceRoutingpolicy” –Name “Site1 Voice Routing Policy”

5. Set Voice Routing Policy and assign PSTN Usage (In lab scenario PSTN usage is created with name “Asterisk”)

Set-CsVoiceRoutingPolicy –Identity “Site1VoiceRoutingpolicy” –PSTNusages @{add=”Asterisk”}

6. Enable and configure location based routing and voice routing policy for Network Site

Set-CsNetworkSite –Identity Site1 –EnableLocationBasedRouting $true –VoiceRoutingPolicy “Site1 Voice Routing Policy”

7. Trunk configuration

Set-CsTrunkConfiguration –Identity Site1Trunk –EnableLocationRestrictions $true –NetworkSiteID “Site1”

8. Change Voice & Routing Configuration

Set-CsVoicePolicy “Site1VoicePolicy” –PreventPSTNTollBypass $true

Set-CsRoutingConfiguration –Enable locationbasedrouting $true

Follow the same steps for multiple sites carefully.

Test multiple calls scenario such as:

Incoming PSTN call while user @ his home location (Site1)

Outgoing PSTN call while user @ his home location (Site1)

Transfer and Forward while both the users @ their home location (Site1)

Simultaneous ring while both the users/endpoint @ their home location (Site1)

Lync users @ their home location are doing conference

Lync users @ their home location are doing Lync conference and PSTN user is joining conference using “Dial-in Conferencing”

Incoming PSTN call while user is logged in from outside

Outgoing PSTN call while user is logged in from outside

Transfer and Forward while both the users or one of them are not @ their home location (Site1)

Simultaneous ring while both the users/endpoint or one of them are not @ their home location (Site1)

Lync users @ their home location are doing conference and one of the conferencing user is trying to conference any PSTN user

These are few examples related to my Lab design, if you have more than one site then you need to test many other scenarios as well which certify that you are compliant with regulation.

Lync Server 2013 – Location Based Routing

Location Based Routing is an impressive feature of Lync Server 2013 which distinct Lync Server 2013 from other UC solutions. LBR allows full fledge Lync 2013 Enterprise Voice deployment for those enterprises who are doing business in regulated countries such as India, UAE, Egypt etc. Lync enterprise voice deployment with LBR requires well-versed planning and designing as your one wrong step can disturb entire voice setup. Now, questions come to every Lync professional if LBR requires planning & designing; it means LBR is not enabled by default or in other ways, LBR configuration part comes later.

Question: If LBR is not enable by default and needs additional configuration, which methodology Lync Server uses by default?

Answer: LCR

Many Exchange professional who are reading this blog, can assume LCR means Local Continuous Replication which was introduced in Exchange Server 2007.

By default Lync server uses Least Cost Routing methodology. Least cost routing can reduce the call rates by minimizing toll charges and maximizing WAN uses, which can benefit to the enterprises but in another ways it is a revenue loss for PSTN service providers.

LBR Benefits:

  • Comply with regulations that restricts IP-to-PSTN routing in pre-defined cases.
  • Routes PSTN calls based on caller’s location to prevent toll bypass.
  • Scoped to specific locations, gateways, and users based on Network configuration.
  • Route call to the gateway closest to the calling party which increase QoS & QoE.
  • Minimize use of WAN which result in better QoS & QoE.

LBR Capabilities:

  • Route outgoing calls to a PSTN gateway local to the caller’s location.
  • Prevent incoming calls if the Lync client is not in the PSTN gateway’s location.
  • Route outgoing calls through international PSTN gateways when there is no local gateway.
  • Ensures that conferences do not have a mix of users from different locations and PSTN dial-out.

Outbound routing:

Trunk-to-trunk routing:

Inbound routing:

There are many test cases involve in LBR implementation which need to be tested. Implementation steps and test cases is explained in the next part of this article.

Courtesy: Lync Conference 2014.

Collocated or Stand-alone Mediation Server

Most of the time, Lync Enterprise voice deployments need debate for collocated or stand-alone mediation server. Collocation of Mediation Server can reduce the TCO and data center footprints. Can Mediation server collocation be a wise option? To choose a wise option out of collocated or stand-alone mediation server depends on the following:

  1. Number of users enabled for UC-PSTN calls
  2. Number of UC-PSTN calls per user per hour
  3. Number of UC-PSTN calls at the time of peak load
  4. Connected gateway / SBC and mediation server
  5. Percentage of calls that support media bypass
  6. Branch sites configuration for UC-PSTN deployment

If I have missed any point here, please leave your comment so that I can add the same.

Any call which initiate from any Lync endpoint has two components signaling and media. For UC-PSTN calls, signaling always goes through Mediation server if stand-alone or Standard Edition / Front End server collocated with mediation server role.

No Media Bypass:

Media Bypass:

If your gateways, SBC or IP-PBX support media bypass, you can use collocated mediation server. But if you are planning for an option which do not support media bypass, I will advise you not to use collocated mediation server as collocated meditation server will increase load on front end servers which can cause of poor performance.

If you still want to use collocated meditation server, you can increase number of front end servers which can help you to distribute the load among front end servers.

A Stand-alone Mediation server deployment also depends on Branch sites which are connected to central site. If your branch sites don’t have dedicated PSTN connectivity then you should go with stand-alone mediation server pool. Again this topic requires more debate. As we know Lync 2013 use M:N trunk, in simple way it means if you have mediation server deployed in branch site and that can support media bypass you can still go with collocated option.

You can use Lync Planning tool to try all options and choose best out of that which provide you better ROI and best performance.