Sep 10, 2010

Network Protocol and Contextual Analysis: Exploring a SIP/RTP Call

by Eric Reeves

Earlier this week, I gave you an overview of some of the protocol analyzer tools we use here at BreakingPoint. In that post we looked at how we use tools like WireShark and NetWitness during the development of the application protocols (now more than 130) that we provide to our customers. Today I wanted to provide a direct example of how we use these tools by exploring a SIP/RTP call. A great way to showcase these features, as well as some of the Application Simulator enhancements in our 2.0 firmware release, is to use the BreakingPoint Storm CTM to produce some traffic. I'll use the NetWitness appliance to capture the traffic, analyze it there, then export it for use in the other analyzers.

On the BreakingPoint Storm CTM I created a simulation containing one Application Simulator component. The application profile for the test contains a custom Super Flow that I copied from the default “SIP/RTP Simple Call (UDP)” Super Flow. This Super Flow enacts a SIP/RTP call between two softphones. The calling party is configured to call from the 512555 NPA/NXX, and the receiving party may possess any number.

The NetWitness appliance runs both a decoder and concentrator service, both of which work together to capture and interpret data received on its monitoring interfaces. Using NetWitness Investigator, I've connected to the appliance so that I can see the captured data. As shown below, we can see information for the many calls generated by our test. Values in blue provide drill-downs into data that shares that attribute, while the neighboring numbers in parentheses represent sessions that contain that data.

Let's say that I am interested in any calls from (512) 555-6793. I locate that number in the “User Account” category and view all sessions for the originating IP address.

Next, I use Investigator's Reconstruction feature while viewing the RTP session. This feature will attempt to present the data in its intended format. In this case, it's audio, so we're presented with a convenient media player.

From these results we've been able to confirm that NetWitness parses the interesting sessions as SIP and RTP. Additionally, we've confirmed that the RTP stream is G.711 u-law. Last but not least, we've successfully listened to the conversation between the two call participants. Now that I've completed my analysis with Investigator, I can export the data for use in other analyzers. As most readers are likely to be most familiar with Wireshark, let's import the capture there and locate our call. Shown below, the granular details of the SIP messages are revealed. The image below shows the detail for the SIP INVITE message, complete with headers and session description information.

What if we want to listen to the audio carried by the RTP stream in Wireshark? We can do so by analyzing the RTP stream within Wireshark, or simply open the RTP player directly from the "VoIP Calls" window. In this example, we have instructed Wireshark to use the RTP timestamp in decoding the stream. By disabling the option we can observe jitter, delay, and other factors that may affect quality of the audio.

Let's take a look at how NetScout's InfiniStream Console and Wireshark complement one another. The first image shows a breakdown of sessions occurring in the packet capture. There are no surprises here -- as expected, SIP, RTP, and RTCP are all present.

Stepping into the "Decode" view gives us the details we want. Wireshark users should be comfortable in this view, where we can step from message to message in order to drill into more specific data.

DejaVu's TrafficScape, by contrast, isn't the usual fare. We import the packet capture, after which it is consumed by the TrafficScape service. The result is the ability to use its built-in Solr search capabilities through a web interface.

Searching against the IP address, we quickly arrive at the detail for the call in which I am interested. Selecting the "From" header allows me to see the relations for the source of the call.

In viewing these relations we see the phone number, IP, and MAC address of the receiving participant in the SIP call. We can drill into any of these values to view their relationships, enabling an efficient audit trail for the network activity of these users. For example, one might want to review the e-mail and web content viewed by the participants before, during, or after the call. The relations and timeline features offered by TrafficScape and Investigator make it easy to do so. In fact, this is a great example scenario that one can simulate with the BreakingPoint Storm CTM: simply add e-mail, webmail, chat, and HTTP Super Flows to the application profile and perform another test! You can do any of the following in order to simulate a starting point for your analysis:

Add a custom dictionary to e-mail, webmail, or chat flows, or use a built-in dictionary that supports five different languages.
Add a custom audio file for use in a VoIP flow.
Add custom HTTP content to an HTTP flow.

Closing Comments

I hope these two posts have provided a small glimpse into the tools and methods we use to ensure the most realistic network simulations possible. In both posts you can clearly see that there is no one tool to perform everything we demand. But fortunately there are a variety of analyzers that can be used together to gain a comprehensive understanding of a network and its users.

Feel free to use the comments section to share your own thoughts and observations about these tools or about your own experiences with protocol analysis. Until next time, happy analyzing!

RESOURCES: Wireshark is available for free at http://wireshark.org and NetWitness has a free version of Investigator available at http://download.netwitness.com/. I encourage you to try, compare, and contrast the two.

Tags: