On many occasions we have encountered situations in which it is necessary to capture calls at the network level in order to debug some problem. Although there are many tools to take captures such as tcpdump and wireshark/tshark, we almost always resort to sngrep, since it is very easy to use and has a large number of features that allow us to quickly access the call we want to inspect. Therefore, we have decided to make a short post on how to install and use sngrep and wireshark to extract audio from a call.
What is sngrep?
sngrep It is a tool to facilitate learning or debugging SIP. It is developed and maintained by the Spanish company irontec, and in our opinion it is essential when debugging problems in SIP. It is distributed under the GPLv3 license. Among the features to highlight are its simplicity, the possibility of running on the console thanks to its interface based on ncurses, and the possibility of filtering by a large number of fields, in addition to the fact that it allows us to capture both SIP signaling and RTP audio.
Facility
The documentation of sngrep It is quite broad and we are not going to replicate it in this post. To get sngrep We have the option of compiling it from sources or choosing to install it using the binaries which are available in various distributions (Debian/Ubuntu, CentOS/Fedora/RHEL, Alpine Linux, Gentoo, Arch, etc.). We generally perform the installation using binaries available in the repositories of irontec. For example, for Centos 5/6/7 We create the following file with the following content:
/etc/yum.repos.d/irontec.repo
[irontec] name=Irontec RPMs repository
baseurl=http://packages.irontec.com/centos/$releasever/$basearch/
After that we must install the repository key:
wget http://packages.irontec.com/public.key -q -O - | apt-key add -
And finally install the package:
apt-get update
apt-get install sngrep
Picking up calls
To run sngrep in such a way that we can only capture calls and also include the RTP in them, we must execute them with the following parameters:
sngrep -c -r
With the above, sngrep starts in its main window where we can view the different dialogs:
Again we recommend consulting the documentation since we have the option to execute different actions such as filtering dialogues and recording certain calls.
By entering a particular dialog (by pressing enter on the line) we can access its different messages:
This window is particularly useful since we can navigate through the different messages and observe each of them in detail, being able to view the SIP headers as well as the values found in the messages.
Likewise, pressing F3 In this window we can see the RTP information.
By returning to the main window (by pressing the ESC key) we can access the capture recording dialog by pressing the key yes, it is there where we can indicate the dialogues that will be recorded as well as if we wish to include the RTP in said capture (Note. To record the RTP it is necessary to run sngrep with the -r option).
When downloading the file .pcap It can be opened again in sngrep, tcpdump or wireshark.
Using Wireshark to extract audio
After opening the file in Wireshark we proceed to view the “RTP Streams” in the “Telephony” menu:
We select one of the flows that we want to analyze and ask Wireshark to find the dialog corresponding to the other address using the "Find Reverse" button:
Then we enter the RTP stream analysis dialog using the “Analyze” button:
In this menu we can obtain detailed information on the RTP flow, play the call, find problems with RTP traffic and download the payload, which is nothing more than the recording of the call. It is important to record the call in format .au and include both channels in the recording:
Finally we will obtain an audio file with the desired call:
The interesting thing about this method to access the audio of the call is that the RTP stream is captured directly on the network interface, so in case of audio quality problems there will be more possibilities of providing a diagnosis of the cause of the problem. same. Likewise, it is completely independent of the telephony core that is being used such as Asterisk, FreeSWITCH, Kamailio, etc., since when it is done this way we are only talking about SIP and RTP.
English 
Spanish