Network Shakeup – Cisco & Vonage VoIP

Posted: November 18th, 2010 | Author: | Filed under: computing | Tags: , | No Comments »

As a Vonage user of many years we’ve always had issues with call quality and heavy network usage. I’ve tried various QoS solutions including several linux firmwares for the WRT54G, a Hawking “auto qos” device and a Netgear managed switch. Last year I got fed up with hack solutions and invested in a Cisco 871-SEC-K9. At about $500 with the Advanced IP Services feature set it was the most cost effective router I found in the Cisco lineup with a solid set of QoS capabilities.

Unfortunately after it arrived I realized just how rusty I am with the Cisco CLI and the SDM gui available at the time was horrible so after getting the thing configured for routing duties it has sat neglected. Now some issues in the past week with our DSL line (Qwest has oversold capacity for our CO -- surprise) caused the voip quality to go to crap during some business calls so it’s become time to put this to bed.

First thing I need to mention is that getting up to speed on Cisco’s various approaches to QoS is a pain in the ass and I hope to purge this useless knowledge from my head with a few beers this weekend. I started by trying the easy route of setting “auto qos voip” on the external interface but it didn’t do a thing for call quality. Next I installed the updated CCP 2.3 gui tool, which is a vast improvement over SDM, but it still pains me to fire up Windows XP (under Virtualbox) to administer my router (really Cisco?? It’s already written in Java and you can’t make a *nix version? Sad). Unfortunately trying various configs with the CCP QoS wizard didn’t get me any closer.

My setup includes 3 Vonage voip lines running on two Moto VT1000v ATAs. The ATAs are set to static IPs and directly cabled to FE2 & 3 on the Cisco router running IOS C870-ADVIPSERVICESK9-M, Version 12.4(24)T1, RELEASE SOFTWARE (fc3).

Digging deeper into the ATA traffic with Wireshark I found:
a) the VT1000v ATA does not mark any packets with DSCP tags so using the Cisco “trust” options are out unless I want to run the ATA packets through another device for tagging before hitting the router

b) Vonage offers 3 call quality settings through their “Bandwidth Saver” feature. Each of these setting uses the following payload codec:
30kbps = G.729
50kbps = G.721
90kbps = G.711

c) the Vonage voip call Signaling (unit registration, call setup/teardown) happens between the ATA’s UDP port 5061 (sip-tls) and remote UDP port 10000 (ndmp)

d) the Vonage voip RTP call data happens between the ATA’s UDP ports 10050-10061 and various remote UDP ports (14K, 16K, etc)

After much trial and error it became clear that the CCP wizard’s configs weren’t working because they either rely on trusted DSCP markings (see item “a” above) or on NBAR, and the built-in NBAR protocol maps for the 871 don’t recognize any of the ports the ATAs are using as RTP or SIP traffic. I then setup shaping (not policing) using the CCP wizard and modified the CCP-Voice-1 class it created to add a custom port-map for UDP ports 10050-10061. This helped considerably. After more tinkering I found the most bulletproof solution has been to add an extended Access Rule under the CCP-Voice-1 class that matches all ip traffic originating from the IPs of my ATAs:

ip access-list extended VONAGE-ATAs
remark All IP Traffic from 192.168.0.5/192.168.0.6
remark CCP_ACL Category=256
remark Src Host 192.168.0.5
permit ip host 192.168.0.5 any
remark Src Host 192.168.0.6
permit ip host 192.168.0.6 any

This ACL approach is a little bit of a hack as it classifies ALL traffic coming out of the ATA as voice payload (including the sip-tls which is technically signaling) and puts it all into the Low Latency Queue for priority processing, but.. IT WORKS so I’m not going to be picky. So far I’ve stress tested this config by running 2 voip calls concurrently with youtube, ssh sessions, multiple bittorrent downloads and refreshing a dozen firefox tabs all at once while maintaining nearly perfect call quality. Note -- this isn’t scalable or foolproof for larger networks with untrusted users, and I’m sure some IOS gurus will have many better ways to do this, but I’m hoping this will save some other poor schmuck the hours of googling, cisco whitepapers and failed attempts that I enjoyed just to make sure I can be heard clearly when I order a pizza.

REFERENCES/CREDIT:
Another blog that made for some interesting reading on the Cisco/Vonage subject: http://blog.lemieuxnc.net/

CISCO QOS (in case you’re reallllly bored):
http://docwiki.cisco.com/wiki/Quality_of_Service_Networking
http://www.cisco.com/en/US/products/ps6558/products_ios_technology_home.html

Enjoy.



Leave a Reply