Le lundi 19 octobre 2026, 19:11:43 heure d’été d’Europe centrale Dave Cridland a écrit :
Hi Jérôme, standardizers,
I saw that Jérôme had resubmitted av_conferences, and since this is an area of interest of mine, and one I sadly lack the detailed understanding to drive, I reviewed it with some interest.
Firstly, this is, in my view, a major step forward and I would welcome it being published as a XEP.
This is despite my suspicion that it will need more work.
The main areas are around signalling for some of the cases that are hinted at. For example, bounded/demand forwarding, resolution selection, and so on.
The biggest structural change - I think - is that the spec assumes that participants would get one or more SSRCs bound to them, and I suspect the "right" way to achieve a good result in the client is to bind SSRCs to UX elements; so a SSRC maps to "The 4th most recent speaker", or "This pinned particiant", for example - and the Focus then instructs the SFU to map an inbound stream to that SSRC accordingly. That implies that <origin/>, which maps to the <content-add/> set in Jingle, would need to be replaced with something that's part of the <description-info/> instead.
Obviously this is all with the caveat that I have no idea what I'm talking about, really...
But, I would really love to see interoperable multiparty calls in XMPP.
Dave.
Hi Dave, Thank you for your interest in this work and for your feedback. For the record, this protoXEP was proposed 2 years ago, and initially used several Jingle sessions, Council asked to use a single session, and due to me being overwhelmed, I could only do it now. I have a working implementation (component + client) for 2 years, using Galene (https://galene.org/) as SFU, that I have recently updated it to follow the changes, so it's compliant with this 0.0.2 protoXEP. My main goals were to have a spec covering the missing parts to use SFU, as much as possible a specification simple to implement for clients once you have already 1:1 calls working, and something which can work with Galene or other SFUs. I think that those goals are achieved with this proposal. The current version covers what is necessary to have working implementation, it is of course a basis that will evolve with feedback like yours. Note that we now have XEP-0507 (Jingle Content Category) by edhelas which helps, along with <origin>, to associate streams with UI elements. Regarding content request (demand forwarding), this is yet to be specified, and it is very much needed indeed. The goal was to have a first working version, and to work with community feedback to find the best way to do that. I currently believe that we lack a <content-request> element/action which should probably be in an separated XEP (more generic than AV Conferences, and XEP-0166 is stable). For bounding, resolution, etc, <description-info> is probably the right mechanism, we just need to specify how to use it. Let's first see if the protoXEPs is accepted this time :) I'm looking forward for interoperability on multiparty Jingle too (MUJI and SFU). Several teams are working on A/V these days, and several got financial support for it (it was also my case, my initial proposal/implementation were possible thank to an NLnet/NGI grant). I have good hope to see great things happening in coming months on this front. Best, Goffi