Recording VoIP calls using Wireshark

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

  7. 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:
  8. VoIP call graph generated from a Wireshark trace
    Playing back a VoIP call using the RTP packets from a Wireshark trace

  9. 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.
  10. From the Statistics menu, select RTP and then Stream Analysis… This will show the packets in either direction:
  11. Analysing an RTP stream based on a Wireshark trace

  12. Click the Save payload… button to save to file – .au format with both streams is probably most useful:
  13. Saving the payload from an RTP stream based on a Wireshark trace

  14. 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:

11 thoughts on “Recording VoIP calls using Wireshark


  1. Mark,

    Thanks very much for this very useful and clear explanation. I had heard before that wireshark could be used for VOIP call recording, but without your detailed step-by-step guide I wasn’t able to try it out.

    Using your instruction I was able to record calls and listen back to them using the recording player embedded in wireshark regardless of what codec was being used. However, your instructions for saving as a .au file only work when the phone call was made using the G711 codec. Do you know how to save calls using othere codes into a .au (or other format) file?

    Brian


  2. Brian – glad you found this useful. But sorry, I’m afraid I don’t know what happens with other Codecs… I think the Cisco phones that I use default to G.711 and I haven’t tried anything else.


  3. John – I need help, How can we store only VoIP Call Setup packets for troubleshooting without RTP or payload since files are becoming very huge in very short time.


  4. Thank you for the post. I debug SIP packets regularly but have never gone as far as recording the RTP packets. I want an automated web application to call people with a standard pre-recorded message and this helps me with the first part. Now I have to figure how to playback the RTP packets when a callee answers a call.


  5. Mark, thanks for this. Although it looks like there has been a minor interface change in Wireshark since you posted this, your guide helped significantly. You’ve also given me the boost I needed to install Wireshark, as it (or a similar application) has been on my list of interesting projects to do in my spare time for ages. Now to try recording Skype calls, although I’m guessing that there are different protocols involved. We’ll see.

    By the way, it’s only a year late, but it looks like (judging by his website) Steve Nutt was wanting to place automated calls to alert subscribers to his alarm service that their home alarm had gone off. That said, my initial impression was that he wanted to provide some sort of echo test service, but I can see how you might have thought he wanted to spam.


  6. @Craig – I’m glad you found it useful – makes it worthwhile writing this stuff up!

    @Steve Nutt – it seems I judged too harshly and owe you an apology. Automated diallers sounded like the sort of thing I experience with frustration; however I now understand you have found a useful and legitimate use for the technology – I hope it’s working out well for you.


  7. Mark, just wanted to report back that this method doesn’t work with Skype, but then I’m not surprised and I’m certain I’m not the first to figure that out. I presume that’s because the stream is encrypted, and so is not recognised as a VoIP stream by Wireshark. I presume the recording plug-ins available through Skype work by interacting directly with the application, not by intercepting TCP/IP traffic. However, they seem to get very mixed reviews, so I did a web search and ended up trying MP3 Skype Recorder. It worked for me on a couple of tests and doesn’t seem too intrusive. Considering it’s free, I looked hard for limitations — e.g., recording length — in the fine print, one of the complaints about other recording plug-ins, but didn’t find any.

    On another note, and getting back to why I found your post in the first place, after doing some successful tests I made the one phone call I set all of this up for. Don’t know what happened, but the two audio streams — me and the person I called — were out of synch by about 10.5 seconds. Have no idea what happened, but I saved the two streams separately and imported them into Audacity. I then added 10.5 seconds of silence to the beginning of one track and exported as MP3 and it was fine.

    Thanks again.


  8. Hi Craig, I don’t know a lot about Skype, except that it doesn’t use SIP (it has its own proprietary protocol), which would explain the problems you had. Thanks for the feedback though – it’s good to know what others have found out on this subject. ^MW


  9. Hello Craig, I have connectd my ip phone to a hub, and the laptop as well. the hub is then connected to the switch going to the PBX. When i run wireshark and make the calls, i see the ip adresses of the phones, the arp and udp formats are cptured. however when i go to telephony-voip calls, there is nothing. what could be the problem


  10. When I read this article and note the date, I marvel at how fast technology has progressed with VoIP and phone call recording in general. I have used Wireshank a lot in the past few years with my business, and always recommend it to my clients.

    Good information, thanks!

Leave a Reply