After installing Kamailio and configuring the basic settings, the key step is to ensure proper monitoring and debugging of SIP traffic. With these tools, you will be able to better understand how Kamailio processes calls, identify issues, and optimize system performance.
In this post, I will show you how to enable and configure various SIP monitoring options in Kamailio, such as logging SIP messages, using traffic analysis tools, and activating debugging mode. With these techniques, you will be able to effectively track and troubleshoot potential issues in your communications infrastructure.
This post is a continuation of the Kamailio series. You can find the previous article here: Kamailio part 1: Install Kamailio 6 on Debian 12 (with MySQL support)
Spis treści
1) Prerequisites
Of course, there are many tools that allow you to monitor SIP packets or collect application logs. Today, we will focus on a few of the simplest tools:
- tcpdump – a tool for capturing and analyzing network packets (including SIP communications)
- sngrep – a tool for displaying the flow of SIP call messages from the terminal
- rsyslog – a service for collecting logs
Let’s take a closer look at them.
2) tcpdump
If you want to capture SIP traffic and analyze it later in Wireshark, tcpdump is the perfect tool for this purpose. Kamailio, as a powerful SIP server, requires thorough packet analysis for debugging and optimization.
If you don’t already have tcpdump, you can install it using the command:
apt install tcpdump
An example command might look like this:
tcpdump -n -s0 port 5060 or port 5061 -vvv -w /path/to/sip_logs.pcap
Here is the explanation of the above command:
- -n – disables hostname resolution, which speeds up capture
- -s0 – sets the size of the captured packet to the maximum (by default, tcpdump cuts packets to 65535 bytes)
- port 5060 – captures SIP traffic for the UDP protocol
- -vvv – enables a more detailed packet display mode
- -w /path/to/sip_logs.pcap – saves captured packets to a .pcap file, which can be opened later in Wireshark
Of course, there are many more capture possibilities. Below are some examples.
Capturing only INVITE and REGISTER messages:
tcpdump -s0 -A port 5060 | grep -E 'INVITE|REGISTER'
Filtering SIP traffic from a specific SIP client (by IP address):
tcpdump src host 192.168.1.100 and port 5060
Collecting traffic for a specific SIP domain:
tcpdump -s0 -A port 5060 | grep 'sip:example.com'
Monitoring SDP packets in SIP requests:
tcpdump -s0 -A port 5060 | grep 'm=audio'
Monitoring multiple protocols simultaneously (e.g. UDP/5060, TCP/5060, TLS/5061):
tcpdump port 5060 or port 5061
Of course, there are many more possibilities. Here we simply want to indicate the different options for using the tcpdump tool.
For more information, see the official documentation.
3) sngrep
sngrep is an ideal tool for live SIP traffic analysis and VoIP call history research. Unlike tcpdump, which captures all packets, sngrep focuses on the application layer of the SIP protocol, allowing you to conveniently track sessions in a readable form.
Key sngrep features:
✅ Captures and displays SIP messages in real time
✅ Visualizes complete VoIP sessions in a call tree
✅ Allows you to filter packets by numbers, IP addresses, and SIP methods
✅ Supports exporting captured messages to .pcap files for further analysis in Wireshark
✅ Allows you to easily debug registration, codec negotiation, and signaling issues
You can compile the sngrep package manually or install it directly from the repository.
apt install sngrep
Below are some examples.
Capturing all SIP packets:
sngrep
SIP user registration monitoring and analysis:
sngrep -f "sip.method == REGISTER"
Tracing SIP messages on port 5060 and saving to file:
sngrep -p 5060 sngrep -I /path/to/capture.pcap
You can find more information about this tool in the official repository on Github.
4) rsyslog and configuring debugging in Kamailio
After capturing SIP packets with tools like tcpdump and sngrep, the next step in Kamailio diagnostics is to collect and analyze logs directly from our application. By default, Kamailio uses a system logging mechanism such as syslog, which can be easily configured with rsyslog to store and filter logs in dedicated files.
If you don’t have the rsyslog service yet, let’s install it first, add a new log file, grant the appropriate permissions, and add the service to autostart.
apt install rsyslog
systemctl enable rsyslog
touch /var/log/kamailio.log
chown kamailio: /var/log/kamailio.log
If you want a dedicated rsyslog file for Kamailio, you can set up log capture in a new file, e.g. /etc/rsyslog.d/kamailio.conf. You can also just add an extra line at the end of /etc/rsyslog.conf.
echo "local0.* -/var/log/kamailio.log" >> /etc/rsyslog.conf
The above command has the following parameters:
- local0.* – all logging levels (*) for
LOG_LOCAL0are to be logged.LOG_LOCAL0is a special logging category that we set in Kamailio (log_facility=LOG_LOCAL0inkamailio.cfg) - -/var/log/kamailio.log – path to the file where the logs will be written. “-” before the path means that rsyslog will use buffered write mode (reduces the impact on system performance)
- >> /etc/rsyslog.conf – we will save the configuration to the global rsyslog configuration file
After editing the rsyslog.conf file, you need to restart rsyslog for the changes to take effect:
systemctl restart rsyslog
From now on you can follow Kamailio logs, preferably in a separate terminal window.
tail -f /var/log/kamailio.log
To make sure Kamailio generates the correct logs, you need to adjust the configuration in the kamailio.cfg file. Depending on your configuration, the file may be located at /etc/kamailio/kamailio.cfg.
Find the location of the debug configuration there.
Here’s what the different logging settings in the kamailio.cfg file mean:
- Logging level (
debug=DBGLEVEL)- 3 = DBG (Debug) – the most detailed logs (for debugging)
- 2 = INFO – general information about the server’s operation
- 1 = NOTICE – important messages, but not yet warnings
- 0 = WARN (Warning) – warnings about potential problems
- -1 = ERR (Error) – errors that require attention
- Logging to standard output (
log_stderror=no)- no – logs are written to syslog instead of being displayed in the terminal
- yes – logs will be printed to the terminal (or you can use the
kamailio -Ecommand)
- Memory diagnostics
- memdbg=5 – memory debugging level (5 = high verbosity)
- memlog=5 – control logging of memory events
- Logging via syslog/rsyslog (
log_facility=LOG_LOCAL0)- LOG_LOCAL0 – defines the logging category, which allows you to filter logs in rsyslog (the
local0.* -/var/log/kamailio.logline described above)
- LOG_LOCAL0 – defines the logging category, which allows you to filter logs in rsyslog (the
- Prefix format in logs (
log_prefix="{$mt $hdr(CSeq) $ci} ")- The default log format will start with information about the SIP message type (
$mt), CSeq header ($hdr(CSeq)) and Call-ID dialog identifier, allowing you to track the SIP session ($ci). You can throw any variables here that you consider practical. You can find their list e.g. in this list.
- The default log format will start with information about the SIP message type (
Thanks to these settings, you can precisely control the logging level, log formatting and how they are stored. If you want more details – increase debug=3 and set log_stderror=yes. If you want to reduce the load on the system – set debug=1 and save logs to a dedicated file via rsyslog.
It should be noted, however, that the default setting for the debug variable is not a numeric value, but the DBGLEVEL variable. It is defined in the code a bit earlier and has a default value of 2.
Of course, you can set it manually. You can also use the WITH_DEBUG variable definition to control the logging level more quickly. Just add a new definition at the beginning of the code.
#!define WITH_DEBUG
This allows you to change the debugging level very quickly.
5) Tracing routing with xlog()
Kamailio allows dynamic event logging in routing scripts using the xlog module. This is useful for debugging and tracking the flow of SIP messages in a configuration.
An example entry could look like this:
xlog("L_INFO", "Authenticating REGISTER - ask for password");
As a result, additional information will start appearing in the kamailio.log file.
The xlog([ [facility,] level,] format) function allows you to write a message to Kamailio logs at a specified level of detail. The simplest configuration can consist of three parameters:
- facility – specifies which log category (syslog facility) the message will be assigned to
- level – level of logging detail (e.g. L_INFO, L_ERR)
- format – message content, in which SIP variables can be used
A sample command might look like this:
xlog("L_INFO", "Received SIP: $rm from $si");
To check all possible options for using xlog() or alternatives like xdbg(format), xinfo(format), xnotice(format), xwarn(format), xerr(format), xbug(format), xcrit(format), xalert(format) I recommend reviewing the document https://kamailio.org/docs/modules/6.0.x/modules/xlog.html
In this part of the series, we have shown how to enable SIP monitoring and traffic debugging in Kamailio. By activating the appropriate logging features and debugging tools, you gain full control over the analysis of SIP messages and can easily diagnose connection problems. Monitoring is a key element in managing large Kamailio installations, and its implementation allows for faster error detection and system optimization. Of course, the possibilities are much greater, and the best friend will be, of course, Kamailio Cookbook.
In the next post, we will install Siremis – a graphical interface for Kamailio.
If you would like to monitor everything that happens at your PBX, try our proprietary VoiperoManager software.
Installation and configuration takes just a few minutes, and you can have the system completely free of charge.
Read what our VoiperoManager system can do in terms of live monitoring and reporting of Asterisk-based VoIP systems.
