« Why I'm going to miss California... | Main | In the doghouse: iamidentity.com imdentity.com »

Why SIP sucks and IAX rocks - a rant on latency and the media path

As many of you know, I tend to tinker with technologies... not to build a business around them, but to add them to my bag-o-tricks, or just for the shear fun of doing something that you can't get as easily, cheaply, or, if possible, at all on the open market.

For the last several years, I've been playing around with VoIP. Hardware, software, various ins-and-outs. And, while there are dozens of blog posts I could write about what I've learned, today I'm going to cover one of the issues I've spent the most time tinkering with, because its one of the issues that every VoIP company has to deal with to satisfy their customers.

Several things go into the perceived quality of a telephone call - fidelity, echo, reliability.... and transmit delay. Transmit delay is tricky - up to a certain point, delay doesn't greatly affect the happiness of the callers, but, after a certain point (around 100ms of total delay, a rough amount of latency from many kinds of technologies that start to get annoying), the delay on a call makes conversation harder. So, as a tinkerer with less-than-top-notch equipment and connectivity, I've spent quite a bit of time over the last few years trying to remove latency from the systems I use for VoIP.

This is tricky, of course. You can look up that your provider is in New York, say, and that your colocated box where you run your VoIP is in Pennsylvania. In theory, that should be close enough that the extra latency isn't very noticable. That is, until you discover there are many different ways the Internet might route between New York and Pennsylvania.

One of my best tricks, as the title of this blog implies, is to use a better tool for the VoIP, and thus get out of the way. I use the open-source Asterisk for my VoIP software, which supports both the standards-based SIP VoIP protocol, and its own, proprietary-but-open IAX protocol. SIP has the benefit of being implemented in fairly widely available hardware... IAX is, to a few exceptions, not supported in hardware. But, IAX has a few really killer features: it has a guaranteed-success transfer handoff, and a small enough base of supported devices that interoperability is rarely a problem. If you want to remove latency from your calls with IAX, you just have to teach your system to hand off the transfer of the media path to the two endpoints - no more routing through Pennsylvania even if both the caller and the callee are on the west coast.

SIP can do this, but, it has a much more complicated media path, and a much bigger pool of implementations. With SIP, you might try to do the same trick where you hand off the media path to be direct between the source and destination, but only find out it didn't work when you get a support call complaining that there was no audio on the call. Or, you have to use elaborate discovery tools on your network to figure out which devices are behind a firewall, and which ones aren't, and then check those results before trying to hand off a call.

In my own setup, I have tags I apply to the incoming channels on my Asterisk system. If a call is IAX, I deliberately try to complete it using IAX, and get my system out of the path. Otherwise, I have SIP set up to hand off where it can, but, in practice, I have to leave the configurations a little bit conservative to avoid no-sound issues from cropping up periodically: my callers pay with extra delay.

Bigger corps have different approaches (and, with few exceptions, all have to use SIP). I've read that Vonage has regional centers, and your device is setup to detect the closest one and use that. Then, presumably, they have internal rules to minimize the total network distance your call crosses. Too hard for someone small-time like myself, but probably very effective. GizmoProject seems to push everything through their SIP proxy. Even if you call from one phone on your local network to another. I believe they can still fix the media channel some of the time, though I'm pretty sure its beyond the reach of the Asterisk SIP implementation.

It's hard to get right... especially because some of the ways you can transfer a call effectively put you outside of the call - if you need to bill on that call, this just isn't an option. Here's hoping the day comes soon when providers just charge for listing and support: when we stop paying per minute, we can stop worrying about auditing every second of every call, and instead focus on delivering the best sound experience. Skype has got this right, and cheers to them for their routinely very high call quality.... but, they're not using SIP or IAX, so there's not much that can be learned from them directly.

Unfortunately, my favorite (and, at this point, the only one I've never had a serious gripe with the service of) VoIP provider started out as an IAX-only shop (http://iax.cc/), but got bought-up to a bigger firm that has now started to treat their IAX features as deprecated (http://vitelity.com/). I hope I'm small-time enough that they let me keep the IAX side active - I sure do appreciate the better call quality that results. Further unfortunately, I'm moving across the country soon, so I'm going to have to reconsider what all of my most-prefered choices are for colocation and VoIP routing. Good for my family, though, who is centered nearer where I'll be living, and are likely to end up with better call quality all around. sigh

Ok, . If anyone reading this is interested in my tricks to detect source channel type and try to send outgoing calls to an appropriately matched destination channel type, please chime in on the comments. It's all done with Asterisk macros, and it isn't quite a drop-in fix, unfortunately.

Technorati Tags: , , , ,


I'm sorry but IAX isn't better than SIP... You're just trading one set of problems for another.


Post a comment

Verification (needed to reduce spam):