Cisco Spark Hybrid Services – Call Service Connect Deployment

 Introduction

Undoubtedly we’ve all heard about Cisco Spark over the past year. Lumped in between the cloud and the cloud’s cloud, there is a component referred to as Hybrid Services. Hybrid Service is summed up as multiple components designed to bridge the preverbal gap between the Cisco Collaboration Cloud and your On-Prem UC (Unified Communications) infrastructure. For some of us, migrating to the cloud may not be an option for quite some time, if ever. Designed to introduce the customer to Cisco’s Cloud offerings, Hybrid Services aims to highlight the benefit of having a unified experience for all collaboration applications. This article is aimed at the engineer looking to deploy the Call Service Connect feature into their companies infrastructure, all the while helping us see a world that is Jabber-free. For instance, If I receive an incoming call on my 10 digit DID (Office number), Call Service Connect will allow me to receive that same incoming call through Cisco Spark on any of my mobile devices. Pretty cool, right? Likewise, outgoing calls to the PSTN are also routed out of your company’s gateway via SIP Trunk or PRI.

Preparation

Let’s make a few assumptions. The first being that you have a working CUCM (Cisco Unified Communications Manager) and the second being that you have read our deployment guide for Expressway located here and here, respectively. Strap yourselves in, it’s a two parter. Satisfying those requirements will help immensely with the configuration and troubleshooting in the next few sections.

The below diagram depicts what the Call Connector will look like in your environment.

Its important to note that you MUST and I mean MUST be running Expressway 8.7.1 or higher on your Expressway-C. The image below was taken directly from the deployment guide. Certain pieces will work on 8.7, but the guide specifically mentions that in order to take “full advantage” of the feature, you need 8.7.1. In addition, CUCM MUST be chugging along at 10.5(2)SU3. The guide(s) I used from Cisco are here and here.

Configuration

Let’s start by agreeing CUCM and Expressway meet the version requirements for this to work. k? cool. Next let’s make sure we have DNS working as it should. Below you’ll see our SRV record we use. The Spark application uses this to route calls destined for your CUCM infrastructure to the correct host. Spark does an SRV lookup for the protocol sips using tcp as the transport protocol and sipmtls as the subdomain for this domain. In our case, we weight this record at 1 (lower value is more preferred) and priority at 10 (only relevant if we have more than one SRV record). The port we tell it to use is 5062 (Mutual TLS) and the target is our Expressway-E (expressway.cloverhound.com). Like B2B or MRA, this uses the same protocol with the exception of us having it use 5062 instead of 5061. If you are using 5061 for MRA today, changing the MTLS port will break connectivity.

➜ ~ nslookup
> set type=SRV
> _sips._tcp.sipmtls.cloverhound.com
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
_sips._tcp.sipmtls.cloverhound.com service = 1 10 5062 expressway.cloverhound.com.

Since we just declared that Cisco Spark should use 5062 on all inbound connections to our Expressway-E, we need to tell Expressway-E that. Below are our SIP settings. Ensure you have Mutual TLS mode set to On and its using 5062 as its Mutual TLS port.

Once DNS is verified and the Expressway-E knows that port to use for MTLS, let’s hop over to CCM (Cisco Cloud Collaboration Management). From there, navigate to Services, Hybrid Call; Settings. Scroll down to the bottom and enable Connect. Under SIP Destination, enter in sipmtls.yourdomain.com. yourdomain will be the external DNS zone you used for your SRV entry above. This step ensures calls destined for your org make it to your Expressway-E. It does this by doing an SRV lookup against the sipmtls service offered by cloverhound.com. Another item involving DNS you will want to take care of while you’re here is Aware. Most notably, Aware makes Spark “aware” of all calls across your UC system enabling Spark to view recent call history. To verify your domain as a valid domain for your org, click Add Domain.

Enter in the domain you wish to add. After submission, the domain will go into a Pending state. Select Verify. In order for Cisco to verify you own that domain, it forces you to manually add a TXT record to your domain’s external DNS zone file. Simply go to your external DNS manager and create a new TXT record with the string below. This string will be unique to each domain.

To verify, let’s look at our external DNS zone to ensure it created the record. For obvious reasons, we can not verify test.com since we don’t own it. Instead, we will use cloverhound.com.

➜ ~ nslookup
> set type=TXT
> cloverhound.com
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
cloverhound.com text = “7744b423ac3a7d45bb83103d9a645168f3e3db5d9e52880f197e6638c7eefa3c”

