CISCO SYSTEMS, INC.

Deploying Cisco Spark Hybrid

Services
By Luca Pellegrini
Revised: 07/22/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.......................................................................................................................... 3
Cloud Collaboration Management Portal .......................................................................................................... 4
Management Connector ...................................................................................................................................... 4
Directory Connector ............................................................................................................................................ 4
Calendar Connector ............................................................................................................................................ 5
Call Connector ..................................................................................................................................................... 6

Call Service Connect Architecture and Call Flow............................................................................................................... 8

Users URIs .................................................................................................................................................................... 8
Loop Detection and Avoidance ................................................................................................................................... 11
Mutual TLS .................................................................................................................................................................. 11
Media Encryption ........................................................................................................................................................ 11
Expressway-C and Expressway-E on a Shared Deployment .......................................................................................... 12
Expressway-C and Expressway-E Dedicated Deployment .............................................................................................. 13
Calling ID and Class-of-Service ....................................................................................................................................... 13
Multiple Unified CM Cluster Deployment Considerations................................................................................................. 14
Sizing Considerations ...................................................................................................................................................... 17

Deployment Steps .............................................................................................................................. 18

Deploy Directory Connector ............................................................................................................................. 18
Deploy Expressway-C Connector Host ........................................................................................................... 18
Deploy Calendar Connector ............................................................................................................................. 18
Deploy Call Connector ...................................................................................................................................... 18

Call Service Prerequisites ................................................................................................................................................ 18

Call Service Aware Deployment Steps ............................................................................................................................ 18
Call Service Connect Deployment Steps ......................................................................................................................... 18

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

3.

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

Management

Cisco Cloud Collaboration

Management Portal
Cisco Management
Connector on Expressway-C

Directory services

Microsoft Active Directory

Cisco Directory Connector

Calendaring services

Microsoft Exchange
Cisco Calendar Connector
Cisco Unified
Communications Manager

Call Control

Cisco Call Connector

Cisco Expressway Series:
Expressway-C and
Expressway-E

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
Provides integration between on-premises call processing
services and Cisco Collaboration Cloud
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 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.

Directory Connector
Cisco Spark integrates with Microsoft Active Directory and supports a single forest with multiple domains. 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 readonly 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.
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.
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.
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 CTIQBE.
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.
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 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.example.call.ciscospark.com, 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.
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:

Note: In cases where port 5061 is already in use we recommend using a different port for Mutual TLS, such as port 5062
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.
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

10

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

11

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

12

Expressway-C and Expressway-E Dedicated Deployment

If Hybrid Call Services are on a dedicated Expressway cluster pair, or if they are shared with MRA but not B2B, a dual-trunk
configuration on Expressway-C and Cisco Unified CM wouldnt be needed. In this case, a single trunk on Cisco Unified CM and
a single neighbor zone on Expressway-C would be sufficient.
Besides, if Hybrid Call Services are on a dedicated Expressway with no B2B or MRA services, a Mutual TLS port can be
configured to use standard TLS port 5061. This wouldnt require opening a new port on an external firewall.
This deployment is recommended if at least one of the following conditions is met:

Corporate security policy prevents port 5062 (or any port other than 5061 that can be associated to Mutual TLS) from
being opened on the external firewall.

Single cluster capacity is exceeded.

