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

Andrew Nenakhov andrew.nenakhov at redsolution.com
Tue Sep 3 13:02:43 UTC 2019

вт, 3 сент. 2019 г. в 17:14, Philipp Hancke <fippo at goodadvice.pages.de>:

> 0353 was explicitly designed for push (by not including the full payload
> due to size constraints) in conjunction with 0357 and should not go to
> MAM (hence no body).
> This has some sad consequences like the lack of a message acting as a
> call data record in the users history.

We're using Processing hints <store> element to make an archive store such
messages.  https://xmpp.org/extensions/xep-0313.html#hints

> The way 0353 is supposed to work is:
> 1) you are offline but have a push-enabled client
> (there is the more interesting scenario where some clients of yours are
> online but none does jingle... and you would need to send a push
> notification to your offline client that does... that is a generic issue
> however)
> 2) you get a push notification with the <propose/> element and know the
> senders full jid, the session id and (FYI) the media types involved
3) your client requests that session at the sender. If that session
> doesn't exist anymore the sender will respond with a message stanza with
> type=error and <item-not-found/> (and potentially the jingle
> <unknown-session/>

No, I think push notifications do not work the way you describe. XEP-0357
says that a published <notification/> MAY contain additional custom
information, however, all our implementations of Push notifications assume
that NO additional information is relayed through third-party services
(ejabberd, as I recall, doesn't even support publishing such additional
information). Thus, we get NO <propose/> in push notifications, NO message
text, nothing. Just notification to an app that it should wake up and
update its data. Consequently, the only ways we can get this information
are MAM and offline messages/ Since offline messages perform poorly when
there are multiple user devices, it leaves us with just MAM.

I strongly oppose any suggestions to make push notifications work
differently. If we start sending payload about calls via FCM/APNS, why stop
at calls? We can just send full message text via push notifications as
Telegram does. And at that point, why messing with XMPP at all? An FCM-only
messenger can be coded in a week, it'll send and receive full message text
via FCM, store messages on FCM cloud database and all will work admirably

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/20190903/4ef4df1a/attachment.html>

More information about the Standards mailing list