[Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

Andrew Nenakhov andrew.nenakhov at redsolution.com
Sun May 10 20:11:30 UTC 2020

вт, 28 апр. 2020 г. в 13:04, Daniel Gultsch <daniel at gultsch.de>:

> Am Do., 29. Aug. 2019 um 11:26 Uhr schrieb Andrew Nenakhov
> <andrew.nenakhov at redsolution.com>:
> >> We have implemented this specification on iOS client, and discovered
> that it is unsuitable in real life scenarios. We have updated it with
> additional callback routine, the changes and stanza format is described
> here:
> >>
> https://docs.google.com/document/d/1geR2-VlKkjwqFftstV7O1cYfGqKQy-eEUepgRrge0ow/edit
> Ignoring the session-still available check here for a second (which I
> think should at least be optional and only done when catching up from
> MAM) why is this changing the proceed to an accept?

Well. You see, we _have_ implemented 0353 as it was written on iOS and Web,
and discovered that it just doesn't really work on iOS that has to wake and
fetch data from the archive.

At that point, since no one had really implemented 0353, we've just said
'screw it' and just make a protocol that is capable to work on all
platforms. We succeeded in that. We dropped 'proceed' because we felt it
serves no purpose if we have carbon copies (it's been a while and i don't
remember all the details). From your feedback in other thread I suspect you
eventually came to a similar conclusion.

I'm not forcing more discussions on this topic for one reason: our approach
to push notifications / jingle initiation that worked so well a year ago
was somewhat crippled by new Apple restrictions on push notifications.
While there is nothing there that fully breaks it, it is likely that it can
be improved to speed up the connection process, and we're still evaluating
it. Short problem description: at first we used push notifications as
completely 'blind' service that just tells the client that there are
updates, withholding from transmitting any meaningful info in push
messages. Apple broke that, and it can't be circumvented anyhow. So in new
implementations we have to put some info in them, and if we have to do so
anyway we might consider sending <propose> information directly in push.
Still, we have to establish a connection to notify other devices on
accepted/rejected calls, etc, but at least initial call pickup can be done
somewhat faster. I'm still on a fence with this.

Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com <http://www.redsolution.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200511/b8a7276a/attachment.html>

More information about the Standards mailing list