[Standards-JIG] Jingle vs. Zoep

Matthew O'Gorman ogorman at gmail.com
Wed Feb 8 21:35:16 UTC 2006

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

On 2/8/06, dirk.griffioen at voipster.com <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
> instead.
>    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
> --
> Groetjes,
> ralphm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060208/9e77bac6/attachment.html>

More information about the Standards mailing list