Tag Archives: Skype for Business

#Skype4B: Call via work (Part IV)


This post is the IVth part of the Call via Work series and continuation of part III. In this blogpost, I am going to cover the limitations of Call via Work. However, CvW is a great feature of Skype for Business Server 2015 which can be implemented easily with a limited hardware configuration but it comes with its own limitations.

There are following limitation which comes with CvW:

  • CvW call back number doesn’t work directly. If a user has setup a call forwarding on CvW call back number and someone invites him through that number, in that situation call will fail because the invitation will not reach to the user. To avoid this situation, you should invite the user for meeting by clicking on his name, not by the number.
  • Following things cannot be used by CvW enabled user
    • Team Call
    • Response Group
    • Delegation
  • Following actions can’t be performed by CvW user through SfB:
    • Record a meeting
    • Mute or Unmute the call
    • Hold or Transfer the call
    • Call Parking
  • CvW can’t be used by user to access their PBX voicemail messages.
  • User of CvW can’t perform following things:
    • Add more users to a 2-person call.
    • Can’t escalate voice call to a collaborative meeting which includes other modalities such as video, PowerPoint etc.
  • No support for deskphone pairing or VDI plugin pairing.
  • Enhanced 911 capability and malicious call tracing are not available during Call Via Work calls.
  • If your PBX system does not support REFER with Replaces, the following behavior will happen. While on a Call Via Work call, if the user transfers the ongoing call from the PBX Phone, the call window will not disappear from their Skype for Business window. If the user then closes the call window, the call between the transfer target and the transferee will end.

Courtesry: Microsoft Technet

I hope you enjoyed the entire series of Call via Work. Please write your queries and feedback in the comment section.

Call via Work Part I

Call via Work Part II

Call via Work Part III

#Skype4B: Call via work (Part III)


Part I and Part II of this blog post cover CvW fundamentals and how does it work. Now this part of the blogpost will cover CvW prerequisites and deployment process.

CvW is a cool feature of Skype for Business but it can only be configured in few scenarios. Below are the prerequisites and infrastructure should meet these requirements.

  • Unified Communication Web API (UCWA): Comes default with Skype for Business Server and installed automatically on all Skype for Business Front End Servers.
  • Mediations Server: Should be deployed standalone or part of the Front End server.
  • Direct Inward Dialing (DID): Each user should have DID on the PBX phone system for users who will be enabled for CvW and enabled for enterprise voice in SfB with the corresponding DID.
  • Automatic Configuration: CvW users must have Automatic configuration selected in their Advanced connections settings. The enables the client to discover the UCWA URLs.


  • Call forwarding and Simultaneous ring: CvW users must enable for call forwarding and simultaneous ring.
  • Dial-in and Dial-out conferencing: CvW users must enable for dial-in and dial-out conferencing which enable these users to get into and out of SfB conferences.


  • Delegation, team call, and response group: CvW users should be disabled for delegation, team call and response groups.

Deploy Call via Work: Now, let’s have a look into deployment part of the CvW.

  • Create a global phone number: for your deployment which Skype for Business displays on the PBX caller ID of users who are making Call Via Work calls.
         Set-CsRoutingConfiguration -CallViaWorkCallerId +<PhoneNumber>
  • Create one or more Call Via Work policies:
        New-CsCallViaWorkPolicy [-Identity] <XdsIdentity> [-Tenant <guid>] [-Enabled <bool>] [-UseAdminCallbackNumber <bool>] [-AdminCallbackNumber <string>] [-InMemory] [-Force] [-WhatIf] [-Confirm] [<CommonParameters>]
  • Assign a Call Via Work policy to each user who will be enabled for Call Via Work:
        Grant-CsCallViaWorkPolicy -Identity <UserName> -PolicyName Tag:<PolicyName>

Part IV of this article covers limitation in Call via Work.

#Skype4B: Call via work (Part II)


Part I of this blog post covers introduction of Call via work, differentiate remote call control and describe how does CvW work etc. Part II will cover different scenarios of call via work which takes place.

