[Foundation] Re: Members digest, Vol 1 #284 - 4 msgs

Jean-Louis Seguineau /EXC/TEC jean-louis.seguineau at antepo.com
Wed Aug 7 13:38:24 CDT 2002


IMHO, we are missing an important point here. Although we might have to
compare the two (just because M$ has endorsed one of them), SIP/SIMPLE and
Jabber have nothing in common. As its name implies SIP means Session
Initiation Protocol, i.e. this is another discovery protocol invented by
Voice over Packet guys in order to establish a "circuit" (in good old
telephony term) between endpoints. It is meant to provide the base call
establishment between two or more machines and negotiate a bare minimum
aggreed communication path.
It relies on redirects and notions of home and host servers to allow an
endpoint to "roam" out of it's local environment.
The details of the session itself, i.e. what the content will be and what
transport protocol you are going to use to communicate is negotiated through
another protocol.
To make it simple, you may initiate a session using SIP and then negotiate
to use Jabber as the transport protocol for the communication, or any
streaming protocol for video or VOIP.

SIMPLE is a hack into SIP, because people thought that once a session was
initaited, it was easy to convey text message using the same mechanisms. I
just want to stress that SIP/SIMPLE implementations will rely heavily on
HTTP which make perfect sense in establishing the session, but become
completely and uterly inadequate when it comes to "real time" communication.
SIMPLE was invented to provide an quick and dirty  application for SIP. As
usual, it is like using a spanner to hit a nail on the head instead of using
the right tool, a hammer.

Lastly, SIP is not deployed on any large scale today. And time will pass
before it is. This is Jabber's chance, because it is a "real time"
extensible protocol. And jabber has a larger installed base both in
commercial and Open Source servers.
There is no problem implementing SIP or SIP/like mechanisms using jabber,
nor is there any problem with having jabber make use of standards like
S/Mime


----- Original Message ----- > Message: 1
> From: Mike Lin <mikelin at MIT.EDU>
> To: members at jabber.org
> Date: 06 Aug 2002 21:19:26 -0400
> Subject: [Foundation] Council "Debate" Responses -- Mike Lin
> Reply-To: members at jabber.org
>
> 2. From a purely technical standpoint, what differentiates Jabber from
> SIP, SIMPLE, and related technologies? Why (or why not) is XMPP a better
> choice for many applications than transporting XML/MIME payloasd via
> SIP?
>
>
> Broadly speaking, Jabber and SIP/SIMPLE both have basically the same
> idea: a widely distributed network of many site-level servers that
> intercommunicate with each other, where every node has a unique
> identifier and messages can be routed between any nodes.
> Architecturally, there is nothing really much different about them. In
> SIP you have this focus on negotiating out-of-band sessions; but you
> could very easily stick an XML payload into a SIP/SIMPLE message, and
> that's not _really_ any worse than transporting your XML inside XMPP, at
> least as XMPP stands today.
>
> In fact, the XMPP wire protocol actually suffers from a number of
> disadvantages relative to SIP/SIMPLE. The canonical example is framing,
> the mechanism by which chunks of data received from a peer are separated
> into packets. In XMPP, we delineate packets by their XML structure. This
> looks very nice on paper, but in fact it is extremely difficult to
> implement, because almost no XML parsers are designed to be used for
> framing. If you look around at the various XMPP XML Streams
> implementations out there, you'll see all manner of hacks and
> workarounds to make this work. SIP/SIMPLE does this in a much more
> conventional fashion, with a Length header. Maybe it's uglier, but
> there's no doubt it's much preferable when it comes to writing the code.
>
> SIP/SIMPLE gains many things like security and authorization virtually
> for free because it builds on technologies like S/MIME and HTTP for
> which there are so many well-established implementations. On the XMPP
> side, we're working primarily with a number of W3C standards, many of
> which (like XML Encryption) are still new and unproven. Indeed, existing
> XMPP implementations for the most part haven't gotten things quite
> right; jabberd is dogged by namespace-processing issues, for example,
> and we're still in the throes of getting security figured out.
>
> Overall, I would characterize SIP/SIMPLE, which primarily builds on
> well-established technologies, as a small, careful step forward; nothing
> revolutionary, but something that (technically) will almost certainly
> work. XMPP, built on technologies that have only been around for a few
> years (and some that are still forming) is in comparison is a huge leap
> forward; but the landing from that huge leap was a bit unsteady, and now
> we're in unfamiliar territory. I think the question of which of these is
> preferable is something over which reasonable people can disagree.
>
> I think the most compelling technical argument for Jabber today is
> developer accessibility. If you wanted to write something that talks
> XMPP, you could head over to jabber.org and find libraries for virtually
> any programming language, on virtually any platform. We have pretty darn
> good documentation, including an IETF-style specification and an
> O'Reilly book. There's a heck of a lot of existing code. If you get
> stuck, you can come and ask questions in a lively open-source community.
> If you wanted to write something that talks SIP/SIMPLE, you would find a
> couple half-assed Java and C++ implementations from Columbia, sketchy
> documentation, and a nonexistent installed base.







More information about the Members mailing list