CISCO SYSTEMS, INC.

Deploying Cisco Spark Hybrid Services

By Luca Pellegrini

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. © 2016 Cisco Systems, Inc. All rights reserved.

Revised: 11/17/2016

1

CONTENTS Hybrid Services .................................................................................................................................... 1 Architecture Overview ......................................................................................................................... 1 Deployment Overview.......................................................................................................................... 4

Cloud Collaboration Management Portal .................................................................................................. 4 Management Connector .............................................................................................................................. 4 Directory Connector .................................................................................................................................... 5 Calendar Connector .................................................................................................................................... 6 Call Connector ............................................................................................................................................. 7

Call Service Connect Architecture and Call Flow ....................................................................................................... 8 Users URIs ............................................................................................................................................................ 9 Loop Detection and Avoidance ........................................................................................................................... 11 Mutual TLS .......................................................................................................................................................... 11 Media Encryption ................................................................................................................................................ 12

Expressway-C and Expressway-E on a Shared Deployment .................................................................................. 13 Calling ID and Class-of-Service ............................................................................................................................... 13 Multiple Unified CM Cluster Deployment Considerations......................................................................................... 14 Toll Fraud and Identity Theft Mitigation .................................................................................................................... 17

High Availability ......................................................................................................................................... 18 Preliminary Sizing ...................................................................................................................................... 18

Deployment Steps .............................................................................................................................. 19 Deploy Directory Connector ..................................................................................................................... 19 Deploy Expressway-C Connector Host ................................................................................................... 19 Deploy Calendar Connector ..................................................................................................................... 19 Deploy Call Connector .............................................................................................................................. 19

Call Service Prerequisites ........................................................................................................................................ 19 Call Service Aware Deployment Steps .................................................................................................................... 19 Call Service Connect Deployment Steps ................................................................................................................. 19

Hybrid Services This document provides an overview of Cisco Spark Hybrid Services design and deployment. The first part is an Architecture Overview that introduces the components involved, with a short summary of how those components fit into a collaboration architecture. The second part of this document is the Deployment Overview and is a deeper technical discussion of the architecture covering the various hybrid services connectors, how they function, the components involved, and best practices in deployment of the connectors. The last section of this document is a high-level step-by-step guide to deploying hybrid services.

Architecture Overview

Cisco Spark Hybrid Services allow Cisco Spark customers to connect on-premises collaboration services to the Cisco Collaboration Cloud. Connecting these services adds value for any Spark customer by enabling simple user onboarding, meeting scheduling, and integration of Cisco on-premises call control. Today there are three Hybrid Services available to Spark customers:

1. Hybrid Directory Service: This service allows any Spark customer to synchronize their current Active Directory with the Cisco Collaboration Cloud. This makes onboarding users to the Cisco Collaboration Cloud simple and consistent.

2. Hybrid Calendar Service: This service allows any Spark customer to enable scheduling of WebEx meetings with an automatically created and associated Spark room. By adding @Spark to the location field of the Exchange appointment, all attendees of the appointment are automatically added to the Spark room. With @WebEx in the location field, the details of the WebEx personal meeting room of the inviting user are automatically added to the invitation sent for the appointment.

3. Hybrid Call Service: This service allows a Spark customer with Cisco Unified Communications Manager, Business Edition 6000, or Hosted Collaboration Solution (HCS) to integrate their current call control with the Cisco

2

Collaboration Cloud. This document is focused on Cisco Unified Communications Manager integration. Hybrid Call Services include two components:

• Call Service Aware makes Cisco Spark aware of all calls across your Unified Communications (UC) system, thus enabling the automatic creation of a one-to-one room whenever a point-to-point call is placed between two Spark users on their on-premises registered endpoints. This one-to-one room provides capabilities such as Zero Touch Meetings, which allow simple screen sharing between the two users. Call Service Aware also provides a unified call history; the Spark client shows missed and placed calls even if the client was not running at the time the call occurred.

• Call Service Connect integrates Cisco Spark with an existing Cisco call control platform, thus making it possible for users to make and receive calls on their Cisco device or Spark application using the same dialing procedure as with on-premises registered endpoints.

Each of the Hybrid Services is enabled through connectors that are deployed and managed by the organization's administrator. The connectors are installed on one or more Expressway-C dedicated to the connectors. An organization can choose to deploy one or more of the services depending on their needs and available on-premises services. Today there are four connectors that enable Hybrid Services:

• Management Connector • Directory Connector for Microsoft Active Directory • Calendar Connector for Microsoft Exchange • Call Connector for Cisco Unified Communications Manager

This architecture enables an organization to use its current on-premises network to support Cisco Collaboration Cloud integration, while also providing high availability for the services. High availability is achieved through service clustering to maintain the Spark experience in the event of a server failure.

Figure 1 shows the components of the architecture and where the connectors integrate the various on-premises collaboration components with the cloud services.

3

Figure 1 — Hybrid Services Components and Architecture

Table 1 lists the components in this architecture. For simplicity, the components are grouped into categories to help define their roles.

Table 1 — Components of the Hybrid Services Architecture

Categories Component Description

Management

Cisco Cloud Collaboration Management Portal

Enables management of Spark-enabled users, registration of Expressway-C connector host to the Cisco Collaboration Cloud, and connector upgrades

Cisco Management Connector on Expressway-C

