Asking for advice for Jabber deployment - multi CUCM cluster\AD domains

Question

I would like some design advice for deploying Jabber and CUPS in our company. We have 2 locations, west coast (SiteA) and east coast (SiteB). Each site have their own CUCM 7.15 clusters, Unity clusters, AD domains (trusted, but not in the same forest).
At SiteA I have setup CUPS (8.6.3.10000-20) and jabber and have it working great.
I would like to setup CUPS\Jabber for SiteB, but they need to be able to IM\call\etc to SiteA (And vice-versa).
SiteA and SiteB both have CUCM LDAP sync turned on, and LDAP directory synced with both domains (although SiteA cannot authenticate to CUCM at SiteB, and vice-versa due to the fact you can only LDAP sync authentication with one domain, CUCM user database contain users from SiteA and SiteB).
We have SIP trucks setup to pass internal calls and line status(BLF) between the trunks, and can communicate via internal extensions just fine.
The problem I’m running into is my jabber-config files uses the EDI directory – which can only look at one domain, so I cannot search the other domain. I believe  changing to UDS fixes this, but I understand it would require me to upgrade both CUCM clusters to 8.6.2 - unless I’m mistaken.
I’m aware the desktop sharing will not work until CUCM is upgraded to 8.6.1 or 8.6.2.
I’m wondering if anyone has any advice, or can confirm I’m on the right track. Thanks in advance!

Answer 1

The thing that's important to understand is how CUP and Jabber build the XMPP URI. The URI has a left- and right-hand side; the left is the username while the right is the XMPP domain. CUP uses the LDAP attribute specified in CUCM's LDAP System page, sAMAccountName by default, for the left-hand-side. The right-hand side is the FQDN of the CUP cluster. Jabber must use the same values as CUP when displaying search results. Take note that nowhere in this process does the entire XMPP URI originate from the directory source.
In your case you have two separate CUP clusters in two separate domains. This won't work because when a user searches for a contact in the directory using Jabber, the client will build the XMPP URI as [email protected]. Even if you got the other domain's user objects into the search results the right-hand-side of the URI would be wrong and the presence subscription would never succeed since the other cluster is in another domain. As such your first task must be to move the CUP clusters into the exact same fully-qualified DNS domain. Once this is done you can use Inter-Cluster Peering to build a larger XMPP network in which all users have the same presence domain. If you intend to do Inter-Domain Federation in the future this must be your public DNS domain, not your internal active directory domain. If you use a non-public DNS domain TLS handshake will never succeed for inter-domain federation requests.
Once you have Inter-Cluster Peering in place you can use Active Directory Lightweight Directory Services (the new name for ADAM) to front-end both forests. Both CUCM clusters would need to import the full list of users representing both domains and the sAMAccountNames must be unique across both domains.
Finally, you can instruct Jabber to use UDS and query it's local CUCM cluster which will be able to return a search result from both domains. Since the CUP clusters are peered in the same domain the XMPP URI can be built properly, the presence subscription can be routed to the correct cluster, and life will be good.
By this point hopefully it's clear that EDI won't cut it since it would be limited to only returning search results from the local forest.
Please remember to rate helpful responses and identify helpful or correct answers.