вт, 3 сент. 2019 г. в 23:18, Georg Lukas <[email protected]>: > > * Philipp Hancke <[email protected]> [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 _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
