[Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)
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
> 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
> 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.
|| 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...
Size: 833 bytes
Desc: not available
More information about the Standards