Jabber iOS unregistered within a minute

[AVITYA]

Hi all,

I'm sorry if this question is already answered before. I couldn't find the same/similar question answered so far.

I have an issue with our Jabber app installed on iOS, where device unregisters within a minute or two if not used.

Phone settings are OK, notifications are enabled, as well as badges and sounds. This randomly happened and it's affecting all our iOS phones with Jabber app installed.  

Once Jabber app is re-opened, phone registers to CUCM and it's working just fine. As soon as Jabber app is closed or phone locked, it unregisters from CUCM very soon.

I've tried resetting Jabber app, reinstalling, re-adding TCT device, nothing helps.

Please let me know if you have any advise.

Thank you

Petar

[A_]

This works as designed. iOS closes the app for battery optimization. You have to use APNS (Apple Push Notification Service) so that Jabber can be woken up. You get notifications like call or message by Apple's Push Notification and this starts Cisco Jabber in the background and your TCT device will be registered again and can download the message or receive the call.

[AVITYA]

Thanks for you answer.

This happened recently, within last month or so and it used to work just fine before. Any recommendation on steps on using APNS?

Tnx

[A_ · Accepted solution]

See https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/im_presence/configAdminGuide/14_su1/cup0_b_config-and-admin-guide-14su1/cup0_b_config-and-admin-guide-1401_chapter_01101.html.

Also for configuration:

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/push_notifications/cucm_b_push-notifications-deployment-guide.html

[AVITYA]

Thanks for both links.

I can't find any steps or configuration guide, just explanation how it works with different versions of CUCM and iOS

[A_]

There is the configuration task flow:

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/push_notifications/cucm_b_push-notifications-deployment-guide/cucm_b_push-notifications-deployment-guide_chapter_01.html#task_57D4670B2139288825D6F926EA99E23B

[Oblivion_Tech]

Hi,

I'm stuck on following the steps from a link above.

I can normally ping idbroker.webex.com, but once I try connectivity test (tcp port 443), connection is refused. Port 443 is opened on the firewall.

Any ideas how to get this working?

[A_]

Hi Oblivion_Tech,

no, it seems your firewall blocking the connection. The first command 'utils network connectivity idbroker.webex.com 443' should work.

[b.winter]

Just follow the instructions in the APNS deployment / configuration guide. Nothing special to do then.

[DaveLawang]

We have this problem too. Management is throwing chairs and smartphones.

Problems started with the latest Jabber for iOS version 14.1.2. Calls don't get signaled after ~1min when device is locked and users fade to status "Away" after a minute or so. Prior versions of Jabber still work fine and calls and messages go through.

My educated guess is that the legacy VoIP sockets got toasted with the latest release. We knew this day would eventually come.

Despite this Field Notice: FN - 70555 from around a year ago (where customers were told to migrate to APNS) Jabber continued to work perfectly fine without APNS until just recently (Jabber Version 14.0.2 still works and calls go through).

Solution to get phone calls working again would be to switch on APNS. That might come with a high price tag though.

We never switched on APNS because in our case it

1. Creates dangerous dependencies on external 3rd parties (ISP, Apple Cloud and Cisco Cloud need to be up&running all the time - it pretty much makes a dual ISP setup a must have if you want to protect yourself from service outages in case your ISP goes down)
2. Completely wrecks the traditional presence model (with APNS switched on all employees are constantly shown as "Away" so presence loses all its value/meaning)

In short (enforced) APNS doesn't go well with highly critical infrastructures.

(Apple introduced the local push API for such scenarios, I don't know if it's supported by Cisco (yet))

We've opened a TAC case and are looking for alternatives, in case APNS really got enforced this time.

[AVITYA]

Hi Dave,

Thank you for your reply.

I was wondering am I the only one around having this issue, as a new jabber version should've affect other users with the similar setup.

Exactly, it used to work perfectly until new 14.1.2 update came out and suddenly our iOS devices using new Jabber version are useless. We have no option to install older Jabber version anymore and APNS is the only option from now and on, which requires configuration change and wouldn't be the best solution for our infrastructure.

I'll check community frequently for a possible solution.

[b.winter]

But the APNS topic is known for years and years now. I think, the change was in iOS 10, with further changes in the further major iOS versions.

I don't know why people still don't know about that needed "feature".

