11-08-2015 05:16 PM - edited 03-18-2019 11:42 AM
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
11-09-2015 02:55 AM
12-24-2015 09:40 AM
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.
12-30-2015 01:36 PM
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
02-01-2016 10:30 AM
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
02-01-2016 02:45 PM
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
|
02-09-2016 10:25 AM
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.
02-09-2016 02:18 PM
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
01-12-2017 10:28 AM
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?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide