Jabber for Android not Regestering

tirianwilson · ‎11-27-2012

Good Afternoon,

We have been having very mixed success with the Cisco Jabber for Android client. Generally users fall into one of two categories - the ones that work fine, and the ones that can never get off of the enter configuration information screen. For the latter group, they fill out the blanks, and then press the verify button, and get an error message that registration failed. If I run a packet capture on the CallManager, I see the client download the configuration over TFTP, then open a TCP connection to port 5060, then close it again without sending any data. This behavior is consistent across different users, it follows the devices. Everyone we have tested with who was unable to get registered the first time, had this issue when I ran a packet capture on the CallManager. Here are four screen shots showing two working devices and two non-working devices. It is interesting that in one case, there are working and non-working devices running the exact same kernel version. This behavior has persisted as long as Cisco Jabber for Android has been out, and nothing has ever been done about it. There was discussion about it being a kernel bug, but there doesn't seem to be any evidence of that. In fact, when testing with other Android SIP clients, they are able to register with CallManager over TCP just fine; so the problem must be in Cisco Jabber for Android. What is being done to address this bug and how can we assist?

Jonathan Schulenberg · ‎11-27-2012

The problem is that Cisco is only supporting a handful of Jabber handsets per the release notes:

 Samsung Galaxy Nexus with Android OS 4.04
 Samsung Galaxy S II (AT&T) with Android OS 2.3
 Samsung Galaxy S II SC-02C (NTT Docomo) with Android OS 2.3
 Samsung Galaxy S i9000 (model number GT-I9000) with Android OS 2.3
 Samsung Galaxy Ace (model number GT-S5830L) with Android OS 2.3
 Samsung Galaxy Tab International (model number GT-P1000) with Android OS 2.3

I recently had a customer who uses DROID RAZRs with this exact behavior. The client-side logs suggested the process was being killed off:

11-14 09:47:20.765 I/ActivityManager(  719): Force stopping package com.cisco.jabber uid=10142
11-14 09:47:20.765 I/ActivityManager(  719): Killing proc 19540:com.cisco.jabber/10142: force stop
11-14 09:47:20.765 I/ActivityManager(  719): java.lang.Exception
11-14 09:47:20.765 I/ActivityManager(  719):    at com.android.server.am.ActivityManagerService.removeProcessLocked(ActivityManagerService.java:4095)
11-14 09:47:20.765 I/ActivityManager(  719):    at com.android.server.am.ActivityManagerService.killPackageProcessesLocked(ActivityManagerService.java:3956)
11-14 09:47:20.765 I/ActivityManager(  719):    at com.android.server.am.ActivityManagerService.forceStopPackageLocked(ActivityManagerService.java:3986)
11-14 09:47:20.765 I/ActivityManager(  719):    at com.android.server.am.ActivityManagerService.forceStopPackageLocked(ActivityManagerService.java:3907)
11-14 09:47:20.765 I/ActivityManager(  719):    at com.android.server.am.ActivityManagerService.forceStopPackage(ActivityManagerService.java:3769)
11-14 09:47:20.765 I/ActivityManager(  719):    at android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:1112)
11-14 09:47:20.765 I/ActivityManager(  719):    at com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:1731)
11-14 09:47:20.765 I/ActivityManager(  719):    at android.os.Binder.execTransact(Binder.java:354)
11-14 09:47:20.765 I/ActivityManager(  719):    at dalvik.system.NativeStart.run(Native Method)
11-14 09:47:20.765 I/ActivityManager(  719):   Force finishing activity ActivityRecord{413d7520 com.cisco.jabber/com.cisco.soundwave.ui.AccountSetupStartActivity}
11-14 09:47:20.765 I/ActivityManager(  719):   Force finishing activity ActivityRecord{41e43eb0 com.cisco.jabber/com.cisco.soundwave.ui.AccountSetupStartActivity}
11-14 09:47:20.835 I/WindowManager(  719): WIN DEATH: Window{414e2e88 com.cisco.jabber/com.cisco.soundwave.ui.AccountSetupStartActivity paused=true}

Seems like a problem with the app except it is happening on an unsupported handset. This means that Cisco TAC tells you to get lost and never opens a defect. There is no recognition from Cisco that this is in fact a bug.

What is being done to address this bug and how can we assist?

You need to speak with your Cisco AM to get your corporate handsets added to the supported list; or, the support policy changed to more device-agnostic. Personally I find the later unlikely based on Cisco's traditional support policies. Short of switching to Apple iOS your options seem limited in the near-term.

Please remember to rate helpful responses and identify helpful or correct answers.

tirianwilson · ‎11-28-2012

Good Morning,

It is nice to hear that someone else is having the same issues. I have been reporting this bug since the initial beta, but there hasn't been any interest in actually fixing it. None of the other SIP clients I test with have similar issues (SIP Droid, CSipSimple, Linphone, etc) and none of them only support specific devices. Even though Skype isn't SIP based, they seem to have no issues supporting most Android devices. In fact, I can't think of a single other app that doesn't work across all the Android test devices we have in our department. Our issue is that due to some vulgarities in the Tax Law, we don't have a corporate handset. Employes are give a stipend to buy whatever handset they want, and so far, they are overwhelmingly buying Android handsets. We do have a very vocal iOS contingent, but from a numbers perspective, we have significantly more Android devices. The Cisco Jabber on mobile devices initiative has never gotten past the evaluation stage because of all the issues we have with Android device support. We can't say "These are the supported handsets", we can't even say "These are the supported carriers". In our office alone, we have AT&T, Sprint, TMobile, Tracfone, US Cellular, and Verizon. There is no single handset that is available across all the carriers that people use, and if there was, we still couldn't enforce it. It is really sad that Microsoft is doing a better job of supporting Android with their Lync client than Cisco does with their Jabber client. And Cisco makes an Android tablet. . .

I was really hoping to get enough complaints from different people together to get Cisco to reevaluate their Android support policy. None of the other major players take this attitude tward Android support - even WebEx doesn't - and the way the market is shaping up, Cisco can't afford to make Android a second class citizen much longer.