Cisco CUCM – MRA (Mobile and Remote Access) – Overview

Hey guys,

Today I’m going to talk about a very useful solution, part of the Cisco Collaboration Edge Architecture: MRA.
This post is going to be the first part, to cover the concepts, requirements and compatibilities.

Basically, MRA (Cisco Unified Communications Mobile and Remote Access) allows endpoints such as Cisco Jabber to have their registration, call control, provisioning, messaging and presence services provided by CUCM when the endpoint is outside the enterprise network. The Expressway provides secure firewall traversal and line-side support for Unified CM registrations.

This solution supports a hybrid on-premises and cloud-based service model. It provides a secure connection for Jabber application traffic and other devices with the required capabilities to communicate without having to connect to a VPN. It is a device and operating system agnostic solution for Cisco Jabber clients on Windows, Mac, iOS and Android platforms.

MRA allows Jabber clients that are outside the enterprise to do the following:

  • Use Instant Messaging and Presence services
  • Make voice and video calls
  • Search the corporate directory
  • Share content
  • Launch a web conference
  • Access visual voicemail

Components

MRA requires Expressway (Expressway-C and Expressway-E) and Unified CM, with MRA-compatible soft clients and/or fixed endpoints. The solution can optionally include the IM and Presence Service and Unity Connection.

Product Versions

image

Protocols

image

Compatible Endpoints

image

If you are deploying any of these devices to register with Cisco Unified Communications Manager through MRA, be aware of the following points. For DX endpoints, these considerations only apply to Android-based devices and do not apply to DX70 or DX80 devices running CE software:

  • Trust list: You cannot modify the root CA trust list on Cisco IP Phone 7800 Series and Cisco IP Phone 8800 Series devices. Make sure that the Expressway-E’s server certificate is signed by one of the CAs that the devices trust, and that the CA is trusted by the Expressway-C and the Expressway-E.

  • Off-hook dialling: The way KPML dialling works between these devices and Unified CM means that you need Cisco Unified Communications Manager 10.5(2)SU2 or later to be able to do off-hook dialling via MRA. You can work around this dependency by using on-hook dialling.

Cisco CUCM Requirements

CUCM dial plan will not be impacted by devices registering via Expressway. Remote and mobile devices still register directly to Unified CM and their dial plan will be the same as when it is registered locally.

Unified CM nodes and Expressway peers can be located in different domains. For example, your Unified CM nodes may be in the enterprise.com domain and your Expressway system may be in the edge.com domain.

In this case, Unified CM nodes must use IP addresses or FQDNs for the Server host name / IP address to ensure that Expressway can route traffic to the relevant Unified CM nodes.

Unified CM servers and IM and Presence Service servers must share the same domain.

  • Certificates

Two certificates on CUCM are significant for Mobile and Remote Access: CallManager certificate and Tomcat certificate.
PS:
If you do use self-signed certificates, the two certificates must have different common names. The Expressway does not allow two self-signed certificates with the same CN. So if the CallManager and tomcat self-signed certificates have the same CN in the Expressway’s trusted CA list, the Expressway can only trust one of them. This means that either secure HTTP or secure SIP, between Expressway-C and Cisco Unified Communications Manager, will fail.

The Expressway certificate signing request (CSR) tool prompts for and incorporates the relevant Subject Alternative Name (SAN) entries as appropriate for the Unified Communications features that are supported on that Expressway.

The Expressway-C server certificate must include the following elements in its list of subject alternate names: Unified CM phone security profile names and
IM and Presence chat node aliases (federated group chat)

The Expressway-E server certificate needs to include the following elements in its list of subject alternative names (SAN): Unified CM registrations domains, XMPP federation domains and IM and Presence chat node aliases (federated group chat)

That’s it for today guys….just an overview.
In the next posts, I’m going to go a bit deeper in the configuration.

Hope you’ve enjoyed!

See ya!

Bruno

Cisco CUCM – Intercluster Lookup Service

Hey people,

Today I’m going to explain the concept of a good feature, called ILS (Intercluster Lookup Service).
ILS enables different CUCM Cluster to exchange directory URI with other clusters in an ILS network, allowing you to create networks of remote CUCM clusters. So, when you configure ILS on multiple clusters, it updates CUCM with the current status of remote clusters in the ILS network.
An ILS network comprises the following components:

Hub Clusters
Hub clusters form the backbone of an ILS network. Hub clusters exchange ILS updates with the other hub clusters in the ILS network, and then relay that information to and from their spoke clusters.

Spoke Clusters
A spoke cluster connects to the hub cluster in an ILS network to relay ILS updates to and from the rest of the ILS network. Spoke clusters contact only their local hub cluster and never directly contact other hub clusters or other spoke clusters. A spoke cluster can have only one hub cluster.

Global Dial Plan Imported Catalogues
To provide URI dialling compatibility with third-party systems, you can manually import a third-party directory URI or +E.164 number catalog from a CSV file into any hub cluster in the ILS network

CONFIGURATION

Let’s go deep to the configuration. For that, I’m going to use this topology as example:
2 CUCM clusters in the ILS network.

  • 10.106.79.71 – HQ Cluster
  • 10.106.79.83 – BR Cluster

