Some time ago my employer asked if I would like to participate in a pilot of AT&T CallVantage from my office. This service is a competitive offering to Vonage’s VOIP service. With CallVantage, you get to pick a phone number in an area code of your preference, they send you a telephone adapter in the mail and off you go. The telephone adapter connects over the Internet to the phone company, bypassing the local carrier’s wires. Within the week I had the telephone adapter. Getting the CallVantage service up and running was no trouble at all. There is a web portal to customize the service, like recording voice mail greetings and setting up a do-not-disturb schedule. You can review call history through the portal and place numbers into a phone book. You can also initiate calls from the web site. The service will ring your phone, wait for you to answer and then ring the other party’s phone.The telephone adapter I received in the mail was manufactured by D-Link. It is actually a combination telephone adapter and firewall, if you choose to use it that way. The network here was already equipped with a firewall, so I decided to use up one of my static IP addresses and place the adapter outside the firewall. The first time the adapter connected over the Internet with AT&T, it spent a few minutes downloading new code and rebooted a couple of times, and when it was ready for service the phone connected to it rang once. The status lights on the adapter showed all green.I had been using CallVantage for a few days and everything was working great until … one day I was on a VOIP call and hosting a screen sharing session with some of my co-workers around the country. I was doing a code review, paging through an editor, showing some diagrams and talking about the design. From the network point-of-view there was a large amount of constant outbound traffic, some consisting of the screen data and some consisting of my VOIP data. Every couple of minutes someone would ask me to repeat something I said, because my voice had broken up for a brief moment. They described it as sounding similar to a cell phone breaking up, and other times they said I just went to dead air for a few seconds. I knew exactly what was happening - there was competition between VOIP and non-VOIP traffic and there was no control over which would leave my network first at any given time. It was time to seriously consider a solution to prioritize network traffic.The D-Link adapter has the ability to prioritize traffic if you use it as a pass-through device. You can configure the D-Link as a NAT router or a bridge, placing it between your ISP’s router and your private network or existing firewall. The D-Link adapter will give priority to packets for VOIP and slow down or drop packets from your network devices to accomplish a poor man’s QoS. I call it a poor man’s approach because I don’t actually think D-Link put a lot of thought and effort into it. I was always suspicious that the telephone adapter had a 10 Mbit network port on the WAN side. They put 100 Mbit ports on the LAN side. The WAN port speed was just a little too close to the upper bandwidth of the Internet connection here. There are days we get well over 10 Mbit on the inbound side of our connection, so this just seemed like a bad idea. In fact, it was a bad idea after I tried it. There was no improvement in the number of voice drop-outs. The next strategy was to move the D-Link adapter behind the firewall, reconfigure it for DHCP and use more robust approach for traffic shaping and prioritization. The D-Link adapter would only be the source and destination for VOIP traffic. No other traffic would move through it. The solution I eventually adopted is open source. I will talk more on the actual implementation in a future post.The first thing to understand about VOIP audio quality is that you can only prioritize and shape outbound traffic. This is traffic leaving your network heading for your VOIP provider. I mean, you can prioritize inbound traffic on the receiving side, but by the time this happens, the traffic has already traversed your connection and has used up some portion of bandwidth. Prioritizing inbound traffic on the receiving side will rarely improve the audio quality you hear. There are reasons beyond VOIP to prioritize and shape inbound traffic on the receiving side, like slowing down the person downloading ISO files all day on Friday. A good example from the real world is highway traffic control. Traffic signals are placed at the on-ramps to the highway, not the off-ramps. Your Internet connection is like a point-to-point highway between your ISP and your site. If you want to prioritize inbound traffic for the purposes of VOIP audio quality, talk to your ISP (the on-ramp for the traffic coming to you) so they prioritize packets before sending them to your place. What about packets traveling between the VOIP provider and your ISP? Anything can happen there and it’s out of your control. Usually these interconnections are so fast, it’s not a significant factor in quality.The next bit of knowledge about prioritizing network traffic is to have only one device at your end making the determination about which packets go out first. This means you don’t want to flood your DSL or cable router with packets, because it’s queuing strategy might undo the order of packets you send to it. The only way to be sure the packet order is maintained is to reduce your outbound bandwidth slightly to make sure only one device on your end is queuing packets in the order you specify. You want to send packets just a little slower than your connection’s upper limit, to keep all the other device queues empty. If your ISP router gets a packet and it’s queue is empty, it can send that packet right out.We will use my office setup as an example. The outbound connection speed at my office is about 1.5 Mbit. We specify to our traffic shaping device to limit outbound speeds to about 1.4 Mbit. If you don’t do some amount of reduction and just blast packets to your ISP router at full speed, it may reorder them based on it’s internal rules, or it may just start dropping packets because the manufacturer designed it with a shallow queue. Because these are usually closed, proprietary devices, you just have to accept that you don’t know what it will do as packets queue up. For our case we have the traffic shaping device reduce our outbound speed by about 6.5%. You might need more or less of a reduction, and experimentation and tuning is a required step. Re-tuning should be done once or twice a year.Next, you need a way to identify traffic from specific devices on your network and determine what the classes of priority should be. In our network we have three classes of priority for outbound traffic. The highest priority traffic comes from the VOIP devices. Medium priority traffic comes from workstations. Lowest priority traffic comes from servers. Remember these priorities are only for traffic leaving the network for the Internet. Our internal network is 100 Mbit wired or 54 Mbit wireless, so workstations connecting to the local SMTP server don’t feel any of this prioritization. The reason servers are at the lowest priority is because there are a few non-essential web sites hosted here and an SMTP server that relays outbound mail. We really don’t care if it takes 5 seconds or 20 seconds to relay an outbound email, because it is all done as background work. The VOIP devices and servers are given internal, static addresses by the DHCP server, so we can determine a packet’s priority by source IP address.The device or software you choose to prioritize your traffic may have constraints on how traffic can be identified. For example, it may only be able to identify traffic based on source and destination IP port numbers, or protocol. A simple hardware device may prioritize traffic based on physical network port connections. I have a small consumer firewall that has five 100 Mbit LAN ports, and each port can be assigned a low, medium, or high priority. Do your research and work out your strategy before committing to a solution.I decided on an open source solution called m0n0wall and a basic Dell PC with multiple network adapters. I stripped out the hard disk and floppy disk, kept the CD-ROM, added an IDE compact flash reader and a couple of extra fans just in case. I will go into details about my m0n0wall firewall and shaper settings in the next post.