I already released a series of posts to the SIP WG about a year ago
explaining exactly how to do this. I suspect I will probably release a
draft at some point in the future explaining how to do it using the newer
versions of the SIP standard.
The mind numbing idiocy of having SIP be "like HTTP but just different
enough to completely invalidate everyone's investment in HTTP" is too
unbelivably idiotic to be allowed to stand.
Yaron
>
> unfortunately, if SIP had followed the http wg's
> advice and made SIP compatible with HTTP (instead
> of a similar, but different), this could
> be a much easier task.
>
> > -----Original Message-----
> > From: Robert S. Thau [mailto:rst@ai.mit.edu]
> > Sent: Friday, June 18, 1999 4:35 PM
> > To: ibell@cisco.com
> > Cc: Friends of Rohit Khare; foib@egroups.com
> > Subject: SIP and Apache
> >
> >
> > Errrrmmm... I'm not the best person to contact wrt Apache politics
> > these days, and I derailed reading your message fairly quickly. Also,
> > I'm not really familiar with streaming audio at anything resembling a
> > technical level. So take everything below as a quick, sloppy guess,
> > concentrating purely on technical issues...
> >
> > Ian Andrew Bell writes:
> > > RST and others..
> > >
> > > IMHO, the relationships defined in IP Telephony
> > architectures like DCS
> > > and DOSA around SIP and RTP streams are identical to the
> > relationships
> > > between an HTTP server that guides us through selectable
> > MP3 streams.
> >
> > This is where I start to derail... the relationships between an HTTP
> > server (that guides...) and what other entity? And how does this
> > guiding take place?
> >
> > > This leads us to Apache.org.
> > >
> > > So am I wrong in thinking that Apache, as an HTTP server,
> > lends itself
> > > particularly well to being a SIP Call Agent? SIP and HTTP
> > are identical
> > > in that they are stateless, can pass MIME types, and do
> > not sustain
> > > connections. SIP has provision for a CGI architecture, as well.
> > >
> > > Does anyone think I'm crazy, after reading the IETF doc,
> > to figure that
> > > a port of Apache code to SIP is simply a case of adding
> > new message
> > > types, modifying port numbers, and broadening CGI handling?
> >
> > Well, like I said, my familiarity with SIP in particular, and
> > streaming audio in general, is at this point pretty minimal. From a
> > quick skim of the SIP RFC, I came away with the following impressions,
> > though I'd welcome corrections from anyone who has actual information.
> >
> > First, HTTP presumes a reliable transport. SIP, which can be
> > implemented over UDP, can't presume one. This means that all SIP
> > servers (or at least anything decent enough to work with UDP) will
> > need some retransmission handling logic which is not present in
> > Apache. And nothing in HTTP ever has to deal with anything like
> > multicast. So, you need some new hair on the low-level I/O.
> >
> > Second, SIP *connections* may be stateless, but SIP requests specify
> > operations on a stateful infrastructure which isn't present in Apache.
> > This includes both SIP-specific parts (whatever keeps enough
> > information about pending operations to sensibly handle a CANCEL
> > request), and the streaming connection mechanism itself (which is
> > separate from the session-initiation machinery that SIP uses, and
> > probably more work to build). In other words, a SIP server by itself
> > isn't much good; it needs to be tied to some kind of streaming media
> > server, and that's probably harder to write than the SIP service.
> >
> > (The handling of this sort of state in Apache isn't as simple as
> > building some data structure that sits in memory somewhere; Apache is
> > currently a multi-process server, and a BYE or CANCEL may not get
> > serviced by the same process that handled the INVITE. You can put it
> > in shared memory --- I understand Ralf Engelschall has put together a
> > library which tries to smooth over the portability problems --- but
> > then you have to worry a bit about locking strategy to protect the
> > indexes and handle multiparty calls right. And CANCEL handling is
> > potentially nastier; there's the question of how process A finds out
> > that the request it's working on has been asynchronously cancelled by
> > process B --- do you do asynch notification, or does something
> > periodically poll the shared state? It's not trivial. Note also that
> > a CGI-style extension mechanism would have to have some way of
> > plugging into this state to be any use at all).
> >
> > Third, and less importantly, the routing functions performed by SIP
> > forking proxies (which have to contact multiple downstream servers in
> > parallel if they want to do a decent job) don't correspond to anything
> > in HTTP. There are HTTP proxies which do similar things (e.g., asking
> > several partner caches, in parallel, if they have a copy of requested
> > content before hitting the origin server), but I don't believe they
> > use HTTP to do it.
> >
> > In short, SIP has some similarities to HTTP, but it seems to me that
> > there are enough significant differences that I don't think you could
> > make a useful SIP server simply by taking Apache and filing the
> > numbers off --- at least not if you wanted to implement any level of
> > SIP support beyond the rock-bottom bare minimum. A call center has to
> > do a lot of things that Apache simply doesn't do, and I'm not sure I
> > see a way around writing new code that does them.
> >
> > Whether Apache is a useful place to *start* is a different question;
> > there's a lot of useful utility code in there which doesn't have all
> > that much to do with HTTP in particular. It's largely a matter of
> > whether the benefit you get from the stuff you can use is worth the
> > price of putting up with the stuff you don't use (it can conceivably
> > get in the way). But I think you do have to write substantial new
> > code to get a call center that does enough to be any use; I don't see
> > it as a quick slam-dunk...
> >
> > rst
> >
>