Showing results for 
Search instead for 
Did you mean: 

Jabber 9.6 Win (and iOS) 'auto' setup method broken

I'm using UCM and IMP 9.1.2.  All versions of Jabber v9.6 won't login in 'auto' mode, even though it can see my IMP server dns address has been identified to jabber via the SRV record.  I must click 'manual setup' and then select Presence as the method and it then setup completes the login to the discovered IMP server.

I can clearly see it wants to use webex instead of presence as the method.  Even the text says "Enter your WebEX ..."  At least on the ipad version, the logs show it checking with Cisco's cloud webex server and finding our domain a valid webex domain.  Why does v9.6 prefer webex and how do I stop it from doing that?


For example, here are snippets from the ipad client that show it trying webex sso method.  I don't understand why it is trying that.  I replaced our real domain name with ''.

-- 2014-01-17 12:09:07.029 INFO [bace000] - [service-discovery][determineIsWebexCustomer] Determining if an organistation's domain ( is a webex customer.

-- 2014-01-17 12:09:07.030 INFO [bace000] - [service-discovery][determineIsWebexCustomerFromCache] Checking if domain is a webex customer from the Service Discovery Cache

-- 2014-01-17 12:09:07.030 WARNING [bace000] - [service-discovery][determineIsWebexCustomerFromCache] The domain tried ( is different to the domain in the cache ().

-- 2014-01-17 12:09:07.031 INFO [bace000] - [service-discovery][getCasLookupResult] CAS Lookup with domain:

-- 2014-01-17 12:09:07.039 INFO [bace000] - [csf.httpclient][CurlHeaders] Number of Request Headers : 0

-- 2014-01-17 12:09:07.418 INFO [bace000] - [service-discovery][getCasLookupResult] CAS lookup request has been successfully finished with domain:

-- 2014-01-17 12:09:07.418 INFO [bace000] - [service-discovery][parseCasResponse] Domain is WebexCustomer but doesn't support WebexSso.

-- 2014-01-17 12:09:07.418 INFO [bace000] - [service-discovery][Discover] Domain is a webex customer. Returning successful result

-- 2014-01-17 12:09:07.424 INFO [bace000] - [service-discovery][writeToCache] Writing to cache

-- 2014-01-17 12:09:07.424 INFO [bace000] - [service-discovery][writeToCache] Domain ( is a webex customer. Saving to cache!

********** Discovered Dns Services Records Found **********

-- 2014-01-17 12:09:07.459 DEBUG [3b8dd18c] - [Login Time Ceck] start to check sso.

-- 2014-01-17 12:09:07.606 DEBUG [3b8dd18c] - CSILoginSSO-- signInSSO

-- 2014-01-17 12:09:07.607 DEBUG [3b8dd18c] - YLCSigninUIMgr enableUserInteraction NO

-- 2014-01-17 12:09:07.608 INFO [3b8dd18c] - [CSFServiceLocatorManager][onDiscoveryFinished:] out

-- 2014-01-17 12:09:07.657 DEBUG [3b8dd18c] - *****Chat Url [all]: - navigationType = 5

-- 2014-01-17 12:09:07.657 DEBUG [3b8dd18c] - *****Chat Url: //

-- 2014-01-17 12:09:07.780 DEBUG [3b8dd18c] - CSIWebViewTouch Connection didReceiveData; original request: < 0x1ba9ae90=""> { URL: }

-- 2014-01-17 12:09:07.784 DEBUG [3b8dd18c] - *****Chat Url [all]: - navigationType = 5

-- 2014-01-17 12:09:07.784 DEBUG [3b8dd18c] - *****Chat Url: //

-- 2014-01-17 12:09:08.505 DEBUG [3b8dd18c] - webViewDidFinishLoad

-- 2014-01-17 12:09:08.505 DEBUG [3b8dd18c] - didFinishLoad

-- 2014-01-17 12:09:08.554 DEBUG [3b8dd18c] - content 2 :

Connect Client Single Sign On



-- 2014-01-17 12:09:08.554 DEBUG [3b8dd18c] - parseSSOResponse str=

Connect Client Single Sign On




Ok, what is happening is that Jabber 9.6 is apparently now hard-coded to contact to check for webex licenses, which we have, so it never tries our IMP servers once it sees we have cloud webex enabled for our domain.  The flowchart in the docs show this behavior.

Apparently there is some webex/UC integration that needs to be done before the 'simple' method will work in 9.6 for those who have webex licenses.


What worked in our case for 9.6 for Windows was a combination of things.  First one was to make sure we had the required internal DNS SRV records - _cuplogin and _cisco-uds.  Second one was to use the switch when installing the client with msiexe.exe (whether manually at a workstation cli or through an SMS flavored package.)

We did have to further tweak the SERVICES_DOMAIN switch just a little in our environment, to SERVICES_DOMAIN=internal DNS server ipv4 address.

We've had to go that way since our internal/external domains match up.  Which seemed to be just enough to still let Jabber 9.6 reach our WebEx Connect site.  Switching to IP address for SERVICES_DOMAIN seems to "trap" the lookup internally, at which point the Jabber client behaves as expected for auto-configuraiton.

You can get a good visual of whether it's going to work at the Jabber login screen.  If it's hitting WebEx, youl'll see that reflected at the login screen.  If it's hitting your internal records, you'll see a callout for Jabber voice services.


The problem for us was that Webex messenger was enabled in the Cisco cloud, and it shouldn't have been.  Our rep got involved and had that deprovisioned in the Cisco cloud and now the simple login method works.  If webex messenger is provisioned Jabber clients 9.6 and above will ignore on-premise presence servers with the auto method.  Jabber 9.6 is hard-coded to check Cisco's CAS and ask for webex credentials if the check is successful.  We do have webex meetingplace licenses but that is a separate thing from webex messenger.

Content for Community-Ad