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