Over the past month or so, I've been trying to put together a new platform to sit at the center of a SIP-based VoIP network. As VoIP starts to take off, I'm unsatisfied with the current solutions in the open-source community for providing PBX-like services for IP phones, so I'm trying to figure out what a "good" architecture would look like. Currently, we have SIP Express Router, the most popular SIP proxy/registrar in the open-source world, the VOCAL service platform, which everybody hates, and Asterisk, the PBX-in-a-box that supports all the bells and whistles you could ever need.

SER is a great product, featuring unwavering RFC compliance, strict attention to optimisation, and good old-fashioned German engineering. It has some weaknesses, such as the bizarre, half-baked interpreted language used for processing incoming transactions, but overall I've been quite pleased with it. Free World Dialup handles almost a hundred thousand calls daily through a single server running SER.

Asterisk is a PBX-like system, started in 1999 before VoIP became popular. Its architecture strongly resembles traditional PBX systems, with all signalling and audio from dumb user terminals (phones) running into a big black box that performs all the processing. While this is fine if you're still using POTS or POTS-like phones, but it seems silly for SIP. If two SIP UAs are able to send audio directly between each other, why insist that the media still be sent through the server? I have other issues with Asterisk as well, such as the lack of scalability, but this Centrex-like architecture bothers me the most.

The problem is that no other free VoIP product offers the features that Asterisk does. While SER provides an excellent SIP signalling and call control platform, you cannot find a powerful voicemail system, IVR capabilities, or PSTN interfacing anywhere in the open-source world besides Asterisk. This is why I'm working on my own.

The goal of the new architecture is to provide an open-source IP-based platform that can accept and redirect calls with SIP, and provide Interactive Voice Response capability on an RTP session. Currently the system is divided into components that handle SIP interfacing, RTP streaming, and call processing using an embedded Perl interpreter. All the components are tied together using D-Bus, which offers both remote procedure calls and asynchronous signalling in a network-transparent way. Splitting the components this way allows the system to be scalable across a server cluster, allowing, say, two SIP frontends to control RTP streams from twenty backend streaming servers.

I have most of the components working now, but it will take some time to figure out the right way to provide the Perl interface for call handling. More on this later.