Jabber Web SDK Discover Failover

[Yasid.ramli1]

Hi All

We implemented the Cisco Jabber SDK on our customers. The current configuration to register the Jabber SDK to CUCM is like below

var cucmServers = [];

cucmServers.push("192.168.48.16");

cwic.LoginController.setCUCMServers(cucmServers);

As you can see, we are only pointing to one CUCM server, in this case, if the server is down, the service will not work. In this case, we want to create an HA mechanism with this script. So, the script will be like below.

var cucmServers = [];

cucmServers.push("192.168.48.16"); > First server

cucmServers.push("192.168.48.17"); > Second server

cwic.LoginController.setCUCMServers(cucmServers);

With the new script above, we don't know why the Cisco Jabber SDK will only use the first server "cucmServers.push("192.168.48.16");" even if the first server is down. This script doesn’t automatically redirect the connection to the second server, we have to change the script manually if we want the Jabber SDK to register to the second server. The script will become like here.

var cucmServers = [];

cucmServers.push("192.168.48.17"); > Second server

cucmServers.push("192.168.48.16"); > First server

cwic.LoginController.setCUCMServers(cucmServers);

the challenge why we don't use service discovery is because of duplicate with another cluster cucm existing.

[dstaudt]

I believe this is how it should work in general, and depends on the Jabber deployment mode (full UC, phone-only mode):

Full UC (calling + IM):

cucmServers: should be the prioritized list of IM & Presence (typically) or CUCM servers (less typically) where an XMPP-based or UDS-based user login will be attempted.

(no other servers configured)

Phone-only mode:
cucmServers: list of CUCM servers where a UDS-based user login will be attempted and UC service profile retrieved.  Typically, upon user login, the user's UC Service Profile will contain a Jabber Client Configuration Profile, which will contain the primary/secondary TFTP/CTI/CCMCIP servers:

If for some reason the user's UC Profile doesn't have these servers configured, then the Jabber SDK app can specify them itself (perhaps provided ones override what's in the Profile.)
Note: none of these Jabber SDK servers arrays control the actual softphone SIP registration and call failover behaviour.  That is controlled via the CUCM admin failover configurations - device pools, CallManager groups, etc. - and retrieved by the phone from its TFTP server prior to SIP registration.  If your Jabber SDK softphone isn't reregistering to a secondary CUCM when the primary fails, you may need to check its device pool configuration, etc.  Generally if you can use the same CSF device with the standard Jabber client successfully (including failover behaviour) then using the same CSF device via the SDK should work similarly.

The main concern for the app is simply to locate the user login service (or prioritized list of such) - everything else should be pulled down automatically from the existing CUCM user/device configuration.  (Finding the user login service is what the auto-discovery stuff is about, i.e,. using DNS to retrieve the login service host location(s); if you don't have discovery/DNS set up, then you can 'hard-code' the login service location(s) via the cucmServers[] array.

[Mustain]

Hi @dstaudt 

I had the same problem with this, and in the Device Pool, we already had all the CUCM servers. But, the Jabber SDK doesn't register to the secondary server. I have two CUCM clusters, with the same domain, for example, ABC.co.id. The problem occurred in the new cluster.

[Yasid.ramli1]

Hi @dstaudt 

Thank you for your reply, for failover after registering, for now, no issue but the issue is if a new user needs to login but the CUCM primary down. 

so we need to know how to manipulate code if we have a return timeout from server primary and then can the next step to the secondary server?

I found on document SRND about failover to CUCM can use the server load balancer, I think it's good if can use the load balancer the third party like (F5, Citrix) to help for discovering login jabber.

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab11/collab11/cmapps.html

[dstaudt]

For the initial user login, adding multiple hosts to the cucmServers[] array should allow the phone to try each in turn.  If that is not working, then probably we need to do some detailed troubleshooting/log analysis via a DevNet support case.

If it is working but is slow - e.g. the host is there in DNS but the client waits for the TCP SYN timeout before trying the next server - then as you suggest an active HTTP load balancer would probably be the best way to provide a more consistent experience.  Perhaps you could also try a test connection to the CUCM server(s) auth URL(s) in your code ad-hoc using a small timeout (couple of seconds) before deciding which host(s) to populate into cucmServers[] (so basically putting the load-balancing login in your code...)

[Yasid.ramli1]

adding multiple hosts to the cucmServers[] array ->> it's like I say on the discussion for the array not work as the documentation state.

var cucmServers = [];

cucmServers.push("192.168.48.16"); > First server

cucmServers.push("192.168.48.17"); > Second server

cwic.LoginController.setCUCMServers(cucmServers);

https://pubhub.devnetcloud.com/media/jabber-web/docs/documents/JSDK/tutorial-login-manual-sign-in.html

today we try ping.js for method monitoring for jabber login and success if the first CUCM down the code can next step to the second CUCM but the limitation of using the ping for checking the health of an application in this context is that it can only tell you if the application itself is alive. It does not reveal anything about the state of its dependencies.

Do you have any input on what we can try to discover login??

about the load balancer for HTTP requests with CUCM, I still open the case to the CUCM team as the documentation says, and absolutely nice to try its work or not, I can update if I have some results after testing.

[dstaudt]

At this point I would recommend opening a dev support case so we can investigate in detail what's up with the cucmServers[] behaviour: https://developer.cisco.com/site/support/

Re the 'ping' workaround, if you can figure out what kind of request Jabber is making, (e.g. UDS clusterUser) you can try a similar request (e.g. with dummy values) - if you get the expected response (e.g. a 401), that tells you more about whether the service is up than a simple ping.

[Mustain]

Already opened a dev support case with an answer similar to yours here. And still trying to figure out the best way to solve this kind of problem.

[Yasid.ramli1]

Hi @dstaudt 

Do you mean open case to dev support with the ticket which is it's where there is a cost?

[dstaudt]

Yes, DevNet Developer Support has dedicated API/developer support engineers who can help analyze logs, troubleshoot, and escalate issues to the appropriate engineering groups.