Jabber for Android won't connect if the user is associated to Standard CCM End users Group!
I have a strange behaviour in my CUCM deployment, about Jabber for Android.
We have a CUCM 10.5 deployment (1 Pub + 1 Sub).
I successfully connect Jabber for Android 10.5 (phone only mode) to CUCM 10.5 using a user called let's say « majaafar ».
My issue is the following :
- When "majaafar" end user is not associated with the "Standard CCM End Users" Access Control Group, Jabber 10.5 connects perfectly to CUCM 10.5
- When "majaafar" is associated with the "Standard CCM End Users", Jabber for Android won't connect anymore!
I granted and un-granted the user several times this Access Control Group and, strangely, this exact above behaviour occurs.
Any thoughts why ? What's the problem with the Group (or with Jabber for Android) ?
It's a problem that the End Users ain't be granted the "Standard CCM End Users" Access Control Group, they need to connect to their ccmuser web page.
Thank you in advance!
EDIT : The problem is specifically in the "Standard CCM End Users" ROLE. I created a custom Access Control Group and each time I associate a specific role to this ACG. When I assign "Standard CCM End Users" Role (which is used to access http://IP/ccmuser page) to my custom ACG, it doesn't work...
That role is also needed for Jabber to access a few HTTP-based APIs on CUCM so it's definitely needed. Does the client give you any specific error when the user is associated to the group? Does it not login at all or does a specific feature not work?
Can you reproduce this behavior with detailed tracing enabled on the app and attach the problem report to the thread? Be advised that the problem report will contain personally identifiable information, including your contacts. If this is a concern you may wish to send this to TAC vs. sharing on here.
Here's attached the problem report generated from Jabber for Android in a Samsung S4.
In fact, may I add something to this :
I created a SIP Phone Security Profile that uses exclusively UDP (not TCP+UDP in the default Cisco Dual Mode for Android Security Profile)
Here's what happens in each case :
- When the Default Cisco Dual Mode for Android Security Profile (TCP+UDP) is applied to the BOT device, and the Std CCM End Users and CTI Enabled Groups are applied to the user, the device works perfectly.
- When the Custom Security Profile (using UDP Only) is applied to the BOT device, and the Std CCM End Users and CTI Enabled Groups are applied to the user, the device doesn't work.
I can understand for these two tests that the problem may relate to "using UDP" instead of "TCP+UDP".
But why ? Especially when the user is not granted any privileges, the BOT device works perfectly using UDP Only.
When I was testing Jabber for Android in my CUCM v9 I had similar problems, but at the end I think is related with the supported devices because I always had problems with phones outside of the official list (like a Moto G and Huawei Ascend)
Cisco Jabber for Android is officially supported on the following devices:
●Samsung Galaxy Note II with Android OS 4.1.2
●Samsung Galaxy Nexus with Android OS 4.1.1
●Samsung Galaxy S III with Android OS 4.1.1
●Samsung Galaxy S II with Android OS 4.0.4
●Samsung Galaxy S II SC-02C (NTT Docomo) with Android OS 2.3.3
Thank you Rolando. Yes the UDP stuff is related to unsupported devices (unsupported devices work when configured with UDP). However hère I talk about a supported phone. In fact my phone is correctly working with the default SIP security profile. But the supported device can't connect when using UDP and the user is associated to the above Access Control Group. My question here is : Is using UDP instead of TCP+UDP will prevent me from connecting to Jabber Android ? Is UDP unsupported with Jabber ?
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...
The below trick might come handy when you have to add a new node to a cluster but you don't have or is unsure of the security password for the publisher. This procedure has been around for ages.
1) Login into the CLI of the Publisher.