Giacomo Vacca

  Wireshark offers a simple but effective option to extend its capabilities, by using Lua dissectors . Just to give an example, recently received a pcap file containing some traffic (it was RTP) encapsulated inside a UDP header. The reason for encapsulation was transporting over a VPN. I'm in such a habit to look into RTP streams on Wireshark, that I have a setting that tells it to try an interpret any UDP packet automatically as carrying RTP ( I wrote how here ). That also failed. So Wireshark was not able to interpret those frames as RTP (or anything else, for what matters), and I remembered time ago writing a custom dissector. Wireshark allows to do that simply in Lua and add it as a plugin. The code is available here . I just had to make it available inside '$HOME/.local/lib/wireshark/plugins/`.

If you have a pcap file with encrypted RTP (SDES SRTP) and have access to the SIP signalling to see the keys, these instructions will help you decrypt the RTP payload and save it as raw audio. Optionally, depending on the codec, you can then import the raw audio in Wireshark and save it as an audio file. Steps

Before I forget again, a Wireshark setting that can help saving time by trying to interpret any UDP as RTP, if possible: Analyze --> Enabled Protocols... --> Search for RTP and enable at least 'rtp_udp' Without that change, when SIP signalling is not present (or it's encrypted) Wireshark would not understand automatically that UDP packets may be RTP. This is particularly true for example for WebRTC calls, where signalling happens elsewhere and is not available to Wireshark. This will also save the reader some time if you're used to right click and 'Decode As...' to achieve the same.

An interesting pattern that caught my attention is the role that Lua is gaining in the RTC (Real-Time Communications) world. Lua is a small-footprint programming language, powerful while keeping a simple syntax. I’ve been using Lua to script dialplan actions for FreeSWITCH since about 2014. It has provided me with a way to define relatively complex logic and speed up the definition of FS’ behaviour. Delegating this type of logic to a scripting language had several advantages, such as: It’s easier to read and understand than native dialplans or native routing logic. Makes unit testing of the dialplan possible/easier. Allows changing some pieces of logic easily, in many cases preventing expensive reload of modules or restart of applications. I’ve been using Lua for Kamailio as well. Kamailio is an open source programmable SIP Proxy . In a specific case, some bits of the routing logic required regex processing and was expecting to change often: an ideal case for...

VoIP/RTC platforms have typically many elements processing audio. When an issue is reported it's important to be able to restrict the investigation field, to save time and resources. A typical scenario is bad or missing audio perceived on the client side. As I've done previously ( here for Opus and here for SILK ) I'd like to share some practical strategies to extract audio from a pcap trace (to verify the audio received/sent was "correct") and to "re-play" the call inside a test bed (to verify that the audio was good but also carried correctly by the RTP stream). Of course a lot can be inferred by indirect data, for example the summary of RTCP reports showing the number of packets exchanged, packets lost, the latency. But sometimes those metrics are perfect while the issue is still there. Focusing in this case on Opus audio, and starting from a pcap file with the network traces for a call under investigation, let's see how to decode the Opus fr...

Three and a half years ago (which really sounds like a lot of time!) I was working with a VoIP infrastructure using SILK . As it often happens to server-side developers/integrators, you have to prove whether the audio provided by a client or to a client is correctly encoded :-) Wireshark is able to decode, and play, G.711 streams, but not SILK (or Opus - more on this later). So I thought of having my own tool handy, to generate a WAV file for a PCAP with RTP carrying SILK frames. The first part requires extracting the SILK payload and writing it down into a bistream file. Then you have to decode the audio using the SILK SDK decoder, to get a raw audio file. From there to a WAV file it is very easy. As I tried to describe in this previous post , I had to reverse engineer the test files contained in the SDK, to see what a SILK file looked like. Since the SILK payload is not constant, all that was needed was to insert 2 Bytes with the length of the following SILK frame. At the be...