Problems with user login into Cisco IM&Presence

Cisco IM&Presence supports both native Cisco Jabber clients and 3rd party XMPP clients like PSI.

Cisco jabber clients use special type of DNS SRV records (_cisco-uds._tcp.example.com) which stores an address of CUCM server. When they get it they make a request to a special service called Cisco UDS for a user login and his respective parameters – Service Profile to be exact. Cisco UDS can be found in UC Serviceability in Control Center -> Network Services -> CM Services, so if you experience problems with Cisco Jabber authorization and RTMT sends you AuthenticationFailed with Interface : cucm-uds  string you can restart it.

Service Profile (CM Administration -> User Management -> User settings -> Service profile) – defines which UC services are available to a user. Navigate to End User configuration to check which service profile is tied to a certain user. Service profile have links to IM and Presence Profile, which are defined by CM Administration -> User Management -> User settings -> UC services.

It is UC services which stores addresses of IM&P nodes. That’s how Cisco Jabber clients reach IM&P and get IM capabilities. Also without _cisco-uds SRV a client queries for _cuplogin._tcp SRV which points to IM&P nodes and uses the same process as 3rd party XMPP client described below.

3rd party XMPP clients don’t use _cisco-uds SRV. They use _xmpp-client._tcp SRV which points to IM&P node. Inside IM&P there is a service of Cisco XCP Connection Manager which listens on 5222 port and provides logins. So when there is a problem with login of 3rd party XMPP client it is likely that Cisco XCP Connection Manager is faulty and should be restarted.

Cisco UDS is pretty new service and a lot of stuff relies on it now in UC infrastructure (like MRA for example – I should definetely write a post on how CIisco Jabber clients login with MRA – it’s a peice of art) and it deals with a huge load ok. But Cisco XCP Connection Manager in certain situations becomes unavailable under heavy load. From the perspective of the client it looks like it’s responding and even provides a list of possible auth mechanisms of PLAIN and CISCO_VTG_TOKEN, but returns nothing when a client send it’s encoded password with XMPP (you can observe this with PSI XML console for example).

Leave a comment