[Jingle] Opinions about Coin

Diana Cionoiu diana-liste at null.ro
Fri Apr 29 17:23:42 UTC 2011

  Hello Enrico,

My proposal it's to have a XEP that is connected to MUC.

Since MUC already have the entire mechanism of invitations, control and 
everything else that is necessary for control, so we don't need to 
reinvent the wheel or implement something new.
The Jingle can establish a session which can be audio, video, remote 
desktop, file transfer.

So the logical implementation from my point of view it's to have an XEP 
declaring resources within a MUC, like an audio focus. This audio focus 
can be located on the MUC server or on any other server or to a client. 
Muji it's just a way to announce several focuses for clients.
Makes sense?

Yes XMPP is wrong for a simple use case. But you need to remember that 
Jabber is used by Google Talk, Cisco WebEx, Facebook and others that are 
really large systems.
SIP is used in far more places but with smaller installations. I don't 
think i know at least one SIP system that has 5 milion users.
It's a different ball game. And any XEP that is out there has to take 
care of that.


On 04/29/2011 01:12 PM, Enrico Marocco wrote:
> Architectural arguments aside, it seems to me that there is a
> fundamental misunderstanding about the use case a bunch of people here
> seem to be interested in and find a Coin-like approach suitable for. The
> use case is pretty simple: a user agent initiates or accepts a Jingle
> call that in fact is (or at some point scales to) a mixed conference
> call. Your iPhone, Android and most likely also your old-fashioned
> desktop phone allows you to do that today by means of n-way PSTN calls,
> so it seems a reasonable assumption in the Jingle case not to require
> any specific feature other than basic call capability. Now, the
> extension being discussed here is simply aimed at conveying additional
> information about the participants in such kind of mixed calls to user
> agents that understand it, yet allowing plain Jingle ones to
> participating in media only.
> Muji, nor any reasonably foreseeable extension of it, seem to cover such
> a use case. Coin is the simplest approach its proponents could figure
> out for such a simple task. If you spot any technical issue, any
> potential improvement or can suggest a better approach, that would be an
> excellent basis for discussion. I am certainly not religious about
> protocol syntax, least about 4575.
> The arguments I've been hearing so far seem to be not about how Coin is
> bad as much as about how XMPP is wrong for such a simple use case. Is
> this really what we are talking about?
> Enrico
> On 4/28/11 10:01 PM, Diana Cionoiu wrote:
>>    Hello Enrico,
>> The question here is "Which problem is COIN trying to solve?"
>> The answer I believe it is "It's trying to make a conference".
>> Now his purpose it's to control the conference. But Jabber already has a
>> model for conference which it's based on MUC. That's the Jabber way to
>> split things in such a way that it can be implemented in layers. So the
>> negociation shouldn't be done by the client. That should be done by the MUC.
>> In SIP you can compare the SIP proxys with the Jabber servers. But in
>> SIP there is no concept for an external component as MUC.
>> That's why the COIN is considered sipish and it's such a strong opinion
>> about it.
>> My personal opinion is that clients if they want to do management of a
>> conference they can do it using iq based commands for MUC as for any
>> other conference.
>> I know that most SIP developers will consider that a far too complicated
>> way. But sometimes an additional layer it's necessary for keeping the
>> long term implementation clean.
>> Regards,
>> Diana
>> On 04/28/2011 04:34 PM, Enrico Marocco wrote:
>>> On 4/28/11 2:14 PM, Dave Cridland wrote:
>>>>> This is beginning to get too generic and I am afraid I am not
>>>>> following. Could you please point the aspects in Coin that you
>>>>> think would prevent XMPP servers to work with one another?
>>>> I think Diana is saying that the model of COIN is essentially that of
>>>> SIP, and doesn't conform well to the federation and deployment model
>>>> of XMPP, which is much more structured and well-defined.
>>> Yes, that's also what I thought was meant. The problem that I'm having
>>> is that ever since we proposed Coin the kind of criticism the we've been
>>> getting has mostly been a variant of "this is not the XMPP way" or "this
>>> is sooo SIPish" or "this is a kitchensink" or even "read it and it'll
>>> make you cry." I now wonder when we'll get "every time you read it a
>>> kitten dies."
>>> It is hard to argue with such statements so it would be great to hear
>>> something more specific. As a starter, an example of the issues that
>>> come with being SIPish in this case -- assuming it is -- would help a
>>> big deal.
>>> In this specific case I simply fail to see the paradigm mismatch. Coin
>>> uses a very simple model that would be easy to adapt to the majority of
>>> the conferencing applications today. In this model people either join or
>>> are called into a conference which looks to them as a regular call.
>>> Those who support coin would simply be able to learn more about it and
>>> those who don't would still be able to participate.
>>> In addition to matching the reality Coin is also very easily
>>> integratable in other architectures, like Muji, since any participant
>>> can act as a proxy between the two.

More information about the Jingle mailing list