[Jingle] Opinions about Coin

Enrico Marocco enrico.marocco at telecomitalia.it
Fri Apr 29 10:12:06 UTC 2011

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?


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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6066 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/jingle/attachments/20110429/4a89009e/attachment-0001.bin>

More information about the Jingle mailing list