Recording VoIP calls using Wireshark

Posted on By Mark Wilson
This content is 16 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Gary Marshall writes about how the UK Government plans to pour billions of pounds (as if they weren’t wasting enough money already) into recording all of our telephone calls. Well, funnily enough, I want to do the same thing… and it turns out to be remarkably easy – at least it is if you’re using a VoIP phone.

First of all, I should point out that, depending on where you live, it might be illegal to record phone calls without consent. In my case, I recorded a call from my desk phone to the voicemail on my mobile phone. As I was both the caller and the receiver I think it’s safe to say that there was consent – even if it does sound a bit mad. This was a proof of concept – the real usage case I have in mind is for the Coalface Tech podcasts, as last time James and I tried to record one over Skype there was just too much lag (and interference… although that might have been a local problem). Using the Cisco 7940 on my desk in the UK in to call a landline in Oz via my Sipgate account shouldn’t be too bad (and won’t cost too much either). What follows is a recipe for recording the call.

Ingredients

* If a softphone were used on the same computer as the packet capture, then it should be possible to capture the network traffic without needing to use a hub.

Method

  1. Install and configure Wireshark.
  2. Ensure that the computer being used for packet capture can see the phone traffic (i.e. that they are both connected to the hub – not a switch, unless port spanning or a tap are in use).
  3. Using Wireshark, start capturing traffic on the appropriate interface.
  4. Once the call(s) to be captured have been made, end the capture.
  5. In Wireshark, select VoIP calls from the Statistics menu – details of all captured calls should be listed:

    6. Viewing VoIP call statistics from a Wireshark trace

  6. At this point, it’s also possible to graph the traffic and also to play back the call (once decoded) – either one or both streams of the conversation:

    7. VoIP call graph generated from a Wireshark trace
    Playing back a VoIP call using the RTP packets from a Wireshark trace

  7. That’s enough to play back the call but to record it a different approach is required. Return to the list of captured packets and select the first RTP packet in a conversation.
  8. From the Statistics menu, select RTP and then Stream Analysis… This will show the packets in either direction:

    9. Analysing an RTP stream based on a Wireshark trace

  9. Click the Save payload… button to save to file – .au format with both streams is probably most useful:

    10. Saving the payload from an RTP stream based on a Wireshark trace

  10. The .au format is generally used for UNIX-generated sound files and can be played in Windows Media Player (see Microsoft knowledge base article 316992). Alternatively convert it to another format using whatever tools are appropriate (I used Switch on a Mac to convert from .AU to .MP3).

Results

I’m not sharing the full packet capture for security reasons but I have made the MP3 version of the RTP recording available.

Conclusion

Recording VoIP calls seems remarkably simple – given sufficient access to the network. Implementing IPSec should prevent such packet sniffing on the local network but, once a VoIP call is out on the ‘net, who knows who might be listening?

Acknowledgements

Whilst researching for this post, I found the following very useful:

Using Wireshark for basic packet capture and analysis

Posted on By Mark Wilson
This content is 16 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

