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

Georg Lukas georg at op-co.de
Fri Sep 6 07:58:31 UTC 2019


* Andrew Nenakhov <andrew.nenakhov at redsolution.com> [2019-09-05 09:45]:
> [..] 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.

You can enable Carbons to receive live messages. If you do so before
fetching MAM, you will receive all messages, just not in the right
order.

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

Yes, but this is only a problem if a call is never answered nor
retracted, AND your time is off.

> If we had that message attachment XEP it could suit this purpose much
> better than the current approach.

You'll be glad to hear of https://xmpp.org/extensions/inbox/fasten.html
then.

> Why is 353 not designed for carbons? <accept/> is a <message/> and
> should be sent to other connected resources once the call is accepted.

Sending a separate explicit message to your other clients is an obvious
hack. The right way would be to ensure that 0280 will deliver a carbon
copy of your <proceed/> to the other logged in clients.

That way, you will not end up in an inconsistent state if the accepting
client dies in the middle of accepting the call, after sending <accept/>
to your account, but before sending <proceed/> to the caller.



Georg
-- 
|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y?   ||
++ IRCnet OFTC OPN ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20190906/2ba142d6/attachment.sig>


More information about the Standards mailing list