On 07.01.22 09:04, Thilo Molitor wrote: > Why an extra XEP instead of extending XEP-0353 to include group calls? > I recently reworked the whole XEP-0353 and given that this includes a > namespace bump, it would be easy to extend it to include other invite types > alongside the jingle invites already included.
It seems weird to add non-Jingle invite types to a XEP called "Jingle Message Initiation" that is mostly about how to bypass the issue of Jingle being IQ-based and thus having the wrong semantics for doing calls when the recipient has multiple resources (online or even offline via push notifications). Of course, as written in the introduction to the Call Invites ProtoXEP, there is some overlap wit XEP-0353, as both can be used to initiate simple 1:1 Jingle calls, but that doesn't obsolete the usefulness of a specific XEP to invite to calls (independent of participant count and connection method) rather than Jingle sessions (independent of content). > Something I'm missing in your XEP is some sort of tie breaking mechanism (at > least for 1:1 calls, but preferably for group calls as well). We don't have specific rules for tie breaking yet, as they don't work that good in the generic call case. For example if user A invites user B to a call X and at the same time B invites A to call Y, how do you resolve this without manual user interaction (in which case, one person will just retract their invite)? We could add the same tie breaking rule as in your PR for XEP-0353 for the special case of two users calling each other directly and only providing <jingle/> method with themselves as 'jid' or no 'jid' attribute (aka. the case where the Call Invites ProtoXEP overlaps with XEP-0353). Maybe those tie breaking rules could also just go in some other place, as they are not very specific to the method described in XEP-0353 or this ProtoXEP. > The XEP mentions Message Carbons (XEP-0280) for synchronization between > clients, but does not mention interaction with Message Archive Management > (XEP-0313) or Push Notifications (XEP-0357) at all. The XEP only mentions XEP-0280 as one means to assure they will be able to receive replies of other devices, so they won't continue ringing if another device accepts or rejects the call. However XEP-0280 is not the only means to achieve this and is not required, for example, MUCs will reflect the message even without XEP-0280 enabled and clients can also subscribe to PubSub MAM instead to get the outgoing messages. Last but not least, if it's guaranteed, that no other resource will accept/reject the call invite (e.g. because the environment is built as such) none of this is necessary. I don't think it makes sense to write down all the means that exist to achieve the goal of ensuring one will receive replies of other devices again in every XEP. Also this may change in the future. Marvin _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
