Giacomo Vacca

This is just a practical guide to have latest sipp on debian , to benefit from features that are not available in the stock package ( sip-tester  - version 3.2.1). For example support for playing pcap files or computing authentication hashes. Build sipp with pcap support apt-get install autoconf libncurses5-dev libpcap-dev g++ cd /usr/local/src/ git clone https://github.com/SIPp/sipp.git cd sipp/ ./build.sh --with-pcap ./sipp is the built binary. You can see the version and capabilities with './sipp -v', e.g.: $ ./sipp -v SIPp v3.6-dev-149-gb95f98f-PCAP-RTPSTREAM. ... This version will be able to use actions like exec rtp_stream="file.wav" or exec play_pcap_audio="pcap/g711a.pcap" (see details in current documentation ). A little caveat for 'rtp_stream' and WAV files . As the documentation says sipp expects a WAV file encoded with PCAM ('A-law'). You can also loop that audio for as long as you need, by adding '...

FreeSWITCH (from now on FS) provides a very powerful tool to interact with it: the Event Socket (ESL), made available via the mod_event_socket module ( https://freeswitch.org/confluence/display/FREESWITCH/mod_event_socket ). ESL is a TCP socket where applications can connect to, and perform two types of action: 1. Send commands. 2. Subscribe to events. The applications subscribing to events will receive the expected notifications through the same TCP connection. A simple protocol and transport made it possible for various libraries in various languages to be written. Events from FS can serve multiple purposes. In this article I'm interested in monitoring and event correlation. Homer ( http://sipcapture.org/ ) is a widely used, open source tool to monitor RTC infrastructures. It has a multitude of features, but the core is the ability to collect SIP signalling and other events from RTC applications, and perform a form of correlation. In particular, it's ab...

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