The Fugue Counterpoint by Hans Fugal


An Heir to SER

SER (and OpenSER) is a SIP router. That is, it receives SIP messages and decides where to send them or how to reply to them, in order to connect the two endpoints of a SIP call. It doesn't do media, it doesn't do voicemail or IVR or PBX or any of these other things. It's focus is routing, and it does it well and fast, and can handle a whole boatload of traffic.

But SER is not perfect. In fact, I would classify SER as barely adequate. In my
opinion, a SIP router should be four things:

  • Robust
  • Powerful
  • Scalable
  • Easy to Administer

By robust I mean it doesn't crash, it's fault-tolerant, and it doesn't require 'reboots' (of the software, not the OS). I like to call this lack of reboot the "living" property, following Steve Yegge's post The Pinocchio Problem. SER is fairly robust, in that if you have a good dialplan and no flaky modules it doesn't crash often, and it's tolerant of rogue packets and other external problems. It is most definitely not living software though, and the constant restarting of the server during development and debugging is a serious problem.

By powerful I mean you can do whatever you need or want to do. You want to hook it up to your database for user authentication. You want to send yourself a Jabber message when Such and Such calls So and So. You want to do least-cost routing or some kind of convoluted load balancing that nobody has ever tried before. This is power. SER has this power, ultimately, through writing modules and using the exec module, it can be difficult (writing a C module), expensive (spawning a new process for every message!), or both. SER is severly limited by its scripting language which has no concept of variables (except storing stuff in an RDBMS with AVPs) and almost no string processing abilities.

By scalable I don't mean speed (though speed can't hurt), but throughput. One
SER server can handle on the order of 6000 SIP messages per second. (Your
mileage may vary, depending on what you're doing and how you do it.) This is
where SER really shines. You might even say it's SER's raison d'être. It's also
important to be able to distribute load across multiple servers. You can do

with SER also.

By easy to administer I mean that a normal human being should be able to configure the daemon, write the routing scripts, and debug the routing scripts. Given, the person doing the routing scripts will need to have a solid understanding of SIP. But with SER, you have to practically be a SIP guru in order to set up even a basic route script. The scripting syntax is simple enough, but as mentioned above the limitations make doing anything nontrivial a real acrobatic programming trick. Don't even get me started on SER route script debugging. I'll just say it involves ngrep and either very terse and unhelpful logs, or very verbose and unhelpful logs.

Ok, so we see how SER measures up to my ideal. What can be done? Can the SER people step up to the plate and bridge the gap? Anything is possible, but I'm not holding my breath. Why not? Because of technical and architectural reasons, let alone community reasons. Technical because SER is written in C, and C makes things hard, and when things are hard niceties like living software often don't happen. Architectural because SER is locked into their scripting language and the design decisions that go along with that. They'd have to break compatibility (or walk on eggshells) to fix that. Even if they surprise us in these areas, there's still the difficulty of writing modules and extensions in C.

No, we can't expect the SER people to make this leap for us. They might, and
that would be nice, but let's not count on it. So where does that leave us? A
SER heir could be written with these four aspects in mind. I think it could be
done and done well if the right tools are chosen. Although I'm not 100% sure
yet, I think the most important tool will be Erlang.
Erlang almost solves the robust and scalable aspects from the very start.
Erlang makes living software almost by default. Erlang was designed by and for
the telephony industry. Erlang has good performance. The only part I'm not sure
about yet (because I'm not familiar enough with Erlang), is whether it will be
easy or hard to do routing scripts. Obviously, I think, you wouldn't ask
sysadmins to write them in Erlang. It's a language with a different paradigm
and that would be a serious barrier to entry. However, it would be nice to
allow scripting to be done in Erlang for those with that skill. I don't know
whether it will be hard to make a sensible DSL in Erlang or not. Based on my experience with
ejabberd the daemon running/interaction might
need some TLC, but I'm confident that can be accomplished with a few good shell

Will I write it? Not while you're looking. But I do want to learn Erlang and I
do like to do real programs when learning a language. So don't be surprised if
an infant heir to the throne of SER comes out of left field some day.

In the meantime, please enjoy Erlang: The Movie.

Comments (2) Trackbacks (0)
  1. Looks like you won’t have to write it:

    I have no idea how good it is, but looking at it might help you decide if you think Erlang is the way to go. Perhaps you could help out with it, or perhaps it will send you in another direction.

  2. yxa looks pretty decent. Not quite an asterisk replacement but maybe someday…

    It does seem odd that erlang does not have a full fledged PBX software yet. What’s an open telephony platform without good VOIP support?

Leave a comment

No trackbacks yet.