[Standards-JIG] Jingle vs. Zoep

dirk.griffioen@voipster.com dgriffioen at voipster.com
Wed Feb 8 21:07:49 UTC 2006

Ralph Meijer wrote:

>On Tue, Feb 07, 2006 at 04:14:41PM -0700, Peter Saint-Andre wrote:
>>In essence they encapsulate entire SIP packets in an XML wrapper and
>>send them over XMPP.
>>I think it would be beneficial to discuss the pros and cons of each
>>approach (e.g., to determine if it makes sense to publish the OpenZoep
>>doc as a JEP).
>>What do people think?
>I'm not sure if the two approaches have the same goals and starting
>points, however, I think the Jingle proposal, because of its inherent
>union with the XMPP world, has my preference for implementing multimedia
>session negiotiation. For one thing, authentication and authorization of
>communicating entities is more straight-forward in the Jingle case
>because they are clearly the same entities. For Zoep, there isn't such a
>relation as far as I can tell: you have a Jabber ID and a SIP address.
>This proposal does not make clear to me how this is handled except for a
>reference to ICE. So in that regard, while implementation may be easier,
>there are drawbacks, too, apart from the two-stack tax.
At danger of missing the point, authorization and authentication are 
handled the Jabber way: you will need a Jabber ID and you will need to 
be connected. After that, for setting up a session a full SIP message is 
used, with some overhead there (XMPP and SIP overlap so we let it be 
redundant a little). In the case of pc2pc the overhead is appearant: 
duplication. In the case of pc2pstn this is no longer the case: the XMPP 
part is discarded and the SIP message is passed into the SIP world, 
going past server X, Y and Z to reach the phone intended.

The two-stack idea: yes, both SIP and XMPP do in a way the same things; 
which becomes clear if you look at the SIP extension moving to do IM and 
XMPP moving to do session negotiation. To me it's simply a matter of 
strong points: SIP is well defined towards the session bit, whereas XMPP 
is much better at IM and more. And maybe I am repeating myself here, but 
there are many places SIP applies - this gets them in, but it allows for 
IM too ...

>Reading JEP-0001, I think the goal of our standards process is to
>document the best approach to address a certain problem domain. Although
>subjective, I read that to mean making a choice between two proposals
>with similar goals. This should also result in better interoperability.
This we would very much like to be part of.

>In other areas, we have chosen for relatively simple solutions for
>certain problem domains. We have tried to avoid importing other 'stacks'
>and their suite of dependency documents, and picking some of the good
>stuff out of existing solutions. I am thinking about JEP-0080/JEP-0112
>instead of OpenGIS' GML and GeoPriv and our hesitation to use RDF for
>profiles, opting to translate on the server if needed.
To be honest, I was not aware of this. Regarding Jingle, as Tins did, it 
looked to me as redoing work already done - I know this could get met on 
the unpopular list - but, is there a reason not to take what is there in 
a 'resistance is useless' way? Just thinking aloud here  :-)  .

>So, if the Zoep proposal only addresses transporting SIP over Jabber, it
>has a different goal then Jingle, which would be acceptable for
>publication as a JEP. However, I don't see this proposal competing with
>Jingle as the solution for multimedia negiotation *as a JEP*. I don't
>want to burden our implementors with multiple competing protocols.
I would very much agree here, Zoep was created in a pre-Jingle era; it 
just took a different approach: the has-a over an is-a (or, the 'amoebe').
We are certainly not in the business of trying to be a replacement or 
takeover, since here are obviously issues both approaches address to a 
different extent. We wanted to be pc and pstn compliant, without the 
overhead of a) a new stack and b) translating elements and having to 
solve appearing problems. However,  I do feel there is some overlap 
between Jingle and Zoep, so what I would be interested in is in 
determining where and how big this overlap is. Jingle is without doubt 
very well thought out, but there is value in SIP too, if only for 
legacy, connectivity or wider acclaim: now XMPP does SIP too .. which 
maybe brings in parties formerly not aware of or not interested in 
XMPP's possibilities.

>Then, on the Zoep protocol itself, I see there is a <socket_id/> element
>being used, that effecively resides in the stream's namespace (usually
>jabber:client). That can never be correct, it must be in another
>namespace (e.g. Zoep's). Maybe <thread/> could be (ab)used for this
This is an obvious miss on my part, I will correct this. The reason it 
is there is because we also use XMPP (rpc) to negociate sockets, thereby 
addressing NAT issues. I know, our Jep only hints at this and would like 
to address it properly, either by mail or Jep? I'll get back at this.

& groet



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060208/989e3da4/attachment.html>

More information about the Standards mailing list