[Jingle] Session Descriptors vs. Session Information (Re: Opinions about Coin)
enrico.marocco at telecomitalia.it
Sat Apr 30 08:35:26 UTC 2011
Well, what I'm getting from this discussion is that whilst it is OK to
transmit session descriptors in XMPP (i.e. Jingle), using it to pass
additional information about a media session (e.g. info about the
contributors in a mixed stream) is just wrong.
I believe your SIP and XMPP deployments comparison is neither correct
nor a good reason for such a strong assertion. As I suppose you're
speaking as an individual, it'd be good to hear also other opinions on this.
On 4/29/11 7:22 PM, Diana Cionoiu wrote:
> 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?
>> 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.
>>> 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...
Size: 6066 bytes
Desc: S/MIME Cryptographic Signature
More information about the Jingle