cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3360
Views
10
Helpful
8
Replies

Jabber softphone via MRA does not fall over to secondary CUCM server when primary CUCM serve is down.

ductra
Level 1
Level 1

I'm running into this bug  

https://tools.cisco.com/bugsearch/bug/CSCuq79072

CUCM Failover isn't supported with single VCS-E Server

Symptom:
User cannot register his softphone over Edge.

Conditions:
When the Primary Call-Manager is down and there is only one VCS-E Server.

Workaround:
Add a second VCS-E node.

I'm running expressway, not VCS-E.  I have a backup expressway E server and backup expressway C running in a second data centre.

Using DNS SRV recording, the backup expressway E server has a weight of 10,  the primary expressway E server has a weight of 0 (prefer server). 


The workaround does not work because Jabber MRA will not connect to the backup expressway E server unless I shut down the primary expressway E server.  

Even when I shut down the primary expressway E server, and Jabber did connect to the backup expressway E server, the softphone still does not register while the primary CUCM server is down. 

The only workaround that is working is to move the backup CUCM server to the top of the list in the CCM group.

Does anyone run into this issue and whether the workaround actually worked ?  


Below are the software version.

CUCM: 10.5.1.10000-7

CUCM IMP: 10.5.1.10000-9

Expressway: X8.6

Jabber for Windows: 10.6.6 Build 18021

Jabber for iPhone: 11.1.0.221459 64-bit

8 Replies 8

Ayodeji Okanlawon
VIP Alumni
VIP Alumni
Ductra, I would open a TAC case for this. Please keep us updated. There are a few failover issues with the solution, so best bet is to open a TAC case
Please rate all useful posts

kdotten36
Level 3
Level 3

I have a very similar problem except it's actually not looking for the primary/publisher CUCM (at least on 9.1.2), it's looking for whichever CUCM appears first in the processnodes table.  In my case, that's unfortunately one of our subscribers which is physically located at a remote site.  UDS for every application in our environment attempts to authenticate to it first but its VLAN is inaccessible, which has broken MRA and WebEx so far.

Jabber MRA/ On-premise jabber chooses your UDS server randomly. You cant influence the decision nether can you predict which server its going to use

Please rate all useful posts

Frank
Level 1
Level 1

I am running into the same issue with the exact same deployment. 

TAC is referencing the same bug but like you state the workaround really does not make sense.

Were you ever able to fix this?

Thanks

Frank

hi Frank,

That is correct, the work around described in the bug ID does NOT work. When you shut down the primary CUCM, Jabber via MRA does not register to secondary CUCM in the CCM Group.

Even when you shut down the primary Expressway E, Jabber will connect via the secondary Expressway E server, but it will fail to register to the secondary CUCM.

The only work around that is working, is to move the secondary CUCM to the top of the list in the CCM group.  Assuming your Publisher is still up to be able to make this change. 


Cisco advised this feature is not support yet, it is now documented clearly in Jabber version 11 release.

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/11_0/CJAB_BK_C04C09E7_00_cisco-jabber-110-planning-guide/CJAB_BK_C04C09E7_00_cisco-jabber-110-planning-guide_chapter_01.html#CJAB_RF_S96EC4E9_00

Cisco Jabber 11.0 Planning Guide - Deployment Scenarios [Cisco Jabber for Windows] - Cisco

High Availability (failover)

Audio and Video services

X

Voicemail services

X

IM and Presence services

X

Just chiming in for visibility, I'm actually in a unique scenario where Site1 and Site2 where our cucm's are homed have specific vlans for security purposes that permits voice/telephone/video traffic to pass but not data/computers/wifi/etc.  So wireless devices and laptops can only communicate with their local CUCM, then we have SRST at each office for emergencies.  This means we cannot use Jabber in any form because about 50% of the time it fails to register.

I've tried stripping the cross-site CM out of DNS, IM&P, and Expressway but nothing will fly.  It continues to search for the other node.  Unfortunate, and I'm hoping more customization is added in future releases since Jabber/Expressway was a big motivator to boost our remote access.

There is a high and low watermark set for failover. It will choose a random number and fail over at the given number. I know this is true for Jabber and would assume it would be the same for MRA.

How long did you wait for client to failover?

Jason

Anthony Holloway
Cisco Employee
Cisco Employee

Just to confirm, the defect you mentioned is not actually your problem, right?  The real reason is that failover is not supported in MRA yet, as mentioned by by your reply later in this thread?  If so, can you please edit your original post to reflect this fact?

Also, did you ever find out if this also impacts desk phones?  88XX, 78XX, DX?