Answers to your Questions
Why is it critical to test security and content-aware devices for VoIP performance?
The requirements for voice quality are vastly different from those of data services.
Devices such as firewalls must inspect VoIP signaling packets so that “pinholes” can be dynamically opened to allow the passage of RTP streams. In addition, if application filtering is enabled, layer-7 packet headers and payloads are examined. Inspection and filtering operations require significant CPU processing, which hurts Quality of Experience in two ways:
- The maximum number of concurrent calls <link to test case Maximum Concurrent VoIP Calls> and the maximum sustainable call setup rate <link to test case “VoIP Call Setup Rate> will decrease;
- Packet latency (delay) and latency variation (jitter) will increase. During busy periods with high call loads, packets may also be dropped. These factors will cause the quality metrics to deteriorate.
It is imperative for manufacturers and network designers to measure the impact on VoIP performance as their equipment is pushed beyond expected peak loads towards the device limits.
How do I measure the impact of data services on VoIP performance?
Business-critical voice services must not be impacted by data applications such as email, instant messaging and P2P file sharing. Network devices may:
- Detect VoIP flows using CPU-intensive application-layer packet inspection;
- Segregate VoIP traffic onto separate VLANs;
- Classify VoIP packets using DiffServ or IP Type of Service (ToS) bits; and
- Prioritize VoIP traffic over data to ensure quality and availability.
Typically, VoIP performance through a device such as a firewall will deteriorate as data traffic load is increased.
The VoIP and Data Convergence Test scenario in The Journal of Internet Test Methodologies describes a procedure to measure the impact on VoIP performance as data traffic is increased. To run this test case you will need test equipment that can:
- Simultaneously emulate and measure the performance of many thousands of data, voice (and perhaps video) applications on the same port simultaneously;
- Control client and server emulations from a single GUI so that measurements can be correlated;
- Graph VoIP and data application performance parameters as data volume is ramped up.
Conversely, the same methodology can be used to determine the impact of many VoIP calls on business-critical data performance.
You will need application-layer test equipment that can emulate multiple voice and data protocols at the same time on the same port and correlate the performance of each.
How will my network device react in a real-world environment where there are several VoIP protocols being used?
A few equipment manufacturers have already found problems that occur when H.323 and SIP are mixed. If these applications share the same resources (such as a firewall state table or encryption hardware), contention can degrade performance.
Measure the maximum call setup rate, the maximum concurrent calls and other VoIP metrics individually, first with H.323 and then with SIP traffic. Next, introduce a mix of H.323 and SIP traffic by creating two client profiles on the same ports and repeat the measurements. Compare the measurements against predicted performance and analyze any unexpected errors by reading the transaction trace.
How do I test the impact of Denial of Service (DoS) attacks on VoIP performance?
Traditional DoS attacks employ specially crafted TCP, UDP or ICMP packets to either use up a device’s resources (such as the number of TCP connections that can be sustained) or to congest a system with unwanted traffic. Newer “application attacks” target known application or device vulnerabilities using specially crafted layer-7 packets (e.g., by filling a VoIP-aware firewall state table or exhausting a gateway’s maximum available number of VoIP calls).
A vulnerable VoIP service can be disrupted by setting up or tearing down many calls at the same time, or by injecting bogus RTP packets into VoIP streams. In addition, Trojan viruses can be used to eavesdrop on sensitive conversations or to make free long-distance calls.
Agilent’s VoIP white paper describes the new types of VoIP DoS attacks. To measure the impact on VoIP performance, first establish a large number of VoIP calls, then slowly ramp up the DoS attack packet rate while graphing the VoIP quality degradation.
See the “ VoIP Performance during DoS Attacks” test scenario of the Internet Journal of Test methodologies for more details.
How do I measure the impact of Network Address Translation (NAT) on VoIP performance?
When NAT for SIP or H.323 is enabled in a firewall, router, or gateway, IP addresses and port numbers must be translated not only within layer-3 and layer-4 headers, but also within layer-7 packet payloads during the establishment of RTP flows.
Because NAT requires intensive CPU processing, it can easily add to voice delay, jitter, packet loss and call setup time. To characterize the impact of NAT, repeat the basic measurements described in maximum VoIP Call Setup rate, with and without NAT enabled. In addition, because the maximum size of the NAT table is likely to be finite, use test case “ VoIP Performance with NAT” (described in The Journal of Internet Test Methodologies) to measure the largest number of calls that can be established with NAT enabled. This determines the maximum effective size of the NAT device’s address translation table.
Remember to repeat this test with both SIP and H.323 traffic and over both IPv4 and IPv6. This may influence the size of each NAT table entry and the number of entries per call.
Why should I measure the application layer performance of my IPsec VPN firewall or router using VoIPsec traffic? Isn’t raw throughput enough?
Packet throughput measurements do not help you predict VoIP quality at your expected peak call rates, and do not stress your device’s VoIP forwarding capabilities. A packet blaster is insufficient; you need to test VoIP performance with VoIP traffic.
IPsec VPNs can degrade voice quality in three ways:
- If IPsec tunnels are established upon VoIP call setup, then the lengthy IPsec tunnel setup duration will add to the VoIP call setup time and will decrease the maximum possible VoIP call setup rate.
- IPsec encryption and authentication take time. This increases packet latency and latency variation, and therefore negatively impacts voice delay and jitter.
- IPsec tunnel establishment and encryption processes can be CPU-intensive, even when using dedicated hardware. Using IPsec will severely decrease your device’s maximum number of simultaneous calls and maximum call setup rate.
The “ Performance of VoIP over IPsec” test case documented in “ The Journal of Internet Test Methodologies” describes a procedure to determine the maximum number of IPsec VPNs that can be established through your device or system before voice quality starts to degrade.
Remember to repeat the tests using both SIP and H.323 traffic over both IPv4 and IPv6 (VoIPsec and VoIPsecv6).
What test capabilities should I look for to measure VoIP performance and scalability of security or content-aware devices and systems?
A dedicated test tool with integrated VoIP capabilities and measurements is the only way to address the test challenges that are faced during the design and implementation of VoIP devices and networks. A VoIP test solution must be able to:
- Emulate H.323 and SIP signaling and data simultaneously;
- Mix voice and data traffic on one port to verify voice prioritization;
- Combine IPv4 and IPv6 addressing to ensure readiness for next-generation networks;
- Establish thousands of calls and calls per second to determine performance limits;
- Launch DoS attacks to characterize the impact on VoIP performance;
- Integrate both IPsec and IPsecv6 seamlessly to measure encrypted VoIP traffic;
- Graph and log statistics to accurately gauge call setup rates, voice quality and scalability limits;
- Partition voice and data onto separate VLANs to verify VoIP security.
Read Agilent’s Testing VoIP Security Devices white paper to understand how these capabilities can increase test coverage, decrease test time and increase confidence that your device or system will meet expected requirements.
|
Network Services 