Enables connectors hosted on Expressway-C to be managed by the Cisco Collaboration Cloud

Directory services

Microsoft Active Directory Provides the full list of corporate users and users’ attributes

Cisco Directory Connector Provides user synchronization between Active Directory and the Cisco Collaboration Cloud

Calendaring services

Microsoft Exchange Provides corporate calendaring services

Cisco Calendar Connector Provides integration between on-premises calendaring application and Cisco Collaboration Cloud

Call Control Cisco Unified Communications Manager

Provides endpoint registration, call processing, and media resource management

4

Cisco Call Connector Provides integration between on-premises call processing

services and Cisco Collaboration Cloud Cisco Expressway Series: Expressway-C and Expressway-E

Enables firewall traversal for Hybrid Services calls

This design uses Cisco Expressway-C and Expressway-E, but the same considerations apply to deployments using Cisco TelePresence Video Communication Server (VCS-C and VCS-E).

Deployment Overview

This section covers the deployment of the Hybrid Services connectors, how they function, the components involved, and best practices in their deployment. The following connectors are covered in this section:

• Management Connector • Directory Connector • Calendar Connector • Call Connector

The deployment articulated in this guide includes a firewall traversal architecture with Cisco Expressway-C and Expressway-E. The Expressway-E deployment is part of the Collaboration Edge Preferred Architecture and in the context of this document is also used for the call signaling and media aspects of Call Service Connect. Deployments not using Call Service Connect don't necessarily need this Expressway-E. The connectors running on Expressway-C as shown in Figure 1 connect back to the Cisco Collaboration Cloud via direct HTTPS connections that do not traverse Expressway-E.

The Expressway-C server or cluster that hosts the connectors must run as a dedicated node or cluster. Business-to-business and mobile and remote access services can be hosted on the same Expressway-C and Expressway–E cluster pair that is also used for call signaling and media related to Call Service Connect (that is, for calls generated by the Cisco Collaboration Cloud entering the corporate network, or vice-versa), as shown in Figure 1. See the Call Connector section for further design guidance. Although the connectors run on a standard Expressway-C, this document refers to it as the “Expressway-C connector host” to differentiate it from the Expressway-C used for firewall traversal. The Expressway-C connector host is owned and managed by the corporation and is deployed in the corporate network.

Cloud Collaboration Management Portal The Cloud Collaboration Management Portal is the web interface to the Cisco Spark administration. Among other tasks it allows the administrator to enable users for Spark and for Hybrid Services. It is also used to register the Expressway-C connector host to the Cloud and to manage connectors directly from the Cloud.

When the administrator registers Expressway-C to the Cloud, Management Connector, Calendar Connector, and Call Connector are downloaded to Expressway-C. Subsequent management of connectors, such as upgrades, is controlled by the Cloud Collaboration Management Portal.

Management Connector

The Management Connector is included in the Expressway-C base software and is used by the administrator to register Expressway to the Cloud and to link the Expressway interface with the Cloud management interfaces.

The Management Connector plays an important role as the coordinator of all connectors running on the Expressway server or cluster. It provides the administrator with a single point of control for connector activities. The Management Connector enables Cloud-based management of the on-premises connectors, handles initial registration with the Cloud, manages the connector software lifecycle, and provides status and alarms. The Management Connector requires that certificates of the Certification Authorities that signed the certificates in use by the Cisco Collaboration Cloud be in the trusted list of the Expressway-C connector host, so that the HTTPS connection can be established. The administrator can decide to allow the Cisco Collaboration Cloud to upload CA certificates to the Expressway-C trust store. Or, in the case where security policies prevent the Cisco Collaboration Cloud from uploading trusted CA certificates on Expressway-C, the administrator may upload them manually.

5

Directory Connector

Cisco Spark integrates with Microsoft Active Directory and supports a single forest with multiple domains. Multiple domains are supported when Active Directory Lightweight Directory Services (AD LDS) is deployed. In this case a Directory Connector per forest is required.

Directory synchronization allows corporate users to be imported into Cisco Collaboration Cloud. Directory synchronization is facilitated using the Cloud Collaboration Management Portal and the directory connector, which runs on a trusted Microsoft Windows domain server deployed in the corporate network. Specifically, Directory Connector runs on Microsoft Windows Server 2003, 2008 R2, or 2012 and works with Microsoft Active Directory 2008, 2008 R2, 2012, and 2012 R2. The server joins the Active Directory domain and needs an administrator read-only account to authenticate the Directory Connector machine to the on-premises domain. We recommend installing Directory Connector and Active Directory Domain Service or Active Directory Lightweight Directory Services on separate machines.

The administrator must log in to Cloud Collaboration Management and download the Directory Connector in the Windows Server. Once Directory Connector is installed and configured, synchronization will take place and users will be pushed to the Cisco Collaboration Cloud. Users log in via the mail attribute. Each user receives an automatic email from the Cloud and is prompted to confirm their email address and specify a password. If Single Sign-On (SSO) is implemented, the user’s corporate password is used instead.

The Directory Connector is configured to pull user information from the Active Directory. User information can be pulled from the entire domain or from specific containers and organizational units. It is also possible to create LDAP filters if more granularity is needed. User information is then pushed to the Cisco Collaboration Cloud through an HTTPS connection. Because this is an outbound connection, it doesn’t require any inbound ports to be opened on the internal or external firewall.