@AVITYA: APNS was the only option since this change in iOS. So, I wouldn't say, that it's the only option since the new Jabber version days ago.

And yes, maybe Cisco changed / screwed up something in Jabber, with the new version, that has problems regarding APNS. But that doesn't mean, nobody shouldn't implement APNS at all.

@DaveLawang:

I don't agree with you on point 1). Because you were and are already depended on your ISP and Apple Cloud to be up.

And the only concern is (and also always was) the ISP.

Because, I won't see an outage of Apple and Webex Cloud coming in. And if it does, I think you will agree, there will be other problems, than a Jabber on iOS not getting the signalling ';-)'

"My educated guess is that the legacy VoIP sockets got toasted with the latest release. We knew this day would eventually come."

Again, this was communicated years and years ago, since Apple announced that switch in iOS. I honestly, don't understand people, who are still surprised by that.

[AVITYA]

Hi,

I agree and understand what you're saying.

Our point is; we had it working without APNS until few weeks ago (new Jabber version came out), hence obviously APNS wasn't only solution, right. Just like Dave, we are also looking for a local solution rather than cloud based.

[DaveLawang]

@b.winter 

Can agree that for most people and less critical setups it probably makes sense to switch APNS on. There are good reasons some people with large JM setups haven't switched it on yet though and I want to shed some light on why they haven't.

There is a very important distinction between internal communication (within the enterprise) and external communication with other parties (customers, etc.) that needs to be made with this one.

Traditional model - The world is burning but we're a happy little island (Things behave like a traditional DECT setup)

Without APNS internal communication with Jabber Mobile functions completely independent from whatever is happening in the world out there. Our hospital can operate as an island cut off from the world in case the ISP goes down. We might not receive external phone calls for a while but internal communication isn't affected by it and we can deal with the emergencies and for most part also keep regular operations up and running. In our hospital it's been like this forever. No matter what, internal communication always worked reliably and to us and our patients having guaranteed and reliable internal communication channels is important.

New model - The world is burning and you're not spared (APNS without local push notifications)

With APNS enabled "signaling" gets hairpinned through ISP/Clouds (technically APNS isn't part of SIP signaling but for the lack of a better word i'll just call it that) thus all internal communication gets disrupted too if the ISP fails. This wasn't the case before. Older PBX's and pre-smartphone solutions worked flawlessly and independently from the outside world. Jabber Mobile without APNS does so too as all traffic stays local.

In our case switching on APNS creates a dangerous dependency on our unreliable ISP where in best case doctors get angry due to missed calls/messages and in the worst case people die.

Try to explain that to a management that's been used to perfectly reliable internal communication for decades. They can't wrap their heads around it and don't understand why they should take the risk of switching on APNS.

Where it doesn't make a difference

It's true that calls with external parties have always been affected when the ISP goes down but generally speaking those are not the critical calls required for frictionless internal operation. (All the 24/7 emergency numbers run through an independent infrastructure anyway)

How the dangerous dependencies could be resolved (Work in progress..?)

Local push notifications have the potential to fix that unwanted dependency. There is no more hairpinning with them and all signaling stays local - that's exactly what we need to be able to guarantee a high reliability and protect us from unexpected service disruptions. But to my knowledge local push notification for Jabber is not publicly available yet and I have no idea if/when it can be expected. 

I'm just a customer though and this is by no means meant to be official information, so Cisco feel free to correct me if I'm wrong.

With local push notifications not available for JM yet it just feels rushed to throw the legacy VoIP sockets overboard with JM 14.1.2 (if that indeed is the problem - not confirmed yet). Might be somewhat of an edge case / special situation but it puts some customers in a very difficult spot.

[b.winter]

Hi @AVITYA and @DaveLawang,

what's the point of this thread then?

I mean, there is a solution, you don't want to implement it. That's totally fine, you weighed up the pro's / con's and took your decision.

But then, IMHO, you can't expect any help here from the community.

If you are looking for help from the community on something deeper down in Jabber with that "local push notifications" stuff, then also the community won't be able to help you too, because the people won't have more info than Cisco itself.

So, the only way is going through the TAC procedure, to interact with the manufacturer.

If the new Jabber has a problem, then I wouldn't open a thread in the community section. I would open a TAC ticket, or better check to release notes first if there is anything stated regarding this. But what I probably would get to here from TAC is "turn on APNS".