[Jingle] Join header for Jingle conferences
emcho at jitsi.org
Wed Jul 31 21:44:07 UTC 2013
On 31.07.13, 22:54, Philipp Hancke wrote:
> Am 27.07.2013 01:36, schrieb Emil Ivov:
>> Hey all,
>> We are currently working on Jitsi's next version of Jingle conferencing
>> and we have one specific issue that we'd like to discuss here.
>> Imagine you use a user agent that can setup and host conferences. This
>> could be a dedicated conferencing server that connects as an XMPP client
>> to an XMPP server. It could also be an actual XMPP client with mixing
>> Either way, the most important part is that it is only registered with a
>> single JID. Something like mixer at example.com/mixer. A conference call
>> here is just a bunch of 1-to-1 calls whose content is being mixed or
> How strong is your requirement that you must be able to use this on an
> c2s connection?
For us it's essential.
Note that this is not only about conferencing. It's really mostly about
auto-answer in cases such as a call center, a teamviewer-like service, etc.
> I would recommend a component connection.
I understand how this would make sense for a number of products, but
that's not the use case I was referring to.
> If you host more than one session you might run into flood protection
> limits rather quickly otherwise.
We've actually been hitting some of those on some servers and worked
around them by implementing partial updates and congestion
By the way, what are your observations for the limits that most servers
> I can certainly see the advantage in being able to start a
> three-person-conference running on your own jid, but since you talk
> about a dedicated conference server...
I just said that a dedicated server is one of the options. Obviously a
server would be more compelled to just run as a component but I can see
why the c2s use case could also be of interest there in some corner
cases (providing a conference bridge on 3d party servers).
>> Now here comes this new person that would like to join this existing
>> conference. How would she go about it?
> <presence to=session at mixer.example.com/mynick>
> <x xmlns=themucns/>
> and then jingle to session at mixer.example.com
Indeed, although again, this wasn't the use case that I was asking about.
> The advantage of using presence here is that the users server is
> responsible for telling you when the user goes away without explicitly
> leaving your room.
If you are doing Jingle in it's current form, a client has to have
presence with that user anyway, so this isn't really a gain.
> The disadvantage is that you probably need to implement a decent
> percentage of MUC functionality ;-)
>> Potentially, we might want to add some possibility for authentication
>> ... like a "secret" attribute for example:
>> <join sid='c95ullxmnc59lhgc' secret='the-password-for-the-conf'/>
> When going the muc path you get that for free. It's somewhat silly that
> we still transfer those passwords in plain but...
We've been through this many times before during the MUJI vs COIN
debate. Ultimately COIN got implemented in some places where it was more
convenient, MUJI got implemented in others (oh, no wait, it didn't ;) ).
MUCs are obviously extremely convenient in a conf call scenario but
using the MUC for all the call signalling isn't necessarily the only way
to go about this.
More information about the Jingle