03-01-2022 02:20 AM
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.
03-01-2022 10:25 AM
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.
03-01-2022 06:42 PM
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.
03-02-2022 02:30 AM
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
03-02-2022 10:24 AM
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...)
03-04-2022 06:10 AM
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);
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.
03-04-2022 12:54 PM
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.
03-04-2022 02:29 PM
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.
03-06-2022 09:43 PM
Hi @dstaudt
Do you mean open case to dev support with the ticket which is it's where there is a cost?
03-07-2022 10:36 AM
Yes, DevNet Developer Support has dedicated API/developer support engineers who can help analyze logs, troubleshoot, and escalate issues to the appropriate engineering groups.
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