[Foundation] Re: SIP/Simple
Jean-Louis Seguineau /EXC/TEC
jean-louis.seguineau at antepo.com
Thu Aug 8 13:40:14 CDT 2002
There are tons of distributed architectures out there that have nothing in
common. SMTP is probably nearer to jabber in essence than SIP.
Just let me quote what Joe Hildebrandt said about it, and as he is a native
english speaker he does it better than I do :)
[SIMPLE takes the idea that SIP can be good, and says "if SIP is good,
then SIP must be used for everything, including IM and presence." There
are some potential wins with this approach, particularly with respect to
enhancing presence with phone on-hook/off-hook/voice-mail status.
However, the SIMPLE group initially decided to use SIP not only as a
signaling protocol, but also as a transport protocol. ...]
And he also explains that
[... since SIP can be transported across UDP, and since any hop can decide
to transmute a SIP/TCP link into a SIP/UDP link for the next hop, I've lost
the ability to send large-ish packets, and I have no congestion control. ]
And l like very much this one
[Just because you have deployed DHCP, should you use that as the basis
for your IM protocol? It could be done, but it would sure be
complicated to get it right. ]
Now, there are wonders in laboratories and great ideas lying around. Many of
them worth inspiring new application. Does not mean every of them will make
it to the street. There are many intelligent features available into
disparates systems that are just awaiting to be included in other systems. I
do not recall having mentioned that SIP/SIMPLE was lacking such and such
features, I said it was uterly inadequate for instant messaging and it seems
I am not the only one to think that way.
We are talking communication here. As immediate the session establishment
might be, if the transport of the communication is bad, then the overall
user experience will be bad. Ever used VOIP for international calls ? If yes
you understand what I mean.
Finaly, I don't recall either having said that jabber was adequate to stream
video. Is my english is so rotten or , is it just your fertile imagination
By the way, I'd like to hear why we could not be using an S/Mime derivative
in jabber ?
----- Original Message -----
> Message: 4
> Subject: Re: [Foundation] Re: Members digest, Vol 1 #284 - 4 msgs
> From: Mike Lin <mikelin at MIT.EDU>
> To: members at jabber.org
> Date: 07 Aug 2002 10:41:27 -0400
> Reply-To: members at jabber.org
> - 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
> 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.
> 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
> > 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
> > transport protocol you are going to use to communicate is negotiated
> > another protocol.
> > To make it simple, you may initiate a session using SIP and then
> > 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
> > initaited, it was easy to convey text message using the same mechanisms.
> > 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"
> > SIMPLE was invented to provide an quick and dirty application for SIP.
> > usual, it is like using a spanner to hit a nail on the head instead of
> > 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
> > 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
> > > 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,
> > > 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
> > > the mechanism by which chunks of data received from a peer are
> > > into packets. In XMPP, we delineate packets by their XML structure.
> > > 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
> > >
> > > 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,
> > > 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;
> > > 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
> > > forward; but the landing from that huge leap was a bit unsteady, and
> > > we're in unfamiliar territory. I think the question of which of these
> > > 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
> > > any programming language, on virtually any platform. We have pretty
> > > 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
> > > If you wanted to write something that talks SIP/SIMPLE, you would find
> > > 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
> Message: 5
> Date: Wed, 07 Aug 2002 10:25:33 -0500
> From: Ryan Eatmon <reatmon at jabber.org>
> To: members at jabber.org
> Subject: Re: [Foundation] Council Questions
> Reply-To: members at jabber.org
> Peter Saint-Andre wrote:
> >Council Candidates:
> >Here are the debate questions submitted so far, sorry for sending them
> >late in the day. You Council candidates have until next Wednesday to
> >answer them. (Yes, I know, the message from reatmon said there would be
> >only 6 questions but since 8 came in I figured I'd post them all. Note
> >that I've rephrased/shortened a fwe of them...)
> >1. What do you think is working and not working with regard to the JEP
> >process? What suggestions do you have for improvement?
> For the most part I like the JEP process. The only two areas that I
> think need help is on community cooperation on writing JEPs and not
> created 15 JEPs on the same subject, and the Council's handling of
> voting and feedback. But that's why I wrote the Council JEP to define
> what was expected of the Council in terms of timely responses and such.
> >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 payloads via SIP?
> To be honest I have no idea what SIP and SIMPLE are. I've never looked
> into them because I've been so focused on Jabber and fixing the problems
> we have in house. I need to read up on it.
> Note: I went to find something that gave an overview and can't find
> one. If anyone has a quick read to describe what SIP is and how it
> works I'd appreciate it.
> >3. Why do you think it is necessary to develop a pub/sub protocol for
> >Jabber? Please provide specific examples. In particular, it seems that
> >there should be some useful synergy among pub/sub, message queueing, and
> >presence. How do you see this fleshing out in specific applications?
> There are alot of applications that are made easier to define and
> describe if you have a pub/sub architecture that you can leverage.
> Pub/sub is just another tool that Jabber can offer to other projects
> that make it attractive. I think that Jabber will survive without one.
> That said, I'm not so sure its as necessary to build a pub/sub as it is
> to build a good pub/sub. There are alot of models we could build on,
> and a lot of protocols that could be used to run it. Our goal should be
> to develop one that is easy to use, and extensible for the future.
> >4. How do you think ownership of the trademark on the Jabber term should
> >be handled?
> I think that the JSF should own the mark, but at the same time I also
> know why we don't. I'll also point out that this is a Board matter and
> not a Council matter. It is going to be up to the Board to negotiate
> and build a relationship with Jabber Inc. to try and faciltate a
> reloaction of the mark in the future.
> >5. How do we establish trust between servers on an Internet scale?
> What do you mean by trust? If by trust you mean how do you know they
> are who they say they are, that's impossible. It wil always be possible
> to fool a system into thinking your someone you aren't. It can be made
> easier and a little safer with soe kind of key system, but again that
> has flaws too.
> >6. Do you think we should build a mechanism for in-band transport of
> >payloads within Jabber? If not and you think an out-of-band transport is
> >sufficent, how do you see that as different from SIP?
> Large data packets should NOT be done in Jabber. The server has to
> process that large packet, and while it crunching on that, it can't be
> delivering messages from all of the other users. Large packets should
> be kept out of band.
> That said, I do think we need to define how to do OOB packets with
> Jabber. I know that there are some mechanisms in place, but at the same
> time we haven't done anything to clarify how it all works.
> >7. How can the growing complexity and functionality of the Jabber
> >be balanced with simplicity and developer-friendliness?
> I think that is up to the library authors. No matter how complicated
> something is, with a good API you can make it simple for a developer.
> That said, I think it's our job to make sure that the protocol remains
> simple. Just because we have 100 features, doesn't mean that we can't
> make them simple to implment and resuse concepts.
> That's part of what x:data is aimed at doing. Providing a tool to other
> JEP authors for gathering and reporting data. We also have another idea
> that is in the works that will provide a navigation namespace for
> looking through large data sets (limit to 10, starting at 5 give me 20,
> etc...) This too will be an x namespace that can be used by others to
> make life simple.
> By providing these core tools it makes a library/client author's life
> easier. They can put in code to handle these tools and when they see
> them they can enable it regardless of how it was used. At least that
> the idea. Only time will tell if it's feasible.
> >8. How can the JSF and the Jabber technical community best work with
> >standards organizations, specifically the IETF and any possible Working
> >Group the IETF forms to to pursue standardization of the core Jabber
> First, by working with them and not turning our backs on them. There
> has been a lot of emotion about the IETF meetinf, and the worst thing we
> could do is walk away from it and not help. There is going to be a
> working group formed to discuss XMPP, and we need to make sure we have a
> lot of people on that group to help guide the direction that XMPP
> should take.
> Second, by maintaining a level head. As was seen in the IETF BOF, there
> are a lot of emotions between SIP and XMPP. We need to make sure that
> we are polite, informed, easy to work with, and if faced with someone
> yelling at you that XMPP is crap just smile and keep working. We won't
> get anywhere by degrading into a "Our protocol is better than yours!" war.
> >Peter Saint-Andre
> >Jabber Software Foundation
> >Members mailing list
> >Members at jabber.org
> Ryan Eatmon reatmon at jabber.org
> Jabber.org - Perl Team jid:reatmon at jabber.org
> Members mailing list
> Members at jabber.org
> End of Members Digest
More information about the Members