How do product developers, implementers and testers make sure that their VoIP, Video, and IPTV implementations can withstand real-world networks?

VoIP, Video, and IPTV products must withstand and continue to function when facing all the conditions that occur on the Internet.  These include attacks from hackers exploiting vulnerabilities in security and protocols as well as the common phenomenon of congestion, delay, jitter, drops, and so on.   VoIP, Video, and IPTV products must demonstrate robustness and resiliency in the face of unusual and/or illegal conditions. 

Maxwell can introduce both protocol impairments and conventional packet impairments during a voice or video session.  When a device failes, Maxwell helps pinpoint the problem so the software developer can fix the bug.  By creating and introducing the full range of adverse conditions on the Internet, Maxwell will expose vulnerabilities typically not found in the lab or in BETA testing.

Maxwell includes SIP vulnerability and robustness tests to verify products and applications have implemented SIP properly. Maxwell modifies SIP packets in real-time to see if the malformed packet is handled properly by the receiving device.

As a result, the tester can check for correct SIP operation to make sure he has a solid implementation that can withstand the rigors of any network environment.

The tester can modify, distort, and corrupt the SIP packets in the protocol exchange, and even change the protocol exchange itself, to see how the SIP devices behave.

Maxwell is in the network acting like a layer 2 device, so it is invisible to the SIP devices in the network.

Maxwell intercepts the SIP protocol exchange between devices, examines and modifies each packet before the packet reaches the destination device. The destination device should process the packet correctly.

The tester can control the interception and packet modification directly, or use Maxwell’s plug-in set of exercises to determine precisely how the receiving SIP device responds. This provides maximum flexibility to drill down and create more tests for problem areas.

 

Maxwell intercepts and modifies the contents of each SIP protocol message.

Areas include, but are not limited to:

• Basic Framing
• Line Termination
• Basic Character Set Issues
• UTF-8 Issues
• SIP Fields
• SDP Issues

Each area contains a set of tests that are controlled from the graphical user interface or the command line.

This approach to exercising the SIP implementation is highly maintainable and flexible. Since Maxwell uses real SIP transactions, and not artificially constructed ones, there is no need to simulate multiple SIP phones or artificially generate SIP messages.

Features:

• All SIP devices and applications can be tested (e.g. soft phones, proxy servers, IM clients)
• Standard impairments (drop, jitter, duplication, etc.) can be added to the scenarios
• Multiple flows of SIP impairments between different source and destination devices can be utilized concurrently.
• Performance testing can be done through timing parameters
• SIP syntax, interoperability, and negative testing are accomplished automatically with the scenarios and exercises
• Users may vary and alter the scenarios and exercises as they desire

The multiple phone and table diagram provides a realistic example of three VoIP phones communicating with a conference phone. The voice traffic is bidirectional and represents multiple, concurrent network flows.

The tester can define any number of network flows, applying any type of network, protocol, and/or packet impairments. The individual VoIP phones on the left have established a session with the conference phone on the right. Maxwell will impair each session according to the criteria specified by the tester.

In the above illustration, the tester has defined impairments on multiple network flows:

Flow 0
The flow from VoIP Phone A travels through Maxwell to the Conference Phone (on the right); Maxwell will introduce 20 ms of jitter over a bell curve along with an extra carriage return/line feed in the SIP 180 Ringing Packet. This represents two impairments. The objective: determine if the Conference Phone handles the two impairments correctly.

Flow 1
The flow from VoIP Phone B travels through Maxwell to the Conference Phone; Maxwell will introduce 5 ms of delay with a 10% probability. This means that any packet in the network flow has a 10% chance of being delayed by 5 ms.

Flows 2-4 are described in the table.

The tester can thoroughly test the resilience and reliability of each network device. Before customers suffer through unexpected behavior such as crashes, hangs, or reboots, the SIP tests can help proactively test and uncover potential issues.

The Maxwell SIP tests are a component of a larger infrastructure that includes protocol and packet impairments for related protocol families. 

List of SIP Protocol Tests

• Fragment packets according to MTU setting
• Remove all data from UDP packets intercepted
• Change the destination MAC address to be all ones (broadcast).
• Change the destination IP address to be all ones (broadcast).
• Change both destination MAC and IP address to be all ones (broadcast).
• Add empty CRLF line at end of message without adjusting Content-Length.
• Add empty CRLF line at end of message and adjust Content-Length.
• Add empty CR line at end of message without adjusting Content-Length.
• Add empty CR line at end of message and adjust Content-Length.
• Add empty LF at end of message without adjusting Content-Length.
• Add empty LF line at end of message and adjust Content-Length.
• Append gibberish to the end of message without adjusting Content-Length.
• Append gibberish to the end of message and adjust Content-Length.
• Add nulls after CRLFs in request/status, header and body lines without adjusting content length
• Add blanks before CRLFs in request/status line without adjusting content length
• Add nulls before CRLFs in request/status line without adjusting Content Length.
• Add blanks before CRLFs in header lines without adjusting Content Length.
• Add nulls before CRLFs in header lines without adjusting Content Length.
• Add blanks before CRLFs in body lines without adjusting content length
• Add blanks before CRLFs in body lines and adjust Content Length.
• Add nulls before CRLFs in body lines without adjusting Content Length.
• Add nulls before CRLFs in body lines and adjust Content Length.
• Remove CRLF after message body (if any) without adjusting Content Length.
• Remove CRLF after message body (if any) and adjust Content Length.
• Remove CR after message body (if any) without adjusting Content Length.
• Remove CR after message body (if any) and adjust Content Length.
• Append a meaningless message body to 100/80 responses
• Insert blanks before colon on header field lines
• Insert tabs before colon on header field lines
• Insert blanks after colon on header field lines
• Insert tabs after colon on header field lines
• Remove whitespace after colon on header field lines
• Add trailing dot to DNS names found in request/status line and message header
• Add trailing dot to DNS names found in request/status line
• Add trailing dot to DNS names found in From: header
• Add trailing dot to DNS names found in To: header
• Add trailing dot to DNS names found in Contact: header
• Remove the trailing dot (if any) in DNS names in request/status line and message header.
• Remove the trailing dot (if any) in DNS names in request/status line.
• Remove the trailing dot (if any) in DNS names in From: header line.
• Remove the trailing dot (if any) in DNS names in To: header line.
• Remove the trailing dot (if any) in DNS names in Contact: header line.
• Insert extremely long but valid domain name in request/status line and header lines
• Insert extremely long but valid domain name in request/status line.
• Insert extremely long but valid domain name in From: header line.
• Insert extremely long but valid domain name in To: header line.
• Insert extremely long but valid domain name in Contact: header line.
• Insert extremely long, invalid domain name in request/status line and header lines
• Insert invalid domain name (with one extra byte ) in request/status line
• Insert invalid domain name (with one extra byte) in From: header line
• Insert invalid domain name (with one extra byte) in To: header line
• Insert invalid domain name (with one extra byte) in Contact: header line
• Insert invalid domain name (with several extra bytes) in request/status line and message header.
• Insert invalid domain name (with several extra bytes) in request/status line