Outbound routing scenario has been covered in Part I. Now, let me describe inbound scenarios.

Skype for Business Server and PBX can be configured in two different ways for incoming traffic:

  1. Skype first in line
  2. PBX first in line

Case 1: User experience when external PSTN user makes an inbound call:

In this scenario, Skype First offers all the features such as Skype toast, missed call alert and voicemail while PBX first only offers voicemail.

Scenario 1: Skype first in line scenario for inbound PSTN call:

User Experience:

  1. PSTN user makes a call
  2. Skype for Business Server receives call
  3. User A client endpoints is alerted
  4. Since User A is enabled for CvW and Simulring, a ms-SkipRnl header is used to force a call out to user A desk phone

Scenario 2: PBX first in line scenario for inbound PSTN call:

User Experience:

  1. PSTN user makes a call
  2. PBX receives call
  3. Since User A has PBX desk phone, therefore user desk phone rings

Case 2: User experience when internal user makes an inbound call:

In this scenario, Skype for Business user (as a first party) offers all the features such as Skype toast, missed call alert and voicemail while PBX desk phone (as a first party) offers voicemail.

Scenario 1: Skype for business user scenario for inbound PSTN call:

User Experience:

  1. User B makes a call to User A from SfB Client
  2. Skype for Business Server receives call
  3. User A client endpoints is alerted
  4. Since User A is enabled for CvW and Simulring, a ms-SkipRnl header is used to force a call out to user A desk phone

Scenario 2: PBX user scenario for inbound PSTN call:

User Experience:

  1. User B makes a call from PSTN desk phone
  2. PBX receives call
  3. Since User A has PBX desk phone, therefore user desk phone rings

I hope, this post gives you clarification about inbound scenarios of CvW. If you have any comments or queries, please write in comments box. I’ll be happy to hear from you and resolve all your queries.

#Skype4B: Call via work (Part I)


Skype for Business Server 2015 introduced Call via Work (CvW) and replaced remote call control (RCC) which was available in previous versions of Lync server. It enables integration between Skype for Business and your PBX phone system. A SfB user enabled for CvW can initiate a PSTN call from SfB client and leverages PBX phone to have a call with another user within organization or outside the organization.

How is it different from Remote Call Control?

RCC is a replacement of CvW but doesn’t work in same way, you can understand it in this way: RCC required computer-supported telecommunications application (CSTA) gateway to integrate Lync Server with PBX system while CvW uses Unified Communication Web API (UCWA) as the back-to-back user agent (B2BUA) between Skype for Business Server and PBX systems. Therefore, CvW only work in case you have direct SIP between Skype for Business Server and PBX systems.

Call via Work offers the following for PBX phone users:

  • Click-to-call experience form Skype for Business client
  • IM, App and Desktop Sharing, File Transfer
  • One-click meeting join experience

How does it work?

The end user selects another end user in their Skype for Business client, and clicks the phone icon to call him. Or, during an IM conversation, the end user clicks to call another user they are having the session with. The PBX phone of the user who placed the call starts to ring. The caller ID for this phone shows a global phone number which you have set up to show in the caller ID of all users placing Call Via Work calls. This global phone number is not an actual phone number that corresponds to any one person’s phone. Instead, it is a visual signal to let a user know that this is their own outgoing call, and not an incoming call happening at the same time. When you deploy Call Via Work, you should educate those users about this global phone number and what it means. The user who placed the call picks up their PBX phone. Skype for Business then initiates the voice call to the callee. When the callee answers, the voice call begins. If the two users already had an IM session going, it can continue. Courtesy: Microsoft TechNet

Let’s take an outbound call scenario where Users A which is enabled for Call via Work initiates a call from SfB client to external PSTN number.

  1. User A initiates a call from SfB client.
  2. Skype for Business Server places call to user’s PBX phone.
  3. PBX System routes call and user answer that call.
  4. When Sfb server perceives that call has been answered by local user then it initiates a far-end call by using user A DID.
  5. PBX system routes a call out to PSTN with user’s DID.
  6. Far-end calls answers and call is established.

