Jabber login failure when subscriber is down - MRA

[Shalid Kurunnan Chalil]

Hi All, 

We have a setup with following in the infrastructure. 

CUCM Cluster :  11.5.1.21900-40 [ one publisher and one subscriber] 

IM and P : 11.5 one pub and one sub. 

Single pair of Expressway E and C version 12.5.9 

The users facing issue when the subscriber CM down. If I understood correctly the MRA doesn't support automatic failover for registration during the CM node failure. But I expected that the Jabber will register with the available call manager node in the CCM group when the user re-try the login in case of CM node (jabber registered CM node) failure. 

unfortunately it is not happening and I can see from the logs expressway still trying to conned to the failed CM node. 

Jabber Error: Cannot communicate with the server and in the Jabber logs error as 502 connect code 0 for the http request https://exp-e-1.domain.com:8443/[...]

I checked further the SRV record for the UDS and I can still see that the SRV is returning both CM records.  so how can we force expressway to use only the active CM node? should it be auto or do we need to remove the failed node entry from the SRV records. 

CSA --> shows the error as  HTTP/1.1 502 Next Hop Connection Failed   on the expressway E. 

I can see the

another query is that the default zone created while adding the CM servers still showing as SIP active even though the call manager is in shut down state. 

Regards,

Shalid

[Vaijanath Sonvane]

Hi,

Cisco Jabber clients support IM and Presence Service failover over MRA. However, they do not support any other type of MRA-related redundancy or failover—including SIP, voicemail, and User Data Services (UDS). Clients use single UDS server only.

You may be hitting this software bug:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCud12486

SIP Registration failover for Cisco Jabber is supported in Expressway version X14.0.

[Shalid Kurunnan Chalil]

Thanks Vaijanath for your response. 

When you/Cisco says the failover doesn't support, is it referring to automatic failover or the user cannot login at all until the CM server comes back?

I was hoping that the automatic failover doesn't work but may work when the user try login multiple times when the expressway able to provide the correct UDS server details to the client?

Regards

[Adam Pawlowski]

The solution isn’t smart enough to know the subscriber isn’t there to send UDS requests or attempt SSO auth with. You’ll have login failures. If you don’t have SSO you may eventually be able to sign in and stay online. With SSO you either won’t be able to sign in or you’ll get booted when it attempts auth. 

[deepshikha2112]

Hello Adam,

In such a case, why will SSO auth fail? Isn't other active CUCM node can be reached out from SRV records list and then proceed with SSO auth (if ADFS is in use)?

Please correct me if I misunderstood it.

[Adam Pawlowski]

Jabber only knows about lists of resources. A UCM subscriber may be down, but eligible for oAuth token verification. I have seen that it does not try multiple endpoints when it wants to make that call, it will pick one, try it, pick it again, try it - once it fails 3 times I believe or times out it will require full re-authentication.

SSO Authentication itself continues to work, the SP is the Expressway in the case of MRA login, it's the token validation that will fail and cause Jabber to be unhappy. Jabber is not really a "dynamic" client in much regard, and as far as I know doesn't have any provision to reconfigure itself to respond to changes in available servers.

[Shalid Kurunnan Chalil]

Thanks for the responses.