Once the Directory Connector is configured, it is possible to perform a full synchronization. Additional incremental synchronizations and full synchronizations can be scheduled in advance to keep the Cisco Collaboration Cloud updated with adds, moves, and changes. Directory Connector synchronizes a number of Active Directory attributes to the Cisco Collaboration Cloud (common identity store of the customer organization). The following table lists a few of the commonly used attributes; refer to the product documentation for a full list.

Table 2 — Active Directory attributes

Commonly Used Attributes displayName

givenName

telephoneNumber

mail

The mail attribute plays a key role in Cisco Collaboration Cloud because it uniquely identifies the user.

Note: The call connector correlates Spark user to Cisco Unified CM end user using email address. It is thus important that the mail ID field in UCM contains the user’s email address.

If Single Sign-On (SSO) is enabled, each user can maintain their Corporate Active Directory password. Corporate password policies such as complexity and expiry time are also maintained. SSO requires that the organization be configured for SSO in Cloud Collaboration Management and that the Identity Provider can be reached from the Cisco Collaboration Cloud. SSO is an architecture that involves many more services other than Collaboration, and therefore it is not covered in this document. If SSO is not enabled, password policies will follow the Cisco Collaboration Cloud rules and might be different from the corporate policies.

Figure 2 depicts the Directory Connector and associated components.

6

Figure 2 — Directory Connector and Associated Components

Calendar Connector

Calendar Connector facilitates the connectivity to the calendaring application, that is Microsoft Exchange. This allows Cisco Spark clients to share personal meeting room calendar information (@webex) as well as to create an associated Spark room in Cisco Spark (@spark) for the meeting.

Calendar Connector integrates Cisco Spark with Microsoft Exchange 2010 or Exchange 2013 through an impersonation account. The application impersonation management role in Exchange enables applications to impersonate users in an organization to perform tasks on behalf of the user. The application impersonation role has to be configured in Exchange and is used in the Calendar Connector as part of the Exchange configuration on the Expressway-C interface.

The impersonation account does not have to be an administrator, but it must have a mailbox. If you've limited the set of users that are synchronized with Active Directory using LDAP filters, you might want to similarly limit the impersonation by using a new or existing management scope in Exchange.

Calendar Connector integrates with Collaboration Meeting Room (CMR) Cloud sites through Expressway-C as well. CMR Cloud settings, such as CMR administrator account and password, need to be configured on Expressway-C. Calendar Connector supports integration to a cloud calendaring service based on Microsoft Office 365. Calendar Connector connects to the Exchange Web Services (EWS) interface of the Microsoft Exchange servers and manages the calendaring appointments on behalf of the user. It also communicates with the Cisco Collaboration Cloud through Expressway-C so that, when a user schedules a meeting, a Cisco Spark room is optionally created by adding @Spark in the “location” field of the meeting window. Communication between Microsoft Exchange and Expressway-C may be secured using certificates.

7

Figure 3 shows the Calendar Connector and associated components. Figure 3 — Calendar Connector and Associated Components

Call Connector Call Connector integrates Cisco Unified Communications call services with the Cisco Collaboration Cloud. With Call Connector, the following services are available:

• Call Service Aware — The Call Connector on Expressway-C notifies Cisco Collaboration Cloud that two Spark-enabled users are engaged in the same call with their on-premise devices, so that their respective Spark clients can offer the option to start desktop sharing. Note that Call Service Aware does not require any media traversal capability or license. Expressway-C communicates with the Cisco Collaboration Cloud using an outbound HTTPS connection. Expressway-E is not involved. The Call Connector on Expressway-C integrates with Cisco Unified Communications Manager through AXL and CTI-QBE.

When a user in the Cisco Collaboration Cloud is enabled for Call Service Aware, the Call Connector uses the AXL connectivity to find devices associated to that user on Cisco Unified Communications Manager (Unified CM). An application user on Cisco Unified CM will monitor devices associated with all CTI-enabled users. In order to allow the Call Connector to monitor the CTI line appearances of the Spark enabled users, the application user credentials are also configured on the Call Connector. For all CTI line appearances monitored by the Call Connector, Cisco Unified CM sends CTI notifications to the call connector which then relays this information to the Cisco Collaboration Cloud. Based on this information, a one-to-one Spark room is created or pushed to the top of the list in Spark clients of users in a one-to-one call on their Unified CM registered endpoints. This one-to-one room presents the option to add desktop sharing capabilities to both users involved in the call.

8

With Call Service Aware, desktop sharing is available to all physical devices registered to Cisco Unified Communications Manager, audio or video-based, if they can be monitored through CTI.

• Call Service Connect — Call Service Connect allows integration between Cisco Spark and Cisco Unified Communications Manager. A prerequisite for Call Service Connect is that Call Service Aware is deployed and configured. If a user has an endpoint registered to Cisco Unified CM and a Cisco Spark client, both the endpoint and the Cisco Spark client will receive the call regardless of whether the call is initiated by another Cisco Spark client or any other endpoint. Call Service Connect not only enables simultaneous ringing on Spark and Cisco Unified CM, but also allows Spark users to place calls using enterprise dialing habits. In order to achieve this, a SIP connection is set up between the Cisco Collaboration Cloud and Expressway-E using standard business-to-business technologies and Mutual TLS. For this reason, Expressway-E must use a certificate signed by a Certification Authority trusted by the Cisco Collaboration Cloud. A list of trusted Certification Authorities is available at: https://help.webex.com/docs/DOC-4302

