Giacomo Vacca

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