Hello all,
With the new emphasis on working from home/remote working, I’ve been looking into mobile XMPP clients. I’ve found several iOS clients and they all seem to work fine with Openfire initially, but as soon as they are pushed to the background or the screen goes to sleep, they all immediately lose connection with Openfire and enter a “detached” state until Openfire eventually kills the connection. A mobile app for real time communication, that loses connection as soon as the screen goes off is not useful. Looking through support for the clients, this doesn’t seem to be a common complaint so I’m not sure if its my Openfire, if its just the nature of the beast, or what.
Just wanted to poll the audience here and see if anyone had good success with XMPP mobile clients? I’ve tried ChatSecure, Monal IM, Siskin IM, and AstraChat so far with varying degrees of success.
You experience mirrors my own. I’m still using AstraChat, but I’ve had to supplement its shortcomings with custom code. I’m using CallbackOnOffline plugin to dispatch a callback and running some code on IIS to create a chat request via my user’s MDM client push receiver.
The callback endpoint is a simple classic ASP script that looks up the JID to get the device ID, then invokes MobileIron’s client messaging URL to pop a banner.
It works OK to notify the mobile device when AstraChat falls offline in the background, which is often.
I’ve had good luck with this client on Android and am hopeful the iOS port will work as well.
My biggest frustration with all the iOS ports is that no developers have implemented appconfig (https://www.appconfig.org/) support to allow the clients to be managed via MDM.
Thanks for sharing that you’ve had a similar experience. I saw Xabber as well but unfortunately I don’t have access to an Android device to test it with at the moment.
Hi,
I think the main problem is really Apple’s policies for apps which they allow to be published on their App Store. They are quite stringent on not allowing apps to perform background processing - thus ensuring minimal power drain (except for certain defined classes of application). This means that these clients are unable to maintain their link to the server open. At least this was the case a few years ago.
Instead, Apple would like you to use their proprietary notification system. I have not looked into this, so I don’t know how it works or if they charge for it, though I suspect that they do
Tim
A big part of the problem is the lack of functionality that’s provided in version 0.6.0 of the Openfire pushnotification plugin. As soon as a couple of known issues are fixed, I expect a significant increase in user experience.
I gave Xabber for Android a trial run and it works really well, maintains a good connection to Openfire. Hopefully their iOS app will actually see the light of day.
Well, with Xabber you never know what will happen. Recently they told me that they won’t support MUC protocol because it’s “bad” and they will switch to their own proprietary one. They already have their own server, so i feel at some point they can just ditch XMPP completely.
So what I know about Apple APNS notifications are they require that the notification originating server-side process use a client certificate to authenticate with the APNS gateway and send the APNS payload on port 2195. The APNS infrastructure matches the payload on the incoming 2195 TCP connection from the server process with the appropriate device, which has made an incoming connection to the APN infrastructure on port 5223. The server-side layer 7 protocol isn’t standards-based, but the client-side uses XMPP stanzas on 5223.
Only devices that have registered for notifications from a particular service by their device ID and “topic” , which is the identifier of the application to be notified, can receive push notifications from that service.
My understanding is that receiving applications also have to be signed from the developer account as the push client certificate is generated.
This means that if each Openfire server is to be a push notifier directly to devices, that the client application that subscribes to XMPP service from Openfire (i.e. Xabber or Astrachat) will have to be signed by the same authority (developer) as the client authentication certificate that Openfire will use to communicate the Apple’s APNS gateway.
What I’ve seen as the typical approach to workaround this restriction is that each application (client) developer also operates a push aggregator service for that client. That way server processes such as Openfire can send push notifications to the client aggregator service, and the server service has the client certificate necessary to communicate with the related applications on the devices.
How will the Openfire Push plugin work given these realities?
In essence, the Openfire push notification plugin will invoke a remote client-implementation specific component (under control of the client developer, not us) to initiate the push. The protocol is described in detail in XEP-0357 Push Notifications
Just wanted to add my experience mirrors what user ioscanner reported, the trace reports notifications delivered but I never actually get any at all on my iOS devices. I am not a programmer so unfortunately I can’t contribute anything of substance to help track down or fix anything.