Once DNS is configured and we’ve verified that inbound Spark calls to our org will route to the correct place, we need to head over to our Expressway-C and configure the CUCM integration. From Application>Hybrid Services>Call Service select New and add the CUCM IP address. Select Verify Credentials. NOTE: This user must have AXL and CTI access permissions. 

Once verified, the status on both CTI and AXL will change to up. If you run into issue with this part, verify application user permissions for the account you used, as well as the AXL Web Service. Ensure it is running.

Once added, navigate to Application>Hybrid Services>Call Connector and toggle the Active radio button to Enabled. This will start the Call Connector.

Now that we’ve enabled the Expressway-C, we need to start work on how we’re going to place and receive calls. As depicted by the diagram, the call originates from the endpoint signaling CUCM where the destination is. As we can see, both outbound and inbound calls traverse the Expressway-C and E through the Unified Communications traversal zone. Outbound calls from CUCM to URIs will look at the SIP Route Pattern. In our lab, we are using * to default route any domain not matching a specific one to the trunk towards the Expressway-C. As this is a lab, we ensure that all domains listed as a destination in a SIP header get routed. The official guide will have you use *.ciscospark.com as your SIP route pattern. 

Once the destination is matched to a SIP route pattern, it routes to the Expressway-C.

The Expressway-C then looks at its Search Rules and determines the best match for the destination to route the call. In our case, we again have a default rule to send anything not matching a specific domain towards the Expressway-E. We do this because during the selection process, it queries its local zone for the destination. As the destination *ciscospark.com doesn’t match any of the URIs on CUCM, it knows to send it on. Below is our rule we use to match.

In our case, the TraversalZone is the Neighbor Zone to the Expressway-E. As this call enters the Expressway-E, it looks at its search rule to find where to go next. As you see by our outbound search rule towards CCM, we see it is matching any pattern string that contains @ciscospark.com and routing it out the DNS Zone Cisco Spark Hybrid Services. 

The Cisco Spark Hybrid Services DNS zone then makes a determination on where to send the call based on the configuration we have listed below. This configuration is similar to default DNS zone you most likely have on your Expressway-E with the exception of isolating the destination to look for. As this is a MTLS connection, we want to ensure TLS Verify mode is set to On as well as including the TLS Subject Verify Name of callservice.ciscospark.com. This ensures that all routes routed to this domain are encrypted using TLS.

Thats outbound. Let’s work on getting inbound calls. Since we have already completed the requisite steps above when we first started, all we need to do is ensure users have a Spark Remote CTI device in CUCM. Under your Unified CM Server setting on your Expressway-C there is an option for your Call Service Connect Configuration. For our lab, we opted for automatic provisioning. If you have thousands of devices, manual import may be better. Once you’ve done that, you will need to go into CCM and enable Connect for the users you want Call Service Connect enabled for. Toggle the switch to On and restart the Call Connector on the Expressway-C.

Almost there. After Call Connector restarts, you should now see the Onboarded Users change to reflect the number of users you enabled for Call Service Connect.

To verify, check CUCM to see the automatically provisioned device.

From the Spark cloud, we can now work through getting calls inbound to our remote CTI device (Cisco Spark application). Caller A initiates a call to Caller B via their PSTN number (7048675309). Caller B will receive an inbound call to that PSTN number through the Spark application. It does this by matching inbound URI destinations. For example, when the Expressway-E receives a call, its destination will look like this:

Our Expressway-E has a Search Rule targeting the Traversal Zone. This is directing all incoming URI destinations towards the Expressway-C.

Once our Expressway-C receives the SIP packet from the Expressway-E, it then looks where to route calls with the destination +17048675309@cloverhound.com;user=phone. As you can see by the below figure, its matching any destination with the @cloverhound.com;user=phone suffix. The target destination to route this call is CUCM Neighbor. In this case, that is our CUCM. 

One of the most time time consuming parts in all of this was the last part. I was able to get calls outbound and inbound but CM traces showed me that once the Expressway-C sent the calls to CUCM, it was stripping everything but 4 digits. If you are a victim of this nonsense, make sure to check the incoming allowed digits on the SIP trunk connecting CUCM to Expressway-C.

We hope this guide can provide benefit in configuring Cisco Spark Hybrid Services for your organization. For any revisions, questions, or comments, feel free to contact myself directly (through Spark obviously) or drop a comment below.