Jabber Deployment ‘Gotchas'(1): Cisco Unified Communications Manager IM and Presence Centralised Deployment

Jabber Deployment ‘Gotchas'(1): Cisco Unified Communications Manager IM and Presence Centralised Deployment

The centralised deployment can provide IM and Presence services to multiple remote CUCM voice and video clusters. In a centralised deployment, the IM and Presence Service manages all IM and presence related services for all the users across the remote CUCM clusters, and each remote CUCM cluster manages its own users’ voice and video needs.

Jabber Deployment ‘Gotchas'(2): Contact Directory Search Why LDAP?
VRF Route Leaking with MP-BGP: routing control for AWS transit VPC
SSH Public Key Authentication to Access Linux (2)

I recently led and successfully delivered a large Jabber project and will summarise the ‘gotchas’ in this series of blog articles.

Cisco introduced a new Instant Messaging and Presence (IM&P) architecture called ‘Centralized Deployment for IM and Presence’ from CUCM IM&P 11.5(1) SU4. The centralised deployment doesn’t require 1:1 ratio of telephony clusters to IM&P service clusters anymore. One central IM&P cluster can provision IM&P service to multiple remote telephony clusters (Release Notes for CUCM and the IM&P Service, Release 11.5(1)SU4).

This article focuses on the gotchas of the IM&P centralised deployment.

Centralised IM&P Deployment Overview

The centralised deployment can provide IM and Presence services to multiple remote CUCM voice and video clusters. In a centralised deployment, the IM and Presence Service manages all IM and presence related services for all the users across the remote CUCM clusters, and each remote CUCM cluster manages its own users’ voice and video needs.

The IM&P central cluster requires it’s own CUCM publisher, which functions as the cluster publisher and synced with Active Directory for user and group information and IM&P service enablement.

IM&P publisher is configured to integrate with the remote Telephony Cluster 1 and the Telephony Cluster 2, so that there is AXL database synchronisation between the IM&P cluster and the remote telephony clusters. This is critical for Jabber user authentication, which is discussed in later section.

The two leaf/remote telephony clusters form a single cluster service via the Inter-cluster Lookup Service (ILS), decipted in the diagram below.

A Jabber user is either homed on the remote Telephony Cluster 1 or Telephony Cluster 2, not both. However, the access Telephony cluster, such as Telephony Cluster 1 in our case, shall have visibility of the users homed on Telephony Cluster 2 via AD sync. If not, the user, homed on Telephony Cluster 2, Jabber authentication will fail.

Centralised IM & Presence Deployment

The CUCM IM&P classic deployment is as below.

Classic IM & Presence Deployment

Configuration Differences between Centralised Deployment and Classic Deployment

The following table outlines the key configuration differences between centralised IM&P deployment and the classic IM&P deployment.

AreaCentralisedClassic
Jabber service auto discovery via DNSPointing to the remote/leaf telephony cluster. The telephony cluster will then direct the user to retrieve the IM&P service from the IM&P central cluster via Service Profile.Pointing to the single telephony and IM&P cluster.
Jabber SSOSSO configured on the remote/leaf telephony cluster. SSO cannot be configured on the IM&P cluster; otherwise, Jabber authentication fails.Configured on the single telephony and IM&P cluster.
AD synchronisation Users must be AD synced on the IM&P central cluster as well as the remote telephony clusters.AD Sync on the single telephony and IM&P cluster.
IM&P Service/UC profilesConfiguring user Service/UC profiles pointing to the IM&P cluster on the leaf telephony cluster, where the user is homed. Configuration not required on the IM&P cluster.Configuring the Service/UC profiles on the single cluster.
IM&P service enablementLeaf telephony cluster: end users shouldn’t be enabled for IM&P service.
IM&P central cluster: enable end users for IM&P service.
IM&P service enabled on the single cluster.
Access authorisation(Standard CCM End Users)Configuring the ‘Standard CCM End Users’ role on the leaf telephony cluster, where the user is homed. Configuration not required on the IM&P cluster.User role configured on the single cluster.
Inter-cluster integrationIM&P cluster and telephony clusters: remote telephony clusters added as AXL peers in the IM&P central cluster for database sync and user authentication
Among telephony clusters: Intercluster Lookup Service(ILS) is used to provision the remote telephony clusters for the IM&P central cluster.
Not required
CUCM Presence gateway/SIP publish trunkNot requiredSIP trunk required between the CUCM and IM&P servers for presence. CUCM acts as presence gateway for IM&P servers.
Rich PresenceHandled by Jabber. Rich presence displays only if the user is logged into Cisco JabberUsing CUCM presence gateway.

Centralised IM&P Cluster Jabber Authentication SSO

Cisco official documentation doesn’t provide detailed information on configuring SAML Single Sign On (SSO) for the centralised IM&P cluster.

The following diagram and the ‘Centralised IM&Presence Deployment’ diagram’ at the beginning of the article illustrates the Jabber SSO authentication process. Highlights are below:

  • Leaf telephony cluster has SAML SSO configured. Do NOT enable SSO on the IM&P cluster. It was due to the IM&P cluster relies on the access token issued by the leaf telephony cluster for IM&P service authentication.
  • Add leaf telephony clusters as AXL peers on the IM&P Publisher so that IM&P cluster will accept the access token issued by the remote telephony clusters.
  • If the IM&P service authentication/access fails, re-sync the AXL peers on the IM&P Publisher. For example, when changing Jabber from LDAP authentication to SSO or any AXL database out of sync incidents between the leaf telephony clusters and the IM&P central cluster.
Centralised IM&P Deployment Jabber SAML SSO

The rest articles in this series will include Jabber related caveats, which you cannot find in Cisco official documentation.

COMMENTS

WORDPRESS: 0
DISQUS: 0