Sniffer manual

Introduction

This manual describes installation and configuration of the VoIPmonitor C++ sniffer. If you are looking for WEB GUI manual, go to http://www.voipmonitor.org/download section. The upgrade procedure from version 4.2 and 5.0 is described at the end of this manual. What's new is at the end of this manual. VoIPmonitor is open source network packet sniffer for SIP and RTP VoIP protocol running on linux. VoIPmonitor was designed to analyze quality of SIP calls based on network parameters - delay variation and packet loss according to ITU-T G.107 E-model which predicts quality on MOS scale. Calls with all relevant statistics are saved to MySQL or ODBC enabled database. Each call can be optionaly saved to pcap file with either only SIP protocol or SIP/RTP/RTCP protocols. VoIPmonitor can also decode sound and play it over the commercial WEB GUI or save it to disk as WAV. Supported codecs are G.711 alaw/ulaw and commercial plugins supports G.729a/G.723/iLBC/Speex/GSM. VoIPmonitor uses jitterbuffer simulator to keep both direction of call synchronized.

VoIPmonitor is C++ program designed to handle thousands of simultaneous calls. It listens on network interface and analyzes all SIP calls on defined SIP ports (default 5060). RTP streams which carries voice are analyzed for packet loss and variation delay (jitter). Each call is saved to MySQL or to any database supporting ODBC. SIP signalization and RTP packets can be saved to individual pcap file which can be opened with analyzers like wireshark and is also used by VoIPmonitor GUI.

Scaling

VoIPmonitor is able to use all available CPU cores but there are several bottlenecks which you should consider before deploying and configuring VoIPmonitor.

CPU bound

The top most consuming CPU is first thread which reads packets from kernel. If you have very large traffic above ~500 Mbit you should check if the first thread is not droping packets by checking syslog where the sniffer is reporting any drop occurences. If you have much more traffic and the CPU is not able to handle, you can use special kernel modules and drivers which supports hardware acceleration for sniffing very large traffic – but this is only case when your traffic is very large (~5000 simulatenouse calls) Second top most consuming CPU is threads processing jitterbuffer simulator. In case you do not have enough CPU cores (one or two only) you can turn off jitterbuffer simulator in configuration and keep enabled only one (f2) or turn it off completely. If you have enough CPU cores (at least 4) you should not worry about CPU.