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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