Figure 4 shows the Call Connector and associated components. Figure 4 — Call Connector and Associated Components

Call Service Connect Architecture and Call Flow

Call Service Connect enables simultaneous ringing between Cisco Spark and Cisco Unified CM devices associated with the same user. In addition, it keeps the user experience consistent so that the user of Spark has the same dialing habits, calling ID, and unified call history as any other user on Cisco Unified CM.

In order to achieve single number reach, the Cisco Unified CM administrator must configure a CTI Remote Device, referred to in this document as a Spark CTI Remote Device, for every user’s primary extension. For the purposes of this discussion, a CTI Remote Device is very similar to a Remote Destination Profile. The Administrator can configure the Call

9

Connector to create the Spark CTI Remote Device automatically, with the limitation that parameters like Device Pool, Calling Search Space, Location and Reroute Calling Search Space will be shared between all the Spark CTI Remote Devices.

Users URIs Once this is done, Call Connector will automatically configure remote destinations associated with the Spark CTI Remote Device on Cisco Unified Communications Manager in order to allow simultaneous ring functionality between Spark clients and Cisco Unified Communications Manager devices. As an example, when the user bob@example.com is provisioned for Call Service Connect, the Call Connector will add a remote destination to the Spark CTI Remote Device of the user via the Cisco Unified CM AXL API. The remote destination will be in the form: <userID>@<subdomain>.call.ciscospark.com For example: bob@example.call.ciscospark.com Where <userID> is the attribute uniquely identifying the user in the corporate directory domain, and <subdomain> is a string configured by the corporate administrator in the Cloud Collaboration Management Portal. In our example, the corporate domain is example.com and the string configured by the administrator is example. The Cisco Collaboration Cloud will check that the string is unique and will prompt to create a new one in case the string is already in use.

When a user is provisioned for Call Service Connect, the Cisco Collaboration Cloud will know by the Call Connector that Bob has an associated Directory URI. The same user will have two addresses:

• Cisco Unified CM Address — Cisco Unified CM address set to match the Directory URI on Cisco Unified Communications Manager (bob@example.com in our example). This address uniquely identifies the user in the Cisco Unified Communications Manager on-premises architecture.

• Cisco Spark SIP Address — Cisco Spark address, set to bob@example.call.ciscospark.com in our example. This address identifies the user on the Cisco Collaboration Cloud. The example.call.ciscospark.com is a publicly reachable subdomain of the domain call.ciscospark.com managed by the Cisco Collaboration Cloud.

When Alice calls Bob using her Cisco Unified CM device (step 1), Cisco Unified CM will fork the call to the Spark CTI Remote Device sharing the same directory number with Bob’s device as shown in Figure 5, step 2. The associated remote destination will be triggered and the call will be sent to bob@example.call.ciscospark.com through a SIP route pattern to Expressway-C. Expressway-C is configured to send any URI of the form <user>@example.call.ciscospark.com to Expressway-E, and Expressway-E in turn sends it to the DNS zone (step 3). Expressway-E will query the public DNS for SRV resolution for the record _sips._tcp.callservice.ciscospark.com even if the domain portion of the SIP URI is example.call.ciscospark.com, because the DNS Zone on Expressway is configured to use “callservice.ciscospark.com” instead of “example.call.ciscospark.com”. This is done through the “Modify DNS Request” and the “Domain to search for” settings in the DNS Zone, and the call will be sent to the Cisco Collaboration Cloud. As a consequence, both Bob’s Unified CM endpoint and Cisco Spark client will receive the call, and Bob will decide which of the two clients he will use. Figure 5 shows the call flow.

10

Figure 5 — Call Flow for Call Service Connect

When Alice on the Cisco Spark client calls Bob, the Cisco Collaboration Cloud detects that Bob also has a corporate account with the directory URI bob@example.com, and it sends the call to both Bob’s Cisco Spark client and the Expressway-E cluster located through the SRV record _sips._tcp.example.com. If this record is already used for business-to-business communications, we recommend specifying a subdomain of the corporate domain as the SIP discovery address in the Cloud Collaboration Portal, and consequently a public DNS SRV record, as follows:

Service and protocol: _sips.tcp.hybridcallservices.example.com Priority: 1 Weight: 10 Port number: 5062, Target: us-expe1.example.com

Details for the Expressway-E location are configured by the corporate administrator in the Cloud Collaboration Management Portal, so that the Cisco Collaboration Cloud knows where to send the call. Expressway-E and Expressway-C are configured to route the call internally, as they would with any business-to-business call. Note: Cisco Collaboration Cloud populates the SIP stack with a Route Header, which takes precedence over the Request URI. In all cases, routing on Expressway-C and Expressway-E is not performed according to the Directory URI (bob@example.com) but according to the Route Header instead, and this has to be considered when creating the search rules on Expressway. Because this is especially useful in case of multiple Cisco Unified CM clusters, this information is covered in the section on Multiple Unified CM Cluster Deployment Considerations, although it applies to a single cluster scenario as well.

11

