I have a client that uses Mitel SME server for VoiP. The VoiP vendor insists that the VoiP sucks because I am not setting the VoiP traffic to high priority. After setting up HTB, the VoiP still sucks.

Can you guys look at my config and see if I am doing this correctly? Also, what is the best way to prioritize traffic bound for a particular destination IP address?

The remote office has a full T1, and a Fedora Core 3 (2.6.11 kernel) box acting as the firewall.

According to the vendor, "Teleworker uses ports 6801, 6802 for encrypted signaling, TFTP on ports 69 and 20001, and voice traffic on ports 20000 to 20999."

So, since all of this traffic starts from the VoiP phones, and the destination is a single IP address, I ran the HTB_init script (from sourceforge), and setup the config files to prioritize all traffic to a single IP as high priority.

I setup the following files in /etc/sysconfig/htb:
eth1
------
DEFAULT=30
R2Q=100

eth1-2.root
--------------
RATE=1400kbit
BURST=15K

eth1-2_10.voip
-------------------
PRIO=0
RATE=1400kbit
LEAF=sfq
RULE=64.60.67.51

eth1-2_30.bulk
-------------------
RATE=1Kbit
CEIL=768kbit
BURST=15k
LEAF=sfq

and here is the output from htb_init list and show commands:
htb_init.sh list
--------------------
### eth0: queueing disciplines

qdisc pfifo_fast 0: bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

### eth1: queueing disciplines

qdisc htb 1: r2q 100 default 30 direct_packets_stat 32633
qdisc sfq 2: parent 1:2 limit 128p quantum 1514b perturb 10sec

### eth1: traffic classes

class htb 1:2 root leaf 2: prio 0 rate 1400Kbit ceil 1400Kbit burst 15Kb cburst 1774b

### eth1: filtering rules

filter parent 1: protocol ip pref 100 u32
filter parent 1: protocol ip pref 100 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 100 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:2
match 403c4333/ffffffff at 16

### tun0: queueing disciplines

qdisc pfifo_fast 0: bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1


htb_init.sh stats
--------------------
### eth0: queueing disciplines

qdisc pfifo_fast 0: bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Sent 28422488 bytes 165959 pkts (dropped 0, overlimits 0 requeues 0)

### eth1: queueing disciplines

qdisc htb 1: r2q 100 default 30 direct_packets_stat 33756
Sent 11229933 bytes 131753 pkts (dropped 0, overlimits 0 requeues 0)
qdisc sfq 2: parent 1:2 limit 128p quantum 1514b perturb 10sec
Sent 7371418 bytes 97997 pkts (dropped 0, overlimits 0 requeues 0)

### eth1: traffic classes

class htb 1:2 root leaf 2: prio 0 rate 1400Kbit ceil 1400Kbit burst 15Kb cburst 1774b
Sent 7371492 bytes 97998 pkts (dropped 0, overlimits 0 requeues 0)
rate 8998bit 116pps
lended: 97998 borrowed: 0 giants: 0
tokens: 89457 ctokens: 9965


### eth1: filtering rules

filter parent 1: protocol ip pref 100 u32
filter parent 1: protocol ip pref 100 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 100 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:2 (rule hit 131715 success 97999)
match 403c4333/ffffffff at 16 (success 97999 )

### tun0: queueing disciplines

qdisc pfifo_fast 0: bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Sent 0 bytes 0 pkts (dropped 0, overlimits 0 requeues 0)

First remove burst options from the script. Burst works in scha way that it allows faster transmission for a short time (but later it should be slower, so the average is as it should). It's good for web browsing etc, but can kill VoIP.

I must say I don't understand all the parameters (I use rather limited set), so there may be something more. Try with (no) burst and see if it helps.

Implmenting VoIP over a frame relay based cloud AND expecting the QoS you are assigning to be maintained within the cloud is pointless. Remember, once the VoIP packet leaves your router onto the frame T1, it becomes "discard eligiable" within the frame cloud. In other words, the frame cloud routers/switches do not honer the QoS settings applied by your router. You might stand a chance of this working if you up the CIR on the T1 circuit, but its still a crap shoot. Plus, buying a full T1 CIR can get rather expensive.

If you are wanting to maintain QoS on VoIP traffic within the cloud, then implement an MPLS based cloud between all remote sites. MPLS based clouds will maintain your Qos settings within the cloud. Believe it or not, implementing an MPLS based cloud was actually cheaper for us. Plus its fully meshed. YMMV, but we saved 40% by going to MPLS versus straight frame relay (we have 23 remote sites).

Good Luck!