[Standards] Proposed XMPP Extension: Call Invites

Marvin W xmpp at larma.de
Fri Jan 7 13:32:14 UTC 2022

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
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.


More information about the Standards mailing list