The call reaches Cisco Unified CM and anchors to Alice’s CTI-RD by matching caller ID. Call anchoring is a mobility feature that is used to preserve calling ID and Calling Search Space, and is discussed in Calling ID and Class-of-Service section. After anchoring, the call is sent to Bob’s directory URI, shared with Bob’s Spark CTI Remote Device. Bob’s Spark CTI Remote Device has a remote destination configured, and thus the call is forked to the remote destination, such as bob@example.call.ciscospark.com, as shown in Figure 6, step 4.

Figure 6 — Call Flow to Bob’s Spark CTI Remote Device

Loop Detection and Avoidance Before forking the call (step 2), Cisco Collaboration Cloud populates the call with the Contact Header parameter “call type=squared”. When the Cisco Collaboration Cloud receives a call from the corporate network containing the Contact Header set to “call type=squared”, Cisco Collaboration Cloud detects that this is a looped call and disconnects it.

Expressway must be configured to allow Contact Header pass-through on Expressway-C and Expressway-E.

Mutual TLS SIP signaling between Cisco Collaboration Cloud and the enterprise network uses Mutual TLS. Any TLS architecture is client-server based, where the client is the initiator of the request. With Mutual TLS, both Cisco Spark and Expressway-E authenticate each other. Specifically, on the DNS zone on Expressway-E to be used for calls from the Cisco Collaboration Cloud, a “TLS verify subject name” is configured, and this needs to match with CN or SAN of the certificate presented by the Cloud to Expressway-E during TLS handshake. Note that inbound calls on a DNS zone is a new feature on Expressway 8.7, whereas in previous releases DNS zones are outbound only and the Default zone is inbound only. Hybrid Call Services use a DNS zone for inbound calls. When a Cisco Spark call is received by Expressway-E (server-side in TLS handshake), Expressway-E requests the TLS client certificate that is the Cisco Collaboration Cloud certificate. If the certificate matches what has been configured in the

12

“TLS verify subject name”, the call is authenticated. Successful authentication also requires that trust is established with the CA that signed this certificate. If authentication is not successful, this means that the certificate validation has failed. The call will thus enter into the Default Zone and will be routed accordingly to the search rules provided for business-to-business scenarios, if business-to-business is configured on Expressway-E.

Media Encryption Media is encrypted with Secure Real-time Transport Protocol (SRTP) between the Cisco Collaboration Cloud and Cisco Expressway. Depending on the configuration, different scenarios can be achieved:

• End-to-end encryption — This requires Cisco Unified CM to be in mixed mode and the endpoints provisioned for encryption.

• Expressway-terminated encryption — If Cisco Unified CM is not in mixed mode and uses non-encrypted RTP media traffic to send the call to Expressway-C, then Expressway-C can terminate the RTP connection with the Cisco Unified CM endpoint and open another call leg using SRTP to the Cisco Collaboration Cloud. Any time Expressway performs RTP to SRTP conversion, it engages a back-to-back user agent (B2BUA). If Expressway performs RTP to SRTP, we recommend enabling it on Expressway-C instead of Expressway-E. This way, the traffic in the DMZ will be encrypted.

Figure 7 shows these two options. Figure 7 — Encryption Options

When a call is placed from the Cisco Spark client using the Calls tab, any number such as a +E.164 number can be entered. In this case the call is sent to Expressway in the form <number>@<CFQDN>, where CFQDN is the Cluster Fully Qualified Domain Name of the Cisco Unified CM cluster, set in the corresponding Enterprise Parameter. Because it is a

13

numeric call with the local CFQDN as the host portion in the SIP URI, Cisco Unified CM will route the call accordingly to numeric routing.

Expressway-C and Expressway-E on a Shared Deployment In case of co-residency of calls generated by Call Service Connect with business-to-business calls and mobile and remote access (MRA) services, it is important to allow PSTN access to Cisco Spark users while blocking unauthorized access of PSTN and other internal-only services to business-to-business (B2B) users. Standard B2B calls from other companies enter into the Default Zone because these connections, even if they are configured for Mutual TLS, will not present a certificate matching the TLS verify name configured on the Cisco Spark DNS zone. Therefore, we recommend configuring the Default Zone as non-authenticated. Class-based Policy Language (CPL) rules controlling access to the corporate network will thus be applied only to non-authenticated traffic, and Spark calls will bypass the control check of non-authenticated traffic on Expressway and will be allowed to access the PSTN. For an explanation on how authentication works with CPL rules, refer to the CPL information in the Cisco Collaboration System Solution Reference Network Designs (SRND) guide available at: www.cisco.com/go/srnd. Although it is possible to use a single traversal zone between Expressway-E and Expressway-C for business-to-business calls and Hybrid Call Services, or for mobile and remote access and Hybrid Call Services, we recommend a separate Hybrid Call Services traversal zone. The dedicated traversal zone will ensure that Cisco Spark-specific settings are applied to Cisco Spark calls only and will help with call routing and security-related configurations. Traversal zones don’t require any inbound port to be opened on a DMZ firewall; but if the corporate security policies block outbound access by default, then an outbound port has to be opened in the firewall for every new traversal zone.

Calling ID and Class-of-Service

When a Cisco Spark user calls a Cisco Unified CM endpoint or service, or when the user dials out to the PSTN, the desired behavior is to present the calling user's Cisco Unified CM directory URI or +E.164 number as the calling ID.

