tutorial

Monitoring RTPengine with Vigilmon

RTPengine proxies RTP media streams for Kamailio and OpenSIPS deployments — a silent failure causes one-way audio or total call drops across every active session. Here's how to monitor RTPengine's ng protocol port, Prometheus metrics endpoint, and process availability with Vigilmon.

RTPengine (by Sipwise) is a high-performance media proxy for VoIP and WebRTC RTP streams, used as a media relay alongside Kamailio and OpenSIPS to handle NAT traversal, codec transcoding, and media recording. When RTPengine goes down, active calls lose audio — both legs may still signal correctly over SIP while all media is silently dropped. Vigilmon gives you external visibility into RTPengine's management interface, Prometheus metrics endpoint, media relay port availability, and process health so you catch media plane failures before your users report silence.

What You'll Set Up

  • HTTP health check on the RTPengine Prometheus metrics endpoint (/metrics)
  • TCP port monitor for media relay ports
  • Heartbeat monitor for RTPengine process availability
  • SSL certificate expiry alerts for HTTPS management endpoints

Prerequisites

  • RTPengine running with --http-notify or the built-in HTTP interface enabled
  • RTPengine accessible on a public or internal hostname/IP reachable by Vigilmon
  • A free Vigilmon account

Step 1: Enable the RTPengine HTTP Interface

RTPengine includes a built-in HTTP server that exposes a Prometheus-compatible /metrics endpoint when started with the --http-notify or --listen-http flag.

Start RTPengine with HTTP enabled:

rtpengine \
  --interface=eth0 \
  --listen-ng=2223 \
  --listen-http=8080 \
  --foreground

Or in your /etc/rtpengine/rtpengine.conf:

[rtpengine]
interface = eth0
listen-ng = 2223
listen-http = 8080

Verify the metrics endpoint is available:

curl http://localhost:8080/metrics

Expected output (Prometheus text format):

# HELP rtpengine_managed_sessions Current number of managed sessions
# TYPE rtpengine_managed_sessions gauge
rtpengine_managed_sessions 42
# HELP rtpengine_streams_per_call_distribution Distribution of streams per call
...

If you see Prometheus-format metrics, the HTTP interface is working. A timeout or connection refused means the --listen-http flag was not applied or the port is blocked by a firewall.

Step 2: Monitor the Prometheus Metrics Endpoint

  1. Log in to vigilmon.online and click Add Monitor.
  2. Set Type to HTTP / HTTPS.
  3. Enter the URL: http://rtpengine.yourdomain.com:8080/metrics
  4. Set Check interval to 1 minute.
  5. Set Expected HTTP status to 200.
  6. Add a keyword check: must contain rtpengine_managed_sessions.
  7. Click Save.

The keyword check confirms that the RTPengine process itself is running and exporting metrics — not just that the HTTP port is open. A dead RTPengine process causes the HTTP interface to go away entirely, and an improperly started process may return an error page without the expected metric names.

Step 3: Monitor the ng Protocol Control Port (TCP 2223)

RTPengine's ng protocol is the control channel that Kamailio and OpenSIPS use to instruct RTPengine to create, update, and delete media sessions. It listens on UDP port 2223 by default, but a TCP listener can be configured for monitoring purposes.

To add a TCP listener alongside the UDP ng port:

# /etc/rtpengine/rtpengine.conf
listen-ng = 2223
listen-tcp-ng = 2224

Then monitor TCP port 2224:

  1. Click Add Monitor → TCP Port.
  2. Host: rtpengine.yourdomain.com, Port: 2224.
  3. Set Check interval to 1 minute.
  4. Click Save.

Alternatively, if your deployment does not use the TCP ng listener, monitor TCP port 8080 (the HTTP metrics interface) as a proxy for process health — a failed RTPengine process takes down both the ng interface and the HTTP server simultaneously.

Step 4: Monitor Media Relay Ports

RTPengine allocates RTP media ports dynamically from a configured range (typically 30000–40000 or similar). While you cannot monitor individual session ports, you can verify that the host's network stack is healthy by monitoring a well-known port that RTPengine binds on startup:

