This made me smile. Thilo on August 27, after being told about issues in current XEPs:
> I'll show you how to make VoIP calls work on iOS with given XEPs and without inventing new ones as soon as I come along implementing the new WebRTC based VoIP XEPs. Thilo on December 8: > Rework whole spec. On a serious note, we do have tested ans implemented voip calling xep prototype that works well on iOS. We can share the spec if anyone's finally interested. On Wed, 8 Dec 2021, 03:18 Thilo Molitor, <[email protected]> wrote: > Hi all, > > I reworked the Deferred XEP-0353 spec and modernized it quite a lot (and > bumped the namespace): https://github.com/xsf/xeps/pull/1128 > Because of that I want to discuss this on this list, too. > > Quick introduction for lazy ones: > > In the old protocol the responder had to send an <accept/> element to his > own > bare jid, to inform his other devices that he accepted the session prior > to > sending an <proceed/> element to the initiator. > Other messages weren't synchronized that way and offline resources did not > get > any of the messages specified in the old protocol. > Depending on XEP-0280 instead of an explicit "manual" carbon copy makes > the > protocol much more simple and uses a XEP already widely in use in IM > scenarios. > It even allows to always distribute he full protocol state across all > devices > of initiators and receivers without any additional effort. > > Nowadays with devices being (temporarily) offline (do you hear me iOS) it > is > necessary to not only carbon-copy all messages but also store them in MAM > (XEP-0313) so that other devices can retrieve them after receiving a push > and > coming online again. > I decided to go with message processing hints (XEP-0334) because they can > be > deployed much faster than MAM rules to be obeyed by servers and even > underlines in the XML that this message will be saved in MAM. > > Using XEP-0280 and XEP-0313 makes sure all devices of all participants are > always in sync about the jingle call state and can show current/previous > calls > with start and end timestamps in UI even if they were offline at the time > the > call took place. > > Upon suggestion I also added tie breaking at the message initiation layer > and > a reason element to <reject> and <retract> messages as well as a new > <finish> > element allowing to archive the precise start and end timestamps of a call > in > the MAM archive (or something equivalent). > > -tmolitor > > > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ > >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
