Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

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

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!

Everyone's tags (1)
1 ACCEPTED SOLUTION

Accepted Solutions
VIP Super Bronze

Re: Asking for advice for Jabber deployment - multi CUCM cluster

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 sAMAccountName@presence.cluster.FQDN. 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.

7 REPLIES
Cisco Employee

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

Hey Jonathan,

If they are two domains are in are the same forest, then you can point Jabber to the root of the forest. If they are two seperate forests then you will need to use something like ADAM to tie them together..

Also you need to upgrade to 8.6.2 to get UDS functionality.

Thanks,

- Colin

New Member

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

Thanks for the response!  Does anyone have advice when picking either UDS or ADAM?  Let's assume I'm already on CUCM 8.6.2.  I'm pretty sure CUCM 8.6.2 still only lets you authenticate to one location, so would using a ADAM solution allow authentication to more than one location?

I'd like to hear opinions one how someone would connect 2 clusters\domains for a Jabber deployment.

VIP Super Bronze

Re: Asking for advice for Jabber deployment - multi CUCM cluster

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 sAMAccountName@presence.cluster.FQDN. 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.

New Member

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

Jonathan,

Thanks again for your response - it clarified things perfectly!

New Member

Re: Asking for advice for Jabber deployment - multi CUCM cluster

What about cross cluster extension mobility, this method would break it since you can't have users on both clusters

Sent from Cisco Technical Support iPhone App

New Member

I have same problemhow can i

I have same problem

how can i use xmpp federation between two cups server version 9.1 with separate domain

site A has ABC.com and Site B has DCE.com

we need to send message between these two site

Please guide me how can I do it


 

New Member

Hello Sh.Shahidi, Were you

Hello Sh.Shahidi,

 

Were you able to do the integration/federation between the two CUP servers? If so, what did you do to complete the task?

 

Regards,

4643
Views
10
Helpful
7
Replies
CreatePlease to create content