When the call leaves the Cisco Collaboration Cloud, the calling ID is set to the Spark SIP Address, such as alice@example.call.ciscospark.com. Because this address matches the remote destination configured in the Spark CTI Remote Device associated with the calling user, the call is anchored on the calling user's CTI-RD and then routed as if it originated from this device. This also sets the caller ID for the ongoing call leg to the enterprise identity (directory number and directory URI) of the calling user.

In this example, Alice dials a PSTN number using Spark. Her calling ID is set to the Spark SIP Address alice@example.call.ciscospark.com. Because the Spark SIP address matches the Remote Destination set in the Spark CTI Remote Device, this call is identified as belonging to Alice on Cisco Unified CM and is forwarded to the final destination as if it started from Alice’s directory number. Therefore, Alice’s calling ID and Alice’s Calling Search Space as set in Cisco Unified Communications Manager will be used instead. This is shown in Figure 9, where steps 3 and 4 are indicating logical processes inside Cisco Unified Communications Manager and not call flows.

Figure 9 — Call Anchoring and Caller ID

14

Call anchoring based on a successful match between calling ID and remote destination is a mobility feature and happens independently from the dialed destination. Note: Cisco Collaboration Cloud has no knowledge of Enterprise dial plan. For this reason, if Alice cannot call Bob using her endpoint on Enterprise due to Calling Search Space limitation, Alice may still call Bob if both use Spark. If Alice uses Spark, Cisco Unified CM will prevent the call from reaching Bob’s endpoint, but Spark client will ring.

Multiple Unified CM Cluster Deployment Considerations Hybrid Call Services support multiple Unified Communications Manger clusters. When multiple clusters are deployed, the incoming call from Cisco Spark has to be routed to the Cisco Unified CM where the calling user is homed, and not to the Unified CM of the called user, in order to associate the call with the Spark Remote Device and correctly set the calling alias and calling search space. This is known as source-based routing. With source-based routing, call anchoring always happens on the Cisco Unified CM of the calling user. With source-based routing, when the Cisco Collaboration Cloud sends a call to the Expressway-E, it populates both the SIP Request URI and the Route Header. Even though the following considerations and examples apply to multiple Cisco Unified CM clusters, the use of the Route Header is general and applies also to single clusters. Thus, Expressway search rules always have to match what’s been populated in the Route Header and not what’s in the Request URI.

15

When both a Request URI and a Route Header are present in a SIP INVITE, the Route Header takes precedence in the routing processes. As an example, when Alice on US cluster dials out to Bob in EMEA cluster using her Cisco Spark client, Expressway-E receives this INVITE:

INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/TLS 10.10.10.10:5062;branch=z9hG4bK-393139-4880f133ef84798fb3625da14a87ad32 Call-ID: 87c778d0a17c9a3a93ef90ff530fda50@30.30.30.30 CSeq: 1 INVITE Contact: "l2sip" <sip:l2sip@10.10.10.10:5062;transport=tls>;call-type=squared From: "Alice" <sip:alice@example.call.ciscospark.com>;tag=1381736467 To: <sip:bob@example.com> Max-Forwards: 70 Route: <sip:l2sip@20.20.20.20:5062;transport=tls;lr>,<sip:us-cm-pub.example.com;lr>

Expressway receives this call on the Cisco Spark DNS Zone enabled for Mutual TLS. The Cisco Spark DNS Zone, Cisco Spark traversal client, and traversal server zone must be enabled for route-header support or the call will be dropped. Expressway-E will thus consider the presence of route headers when routing the call; and since the route header takes precedence over the Request URI, the routing process will analyze us-cm-pub.example.com instead of alice@example.com. Search rules on Expressway will thus match us-cm-pub.example.com and route it to the next hop, Expressway-C or Cisco Unified CM.

When Charlie, on EMEA cluster, calls Bob, the INVITE looks different:

INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/TLS 10.10.10.10:5062;branch=z9hG4bK-393139-4880f133ef84798fb3625da14a87ad32 Call-ID: 87c778d0a17c9a3a93ef90ff530fda50@30.30.30.30 CSeq: 1 INVITE Contact: "l2sip" <sip:l2sip@10.10.10.10:5062;transport=tls>;call-type=squared From: "Charlie" <sip:charlie@example.call.ciscospark.com>;tag=1381736467 To: <sip:bob@example.com> Max-Forwards: 70 Route: <sip:l2sip@20.20.20.20:5062;transport=tls;lr>,<sip:emea-cm-pub.example.com;lr>

This time the Expressway will route the call based on destination emea-cm-pub.example.com, and thus the INVITE will be sent to the EMEA Cisco Unified CM through the Route Header, where Charlie’s devices are registered. The Cisco Collaboration Cloud populates the Route Header based on the information received by the Call Connector, and specifically copied from the Cisco Unified CM Cluster Fully Qualified Domain Name (CFQDN) Enterprise Parameter. In this way, the Cisco Collaboration Cloud builds a table where every Directory URI is associated with the respective CFQDN. When a call is sent from the Cisco Collaboration Cloud, the destination directory URI of the call populates the INVITE Request URI, and the home cluster of the calling user populates the Route Header. In case of multiple CFQDN entries, only the first one will be copied in the route header, as shown in Figure 10.

16

