[Jingle] Opinions about Coin

Diana Cionoiu diana-liste at null.ro
Tue Apr 19 17:26:48 UTC 2011


  Hello,

I will start by saying that jingle != SIP.
Coin it's a nice proposal if you have a SIP client not if you have a 
Jingle client. Muji it's a nice proposal if you are doing a Jingle only 
conference without any connection with a system that has a different 
protocol.
Each of them have their merits and his crowd of supporters.

But we don't live in a SIP only or Jingle only world.

We need a protocol for the Muji crowd which want the mixing to be done 
in the client side and we need a protocol for the Coin crowd that want 
the mixing to be done in focus. I'm not a fan of ending up implementing 
both of them.

So my proposal it's different. We need a protocol that will do the 
following.

1. We need a protocol for audio conference, video conference, remote 
desktop (one computer shares his desktop and the others are seeing it), 
file transfer (like when you want several clients to have access to the 
same file)
2. We need a protocol that handles all situations:
     - each client has his own mixer
     - one of the clients does the mixing for all the other clients.
     - there is one mixer on the conference server (how the conference 
server handles different nodes it's his implementation and i don't think 
is within the scope of a xep)
3. We need a protocol capable to handle the entire management of a 
conference. Like, muting everyone and let just 3 moderators to speak.
4. We need a real "simple" (sorry i couldn't help it) protocol, that 
will not be the ultimate challenge to implement.

Regards,
Diana


On 04/13/2011 02:37 PM, Saúl Ibarra Corretgé wrote:
> Hi,
>
> First, sorry for breaking the discussion thread, I wasn't subscribed 
> with this email address before.
>
> On Tue, 2011-04-12 at 13:33 +0200, thiagoc wrote:
> > In short, Coin is definitely interesting for the following reasons:
> > * Does NOT require MUC support on client nor server
> > * It includes server side mixing, which might be required for most
> > conferences with more than 3 participants
> > * For mobile world, client side mixing and multiple streams handling
> > is out of question
> > * Matches current real life requirements
> > * It is easy to implement, that speeds up adoption
>
> Full disclosure: My knowledge in this area is mainly due to my SIP 
> background, and I enjoyed a nice discussion with Emil Ivov at FOSDEM 
> about this, so I'll throw my 2 cents.
>
> Having implemented a conferencing server with RFC4575 support (using 
> SIP, but anyway) Coin makes more sense to me and I do agree with all 
> points Thiago mentioned above:
>
> - Needing cooperation from the client side is a bad idea, people with 
> the cheapest Jingle client should be able to join the conference, 
> though it may not be able to experience shiny features like RFC4575.
>
> - Server side mixing might be a problem for some (what if the server 
> fails...) but I think we have more to gain by doing it in the server: 
> bandwidth and resources being the main reasons here. Not sure if this 
> can be applied to XMPP, but in SIP we have the concept of 'cascading 
> focus', that is, a conference server may join another conference 
> server and all the data is aggregated by both, so participants see a 
> full RFC4575 payload with the aggregated information of both servers. 
> The number of servers may grow arbitrarily, so the load can be 
> balanced and if a server fails only some participants will be dropped. 
> Doing it server side also allows for stuff like scheduled conferences, 
> for example.
>
> - Interoperability with SIP: Being a SIP guy Coin made a lot of sense 
> to me since it reuses existing standards to achieve same purpose in 
> the XMPP world. Moreover, we plan to add XMPP gateway support, so 
> being so symmetric with Coin things would just match and conferencing 
> between XMPP and SIP mixed together would be far easier to implement 
> IMHO.
>
> That's my 2 cents.
>
>
> Kind regards,
>



More information about the Jingle mailing list