Sunday, 15 January 2017

Analysing Opus media from network traces

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 frames carried by the RTP packets into an audible WAV file.

You don't even need to have captured the signalling: it's sufficient to have the UDP packets carrying the RTP. If signalling is not visible by Wireshark it may not recognize that the UDP packets carry RTP, but you give it a hint by right-clicking on a frame and "Decode as..." and selecting "RTP".

It's typically easy to find the relevant RTP stream in Wireshark ("Telephony -> RTP -> RTP Streams"), select it, and prepare a filter. Then you can Export the packets belonging to that stream into a dedicated pcap file ("File --> Export Specified Packets...").

I've then modified opusrtp from a fork of opus-tools in order to be able to extract the payload from a given pcap, creating an Opus file. e.g.:

./opusrtp --extract trace.pcap

This will output a rtpdump.opus file, which can be converted into a WAV file directly with opusdec, still part of opus-tools:

./opusdec --rate 8000 rtpdump.opus audio.wav

You can listen to the wav file and verify whether at least the carried RTP payload was valid.

The network trace with the RTP can also be used to re-play the call, injecting the same RTP as in the call under investigation. With the help of sipp you can set up a rudimentary but very powerful test bed. Use the standard UAS scenario (e.g. in uas.xml), but with an additional part:

right after the ACK is received. If you launch sipp with a command like:

sipp -sf uas.xml -i MEDIA_IP_ADDRESS

you'll be able to call sipp. It will answer the call, as the scenario mandates, and will play the RTP contained in rtp_opus.pcap. The stream SSRC, timestamps, even Marker bits will be preserved. This will give you quite an accurate simulation of the stream received by the client in the original call.

It should be straightforward to reach all these components. For opus-tools, on a debian-based machine, you can just:

sudo apt-get install libogg-dev libpcap-dev
git clone https://github.com/giavac/opus-tools.git
cd opus-tools
./autogen.sh
./configure
make

For sipp:
sudo apt-get install sip-tester

I hope this will save the reader some time in future investigations.

UPDATE: The fork of opus-tools was merged into the original repo, so you don't need my repo.

UPDATE 2: This only works if the opus payload in the RTP is not encrypted. Also it may need a patch when the extension header for volume indications are used (e.g. 'urn:ietf:params:rtp-hdrext:ssrc-audio-level', see RFC-6464). Don't forget that at the moment the payload type is harcoded to 120. You may need to rebuild opusrtp with the type your trace has, e.g. 96 (It should be easy to pass it as command line argument, something for a quiet moment).



8 comments:

  1. Hi,

    I am trying to covert a pcap and I have the following error:

    Got 132 byte packet (132 bytes captured)
    skipping packet: unrecognized linktype 12
    Got 127 byte packet (127 bytes captured)
    skipping packet: unrecognized linktype 12


    Here the capture:
    https://drive.google.com/file/d/0BySOpdix-JH6b2Z2Q2xnbFVnOUk/view?usp=sharing

    BR,
    Martín.



    ReplyDelete
  2. Hi Martin,
    the tool as is now expects data captured with ethernet (DLT_EN10MB) or null (DLT_NULL) type, while yours is a raw packet capture.

    Is there any chance you can have a capture with the ethernet layer?
    Otherwise the tool should be changed to support raw packet data (I don't think I'll be able to work on this any time soon).

    Giacomo

    ReplyDelete
    Replies
    1. HI Giacomo,

      I am using rtpengine to save the videocall, and right I save the pcap with the eth header, and the .opus is generating but is no audible.

      I am attaching the pcap here:
      https://drive.google.com/file/d/0BySOpdix-JH6djB0T01ncVpEblE/view?usp=sharing

      I think the log is ok:
      Got 155 byte packet (155 bytes captured)
      eth 0x0800 00:00:00:00:00:00 -> 00:00:00:00:00:00
      ipv4 protocol 17 195.77.235.141 -> 195.77.235.141 header 20 bytes
      udp 121 bytes 40268 -> 40282 crc 0x0000
      rtp 0xfca33a6e 111 23426 985204741 v2 .X. CC 0 101 bytes
      Got 157 byte packet (157 bytes captured)
      eth 0x0800 00:00:00:00:00:00 -> 00:00:00:00:00:00
      ipv4 protocol 17 195.77.235.141 -> 195.77.235.141 header 20 bytes
      udp 123 bytes 40268 -> 40282 crc 0x0000

      I don't know what I am doing wrong, maybe when I have exported from the original pcap to the only opus.pcap

      Delete
    2. After you have the .opus file, decode it into a wav file, e.g.:

      ./opusdec --rate 8000 rtpdump.opus output.wav

      Delete
    3. also the wav file is not audible, has the following errors:
      Decoding to 8000 Hz (2 channels)
      Encoded with opus rtp packet dump
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding error: corrupted stream
      Decoding complete.

      Delete
    4. Hi Giacomo,

      Could you help me to see what happens? Do you need the capture?

      Thanks,
      Martín.

      Delete
    5. OK Martin, feel free to send me the capture (gmail email address).

      Delete
  3. This comment has been removed by the author.

    ReplyDelete