[Standards-JIG] Jingle vs. Zoep
scottlu at google.com
Thu Feb 9 18:34:51 UTC 2006
Pushing Jingle as a replacement of SIP would be a meaningless pursuit.
That's not the intent of Jingle.
Jingle provides: a lightweight and flexible session description and
management system that uses the xmpp infrastructure, combined with a
high quality p2p implementation. This simple facility can be the basis
for many new p2p session types. For example, if you look at
libjingle-0.2.0 which was just released, another session type was just
added: a tunnel session for creating reliable TCP like streams between
peers over p2p. Adding this didn't require inventing a new way of
managing sessions or a new way to do peer to peer. This ability has
value to XMPP clients, and it has nothing to do with SIP.
The fact that one of the session types is voice is a benefit to client
implementors who wish to use Jingle in their clients. It offers
implementors the choice of putting SIP interfacing in a gateway,
rather than putting 2 stacks in the client. It is convenient to push
complexity to the server when it can be. It's easier to service when
it's on a server.
An issue I see with proposing to tunnel SIP is if for xmpp
destinations, you plan to deliver the SIP message over XMPP. Then you
are building in a dependency in the client that it has a SIP stack (so
that it can receive SIP messages). If you instead unwrap all your
tunneled SIP at a gateway and send it via normal SIP mechanism for any
destination, then Talk and other clients who choose to gateway SIP at
the server can interoperate.
On 2/8/06, Joe Hildebrand <hildjj at gmail.com> wrote:
> On Feb 8, 2006, at 2:28 AM, dirk.griffioen at voipster.com wrote:
> > However, there is one big difference: Zoep does not try to xmpp-ify
> > SIP, it just wraps it. So there is no need for invention :-) or
> > own extensions: you need a simple SIP stack (of which many exists,
> > either open or not): parser + statemachine to get up and running.
> Actually, I'll take issue with this. We haven't found any free
> (either beer or speech) SIP stacks that don't have fatal flaws in
> terms of memory leaks or mis-implementations of the protocol. I'd
> love to have pointers to some more that we haven't looked at, if you
> have suggestions, however.
> Joe Hildebrand
More information about the Standards