Figure 10 — Cluster Fully Qualified Domain Name (CFQDN)

We recommend avoiding the use of wildcards in the first entry of the CFQDN enterprise parameter. If the CFQDN uses wildcards, we recommend adding another one in front, such as in the following example:

CFQDN: us-cm-pub.example.com *.example.com Note: CFQDN must be different than Expressway-E DNS domain or Expressway. As an example, if CFQDN is set to example.com and the DNS domain of Expressway is also set to example.com, Expressway might not be able to route the call Expressway-C should therefore include search rules to route the call to the correct Cisco Unified CM cluster based on the Route Header, as shown in Figure 11.

17

Figure 11 — Call Routing Based on Route Header

In this scenario, two search rules are built on Expressway: the first matches calls with destination us-cm-pub.example.com and sends them to Cisco Unified CM in the US cluster, and the second matches calls with destination emea-cm-pub.example.com and sends them to Cisco Unified CM in the EMEA cluster.

In case of multiple clusters it is required that each CFQDN is unique for source-based routing to work properly, as shown in figures 10 and 11.

Before routing the call to Cisco Unified CM, Expressway-C should be configured to strip off the Route Header. Thus, when the call enters Cisco Unified CM, the Route Header will be missing and Unified CM will route the call accordingly to the Request URI.

Note that this call flow is not supported in architectures where a transit node is used, such as in the case of a Cisco Unified Communications Manager Session Management Edition (SME) deployment. In all cases the Spark call has to reach the home cluster of the calling user.

Toll Fraud and Identity Theft Mitigation

Because inbound calls to Cisco Unified CM with calling ID set to the Spark SIP Address are anchored, it’s important that Expressway-E provides a first line of defense against users not part of the organization that might present themselves with a calling address equal to a Spark SIP Address. Expressway-E can block those fraudulent calls through the use of Call Policy rules. The logic is that if a call has been authenticated through Mutual TLS and public certificates, it will be allowed. Conversely, if a call coming into the Default Zone contains a source alias with the Spark SIP domain, it will be rejected.

18

The following example shows the Call Policy rules in order to block calls from Expressway-E Default Zone that contains the Spark SIP domain example.call.ciscospark.com, while allowing calls from the Spark DNS Zone to Expressway-C containing the same domain in the source alias:

Table 3 — Call Policy rules blocking access from the Default Zone with source alias containing the corporate Spark domain

Source type Rules applies to Source pattern Destination pattern Action Rule 1 From address Authenticated callers .*@example\.call\.ciscospark\.com .* Allow Rule 2 From address Unauthenticated callers .*@example\.call\.ciscospark\.com .* Reject Next, the Authentication Policy in the Default Zone has to be set as “do not check credentials”, and the authentication policy of the Spark Traversal Server zone has to be set to “treat as authenticated”. This way traffic coming from the Default Zone and containing the Spark SIP domain will be marked as unauthenticated and will thus be rejected by the rules. For more details on Call Policy rules, refer to the Dial Plan Protection section from the Collaboration SRND: http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab11/collab11/gateways.html#45435

High Availability Hybrid Services will be highly available if Exchange, Unified CM, Cisco Expressways are deployed in a cluster. Specifically, Expressway-C Connector Host can be deployed in a cluster to account for redundancy. Same guidelines that apply to Cisco VCS and Expressway apply for Expressway-C Connector Host clustering as well.

Preliminary Sizing As seen, when all users are enabled for Call Service Connect, a large amount of calls is generated toward Expressway-C and Expressway-E because internal Cisco Unified CM calls are reflected as call legs on Expressways through remote destinations. The number of calls depends on the user BHCA of the organization. Therefore, it is important to size the solution properly so that the capacity of the Expressways is not exceeded. Besides, CTI-RD has an impact on Cisco Unified CM and this must be taken into considerations It is possible to share a single Expressway-C and Expressway-E cluster with multiple services such as mobile and remote access, business-to-business communications, and Hybrid Call Services. However, when the traffic exceeds the capacity of the Expressway cluster, appropriate sizing and possibly deployment of additional Expressways for Hybrid Call Services might be required. Table 4 shows the number of Cisco Unified CM, Expressway-C and Expressway-E servers required for a specific number of users. Two options are considered: Expressway-C connector host with redundancy or without. Table 4 – Sizing examples

Number of users Unified CM Expressway-C Expressway-E Expressway-C Connector Host

Expressway-C Connector Host with HA

1000 5 2 2 1 2 2500 5 2 2 1 2 5000 5 2 2 1 2 7500 7 3 3 2 4

10000 7 3 3 2 4

The number of Cisco Unified CM servers includes a dedicated publisher and two TFTP servers. These examples are based on the following assumptions: - Every user has a Cisco Spark client and a Cisco Unified CM device - 4 BHCA per user - 3 minutes AHT (average hold time) - 7% of users engaged on a multiparty conference call during the busy hour - 3 minutes is the average time interval required for users to get into the conference - 50% of traffic on net - 25% of traffic outgoing to the PSTN

19

- 25% of traffic incoming from the PSTN - 20% probability of using Cisco Spark client on a call - 20% of calls are video-based

Deployment Steps This section is a high-level step-by-step guide to deploying each connector. This guide should be used in conjunction with the product documentation shown below. Deploy Directory Connector

1. Deploy a new Microsoft Windows Server and join Active Directory. 2. Log into the Cloud Collaboration Management Portal from the Windows Server and download the Directory

Connector. 3. Install the Directory Connector. 4. Select containers objects, LDAP filters if available, and set the schedule. 5. Run a first synchronization; configure full synchronization and incremental synchronization.

Detailed installation and configuration instructions for Directory Connector are available at: http://www.cisco.com/go/hybrid-services-directory

Deploy Expressway-C Connector Host 1. Download and deploy Expressway-C connector host OVA or use a hardware appliance. 2. Register it to the Cisco Collaboration Cloud using the Cloud Collaboration Management Portal.

Deploy Calendar Connector 1. On Exchange, set up Impersonation for the Calendar Connector Service User Account. 2. On Expressway-C, configure the Exchange connection using the Impersonation account. 3. On Expressway-C, configure the WebEx details for CMR integration. 4. On Expressway-C, enable the Calendar Connector.

Detailed installation and configuration instructions for Calendar Connector are available at: http://www.cisco.com/go/hybrid-services-calendar

Deploy Call Connector

Call Service Prerequisites 1. On Cisco Unified CM, set the mail ID of the user or import it from the LDAP directory. 2. On Cisco Unified CM, associate a directory URI to the user’s directory number. 3. On Cisco Unified CM, set the telephone number attribute and associate it to the user’s primary directory

number. 4. On Cisco Unified CM, configure the Enterprise Parameter “Cluster Fully Qualified Domain Name.” 5. On Cisco Unified CM, associate users with devices. 6. On Cisco Unified CM, set the home cluster on the user configuration page. 7. Deploy Expressway-C and Expressway-E for firewall traversal capabilities.

Call Service Aware Deployment Steps 1. On Cisco Unified CM, enable Spark users for CTI control. 2. On Cisco Unified CM, configure an application user to monitor devices enabled for CTI control. 3. On Expressway-C connector host, enable Call Connector.

Call Service Connect Deployment Steps 1. On Cisco Unified CM, enable users for unified mobility. 2. On Cisco Unified CM, configure a CTI Remote Device for each user’s primary extension. Alternatively, the

administrator can configure automatic creation of the CTI Remote Devices with the limitation that settings like Calling Search Space, Rerouting Calling Search Space, Location and Device Pool will be shared between all CTI Remote Devices.

3. On Cisco Unified CM, set the CTI Remote Device to the user’s primary extension and partition.

20

4. On Cisco Unified CM, associate the CTI Remote Device to the user’s account. 5. On Expressway-E, set up a new DNS Zone for Cisco Spark. 6. On Expressway-E, configure the DNS Zone for Mutual TLS on a dedicated port (for example, port 5062).

First enable port 5062 for MTLS globally under Configuration -> Protocols -> SIP, then set the “Enable Mutual TLS on Default Zone” parameter to “off”. In case port 5062 must be used, please check that this port is open on the firewall.

7. On Expressway-E, enable the Route Header support for this zone (otherwise an INVITE containing a route header won’t be processed).

8. On Expressway-E, configure a Spark traversal server zone (standard traversal server zone enabled for SIP only). Set the encryption type to “force encrypted” in order to have an encrypted communication between the Cisco Collaboration Cloud and Expressway-C. Enable Route Header support and SIP parameter preservation to preserve the Contact Header in case B2BUA is engaged, so that Cisco Collaboration Cloud is able to stop the loops.

9. On Expressway-E, create a search rule matching any call with a domain portion that includes “<subdomain>.call.ciscospark.com” and with the destination set to the DNS Zone.

10. On Expressway-E, create a search rule matching the Cisco Unified Communications Manager CFQDN and the destination set to the Spark traversal server zone.

11. On Expressway-C, configure a Spark traversal client zone (standard traversal client zone enabled for SIP only). Set the encryption type to “force encrypted” in order to have an encrypted communication beteween the Cisco Collaboration Cloud and Expressway-C. Enable Route Header support and SIP parameter preservation to preserve the Contact Header in case B2BUA is engaged, so that Cisco Collaboration Cloud is able to detect the loops.

12. On Expressway-C, configure a neighbor zone to Cisco Unified CM for Hybrid Call services, different from the neighbor zone used for B2B. Set the port to a value different than 5060 and 5061, such as 5660 or 5661. Don’t enable Route Header support; from this moment on, routing will be performed by Cisco Unified CM by using the Request URI only.

13. On Expressway-C, create a search rule matching any call with a domain portion that includes “<subdomain>.call.ciscospark.com” and with a destination set to the Spark traversal client.

14. On Expressway-C, create a search rule matching the Cisco Unified Communications Manager CFQDN and the destination set to the Cisco Unified CM neighbor zone.

15. On Cisco Unified CM, create a SIP Trunk Security Profile with listening port set to 5560 or 5561 (in case security is turned on).

16. On Cisco Unified CM, create a SIP Trunk linked to the security profile created in step 15, and point it to the Expressway-C. Include the SIP trunk in a route group and a route list.

17. On Cisco Unified CM, create a SIP Route Pattern (if not present) to route the domain *.ciscospark.com to the Expressway-C, and specify the previously created route list as target.

Detailed installation and configuration instructions for Call Connector are available at: http://www.cisco.com/go/hybrid-services-call