[Jingle] Rebooting XEP-298: Delivering Conference Information to Jingle Participants (Coin)

Saúl Ibarra Corretgé saul at ag-projects.com
Tue Jul 9 07:10:27 UTC 2013

Hi Philip,

> Quick feedback (based on the example in section 6):
> - <conference-description/> is basically the MUC topic. I suppose that if jingle were <message/> based you could even pull it out of the jingle element.

We will add a reference to http://tools.ietf.org/html/draft-ivov-grouptextchat-purpose-03, which says how to indicate a related MUC to a Jingle conference, so assuming a MUC is also taking place, the focus could pull in the subject.

> - <users/> is going to hit the maximum stanza size rather quickly. In MUC i would deliver that (in particular: src-ids) with the individual participants <presence/> elements and collate when receiving the code=110 presence. (this might even work nicely with the "PLAN B" stuff)

RFC4575 specifies how to use partial notifications: http://tools.ietf.org/html/rfc4575#section-4.4

> It seems the example is not even valid xmpp because it iq has two children (the fact that google does <jingle/> and <session/> does not make this valid :-)). Example 5 has the conference-info as child of jingle, I suppose that is the plan here as well.

Oh, we need to fix that :-S There are 2 different things going on here: the 'conference' element, set by the focus (in the jingle stanzas) to indicate that she is acting as a mixer and the 'conference-info' payload (rfc4575) which carries the participants information. The information about participants is not necessarily bound to Jingle, we added the jingle element to add a reference to the session so that clients can track to what sesion the payload belongs. Since the rfc4575 schema allows for extensions, I'll probably put the jingle element with the session id inside the conference-info payload, thus making it valid XMPP.

> The design of not using MUC bothers me for a number of reasons...
> (but I can't allocate the time necessary for writing up how I would do it instead :-/). The major advantage of this approach is that is maps easily to RFC 4579, eh?

We will add some text on how this interacts with MUC hopefully soon. 4579 is the application of 4575 to SIP conferencing, this is the XMPP equivalent, in a way.

Thanks a lot for the feedback!

Saúl Ibarra Corretgé
AG Projects

More information about the Jingle mailing list