Le mardi 6 août 2024, 18:52:04 UTC+2 Marvin W a écrit :
Hi,
Thanks for proposing this specification.
I still fail to see why it is necessary or a good idea to create a new
Jingle session for every participant stream. I see a lot of downsides
without any obvious upside. As I understood, the reason to do this is
that some SFU implementations use one WebRTC session per participant.
However, there is no rule that says that a WebRTC session corresponds
to a Jingle session. It's perfectly valid to translate multiple WebRTC
sessions to multiple contents in a single Jingle session.
There's no way for a client to know if an incoming call is part of
already running conference call or independent, except for comparing
the from-attribute if the iq stanza of an otherwise unrelated Jingle
session.
As of now, a single device can (technically) have multiple independent
Jingle sessions and calls, even multiple between the same JIDs. While
there probably aren't a lot of usecases for that (except for file share
+ single call at the same time), it seems inappropriate to disallow
this by giving two calls with the same entity a special meaning (aka
saying they form a conference) which is effectively what this XEP does.
When multiple sessions are used, each stream needs to negotiate an
additional ICE (+DTLS) session, because BUNDLE grouping is only defined
within a Jingle session, not across sessions. This means unnecessary
delay when new participants join. I understand that some available SFUs
don't BUNDLE different participants, but that doesn't mean it's always
a bad idea to support that.
The current design doesn't allow the SFU to mix audio signals. While
mixing is not strictly a task for SFUs, hybrid SFUs that mix audio and
forward video are not uncommon for large A/V setups, so supporting this
also would be reasonable. COIN already does support to announce audio
mixing, but that by design wouldn't work if each participant needs to
get their own Jingle session.
Marvin
Hi Marvin,
thanks for the feedback.
As we have discussed during last Berlin sprint, I've followed closely the
implementation of the SFU I've used for the implementation (Galène) for
simplicity, and to have something working quickly. I'm totally open and
willing to move gradually to another design, and notably to use a single
session. I'm still wondering if it would make sense to have both approaches or
if having a single Jingle session is always the best way to go (also regarding
the facility of implementation which is a design goal).
The current design has the advantage to be very easy to implement, and
relatively similar to what is done with MUJI (without the MUC part, which is
not necessary here). The peer JID is indeed the way to differentiate the call:
the disco identity is here to indicate that it's an A/V conference room (and
XEP-0298 'isfocus' attribute is used during the Jingle negotiation as
additional indicator). The SFU service must not do independent call, it's A/V
conferences only, so there is not way to mix it. A file sharing can still
happen with an SFU service/av conference room (it's just another session with
jingle-ft instead of A/V streams).
Yes the ICE negotiation indeed add delay, this is also noted on Galène. I
think that this is acceptable as first implementation, and this can evolve to a
better design with following revisions.
While supporting audio mixing would be nice, I don't think that this is
necessary for first implementation. This also can be a future addition when the
design will be updated.
The goal here is to have something very simple, straightforward to implement,
so XMPP ecosystem can have several clients with multiparty conferences soon.
I have already a SFU service and client implementation using this
specification. Again I'm totally open to move this gradually to a better
design. However I think that the current one is acceptable as starting point,
and is very easy to implement.
On another topic, several people have informed me that there was a copy/paste
error with the "overview" section appearing twice, it would be nice to remove
one of them but I don't want to modify the protoXEP before council review.
I'll do it at next revision.
Note that I'll be on vacation in coming weeks. I'll check from time to time my
message, but I'll be very slow to answer.
Best,
Goffi