> -----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
>