Tech

SIP via UDP vs. TCP

One of the things I enjoy doing is taking complex subjects and explaining them in such a way that nearly any interested party can understand. I spent nearly an hour last night explaining the Big Bang theory to my 12 year-old son. I think, eventually, we got there. The task before me today is to explain why SIP, the protocol of VoIP, is best left as a UDP service as opposed to a TCP service. This is nearly as formidable as explaining the Big Bang to a sixth grader.

First, we need to build some vocabulary. TCP and UDP are connection protocols in use today for data traversing the Internet. Data travels across the Internet in packets. Think of them like letters. Like letters, they have an envelope with a to/from address on them. TCP and UDP are just two types of envelopes. The IP addresses are the to/from addresses. They both carry data and both use IP addresses, but just the outside envelope is different. Think US mail vs. FedEx. The address on the envelope is the IP address for where the packet came from (source address) and where it's going (destination address). TCP is so prevalent on the Internet that it's typically combined with IP, and written as TCP/IP.

TCP would be the 'FedEX' part of the analogy from above. Whenever two servers 'speak' TCP, they set up a formal connection. Every time a packet is sent from one side, the other side sends a packet back acknowledging the packet's arrival. If no acknowledgment packet arrives after a certain amount of time, or if the acknowledgment states that there was a problem, then the packet is re-sent. It can sometimes take a few seconds for a packet to be fully successfully transmitted. TCP is optimized for accurate delivery, not timeliness, and is the protocol for WWW sites and e-mail among others.

UDP is the opposite. It is a protocol optimized for getting packets there in a timely fashion with little overhead, but with just as little accountability. It's more like throwing a bottle in the ocean. Ok, a very rapidly moving ocean, but you get the point. With UDP, you just address the envelope and drop it on the network. There's no handshake, and no setup. Just the data packets. UDP is meant for real-time conversations where you are more interested in keeping the stream going then making sure that you have every single packet.

Right this very moment, Junction Networks has over 3,500 devices attempting to connect with Junction Networks. These devices are everything from individual SIP phones, to SIP devices, to other PBXs. Most of the connection attempts are simple SIP registrations. A SIP registration is when a SIP device tells the server, in this case Junction Networks, that it's available for calls and what its IP address is. This communication happens anywhere from every minute to every hour, for EVERY device. That's a LOT of packets. If these were TCP packets, each time a phone wanted to tell us that it's available, it would have to go through the whole TCP connection setup. That would be a HUGE amount of overhead for a VoIP carrier. In a LAN environment, it would be manageable, but for thousands of individual devices and hundreds of them attempting to register EVERY SECOND, a TCP connection would grind servers to a halt.

Next, once the phones are registered and a call is set up, it's really UDP's time to shine. A phone conversation is a stream of packets meant to be created, sent and received in real time. A lag, any lag, would mean a degradation in the quality of the phone call. Imagine hearing something on the call one to two seconds after the person on the other end says it. You're replying to what they're saying, but they've already moved on. It would be totally disconcerting. And, since it's real-time, there's no catching up. Better to drop a packet and have a millisecond of silence than seconds of lag.

In short, VoIP traffic is best left as UDP traffic for both server load and call quality reasons.

This post gives me the background I need to answer why BitTorrent will NOT bring down the Internet and VoIP if/when they switch to UDP, contrary to
this article. Taking on explaining BitTorrent is going to be much harder than the Big Bang.

There is a great post over at Bradley Holt's blog about using Google Talk's XMPP service in conjunction with SIP from Junction Network's OnSIP Hosted PBX.

Here is my take on XMPP and SIP. XMPP is an XML-based open standard with, among other things, built-in protocols for subscribe and publish, e.g. subscribe to someone's presence information and publish your own presence. SIP, another open standard, is good for a bunch of rapid-fire, short messages back and forth. It's kind of like DNS on steroids. SIP is currently (and for the foreseeable future) the de facto standard for VOIP.

Internally we have been running an XMPP server for presence and instant messaging for a few months now at our domain: junctionnetworks.com. Additionally, using open XMPP servers like Google Talk, I can see the presence of my XMPP 'buddies' at other domains as well. If you are connected to an XMPP server, you can chat with me at mike-at-junctionnetworks.com. That address is my e-mail, SIP and XMPP address. That's what I call real unified communications. We are making these XMPP services available to all of our customers at either their current onsip.com domain or even (eventually) at their own domain. (This is something we offer today for SIP calling.)

