Maeglin (maeglin73) wrote,

  • Mood:

Vonage and traffic shaping

One of the disclaimers that Vonage makes with the non-router phone adapters is that they can't guarantee that the adapter will have the bandwidth it needs if a call is connected while you're making heavy use of your internet connection, in which case the audio could be quite shitty. This isn't a problem, though, if your router lets you adjust quality of service for it... kind of like mine.

My router is home-brewed, a single-board computer running an embedded form of Linux, and it works rather well. I don't want to replace it, though, because it's very customized for my setup, which is a bit complex for a home network. The problem then becomes learning how to do traffic shaping in Linux and how I want to apply it to my needs.

As it turns out, what I need isn't exactly traffic shaping in the strictest sense, but more the ability to tweak priority depending on where the packet is coming from on the home net. By default, Linux has a 3-level priority system that's based on the type of service specified in the IP header of a packet. What I needed to do was push traffic coming from the phone adapter to the top priority level, preferrably without mucking with the packet itself. With the kernel recompiled to be able to support traffic shaping, this turned out to be pretty easy. First, there's this:

tc qdisc add dev eth0 root handle 1: prio bands 4 priomap 2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2
tc qdisc add dev eth0 parent 1:1 handle 10: pfifo limit 128
tc qdisc add dev eth0 parent 1:2 handle 20: sfq perturb 10
tc qdisc add dev eth0 parent 1:3 handle 30: sfq perturb 10
tc qdisc add dev eth0 parent 1:4 handle 40: sfq perturb 10

That set of commands basically replicates the 3-level priority system, but adds a 4th level above the others and makes most of the packet queuing fairer to the different devices on the network. I made that 4th level a straight FIFO queue instead of using "fair queuing", as for now the Vonage adapter will be the only thing occupying it and it seems like it would be slightly more efficient that way.

Once the packet queues are set up, there needs to be a way to direct packets from the Vonage adapter to that top priority level, and bypass the other traffic leaving the house. That's where this comes in:

iptables -t mangle -N qos_mangle
iptables -t mangle -A POSTROUTING -j qos_mangle -o eth0
iptables -t mangle -A qos_mangle -s $VOIP_IP -j CLASSIFY --set-class 1:1

Granted, I could have gotten away without splitting off a different chain, but I did it this way to allow for working with packet classifying rules later without touching the rest of the iptables rules.

I didn't do true traffic shaping, as far as limiting traffic flow or anything, because I didn't want or need to do any real subdividing of what bandwidth I have. What I did want is full use of my internet connection but, when a call or fax is connected, the Vonage adapter immediately gets first dibs on what upstream bandwidth I have while allowing other things to use it. This setup pulls that off nicely.

Now, if Vonage and AT&T would simply stop putzing around and coming up with excuses to avoid transferring my old number to the new account, and just do it. I received an email yesterday stating that the distinctive ring feature that I had with AT&T was blocking the transfer, when I had already had that removed a week before due to a similar email. Someone's left and right hands need to start talking...
  • Post a new comment


    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.