Once call has been initiated, media will directly flow between both the end points.

Let’s take an another outbound call scenario where Users A which is enabled for Call via Work initiates a call from SfB client to User B within same organization. Here, User B is enabled for call via work and Simulring.

  1. User A initiates a call from SfB client.
  2. Skype for Business Server places call to user’s PBX phone.
  3. PBX System routes call and user answer that call.
  4. When Sfb server perceives that call has been answered by local user then it initiates a call to user B.
  5. Since User B is internal user and enabled for call via work and set to simulring their own desk phone, a ms-skipRnl header is used on an outbound call to force another call out to user B desk phone
  6. User B answers call from either skype client or desk phone and call is established.

Once call has been initiated, media will directly flow between both the end points.

The above examples are simple scenarios but there are many other scenarios which take place when deploy call via work. Rest of the scenarios, I’ll coven in next part of this blog series.

Call flow with Cloud Connector Edition


Cloud Connector Edition is an option for those customers who are new to Microsoft Real Time Communication and directly adopting Skype for Business Online (Office 365) for real time communication. At present to find an organization without any telephony system is almost impossible. When customers are looking for best RTC solution and adopting SfB online, it is crucial for them to leverage existing telephony investment while maintaining seamless user experience across all RTC modalities. Microsoft is committed to provide seamless PSTN calling experience through Cloud Connector Edition to those users who are accessing all the SfB modalities except PSTN calling form SfB online infrastructure.

Let’s discuss more about PSTN calling. In Skype for Business each conversation is divided into two pieces i.e. signaling and media. When you are using CCE all media traffic for PSTN calling will be managed by CCE and PSTN Gateway while signaling will be managed by CCE and SfB online infrastructure.

Whenever, we talk about telephony communication, it could be either inbound or outbound.

Outbound Calling: If a user place a call from internal network:

  1. Users dial an external PSTN number in E.164 format
  2. SIP traffic routes to Skype for Business online infrastructure
  3. SfB online performs a reverse number lookup for the dialed number
  4. The RNL fails because it is an external number and doesn’t belongs to any SfB user
  5. The call is routed to the Edge component of CCE
  6. If the PSTN routes exist Edge Server relays the traffic through Mediation component of CCE
  7. Mediation component sends the traffic to the PSTN gateway and establish a connection between the user end point and PSTN Gateway through Mediation component for media flow

Inbound Calling: If an internal user receive a call from PSTN network:

  1. PSTN Gateway receives a call from external PSTN number for a SfB online user who is in internal network as of now
  2. Gateway routes the SIP traffic to Mediation component of CCE
  3. Traffic goes out from Mediation component to SfB Online through Edge component of CCE
  4. SfB online performs a reverse number lookup
  5. The RNL passes and SfB online finds that this number belongs to the SfB online user
  6. SIP signaling goes to all the point of presence of that user
  7. Finally, Media traffic will be established between PSTN gateway and Mediation component and between Mediation component and the user end point for media flow

These are the features which are available through CCE as of now.

There are many limitation if you will compare it with Skype for Business on-premises or hybrid. Below are the list of limitations:

  1. No call via work or remote call control
  2. No media bypass
  3. No response group
  4. Active call can’t be transferred to the cell phone which is registered in your Active Directory by picking it from a list of suggested phones in the transfer menu. You can transfer to any other number.
  5. Call between SfB user and PSTN number can’t be escalated as conference call
  6. Users must use full number in E.164 format only
  7. Only specific series of Polycom phones are supported as of now
  8. No integration available with contact centers
  9. Private lines and common area phones are also not supported

I tried to cover most of the stuffs but there is no guarantee if you face any other limitation.

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.

Note:
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:

Components

Small Version

Large Version

Processor

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

Memory

32 GB DDR3-1600 non ECC

64 gigabytes (GB) ECC RAM

Storage

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

Network

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

Hypervisor

Hyper-V

Hyper-V

Guest Operating System

Windows Server 2012 R2 Standard / Data Center

Windows Server 2012 R2 Standard / Data Center

PBX

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.