XMPP and SIP are two great tastes that taste great together. We have written an SIP to XMPP gateway which allows us to gateway SIP information to an XMPP server. Once you have that, you can then receive instant messages and screen pops on inbound calls. Our current project is to wrap all of this up in an easy to use web-based interface for the end user. One interface will handle your presence, chats and phone calls. We'll be writing more about that in the coming weeks. The point is that we are excited to see our customers looking to use the same technology and standards that we are building toward. As always, we will keep with our corporate themes of no walled gardens, open source and open standards.

This morning I saw this excellent blog post by Garrett Smith which points out a few tips on making the transition to VoIP easier for SMB.

His main point is bandwidth, bandwidth, bandwidth. Although it seems obvious, adequate bandwidth is an absolute requirement for VoIP. VoIP is very sensitive to packet loss and latency, which results in quality of service issues (i.e., echo, dropped calls, etc.). Do all of your employees stream music while checking their e-mail and utilizing web applications? That's going to affect the quality of your phone calls if you don't have the bandwidth to be able to handle it.

Fortunately, in modern computing, bandwidth is one of the cheaper things that you can buy, so resolving this problem is potentially pretty easy. (Who remembers paying $1,500+/month for a 1.5 MB T1 a few years back? Good riddance to that!) But Smith's advice of doing a network analysis before buying into VoIP is super important - and easy to forget when you're excited about saving money and integrating your phone into your business life in a way that only IP telephony can do.

