[Standards-JIG] Jingle vs. Zoep

dirk.griffioen@voipster.com dgriffioen at voipster.com
Wed Feb 8 22:30:50 UTC 2006

Matthew O'Gorman wrote:

> Having written my own jingle library in a short amount of time, I can 
> say that is the better way to go.  I think the jingle spec still needs 
> some improvement here and there, encapsulating sip inside of xmpp is 
> just silly, better to do it right with jingle, if you need sip use a 
> sip to jingle gateway.
Where do I start? What is 'a short amount of time' and why is that 
better and 'silly' ? Why is taking a protocol, add tags for all you can 
find, forget this and that, add something nobody needs not silly?

Hmm, hat would be my first reaction; the second one would have nuance: 
clearly, as you say, there is a need for connectivity between sip and 
jingle (google and I believe now gizmo are the only ones speaking 
jingle) so this (Zoep I mean) is nothing but handy: strip off the XMPP 
and you're there...



> Mog
> On 2/8/06, *dirk.griffioen at voipster.com 
> <mailto:dirk.griffioen at voipster.com>* <dgriffioen at voipster.com 
> <mailto:dgriffioen at voipster.com>> wrote:
>     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
>     Dirk

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

More information about the Standards mailing list