9.7. Voice QoS on Windows
Windows XP and 2003 can be used as routers to enforce Quality of Service on a VoIP network, though there are much better, and less expensive, ways to build a good QoS enforcement device. In one situation, though, Windows should be a QoS enforcement devicewhen it's used as an Internet gateway router with ISA services, a third-party firewall like CheckPoint Firewall-1, or a Microsoft Internet Connection Sharing feature. In this situation, you'll need to familiarize yourself with the Windows QoS Packet Scheduler.
9.7.1. QoS Packet Scheduler
The Internet Connection Sharing feature, which comes as a part of Windows XP, allows one computer to provide NAT/firewall services and gateway routing for a group of other computers on the same LAN. This way, these computers, which don't have a direct connection to the Internet, can still access Internet resources.
Using VoIP endpoints to place calls routed through the ICS gateway isn't really an enterprise-class solution, but it can be done. One might do it in a home office or hobbyist setting. The software element responsible for prioritization of packets passing through ICS, and through Windows in general, is called the QoS Packet Scheduler. Its job is to enforce the policy set forth in the computer's system policy profile, so that applications using Microsoft's QoS API can benefit from its QoS provisions. The Windows kernel, which can perform routing and packet filtering like a standalone router, uses this API to support 802.1p, RSVP, and other, non-telephony- related QoS standards.
9.7.2. Windows RSVP Service
Windows NT Server, Windows 2000 Server and Advanced Server, and Windows Server 2003 can use a service-based RSVP software agent. The RSVP Service allows the Windows server to become a policy enforcement point, either as a router or as a softPBX.
9.7.3. Project 9.2. Audit a Network's Capabilities Using pathping and traceroute
22.214.171.124 What you need for this project:
Though Linux is far better equipped to do VoIP network building and troubleshooting, Windows does have a nifty command-line tool that can be used to determine how well an IP route supports QoS measures. pathping , which ships with Windows 2000 and Windows XP, lets you see how well your Internet provideror your corporate networksupports 802.1p and RSVP. It also lets you identify hops along the call path that are having excessive packet loss.
pathping is similar to traceroute . It first displays the IP route along all hops from the host where it's running to the host at which it's targeted . Then, it collects information from each hop along the way, like latency times, and displays it for you, the administrator.
This example returns the hostname and IP address from each hop along the route to the destination, if each hop provides an ICMP response:
C:\> pathping www.broadvoxdirect.com
The output shows the route to the destination, similar to traceroute :
Tracing route to www.bigvoxdirect.com [126.96.36.199] over a maximum of 30 hops: 0 kelly-6aizy9qd1.ce1.client2.attbi.com [10.1.1.202] 1 10.1.1.1 2 10.248.164.1 3 bic01.elyehe1.oh.attbb.net [188.8.131.52] 4 184.108.40.206 5 220.127.116.11 6 gbr2-p70.phlpa.ip.att.net [18.104.22.168] 7 tbr1-p012601.phlpa.ip.att.net [22.214.171.124] 8 tbr1-cl8.n54ny.ip.att.net [126.96.36.199] 9 ggr2-p300.n54ny.ip.att.net [188.8.131.52] 10 so-1-0-0.gar4.NewYork1.Level3.net [184.108.40.206] 11 ge-2-1-0.bbr1.NewYork1.Level3.net [220.127.116.11] 12 so-0-0-0.mpls1.Cleveland1.Level3.net [18.104.22.168] 13 ge-6-0.hsa1.Cleveland1.Level3.net [22.214.171.124] 14 BIGVOX-DIS.hsa1.Level3.net [126.96.36.199] 15 penguin.bigvoxdirect.com [188.8.131.52]
This example checks to see whether each router along the path supports 802.1p precedence tags:
C:\> pathping www.bigvoxdirect.com -T
The output from pathping first shows the route, like the previous example, but also adds the 802.1p feedback as far along the route as is possible. Not all devices along every route support 802.1p. In this example, the sixth hop does not, because the router isn't configured for IP ToS and 802.1p. Since the 802.1p header can't be carried past the sixth hop, subsequent hops cannot be tested for 802.1p support:
Checking for connectivity with Layer-2 tags. 1 10.1.1.1 OK. 2 10.248.164.1 OK. 3 184.108.40.206 OK. 4 220.127.116.11 OK. 5 18.104.22.168 OK. 6 22.214.171.124 General failure.
The -R option will do a similar check for RSVP support in a similar fashion. You aren't nearly as likely to find RSVP-supporting hops on the public Internet as you are 802.1-aware hops. But, if RSVP is configured on your private network, you can use pathping to help you evaluate your network's hardware readiness for QoS. It will tell you which routers support RSVP and which routers either need to be re-programmed or upgraded to support it.
More information on pathping is available on Microsoft's TechNet web site (http://www.microsoft.com/technet).
126.96.36.199 Measure the latency time and jitter on a call path
The cumulative latency on a route is a good indicator of how latent it is and, therefore, how well it will work as a VoIP call path. An easy way to record latency between hops (routers) on a route is by using the TRaceroute (on Windows, TRacert ). The syntax is very simple:
# traceroute 188.8.131.52
This example will discover the route to the host at address 184.108.40.206, send several ICMP packets to each hop on the route, and then show you:
Whether on Linux, Windows, or Mac, traceroute 's output tends to be the same. The following sample output is from Windows, but all traceroute s show you the minimum, average, and maximum latency to each hop along the route:
Tracing route to www.macvoip.com [220.127.116.11] over a maximum of 30 hops: 1 1 ms 1 ms 1 ms 10.1.1.1 2 14 ms 13 ms 18 ms 10.248.164.1 3 18 ms 16 ms 12 ms bic01.elyehe1.oh.attbb.net [18.104.22.168] 4 19 ms 21 ms 34 ms 22.214.171.124 5 31 ms 23 ms 24 ms 126.96.36.199 6 25 ms 26 ms 28 ms tbr1-p012401.phlpa.ip.att.net [188.8.131.52] 7 32 ms 27 ms 27 ms tbr1-cl8.n54ny.ip.att.net [184.108.40.206] 8 28 ms 28 ms 34 ms ggr2-p300.n54ny.ip.att.net [220.127.116.11] 9 31 ms 30 ms 28 ms att-gw.ny.aol.net [18.104.22.168] 10 32 ms 28 ms 43 ms bb2-nye-P1-0.atdn.net [22.214.171.124] 11 29 ms 47 ms 34 ms bb2-vie-P12-0.atdn.net [126.96.36.199] 12 64 ms 48 ms 62 ms bb2-chi-P6-0.atdn.net [188.8.131.52] 13 60 ms 60 ms 62 ms RR-DET.atdn.net [184.108.40.206] 14 59 ms 54 ms 66 ms os0-0.fmhlmi1-rtr1.twmi.rr.com [220.127.116.11] 15 57 ms 53 ms 63 ms ig0-1.fmhlmi1-ubr5.twmi.rr.com [18.104.22.168] 16 64 ms 66 ms 68 ms www.thelinuxfix.com [22.214.171.124]
Not all IP networks permit ICMP traffic, or traceroute s in particular, because some system operators prohibit them for security reasons. Most routes across the Internet should provide a valid response when using the traceroute command.
As you examine the output from the traceroute command, pay special attention to the variance in highest and lowest latency times ( not the average latency time). This is a good, rough estimate of jitter between each hop.
Using pathping and traceroute during peak traffic periods, you'll be able to establish whether or not a particular IP route is a good place for voice traffic. You'll know the jitter and latency qualities of the network, you'll have identified problem routers and potential traffic bottlenecks, you'll know whether or not each router supports RSVP, and you'll know how well the network supports 802.1p precedence tagging.