This blog is working under the assumption that the following on-premises pieces have already been built out and are working independently of the WebEx cloud piece:
- Cisco Unified Communications Manager solution on-premises
- On-premises PSTN connectivity via a Cisco Voice Gateway or CUBE
This blog also assumes that the WebEx piece has already been provisioned and that Video endpoints are already registered to the cloud.
Part 2 of this blog adds some details around the pieces that added to what’s listed above to pull this together. Here’s the high-level list of technologies mentioned again.
- WebEx Control Hub
- Cisco CUCM
- Cisco Expressways
- Firewalls
- NAT
- DNS
- Certificates
- Cisco Directory Connector software
Please read all of the Cisco guides thoroughly before attempting design or installation. With that said here’s a little bit of information about each technology with my tech notes.
The curve balls I ran into in the process are in orange text.
The curve balls I ran into in the process are in orange text.
WebEx Control Hub
The WebEx Control Hub is the partner/customer configuration touchpoint for the WebEx cloud. Below is a high-level list of most of the things configuring in the WebEx Control Hub for Hybrid Calling.
- Created a custom SIP subdomain (for example joshualearn.com)
- “Verify” the subdomain via a DNS text record with a special hash value provided in the WebEx Control Hub
- Optionally “claim” the subdomain with a TAC case. (If the subdomain is claimed then any new WebEx Teams account with that email domain has to be created in the official Company organization)
- Call Connect
- It gets enabled pointed to the SRV record for the MTLS connection to the Expressway-E For example, _sips._tcp.sipmtls.joshualearn.com (It’s also possible to use an IP and port in the case of a quick POC)
- Upload the expressway certs to WebEx (if they’re self-signed)
- Active Hybrid Call Service
- Add a default SIP destination for Hybrid Call Connect Service
- Enable Hybrid Calling for the user in the WebEx cloud. (The directory URI of the Spark Remote Destination should match the user's mail id in CUCM which should also match the user-id in the WebEx control hub
Cisco CUCM
The Cisco CUCM should already be in place but there a few things that to be validated and or remediated to start and there a few things that need to be configured specifically to the integration build-out.
General Prerequisites
- The CUCM database replication needs to be built out using FQDNs. The Expressway will connect to the CUCMs using that same value and need a FQDN that can be resolved via DNS. This caught me off guard the first time and required additional planning to update the system to FQDN entries and to re-establish the database replication between CUCMs.
- Cluster Fully Qualified Domain Name in the Enterprise Parameters needs to be configured to something unique. For example cluster1.joshualearn.com
New build out for Hybrid Calling
- The CUCM needs a service account with AXL permissions (which is pretty standard for most applications)
- Cisco CUCM needs a SIP trunk built out to the Expressway C server
- Cisco CUCM needs SIP route patterns to send calls to WebEx.
- *.calls.webex.com
- *.rooms.webex.com
- Configure the Spark remote device
- Configure a Spark Remote Destination for the user
Cisco Expressway
The Cisco Expressways is a bit of Swiss Army Knife for Cisco when it comes to additional software required for Hybrid Calling. Most of the specific connector software runs on the Expressway-C Connector host. There is also a transit pair required to create the secure transport between CUCM on the WebEx cloud.
Cisco Expressway-C Services Host
- Cisco recommends that the Expressway-C Services Host is updated to the latest version of code. This will allow for interoperability with the WebEx Control Hub. This is also the reason why it’s helpful to have the Services host on its own dedicated Expressway. (Some customers have very small deployments and are tempted to use the same Expressway-C as the Connector host and the transit host. However, these can cause additional challenges with keeping up the latest Expressway code on the C and E. If the Expressway-C Connector host is separate than the transit pair for the Expressways can be updated on a different interval.
- The Management Connector is installed to establish connectivity to the WebEx Control Hub from the Expressway
- The Call Connector is installed to create the data hook between the CUCM and the WebEx control hub
- Linking the Call Connector to CUCM pulls the IP address or the FQDN of the CUCM. If the system was defined using a hostname in CUCM the connection will fail. This is an issue I ran once. For whatever reason, the folks that deployed the initial CUCM decided to use hostnames. The Expressway-C Connector host could not resolve the hostname and therefore could not connect the CUCM.
Cisco Expressway Traversal Pair
The traversal pair is basically a way for the SIP traffic to traverse from the Cisco CUCM on-premises environment to the WebEx Control Hub and cloud registered video endpoints. The expressway traversal hosts can be dedicated or shared with existing MRA and or B2B expressways. Refer to the Expressway guides for details on how to spin up and license them.
Cisco Expressway-C Traversal Host
- The Expressway-C host sits on the internal voice server network.
Cisco Expressway-E Traversal Host (with 2 NICs)
- The Expressway-E ideally sits in a firewall environment with a transit DMZ and a service DMZ. However, I have also seen it deployed with one NIC in a service DMZ and the other NIC on the inside network.
- Create an MTLS zone between the Expressway-E and the WebEx cloud.
- Follow the guide to configure zones and search rules on the Expressways.
- One caveat I ran into once was with using the automatic WebEx DNS zone. It ended up causing an error message to pop up. I don’t remember any more specifically what the message was. It may have been that is was looking for additional SIP ports to be available instead of just the MTLS SIP port 5062. In any case, I manually built this rule and I didn’t receive any errors.
- Another caveat I ran into was the tool to validate the connection to the WebEx control hub was bugged out and didn't support MTLS. That warning can be ignored. (At least until Cisco updates that portion of the code). Bug ID:
Firewall
- Two firewall DMZs are recommended by Cisco however, some customers have opted to implement one and put the “transport DMZ NIC” on the inside network.
- Firewall policies
- Open up port 5062 on the firewall for traffic towards the Expressway-E (for the WebEx Control Hub)
NAT
- NAT the “Service DMZ” interface of the Expressway-E to a public IP address
DNS
- A record – create an A record for the Expressways. For example expe.us1.joshualearn.com.
- SRV record – create an MTLS SIP service record. For example _sips._tcp.sipmtls.joshualearn.com. 300 IN SRV 5 10 5062 expe.us1.joshualearn.com.
Certificates
- Internal certificates are allowable if the Expressway-E is only hosting the Hybrid Calling, however, the WebEx Control Hub needs to trust the issuing CA chain. If the Expressway-E is also hosting MRA and or B2B then a publicly signed certificate is required on the Expressway-E
Have you implemented this before, have thoughts about trying it out, or do you just like to leave comments? If so, please leave one below.
No comments:
Post a Comment