If corporate security policies do not allow use of port 5062, it is possible to use port 5061 on a dedicated deployment. In cases
where 5061 is already used for TLS-based business-to-business services and is defined in the public DNS server as an SRV
record, such as:
Service and protocol: _sips.tcp.example.com
Priority: 1
Weight: 10
Port number: 5061,
Target: us-expe1.example.com
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: 5061,
Target: us-expe1.example.com
The SIP destination on the Cloud Collaboration Management Portal would in this case be equal to
hybridcallservices.example.com.
The SIP domain is used on the SRV request only for Expressway-E discovery and doesnt impact the called alias. In case of a
dedicated Expressway for Hybrid Call Services, only a single trunk and a single neighbor zone are required on Cisco Unified CM
and Expressway-C, and a single traversal zone will be required between Expressway-C and Expressway-E.

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:5061;branch=z9hG4bK-393139-4880f133ef84798fb3625da14a87ad32
Call-ID: 87c778d0a17c9a3a93ef90ff530fda50@67.23.43.22
CSeq: 1 INVITE
Contact: "l2sip" <sip:l2sip@10.10.10.10:5061;transport=tls>;call-type=squared
From: "Alice" <sip:alice@ent-4pa.call.ciscospark.com>;tag=1381736467
To: <sip:bob@example.com>
Max-Forwards: 70
Route: <sip:l2sip@20.20.20.20:5061;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:5061;branch=z9hG4bK-393139-4880f133ef84798fb3625da14a87ad32
Call-ID: 87c778d0a17c9a3a93ef90ff530fda50@67.23.43.22
CSeq: 1 INVITE
Contact: "l2sip" <sip:l2sip@10.10.10.10:5061;transport=tls>;call-type=squared
From: "Charlie" <sip:charlie@ent-4pa.call.ciscospark.com>;tag=1381736467
To: <sip:bob@example.com>
Max-Forwards: 70
Route: <sip:l2sip@20.20.20.20:5061;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.

Sizing Considerations
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.
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.

17

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

3.
4.
5.

Deploy a new Microsoft Windows Server and join Active Directory.

Log into the Cloud Collaboration Management Portal from the Windows Server and download the Directory
Connector.
Install the Directory Connector.
Select containers objects, LDAP filters if available, and set the schedule.
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.
2.

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

Deploy Calendar Connector

1.
2.
3.
4.

On Exchange, set up Impersonation for the Calendar Connector Service User Account.
On Expressway-C, configure the Exchange connection using the Impersonation account.
On Expressway-C, configure the WebEx details for CMR integration.
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.
2.
3.
4.
5.
6.
7.

On Cisco Unified CM, set the mail ID of the user or import it from the LDAP directory.
On Cisco Unified CM, associate a directory URI to the users directory number.
On Cisco Unified CM, set the telephone number attribute and associate it to the users primary directory number.
On Cisco Unified CM, configure the Enterprise Parameter Cluster Fully Qualified Domain Name.
On Cisco Unified CM, associate users with devices.
On Cisco Unified CM, set the home cluster on the user configuration page.
Deploy Expressway-C and Expressway-E for firewall traversal capabilities.

Call Service Aware Deployment Steps

1.
2.
3.

On Cisco Unified CM, enable Spark users for CTI control.

On Cisco Unified CM, configure an application user to monitor devices enabled for CTI control.
On Expressway-C connector host, enable Call Connector.

Call Service Connect Deployment Steps

1.
2.

3.
4.
5.
6.

On Cisco Unified CM, enable users for unified mobility.

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.
On Cisco Unified CM, set the CTI Remote Device to the users primary extension and partition.
On Cisco Unified CM, associate the CTI Remote Device to the users account.
On Expressway-E, set up a new DNS Zone for Cisco Spark.
On Expressway-E, configure the DNS Zone for Mutual TLS. Mutual TLS can be activated on a dedicated port on
Expressway-E, or in the default TLS port 5061. To enable TLS on port 5061, set the Enable Mutual TLS on
Default Zone parameter to on in the Default Zone. This will turn on MTLS on the standard port. If MTLS has to
be enabled on a dedicated port only (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. This
will turn on MTLS on the dedicated port only.

18

7.
8.

9.
10.
11.

12.

13.
14.
15.
16.
17.

In case when port 5062 must be used, please check that this port is open on the firewall.
On Expressway-E, enable the Route Header support for this zone (otherwise an INVITE containing a route
header wont be processed).
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.
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.
On Expressway-E, create a search rule matching the Cisco Unified Communications Manager CFQDN and the
destination set to the Spark traversal server zone.
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.
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.
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.
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.
On Cisco Unified CM, create a SIP Trunk Security Profile with listening port set to 5560 or 5561 (in case security
is turned on).
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.
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

19