How to test UCM (callManager) failover functions?

[iamjackbob1]

Hi,

Do the UCM provides failover functions? (in the sandbox labs, there are 2 UCM server).

if it does, how to make the current active UCM server (the VM) disactive?

Thanks,

Simon

[dstaudt]

If you are testing failover of certain services on CUCM - for example call control - then you can disable (and re-enable) services via the CUCM admin Serviceability pages. 

I suspect that the ability to power-off the CUCM VM itself, or to modify the virtual networking (to simulate disconnection) is not available to users of the Sandbox labs, but perhaps one of the lab admins can comment.

If disabling CUCM services does not cover your use-cases, let us know in some more detail what you need and why - perhaps some alternate suggestions or lab enhancements could be made.

[simon_new11]

Hi Dstaudt,

Thanks for your reply.

My test case is that after the UCM system fail-over, the old calls/conferences (made before the failing)  are still under the control or not via JTAPI.

According your reply, I deactivate all the services of one UCM, and activate all the services of another UCM, but the old calls are out of control after that.

For instance:

1. all services of UCM Server 1 are active, deactivate all the services of the UCM Server 2
2. login agents (two jabber client), make a call between them
3. get the call list by JTAPI (get provider by defaultPeer.getProvider("{publisher IP}, {subscriber IP};login=....")
4. deactivate all the services of Server 1
5. activate all the services of Server 2
6. check the call list of JTAPI with the same provider of above step 3

In the above step 6, the current server of provider has be changed to Server 2, but can NOT get the call list form the provider (in fact, the call which is made in step 2 is still running).

Could you give some suggestions about that?

or we need some additional  configurations about the UCM servers (or on the sandbox lab)?

Thanks in advance.

Simon New

[dstaudt]

If I understand your scenario, the Node1 instance of Callmanager service would have registered the two Jabber instances and provided the call setup processing.  By turning down all Node1 services and turning up Node 2, the following multiple things are potentially occurring:

- The actual call state and call handling process are killed and the call dies, as it was on Node1/Callmanager

- The endpoints may go into 'call survivability mode', where audio reception/transmission continues until the users manually terminate the call and the Jabber client then starts a re-register/failover sequence, but no actual call signaling happens or can be requested (like a transfer or hold) as Node1/Callmanager is down

- A JTAPI application monitoring Node1/CTI-Manager would get a device out-of-service event for each monitored Jabber.  If the Jabber calls stayed running in call survivability mode, the JTAPI app would not receive a device-in service event until the Jabber client manually ended the call and re-registration occured (with Node2.)  While the device would then come in-service, it would show no calls in progress, as the active call died in the first step

So I guess the end effect is similar to what you might see if you unplugged the network cable from Node1, and plugged it in for Node2...

Perhaps the scenario you seem to be wanting to see could be achieved by having all Jabber clients and the application connected to Node1, have all services on Nodes1&2 running, start a Jabber-to-Jabber call monitored by JTAPI, then disable the Node1/CTI-Manager service.  Here the call would still be alive (on Node1), the JTAPI app would detect the disconnection from Node1/CTI-Manager, send device out-of-service event for all devices on that provider, failover and reconect to Node2/CTI-Manager, send in-service events to all the devices, then send 'snapshot' events that catch the JTAPI call model up to the current status of the observed calls

[Simon_New1]

Thanks a lot.

Summary up my understanding based your reply, please clarify them:

1. when the server node changed, we cannot get the original call form the JTAPI provider

2. we can observe the events such as provider/device out_of_service/in_service when the server failover happens

3. when the new server connected,  the 'snapshot' of the original call can be got

According to above, when CUCM fail over happens, the original calls will be out of control (get states, end call), right?

Simon New

[dstaudt]

I think you got it...

In the case of a CUCM call processing node failure, state of any calls in progress will be lost.  However, note that depending on the participating endpoints in the call, the endpoints may continue the call in 'survivability mode'  - i.e. continue to send/receive audio/video media until the user manually ends the call (the endpoint would then failover/re-register to its assigned backup call processing node - at this point JTAPI would start getting in-service/events for the endpoint again)