AI and VoIP Blog

RTPEngine is a powerful media relay for VoIP applications, and effective logging is crucial for monitoring and troubleshooting. This post covers how to manage RTPEngine log levels, including setting them at startup and/or adjusting them dynamically.

Understanding RTPEngine Log Levels
RTPEngine uses the standard syslog log levels, defined as follows:

Value	Name	Description
0	LOG_EMERG	System is unusable (highest priority).
1	LOG_ALERT	Immediate action required.
2	LOG_CRIT	Critical conditions (e.g., hardware errors).
3	LOG_ERR	Non-critical errors (e.g., failed services).
4	LOG_WARNING	Warning: Potential issues.
5	LOG_NOTICE	Significant but normal events.
6	LOG_INFO	Informational messages (default level).
7	LOG_DEBUG	Debug: Detailed debug messages (logs all).

By default, RTPEngine logs at LOG_INFO (6). Setting the log level higher (e.g., 7) increases verbosity, useful for debugging. Lower levels focus on critical issues.

Understanding RTPEngine Subsystem
RTPEngine has multiple subsystems that are used to handle different functionalities . We can update the log level of the system as a whole or we can change subsystem level logging to debug specific module. To check the different subsystems and there log levels we can use the rtpengine-ctl tool as shown below:

rtpengine-ctl list loglevels
core - Everything that isn't part of another subsystem
spandsp - Log messages generated by SpanDSP directly
ffmpeg - Log messages generated by ffmpeg directly
transcoding - Media and RTP transcoding
codec - Codec negotiation
rtcp - RTCP handling
ice - ICE negotiation
crypto - Negotiation of SRTP, crypto suites, DTLS, SDES
srtp - SRTP encryption and decryption
internals - Noisy low-level internals
http - HTTP, HTTPS, Websockets
control - Control protocols including SDP exchanges, CLI
dtx - DTX timer/buffer

Default log levels are given below:

rtpengine-ctl list loglevel
core = 6
spandsp = 6
ffmpeg = 6
transcoding = 6
codec = 6
rtcp = 6
ice = 6
crypto = 6
srtp = 6
internals = -1
http = 6
control = 6
dtx = 6

There are two ways to set the debug log levels:
1.Runtime
2.Startup
Lets go through both options one by one.

1. Runtime
Step 1: Check Current Log Levels
Before making any changes, list and document the current log levels to ensure you can restore them later if required. Use the following command:

rtpengine-ctl list loglevel

• 6 (LOG_INFO): Default informational logging level.
• -1: Logging disabled for the internals subsystem by default.
Take a note of these values before proceeding with adjustments.

Step 2: Setting Log Levels Globally
To apply the same log level across all subsystems dynamically, use the rtpengine-ctl utility.

Set Global Log Level

rtpengine-ctl set loglevel <level>
Example
rtpengine-ctl set loglevel 7

• 7 (LOG_DEBUG): Enables detailed debug logging for all subsystems.
• 6 (LOG_INFO): The default, less verbose level for production.
• -1: Disables logging for all subsystems.

Verify Changes
After applying the new log level, verify the result with:

rtpengine-ctl list loglevel

Step 3: Adjusting Log Levels for Specific Subsystems
If you need to modify the log level for individual subsystems, you can do so without affecting the others.

List Subsystems
View all available subsystems and their purposes:

rtpengine-ctl list loglevels

Set Log Level for a Specific Subsystem

rtpengine-ctl set loglevel <subsystem> <level>
Example
rtpengine-ctl set loglevel srtp 7

This increases verbosity for the SRTP subsystem only, enabling detailed debug logs for SRTP encryption and decryption.

Verify Changes
Check the updated log levels to confirm:

rtpengine-ctl list loglevel

Step 4: Restore Defaults
• Refer to your initial note of the log levels (or the default values provided earlier).
• Use the rtpengine-ctl set loglevel command for global or specific subsystem adjustments.

Examples 
Global:
rtpengine-ctl set loglevel 6
Subsystem:
rtpengine-ctl set loglevel srtp 6
rtpengine-ctl set loglevel internals -1

Monitoring and Debugging
1. Monitor Logs:
Use tail to monitor real-time RTPEngine logs and verify verbosity. The logfile depends on youre configuration.

tail -f /var/log/syslog
or
tail -f /var/log/rtpengine.log

2. Startup
At Startup we can use the -L, –log-level=INT flag to define the system level log level. To define log level per sub-system we can use –log-level-subsystem=INT flag.

Example:
rtpengine –log-level=6
rtpengine -L 6

2. Best Practices:
• Use LOG_DEBUG (7) or higher sparingly to avoid overwhelming logs.
• For production, stick to LOG_INFO (6) or lower.
• Disable unnecessary subsystems (-1) to reduce log noise.

Summary
1. Always Check the Current Log Levels First:
Use rtpengine-ctl list loglevel to document the current configuration.
2. Set Global Log Levels:
Apply the same log level across all subsystems with rtpengine-ctl set loglevel.
3. Adjust Specific Subsystems:
Modify individual subsystem log levels dynamically for precise control.
4. Restore Defaults:
Revert to default settings based on your notes or the provided defaults.

By following these steps, you can manage RTPEngine’s logging behavior effectively and confidently.

Additional Links
Syslog Documentation
RTPEngine Documentation

Let me know if you have any questions or share your tips in the comments!
Got questions or want to share tips? Let’s discuss in the comments below!

Akash Gupta
Senior VoIP Engineer and AI Enthusiast

---