But it's not just the Internet bandwidth that matters - the speed of your LAN also counts. If you're using significantly older equipment, you may not have the throughput locally to handle additional traffic. If you have any equipment that is still 10baseT (and we've seen this), you probably already have speed issues with your existing data connections. Adding VoIP will be a disaster.

But there's good news here too - if you've built or upgraded your network in the last 5-8 years, it's pretty unlikely that that you're going to run into that problem. If you've signed your contract with your ISP within the last 5 years or so, you probably also have adequate bandwidth. But it certainly never hurts to get some numbers into your hand before you make the leap and add your telephony traffic to your data connection.

VoIP is excellent in many regards - but like any technology, it must be implemented correctly.

When we heard about an Open Source router at Junction Networks, we were naturally very intrigued. We love the Open Source movement and have invested heavily in it, so being able to recommend an open source router would have made us very happy.

Alas, we cannot. At least not an out-of-the-box Netgear WRG614L, which is the router touted on myopenrouter.com. We have a historic problem with Netgear routers in that they implement an ALG for SIP that cannot be turned off. (What's an ALG? Read about it here.) Unfortunately, out of the box, the WRG614L continues to have this problem, so it will not work successfully with the OnSIP Hosted PBX. We chose to test the Netgear of all the open source routers because we'd hope this had been fixed.

However, being open source, it's entirely possible for someone to change the WRG614L so that the SIP ALG can be turned off. Have you done it? We'd love to hear about it.

I'm afraid this post has nothing at all to do with VoIP. However, like the rest of the world, Junction Networks is deep in the grip of iPhone mania.

Yesterday, the Engineering department had a physical engineering problem to solve. We ordered a white board to put up in our conference room. We needed to put the white board on the wall. And, of course, we're unapologetic geeks, which means we're chronically unprepared for dealing with such mundane real world challenges.

We didn't have a tape measure. Or a hammer. But we did have several willing bodies and two iPhones with the Dual Level program, which uses the tilt functionality of the iPhone to tell you if your iPhone is level. So we stuck the iPhones in the tray of the white board and lifted it up. We made marks on the wall. We got a screwdriver and pounded some nails into the wall with the blunt end. Our white board is now being frantically scribbled on, which is a much more comfortable endeavor when it's on the wall and not sitting on the floor.

O iPhone, you are a simply brilliant device. Your possibilities seem endless.

As for my personal use, the only thing that I haven't been able to find is a Tasks program that rivals the task management on Palm OS or an Outlook/Blackberry solution. I, along with lots of other netizens who have posted about their frustration, would just love an app that synced with Apple's Mail and Calendar Tasks. Recurrence is a big missing feature in the many task programs that are out there.

But it's hard to actually want to look at things in a To Do list when there are so many other things the iPhone can do. I've been reading books with Stanza, playing games that I haven't seen since childhood, updating the social networking sites I'm involved in (which I rarely logged into before, but now update almost daily since I can do it while waiting for my train), giggling at the portable LOLcats and using aSleep as a white noise generator and meditation aid. I've spent about $10 in the App Store since I started using it, which feels like a steal for all the extra functionality I've added. And this is all in a device that's also a MP3 player and a phone.

The sheer creativity of the apps in the App Store have been really inspiring - I certainly never thought I'd be using a phone as an accurate level. I can't wait to see what else people think up to turn my phone into the best Swiss Army knife I've ever owned.

Although Cisco makes a nice line of phones, we don't recommend them for our customers because Cisco does not plan to continue to support SIP on them. They will continue developing SIP support on their Linksys branded phones, which we've tested out and really like.

However, as a courtesy for customers who already have Cisco phones, we published a Knowledge Base article on how to get them set up and configured for our OnSIP Hosted PBX, which you can find here.

Note: We were wrong. Cisco will continue to develop SIP for their Cisco line of phones. However, the Linksys phones are easier to configure and manage, so we still recommend avoiding the Cisco line if you have not already purchased your phones.

If you have an Aastra 480i, you may have noticed the note in our Knowledge Base about a bug where the 480i stops sending or receiving audio on transfers across NATs to certain phones. With the currently available firmware, the 480i writes the Refer-To in the SIP REFER packet to the user@IPAddress, which works just fine on a LAN, because the IP address is always available. Once the Internet and a NAT is introduced, this fails, since the two phones are no longer on the same network. Certain phones from other vendors can compensate for the problem, but we found that Linksys and Grandstream phones do not. The Aastra 5xi series of phones do not have this problem.

We've been working with Aastra to get this bug resolved. (It must be said that they were very responsive once we reported it - the delay in testing it was entirely ours.) They've released a beta firmware update (1.4.3), which we tested. It resolves the problem nicely, so we'll be updating our Knowledge Base as soon as it becomes generally available, which should be in the next week or so.

Lately in the Junction Networks labs, we've been focusing on IP PBXes. In that spirit, we have an Edgebox network appliance and have been testing it out.

The Edgebox is much more than a PBX - it also includes the functionality of a firewall, router, print server, file server, mail server, DNS server, etc. It can do QoS and WiFi and NAC. It's likely that I'm leaving a few other things in there - our focus was mostly on the IP PBX. Everything is administered through an attractive web interface that is intuitive and easy to use.

The IP PBX is an Asterisk based system, though you might not know that as an Edgebox administrator unless you happened to be familiar with Asterisk first. I had the Edgebox set up and connected to our PSTN gateway service within minutes. (Knowledge base article here.) I assigned it a phone number via our OnSIP interface and dialed it. Dialing out was slightly more complex - I had to create a dialing plan and give the phone I was dialing from permission to use it. That still only took a minute.

So it's a great device for our PSTN Gateway service. But there is so much other functionality in the box that OnSIP customers might want to use it for its other servers, so we tested the OnSIP Hosted PBX service through it, using it for its router and firewall functionality. There were no problems there, either. It seems to be a very solid device that is ideal for the SMB market. It definitely gets our approval.

While a true story, the following contains what may very well be a bad idea...

I have an external 250 GB hard drive that, as of a few days ago, would not spin up. Upon power up, it would make an short buzzing sound following by, click, click, click, click, click and so on. I tried disconnecting and reconnected it a few dozen times with different cables, different ports, different power supply. No luck.

Finally, I decided to try freezing the drive by letting it sit on top of a large gel ice pack for 15 minutes. While still sitting on the ice pack, I powered it and it spun up on the first try! I then immediately began copying everything off the drive. The drive ran for about 3 hours while the ice pack slowly melted. Then it was back to click, click, click...

I got the idea from here:

http://www.macosxhints.com/article.php?story=2006110111270170

Lately, there's been a lot of buzz in the VoIP community about high-definition telephony. The first time we heard about it, we all raised our eyebrows since high-definition is a term that gets overused in technology. But we're open-minded geeks, so we tried it...and it's really, really cool. The audio has so little distortion compared to a traditional telephony call that it's slightly unnerving at first because the vocal clarity approaches stereo quality.

So what is it? High-definition telephony comes down to the G.722 codec. In pragmatic terms, the codec is responsible for the compression and decompression of the media stream (i.e., your voice) that comprises a VoIP phone call. One of the first things a SIP phone does when it talks to a SIP proxy is to negotiate which codecs both support so that when the media stream comes, it is compressed and decompressed at the same rate and overhead. G.722 is one of the most efficient codecs out there, so it does a very good job. Voila, high-definition.

(For more information on codecs, Voip-Info has a thorough list.)

The OnSIP Hosted PBX already has high-definition functionality for extension-to-extension dialing. Both parties will need a phone that supports G.722, such as the Polycom IP 560 or the SNOM 320. (Please note, the Grandstream 2000 has support for G.722, but it's problematic.)

But we won't stop there, of course - we're currently testing moving some of our other applications to high-definition. We'll announce their launch in this blog, so stay tuned!