* Andrew Nenakhov <[email protected]> [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 ||_________________________________________________||
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