As I’m trying to get my head around the notes I made from last week’s Wireshark webcast by Mike Pennacchi of Network Protocol Specialists, I thought I’d post the highlights here – these are just my notes with very little interpretation or linking out to other sites, so check out the video for more detail:

  • Analyser placement is critical to successful network troubleshooting – switched networks provide direct traffic so you can’t just plug in and view everything right away.
  • Three common methods for monitoring a switched network are:
    • Spanning/port mirroring – copying ingress and egress traffic between switch ports to form a single data stream – even for an entire VLAN (although it’s likely that would exceed the capabilities of the destination port).
      • Advantages include: configuration requires no interruption to traffic flow; multiple ports can be sent to a single port; remote spanning is possible between switches; some switches can filter packets as part of the spanning.
      • Disadvantages include: configuration requires access to the switch; not all switches fully support spanning; has been known to cause problems.
    • Tap – for monitoring full duplex traffic, including physical errors, passing traffic between devices in a fault tolerant manner.
      • Taps may be fibre or copper-based.
        • Fibre taps require no power and will split the signal using a ratio intended to provide the greatest signal level to the destination and a usable signal for analysis.
        • Most copper taps regenerate the signal (and will pass the signal on directly in the event of power failure).
      • Port aggregation taps can internally combine data streams, allowing a single port to capture full duplex traffic and also to buffer traffic when the combined data rate exceeds the egress data rate for the port. They can be:
        • Passive – dropping inbound packets from the analyser.
        • Allow reset packets – allowing packet injection, e.g. for an intrusion detection system to kill a TCP connection.
      • Advantages include: taps are independent of the switch infrastructure and work out of band.
      • Disadvantages include: the link needs to be broken to insert the tap and, for full duplex taps, the analyser needs to be able to accept two streams and merge them into a single trace file.
    • Hub – an inexpensive solution to copy all traffic to all other ports, including physical errors.
      • Hubs are effectively repeaters.
      • Beware that some hubs are really switches, labelled as hubs.
      • Dual-speed hubs are actually switched between the 10 and 100Mbps networks – so the analysis device will need to operate at the same speed as the devices being monitored otherwise only broadcasts will be detected from devices running at a different speed.
      • Advantages include: low cost, easy to install and readily availble; traffic can be sent to multiple monitoring ports.
      • Disadvantages include: only half duplex; not fault tolerant and require breaking the link for installation.
  • Wireshark analysis method (D.I.S.C.A.R.D.):
    • Download Wireshark (free).
    • Install – two components: the Wireshark application and the packet capture driver (for Windows that’s Winpcap).
    • Setup – select the interface (from the Capture menu) and click Prepare. Where present, a generic dialup adapter can be used to capture VPN packets prior to encryption. Ensure that promiscous mode is used to capture all frames seen by the interface (not just those addressed to the analyser). Set capture filters if required (but it may be better to filter post-capture). Tweak the display options to improve performance – turn off real-time packet listing and automatic scrolling.
    • Capture – click start to run a capture. In practice, the maximum capture rate using a built-in NIC before packets begin to drop will be around 230Mbps although cards are available for full duplex 1Gbps network captures (e.g. the Cace TurboCap).
    • Analyse – view frames using the display filter against the packet list, then view the packet detail and, if necessary, the packet bytes. Setting the time display format (on the View menu) as seconds since previous displayed packet will help to identify gaps. Even encrypted traffic will show the deltas. The filter input box turns green when a valid filter is applied – alternatively the Expression option provides a GUI to assist. Some filters are case-sensitive and beware when using booleans with multiple filters (i.e. use or not and to avoid attempting to filter on two protocols at the same time!). Follow TCP Stream can be useful to quickly create a filter based on an IP address pair and particular port numbers.
    • Resolve – after thorough analysis, resolve the issues.
    • Document the solution.
  • Pilot is a companion tool for Wireshark (chargable) and offers deep packet analysis.
  • Example captures are available at Packetlife.net

Free Wireshark training – and the 10 truths of network analysis

Posted on By Mark Wilson
This content is 16 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Last week, I was working my way through my RSS backlog when I spotted Thomas Lee’s post highlighting some free Wireshark (formerly Ethereal) webcasts by Network Protocol Specialists.

Wireshark is an open source packet capture and analysis tool (a bit like Microsoft Network Monitor – but available for a variety of platforms as well as in portable application and U3 form). I’ve struggled with deep packet-level networking since my days at Uni’ but a little knowledge in this area can really help when troubleshooting connectivity, so I registered for the first session and found it both worthwhile and interesting as Mike Pennacchi explained:

  • Analyzer placement.
  • Starting up Wireshark.
  • Selecting an interface.
  • Basic capture filters.
  • Capturing packets.
  • Displaying and decoding packets.
  • Saving the trace.

The next two sessions will look at:

  • Using display filters effectively.
  • Long term captures.

and:

  • Separating the good traffic from the bad traffic.

If you want to know more, check out the video from session 1 – or register for the next two sessions on the Network Protocol Specialists website.

In the meantime, I’ll round up this post with Mike’s 10 truths of network analysis:

  1. The wire does not lie. It is not out to prove a point, nor is it politically motivated. Interpreting traffic on the wire can help to solve problems.
  2. Packets cannot hang around at a device for more than a few milliseconds. Routers and switches do not have large enough buffers for packets to “hang around” – they may get dropped and retransmitted – or an application may be holding on to them. Network analysis can help to identify where the delay is.
  3. The total response time is the sum of the various deltas. Long response times may be the result of many packets with small gaps or fewer packets with long gaps.
  4. Every application program can be diagnosed. Solving them is a different issue.
  5. Focus on eliminating components that are not part of the problem. Figure out which layer of the OSI model is causing the problem, then implicate or exonerate.
  6. Don’t guess. Only state the facts after thorough analysis.
  7. Don’t believe anything that anyone tells you. Carry out your own troubleshooting and analysis. Be thorough.
  8. Explain the problem and diagnosis in a way that can be understood by all. Avoid misinterpretation and misunderstanding.
  9. Understand how to use the analysis tools before problems occur. And practice!
  10. Look for differences between working and non-working examples. If the normal situation is captured then it’s like a digital photo for comparison.

And finally, if this sort of thing is what interests you, Network Protocol Specialists have created a LinkedIn group for protocol analysis and troubleshooting to provide tips, tricks and valuable information to network professionals, application developers and anyone tasked solving computer network problems.