Simulate Custom SIP VoIP Traffic To Validate Network Performance
by Pat McGarryBy Pat McGarry
At BreakingPoint, one of our primary goals is to emulate the entire Internet from a single small device. And when we say the entire Internet, we mean the entire Internet. We're not there yet, but already our 4U chassis outfitted with three BreakingPoint FireStorm CTM blades can support up to 120 gigabits per second of realistic, stateful application traffic. We natively support 150+ application protocols, ranging from the obvious ones like web traffic, email traffic, file sharing, and databases, to more specialized applications like financial transactions (FIX and FIXT), server message block (SMB), Pandora, Facebook (including Farmville), Netflix, BitTorrent, World of Warcraft, and a plethora of others.
There has been an emerging trend for several years now in the voice over IP (VoIP) space, and in many enterprise environments, VoIP has become mission-critical. One of the most popular VoIP formats in use today is the combination of session initiation protocol (SIP) and real-time transport protocol (RTP), running over TCP or more commonly UDP. If you can’t accurately model SIP/RTP, then you simply aren’t modeling some of the mission-critical traffic flowing over your network. Since SIP/RTP streams are carrying real-time traffic, modeling this accurately can be extremely important to ensuring acceptable quality and performance of the transmitted data streams, especially when loading a network with significant amounts of SIP/RTP traffic in conjunction with other realistic background traffic. It probably won’t surprise you to find out that BreakingPoint supports SIP/RTP straight out of the box.
In this post, we’re going to investigate the BreakingPoint CTM’s implementation of SIP/RTP streams, and discuss the associated benefits to your organization when modeling SIP/RTP traffic in your pre-production environments.
Configuring SIP
Let’s start with one of our pre-existing SIP/RTP protocol models (we call them Super Flows) and extend it for our purposes. From the menu, select Managers > Application Manager and select the Super Flows tab, and scroll through the list to select SIP/RTP Simple Call (UDP), and save it as a new super flow so that we can make changes to it. In this example, I’ve decided to name my super flow “Custom SIP-RTP”:
In a SIP/RTP VoIP configuration, SIP acts as the signaling channel. So that’s where we would expect to find the configuration for the phone number we want to connect to. In the Define Flows section, highlight the SIP protocol entry, and then click the bracketed ellipsis to open the configuration detail for the SIP protocol:
In the accompanying screen, you can configure things like caller and recipient phone numbers, client and server ports (or randomize them), the transport protocol (TCP or UDP), and client and recipient user agents (these are similar to browser user agents, and you can make them anything you want). Here were the settings I used for this example:
One of the nice things about using the preconfigured SIP/RTP datastream is that we can save it off so that we can make minor tweaks to it. This is typically much easier than creating a new one from scratch, and even if you have just a basic understanding of SIP/RTP, you can make simple configuration changes knowing that the default example works correctly out of the box.
Rest assured, though, that for more advanced scenarios, there are tons of configuration details available to you. For example, you can adjust the “SIP Invite” action in the Define Actions section if you need to configure things like the caller and recipient tags, the session start and stop times, and media settings. You can even upload your own custom session description protocol (SDP) attributes.
BreakingPoint’s RTP Defaults
As with all of our built-in protocols, RTP works as-is out of the box. If you leave the RTP defaults in place, the bidirectional data stream will use the default audio recordings that ship with every BreakingPoint CTM. These audio recordings make use of what are known as the “Harvard Sentences.” These are a series of sentences selected by the IEEE for optimal measurement of speech quality. That’s right — these standard spoken sentences, as dictated by a real human being, are included in the product by default. How’s that for realism?
But let’s say you want to use your own recordings. There are many reasons that you may want to do that. Maybe you want to consider a foreign language recording or speaker, for example, as foreign languages often require different speech quality assessments than the English language does. Or maybe you have a voice analysis system and you want to inundate it with certain wiretap recordings of varying demographics to see how well your system’s detection and analysis algorithms perform. Or maybe you even want to introduce a white noise recording for similar purposes. The point is, with the BreakingPoint CTM, you have full control for the utmost in realism for your particular SIP/RTP application, whatever it may be.
Configuring RTP
As an example, we’ll configure our actual real-time RTP bidirectional datastream with recordings of our choice. Scroll down in the Define Actions section to highlight the RTP “Bidirectional Stream with RTCP” entry (it will likely be truncated to “Bidirectional Strea” on your screen), and then click on the bracketed ellipsis to open up its detail configuration dialog:
The resulting dialog allows you to configure the precise behavior of the bidirectional data stream. Our notation includes (F) and (R) designators for the forward and reverse directions, respectively. We support several payload formats, including G.722, G.723, G.728, G.729, GSM, H.261, H.263, PCMA, PCMU, and many more.
We’ll first want to create a recording so that we can upload it to the BreakingPoint CTM. To do that, you can use any audio file and any audio recording/conversion software that can save a file in one of our supported standard formats. I like to use Audacity, which is a free cross-platform sound editor readily available on the Internet (you can download it yourself at http://audacity.sourceforge.net/). You can either load an existing audio file and save it in an appropriate format, or configure Audacity for your preferred microphone settings, then make your own recording at mono 8kHz. You can then use Audacity’s File>Export feature, select “Other uncompressed files” as the type, and select WAV (Microsoft) and Encoding: U-Law. We chose WAV/U-Law because that maps to “PCMU,” which is our default payload type.
Once you save your recording, you can upload it to the BreakingPoint CTM via the “Bidirectional Stream with RTCP” dialog window that you are currently accessing. To do that, uncheck “Raw File Size,” select the “Raw File to Stream” entry, and then click the “Import Raw File to Stream” link below it. Once you’ve imported, select it from the dropdown list. In the example here, I’ve uploaded a personal recording called pat-bps.wav:
The example above showed the configuration for the forward direction, but you can do this for the reverse direction as well (the reverse direction parameters are further down in the configuration dialog). If you want, you can even select the same playback file for both directions, which is what I chose to do in this example. We then Apply Changes and click Save Super Flow:
Running the Scenario
Now that we’ve configured the audio datastream that we want flowing in each direction, we simply include this Super Flow in an Application Profile (I chose to call mine “Custom SIP-RTP Profile”), which is attached to an Application Simulator component that we include in a new Scenario:
Note that nothing precludes us from adding other components if we’d like, or even extending our Application Profile to include other Super Flows. Doing that could help us make up a realistic background traffic mix to more closely match whatever environment we are emulating. With any BreakingPoint CTM, all components are available to you at any time, and you can stack them to your heart’s content. So, if you want to, as part of the same scenario definition, you could add more Application Simulator components, or Stack Scrambler components, or Security components . . . well, you get the idea. Furthermore, you can even control the bandwidth used by each of these components, including traffic amplification up to millions of simultaneous sessions at rates of hundreds of thousands of sessions per second, all stateful and up to line rate.
After we run the scenario, we can use the BreakingPoint CTM’s built-in packet capture (PCAP) capability to download the generated packets as a PCAP file for viewing directly in Wireshark. We can use Wireshark’s powerful VoIP/Telephony analysis to prove to ourselves that the traffic that we generated is real from client-to-server-and-back. We can even use Wireshark to listen to the audio in either direction. For illustrative purposes, here’s a Wireshark screen capture of the SIP/RTP VoIP telephony stream that we just created with our scenario:
SIP/RTP Network Confidence
We’ve finished our SIP/RTP emulation with our customized, realistic, and bidirectional audio traffic, showing that we can effectively emulate both ends of a SIP/RTP VoIP conversation, in completely customizable fashion — all from within our powerful web-based user interface.
You’re now ready to connect directly to any network equipment that you want to evaluate from a SIP/RTP perspective, whether it be for voice-quality analysis, audio detection and analysis systems, SIP/RTP overload scenarios, traffic propagation in the presence of realistic background traffic, or any other scenario that might be required.
With this scenario created, we can quickly and easily run it again in the future whenever needs dictate, especially to evaluate performance when network conditions change or when we want to modify the traffic mix. The combination of SIP/RTP emulation with our other powerful components allows you to stress your equipment and systems in ways that no other tool on the market can. As a bonus, if you are familiar with the TCL scripting language, you can use the BreakingPoint CTM’s TCL implementation — another out-of-the-box feature, naturally — to automate the entire procedure.
Armed with the BreakingPoint CTM, you can rest easy knowing that your infrastructure meets your mission-critical SIP/RTP VoIP requirements.
Related Content:
blog comments powered by Disqus