# /etc/rtpengine/rtpengine.conf
# Reserve a fixed monitoring port at the start of the RTP range
port-min = 30000
port-max = 40000

Some operators bind a static test socket on port 30000 and monitor it via TCP. A more practical approach is to rely on the /metrics endpoint (Step 2) which reports active session counts — a sudden drop to zero with active calls suggests media relay failure even if the process is nominally running.

For deployments with a fixed TURN/SRTP relay port, add a TCP monitor for that port:

  1. Click Add Monitor → TCP Port.
  2. Host: rtpengine.yourdomain.com, Port: your-relay-port.
  3. Set Check interval to 2 minutes.
  4. Click Save.

Step 5: SSL Certificate Expiry Alerts

If RTPengine's HTTP interface or any management reverse proxy in front of it runs over HTTPS, monitor the certificate:

  1. Click Add Monitor → SSL Certificate.
  2. Enter hostname: rtpengine.yourdomain.com.
  3. Set Alert threshold to 14 days before expiry.
  4. Click Save.

For WebRTC deployments using DTLS-SRTP, the certificates used for DTLS negotiation are managed by RTPengine internally and rotated automatically — these do not need external Vigilmon monitoring.

Step 6: Heartbeat Monitor for RTPengine Process Availability

RTPengine can be healthy at the HTTP level but have an internal issue — a stuck worker thread, memory pressure preventing new session allocation, or a kernel module problem (RTPengine uses a kernel module for high-performance packet forwarding). Use a heartbeat monitor driven by an external script that performs an actual ng protocol ping.

Create the heartbeat monitor

  1. In Vigilmon, click Add Monitor → Heartbeat.
  2. Name it RTPengine Process Health.
  3. Set Expected interval to 5 minutes.
  4. Copy the heartbeat URL: https://vigilmon.online/api/heartbeat/YOUR_TOKEN

Send a heartbeat via cron

Create a script that sends a minimal ng protocol ping command and then notifies Vigilmon on success:

#!/bin/bash
# /usr/local/bin/rtpengine-hb.sh

RTPENGINE_HOST="127.0.0.1"
RTPENGINE_NG_PORT="2223"
VIGILMON_HB_URL="https://vigilmon.online/api/heartbeat/YOUR_TOKEN"

# Send ng protocol ping (bencode format)
PING_CMD="d1:vi1e1:l10:pinge1:cl0:ee"
RESPONSE=$(echo -n "$PING_CMD" | nc -u -w2 "$RTPENGINE_HOST" "$RTPENGINE_NG_PORT" 2>/dev/null)

if echo "$RESPONSE" | grep -q "pong"; then
  curl -sf "$VIGILMON_HB_URL" > /dev/null
else
  echo "RTPengine ng ping failed at $(date)" >&2
fi

chmod +x /usr/local/bin/rtpengine-hb.sh

Add a cron job:

# crontab -e
*/5 * * * * /usr/local/bin/rtpengine-hb.sh

Replace YOUR_TOKEN with your Vigilmon heartbeat token. If RTPengine stops responding to ng protocol pings — due to a process crash, kernel module unload, or resource exhaustion — Vigilmon alerts you after 5 minutes without a ping.

Summary

Your RTPengine deployment now has five layers of monitoring:

  1. Prometheus /metrics endpoint — confirms the RTPengine process is running and exporting session data, polled every 60 seconds.
  2. TCP port 2224 (ng TCP) — verifies the control channel interface is reachable.
  3. Media relay port monitor — catches host-level network failures affecting the RTP media plane.
  4. SSL certificate — alerts you 14 days before any management HTTPS certificate expires.
  5. Heartbeat — an actual ng protocol ping confirms RTPengine is accepting control commands, not just that the HTTP server is up.

Vigilmon handles check scheduling, multi-region polling, alert routing, and uptime history. You get notified within 60 seconds of any failure — whether it's a crashed RTPengine process, a kernel module unload, or a network partition silently dropping all media relay traffic.

Monitor your RTPengine infrastructure free at vigilmon.online

#rtpengine #voip #webrtc #monitoring #sip

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles