CISCO SYSTEMS, INC.

Deploying Cisco Spark Hybrid

Services
By Luca Pellegrini
Revised: 11/17/2016

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.

 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

1
 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.

2
 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
Cisco Cloud Collaboration
Management Portal
Management
Cisco Management
Connector on Expressway-C
Microsoft Active Directory
Directory services
Cisco Directory Connector
Microsoft Exchange
Calendaring services
Cisco Calendar Connector
Call Control Cisco Unified
Communications Manager
Description
Enables management of Spark-enabled users, registration
of Expressway-C connector host to the Cisco Collaboration
Cloud, and connector upgrades
Enables connectors hosted on Expressway-C to be
managed by the Cisco Collaboration Cloud
Provides the full list of corporate users and users
attributes
Provides user synchronization between Active Directory
and the Cisco Collaboration Cloud
Provides corporate calendaring services
Provides integration between on-premises calendaring
application and Cisco Collaboration Cloud
Provides endpoint registration, call processing, and media
resource management
3
 Provides integration between on-premises call processing
Cisco Call Connector
services and Cisco Collaboration Cloud
Cisco Expressway Series:
Expressway-C and Enables firewall traversal for Hybrid Services calls
Expressway-E

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 ExpresswayE 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.

4
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
users 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 doesnt 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 users 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.

5
 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.

6
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.

7
 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 users 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

8
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 Bobs 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 Bobs 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.

9
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 Bobs 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.

10
 The call reaches Cisco Unified CM and anchors to Alices 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 Bobs directory URI, shared with Bobs Spark CTI Remote Device. Bobs
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 Bobs 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

11
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

12
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 dont 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 Alices directory number. Therefore, Alices calling ID and Alices 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

13
 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 Bobs 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 whats been populated in the Route Header and not whats in the Request URI.

14
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 Charlies 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.

15
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.

16
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, its 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.

17
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 Expressway-C Connector

Connector Host 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

18
- 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 users directory number.
3. On Cisco Unified CM, set the telephone number attribute and associate it to the users 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 users 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 users primary extension and partition.

19
 4. On Cisco Unified CM, associate the CTI Remote Device to the users 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 wont 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. Dont 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

20