topology.png

  • Activate Intercluster Lookup Service on all the CUCM Publisher

    You must activate the Intercluster Lookup Service to configure Cluster IDs and Remote Clusters.
    From Cisco Unified Serviceability, choose Tools > Service Activation.
    From the Server drop-down list, choose the node and then click Go.
    Select ‘Intercluster Lookup Service’ and Save.

    0.png

  • Configure Cluster IDs

    You must configure a unique cluster ID for each cluster in the ILS network. The clusters use this unique cluster ID and peer ID when they exchange status messages.
    In Cisco Unified Communications Manager Administration, choose System > Enterprise Parameters.
    In the Enterprise Parameters Configuration window Cluster ID field, enter a name of the cluster that you
    want to configure in your network.

    1.png

  • Activate ILS on the Hub Cluster

    You must configure each cluster in your ILS network as either a hub cluster or a spoke cluster. Each ILS network must have at least one hub cluster. You can connect a hub cluster to other hub clusters, or you can configure a hub cluster as the only hub cluster in the network. In addition, you can connect a hub cluster to multiple spoke clusters, or you can configure the hub cluster with no spoke clusters.

    Now, considering the Node 10.102.79.71 as the ILS HUB Cluster.

    Go to Advanced Features > ILS Configuration > and configure as follows.

    AA1.png

    Route String: This will be a unique string that will be advertised to the other clusters. Other ILS peers use Route String to route the call.

    Above configuration uses ‘Password’ based ILS authentication and synchronize the clusters every 1 minute.
    The moment you click Save, it will ask for ILS Registrar Server. Since I do not have any other HUB cluster, we can leave blank and click OK.

    4.png

  • Activate ILS on the Spoke Cluster

    Now, the node 10.106.79.83 will be  the SPOKE cluster.
    Go to Advanced Features > ILS Configuration > and configure as follows.

    A2.png
    When you click Save, enter the Registrar server as the HUB cluster 10.106.79.71.

    6.png


    Now refresh the ILS configuration to see the updated status.

    A3.png

  • Configuring URIs for the End Users

    Go to User Management > End User > and select the user you want to enable URI.
    For LDAP user, make sure the URI is synced from LDAP server. For the local users, you can set a URI as shown below.
    CUCM End User URI Configuration.png

    Then, go to the Controlled Devices section and assign the user’s desk phone as the controlled device. Also, configure the primary extension (mandatory!!).

    Primary extension for URI dialing.png

    Now go to the Directory number configuration(e.g. 1002). Now you will be able to see the URI field.

    Direcory URI configuration CUCM.png

  • Verify the Learned Directory URIs

    Go to Call Routing > Global Dial Plan Replication > Learned Directory URIs

    9.pngA4.png

    Any of the URI learned via ILS will be having 2 unique values. One is the Route String and another one is Cluster ID. Route String is used to route the call back to the respective cluster via a separate SIP trunk.
    ILS will only take care of advertising the URIs between clusters. They do not participate in call routing. For dialling the URI from one cluster to another, we need to have a separate SIP trunk.

  • ILS Restrictions


    imageimage

  • ILS Troubleshooting

    Here are some Troubleshooting Tips:

    Issue: Local Cluster Cannot Connect to the ILS Network

    To troubleshoot connection issues within the local cluster, open RTMT and run alarms and diagnostic traces on that publisher node. If you receive an error message when trying to establish ILS between your clusters, you can try to restart the Cisco Intercluster Lookup service from Cisco Unified Serviceability Administration. In addition, connection issues may arise if authentication is improperly configured between clusters. Check authentication in the following manner:
    • If you are using TLS, make sure that all clusters in the network are using TLSand that Tomcat certificates have been exchanged for all the servers that need to communicate.
    • If you are using TCP password authentication, make sure that all ILS clusters are using TCP password authentication and that the same TCP password is assigned across the network.

    Issue: Directory URIs Are Not Being Replicated Across the ILS Network

    This error can occur for a variety of reasons. Check the following:

    • Verify that all clusters in the network are configured to exchange global dial plan data. If a hub cluster is not configured to exchange global dial plan data, none of that hub’s spoke clusters will be able to exchange directory URI catalogs.
    • Allow enough time for end-to-end replication based on synchronization intervals (set on the ILS Configuration page) that are configured for all the clusters involved in the path. All clusters in an ILS network are a maximum of three hops from every other cluster in the network.
    • Use the utils ils showpeerinfo CLI command to monitor replication progress by looking at the USN values for the remote clusters.
    • Increase speed of replication by changing the ILS Sync Throttle Service Parameter. Note that a low setting can affect system performance.
    • Verify that all clusters in the ILS network have unique cluster IDs and that none of the clusters are configured with Stand Alone Cluster as its cluster ID. You can check Cluster IDs in Cisco Unified CM Administration under System > Enterprise Parameters.

    Issue: Global Dial Plan Replication Is Configured, but Unified CM Still Cannot Place a Call to A Learned Directory URI or Learned Number in a Remote ILS Cluster

    This condition can occur if ILS and Global Dial Plan Replication are enabled on all clusters in the network, but SIP route patterns that route to the route strings for the remote clusters have not been configured. Do the following:
    • In the ILS Clusters and Global Dial Plan Imported Catalogs view in the ILS Configuration window, check the route string for the remote cluster.
    • In the SIP Route Pattern configuration window, make sure that you have route patterns that map to the route strings for your remote clusters

    Hope you’ve enjoyed Smile

    See ya!

    Bruno