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

Mike Lin mikelin at MIT.EDU
Wed Aug 7 09:41:27 CDT 2002


- SIP and Jabber have a lot in common. The distributed server
architecture and routing concepts are basically exactly the same
- SIP's focus on call signalling does not exclude its use for in-band
transport (IIRC if the packet size is greater than some MTU, it always
uses TCP, thus giving you the same routing capability as Jabber)
- I'm not exactly sure how SIP/SIMPLE are "compteletly and uterly
inadequate" since I've seen and used SIP/SIMPLE instant messaging
clients that work fine
- I've also seen demos of SOAP queries being transported via SIP
- I don't know how much more "real time" it gets than the immediacy you
expect between when a phone rings and you start talking, which is what
SIP is designed to handle
- You can't use Jabber as the transport for streaming video or VOIP
because it uses TCP. TCP is unacceptable for these applications because
of retransmit delays.
- Give me a break, we're not going to be using S/MIME in Jabber any time
soon

I'm not saying SIP/SIMPLE is so great, because it's not, and I think
it's probably going to die a slow and painful death. There are a lot of
stupid things in it, but there's more to it than meets the eye, and
there are certain things we can learn from it.

-Mike

On Wed, 2002-08-07 at 14:38, Jean-Louis Seguineau /EXC/TEC wrote:
> 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.
> 
> 
> 
> 
> _______________________________________________
> Members mailing list
> Members at jabber.org
> http://mailman.jabber.org/listinfo/members





More information about the Members mailing list