Jabber Persistent Chat across multiple clusters ??

[robmusitano]

All.

I am building a sandbox to test persistent chat for my region.  I see that a postgres db is needed per node however I don't see details on what that allots me.  Does that mean that only the users assigned to that cluster can access that node(s) persistent chat rooms? Or does that mean that I can house a persistent chat room on that cluster and users from all regional clusters can then join them?

Jabber 9.7.1 / CUCM&CUPS 9.1.1

Thanks in advance.. r

[Jonathan Schulenberg]

That's an interesting question. Since no one has answered this in nearly two weeks, I'll take a generic XMPP stab; however, be aware I haven't tested this specifically with Jabber/IM&P across a multi-cluster environment.

The generic answer is that each node has a text conferencing server alias which is used as the right-hand-side of an XMPP URI unique to each chat room. You can see this under IM&P Administration > Messaging > Group Chat Server Alias Mapping. For example, the chat room may be somerandomstring@conference-2-myxcpcluster.mydomain.com. Just as a user has an XMPP URI, so does an ad-hoc or persistent chat room. This is controlled by the Cisco UP XCP Text Conference Manager service. So, each node needs a PostgreSQL database to cache the relevant details about the rooms it is hosting. Users homed on other nodes simply interact with the URI and the XCP fabric takes care of routing the message.

That leaves the question: what about other clusters (inter-cluster peered or not). Well, when doing inter-domain federation, it states that you need SRV records for the Chat Server Aliases. But there are two other scenarios that I don't have a ready answer for:

• multiple clusters with inter-cluster peers.
• multiple clusters in the same domain relying only on the XMPP fabric.

[adrianoden]

Has anyone done additional testing on this type of setup. We have a multi-cluster deployment of CUCM and are wondering how persistent chat rooms would work across clusters.

[Jaime Valencia]

I actually have a setup in my lab with a 10.5(2) and an 11.0 system with inter-cluster between IM&P and ILS/GDPR between CUCM, and I can access the persistent chat rooms configured on 10.5(2) using clients registered to 11.x

[robmusitano]

All.

I just wanted to circle back to this topic.  I have been running 5 clusters with only one node in one cluster hosting all of my persistent chat rooms successfully.  I understand from the documentation that each node wants to host rooms but it made zero sense for us to present rooms this way.  We didn't want to have to 'balance' hosted rooms as we have one chat room admin that controls room creation for all 5 regions.  We use one Postgres db for all of our hosted rooms.  Intercluster takes care of any communications from other regions.  Granted this is one point of failure but there is nothing showing us how to cluster the database if one of the hosting nodes fail anyway.  Its not in the CUPs functionality to cluster dbs across nodes so we went forward with one db/one node for all.

Even in the one cluster that hosts persistent chat our PUB is connected to the Postgres db and the SUB is not connected to any db (left blank).

r

[JacobMunson]

Hello all,

Does anyone have any insight into how persistent chat works when a postgres db is configured on multiple nodes in multiple clusters?

example 2 CUCM/IMP clusters both with 2 IMP servers all IMP servers have a postgres db configured. which db is selected for the group chat and how are the other db's used?

[Reece]

EDIT:  Is the there a way to force the Location (conference node alias) in the New Room>Room Information, when creating a new chat room?

If using inter-cluster peering, Jabber clients will have the option to choose a chat node alias from any cluster, from the Location drop down.

If set to Automatically Select, all Jabber clients from different clusters will use the first chat node listed in the Location drop down. (you can see this if you check the SQL tables)

Jabber should be using the chat node that the user is assigned to.

[Jm2008]

Any update on this?

[Mark Swanson]

Reece,

I totally agree with you. You would think, Cisco Jabber would "Automatically Select" the chat node assigned to the user but it doesn't. I spent several weeks trying to get this to work the way I think it should work but I concluded, this is simply a limitation (or design flaw) of the client application.

You likely discovered already, the Location drop down menu is;

- Sorted by alphanumeric order. 'A' comes before 'B' and '1' comes before '2'. Each character is evaluated from left to right, so; conference-10-standalonecluster123ab.example.com

Would be listed above; conference-2-standalonecluster123ab.example.com 

- Only the nodes with XCP Text Conference Manager running ("STARTED") will be listed as a Location.

- If something happens to this node or service, then it -potentially- disappears from the list of Locations.

- If you add a new Group Chat Server Alias, this alias would be listed as a Location as well and your list becomes excessively longer.

- Certificates also play a vital role as well, meaning, if a node doesn't trust another node (i.e. cert expired)... you wouldn't be able to find/select this chat node from the Location list. If this happens, you wouldn't be able to attend any chat rooms hosted by this node until you generate/upload new certs. Or, you could reassign yourself to the same node hosting the vast majority of chat rooms.

Like you, I would love to change how Cisco Jabber automatically selects and balances the chat rooms throughout the external databases. Let me know if you find a solution.

[Mark Swanson]

Does anyone know if Oracle or MySQL reacts the same way? I know this thread is old but for me, this problem is still relevant.

The only problem is... if the Group Chat (Conference) Server goes down, thousands of chat rooms become non-responsive and/or disappear from the list of chat rooms. When this happens, dozens of chat rooms are recreated on another node. This results in duplicate chat rooms. This doesn't cause a conflict when I restore the service because how Postgres stores/converts the room_jid.

For example; My_Chat_Room!

The room_jid looks like this; mychatroom1234567890123@conference-2-standalonecluster.example.com

I believe, the series of numbers after mychatroom is randomly generated by Postgres.

I assume, merging the external databases via IM&Presence Administration > Messaging > External Server Setup > External Database Jobs would provide a type of high availability for persistent chat within the subcluster - Yes/No?