The Fugue

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 this 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 scripts.

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.

Last night's presentation on OpenSER and MediaProxy went well, I think. We talked a lot about SIP and NAT, and looked at some sample configurations. The question came up about why or when one should want to deal with SER, and my answer is either when you need the scalability of SER, or when you want to use MediaProxy. There are other reasons why you might want to user SER, but IMHO MediaProxy is the first and most important reason to use SER. Unless you like troubleshooting NAT problems...

The slides and sample files are at http://hans.fugal.net/utaug. There are hyperlinks in the slides, but I couldn't figure out how to get them to stand out, so watch that mouse cursor. The sample openser.cfg has not been tested, but was pruned from a working config. If you see a problem with it let me know and I'll fix it.

If you want to prefix the area code for 7-digit numbers with Asterisk, it usually looks like something like this:

ext => _NXXXXXX,1,goto(505${EXTEN},1)

But if you need to server all area codes dynamically, you can do something like this:

ext => _NXXXXXX,1,goto(${CALLERID(number):0:3}${EXTEN},1)

This assumes caller id is set, and that your callers are using standard PSTN-like DIDs.

If you ever see strange sdp content like the following:

...
c=IN IP4 68.142.145.14568.142.145.145
...
m=audio 3501835018 RTP/AVP 0 8 3 98 97 101
...

That is, the IP address and port are repeated back to back (which really throws off the far end), and you are using openser and mediaproxy, then you are probably calling use_media_proxy twice in your ser routing. Apparently, this is a bad idea.

X-Lite and Twinkle don't have a way to set ToS. So let's get iptables to do it:

iptables -A POSTROUTING -t mangle -p udp -m udp --sport 8000:8009 \
    -j DSCP --set-dscp 0x2e

That sets the DSCP for UDP packets with a source port of 8000-8009 to 0x2e, which is the Expedited Forwarding PHB. You'll need to pick a range that works for you. Both X-Lite and Twinkle use 8000 as a default, so that's what this rule says.

So I learned this morning that ToS is old-school. According to RFC 2474 we now have the Differentiated Services Field. I came to this realization as I was looking for the ToS bits in Ethereal, which decodes that octet as the Differentiated Services Code Point (DSCP). I found this great article on Precedence and DSCP which explains both ToS and the newer DS Field very well. Go ahead, we'll wait for you to read it.

RFC 2598 defines the Expedited Forwarding PHB, which is what "most" VOIP implementations use, supposedly. The DSCP for Expedited Forwarding is 0x2e. However, the whole octet includes the two unused bits, so left shift twice and you get 0xb8. This is the magic number to use in Asterisk:

; sip.conf and/or iax.conf
[general]
tos=0xb8 ; Expedited Forwarding DSCP

You'll need to restart Asterisk in order for this to take effect; reload is not sufficient.

The Expedited Forwarding DSCP is backwards-compatible with the old ToS field. It breaks down to precedence 5 and the low delay and throughput fields set.

I was rather surprised and disappointed to learn neither that X-Lite, which I use on my iBook, nor Twinkle, which I use in Linux, seem to have any way to set the ToS field, and just use 0x0. If you know how to set ToS on either of those programs I'd sure like to hear it.

I ran across the Gizmo Project today. It warms my heart. Now that I have cultivated your curiousity, Gizmo is what Skype should have been. In other words, Gizmo is Skype with standard open protocols. (SIP, to be specific)

It was easy to set up Asterisk, and I have bidirectional Asterisk-to-Gizmo communications. The one caveat is that I can't seem to call my Asterisk box from my Asterisk box via Gizmo. I'm not sure why that is, but aside from testing that wouldn't be all that useful so I'm ok with it.

My only complaint is some clown stole the username I prefer. So, on Gizmo I guess I go by hans_fugal (17476265435). Give me a call! Or, at least, give my monkeys a call.

When we moved to Las Cruces I ditched Qwest for telephone service, and went with standalone DSL, Asterisk, and NuFone for my phone service. The other day someone was downloading stuff from my website, using all my upload bandwidth, and my wife was trying to talk to someone on the phone. Although she could hear them just fine, they couldn't hear a thing she said because she was breaking up so bad. Thus began my quest for QoS.

Actually, I had downloaded and set up a script to do QoS that I got from the wiki, and I forgot to reconfigure it to my current bandwidth. So ironically, undoing what that script did helped just because it let me use all of my bandwidth. Then I tried to adapt the script to my current situation, and found that it didn't really work. So I went to the lartc and read up on Queueing Disciplines and tried to make my own VOIP QoS script. I spent hours on this, and although I gained a pretty good understanding of it all I never did get a script that worked well. It kind of worked, but not well enough.

This morning, I stumbled across the Wonder Shaper and decided to give it a try. If it didn't work well for VOIP at least I'd have a starting point for modifications. The results were truly wonderful. I was able to carry on a normal conversation with my mother while uploading an ISO with scp to my ISP.

The added bonus of having really great performance for other interactive applications such as ssh has really sold me on the Wonder Shaper. Even if you don't do VOIP, you should give it a try. If you have a recent kernel it's so easy to use, and has such great returns, that you would be foolish not to.

NuFone is my VOIP provider of choice, but I had a devil of a time being able to call out from my Sipura SPA-1001, through Asterisk, to NuFone. It turns out the problem was Caller ID. When I set my sipura's extension to 42 instead of sipura, I was able to dial out, but the CID said simply 42. Well that is kind of cool, and demonstrates that the reason NuFone's Asterisk (or PSTN connection) was rejecting my call is that I had invalid Caller ID for the number ("sipura"), but I would like to be a good phone system citizen. Junction Networks, of whom I had never before heard until google matched us up, has the answer. So I added that SetCIDNum call and things are working great.