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

Andrew Nenakhov andrew.nenakhov at redsolution.com
Thu Sep 5 07:42:23 UTC 2019


вт, 3 сент. 2019 г. в 23:18, Georg Lukas <georg at op-co.de>:
>
> * Philipp Hancke <fippo at goodadvice.pages.de> [2019-09-03 14:15]:
> > 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).
>
> Let's imagine the following:
>
> - 0353 or 0313 get changed to store all 0353 messages into MAM
>
> - a remote entity sends a <propose/>
> - the user's server stores the <propose/> into MAM
> - 0357 triggers a push on this new MAM message
> - the (mobile) client connects and fetches MAM
> - the client sees a <propose/> that was neither retracted, rejected or
>   accepted and is sufficiently recent (say, last 30 second)

How does a client know that fetched <propose/> that he 'sees' is
neither retracted, rejected or accepted?
The thing to know about push notifications is that we DO NOT send
presence on connect. Sending presence results in receiving a massive
chunk of data that occupies all 30seconds of operation that iOS grants
to an application for reaction on a notification. So we have to
operate fully without presence, thus, if a caller rejects a message at
the exact moment we fetch an archive, we won't receive <reject/>
message in normal XMPP way. We won't be fetching it from an archive
until the next push arrives. So, a phone would ring for a call that
was already cancelled by a caller.

<iq> method that we use has an advantage that it is delivered to a
fulljid even if a client does not send presence, so it helps in this
situation.

Also, 'sufficiently recent' is an extremely unreliable method because
time on a user device can be different from the server.

> - the client <accept/>s the call
>
> @Andrew, would this be sufficient to make the protocol work for your iOS
> case?

> A side benefit of this would be that both the call itself and whether it
> was accepted/rejected is stored in MAM and can be displayed in the
> client's message history.

We actually store rejects in MAM. Also, when the call is finished we
store information about call duration. If we had that message
attachment XEP it could suit this purpose much better than the current
approach.

> Speaking of 0353 as is, it was also not designed for Carbons. I think we
> should explicitly make use of Carbons (by similar means as with MAM), so
> that we do not need separate <accept/> (to self) and <proceed/> (to the
> initator) messages. Instead, the <proceed/> will be carbon-copied to all
> other resources, letting them know that one client accepted the call.

Why is 353 not designed for carbons? <accept/> is a <message/> and
should be sent to other connected resources once the call is accepted.
I'd say that current XEP-0353 specification is designed exclusively
for carbons.


--
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com


More information about the Standards mailing list