At some point I needed a fast way to get SIP traffic monitoring into Prometheus β without installing agents on servers, configuring SPAN ports on switches, or being locked into specific software. Just connect to a network interface and see everything happening. With minimal latency and zero impact on telephony performance β monitoring shouldn't become the source of problems.
In this article β how I solved SIP telephony monitoring with eBPF: from packet capture in the Linux kernel to RFC 6076 metrics with breakdown by traffic source and device type in Prometheus/VictoriaMetrics.
HOW IT WORKS
eBPF (extended Berkeley Packet Filter) allows running small programs directly in the Linux kernel. The eBPF verifier guarantees safety: the program cannot exceed allocated memory, cannot loop indefinitely, cannot modify the kernel.
My approach β eBPF socket filter on AF_PACKET. This is passive network traffic observation:
SIP Traffic β NIC β eBPF filter β AF_PACKET socket β Go β SIP Parser β Prometheus Metrics
Key point: the eBPF filter is a socket filter, not a tc/XDP filter. It only decides whether to copy a packet to the application. The packet continues through the network stack to its destination regardless. The filter cannot modify, block, or redirect traffic. Zero impact on call delivery.
The entire filter is 100 lines of C. Ports are configurable from Go code via BPF map, defaults are 5060/5061. eBPF drops 99% of traffic in kernel β only SIP packets on the right ports reach userspace.
THE FULL METRICS STACK
The exporter provides not just RFC 6076 metrics, but a complete observability stack for SIP infrastructure.
Real-time traffic:
β’ 14 SIP request counters: INVITE, BYE, REGISTER, OPTIONS, CANCEL, ACK, SUBSCRIBE, NOTIFY, PUBLISH, INFO, PRACK, UPDATE, MESSAGE, REFER
β’ 30 response code counters: 100, 180, 181, 182, 183, 200, 202, 300, 302, 400, 401, 403, 404, 405, 407, 408, 480, 481, 486, 487, 488, 500, 501, 502, 503, 504, 600, 603, 604, 606
β’ Active sessions gauge β current number of active SIP dialogs. Dialog is created on 200 OK to INVITE, removed on 200 OK to BYE or Session-Expires timeout (default 30 minutes)
Connection quality β RFC 6076:
RFC 6076 defines standard SIP performance metrics. All metrics are cumulative, computed from atomic counters, updated on every scrape.
SER (Session Establishment Ratio) β percentage of successfully established sessions:
SER = (INVITE β 200 OK) / (Total INVITE - INVITE β 3xx) Γ 100
3xx (redirect) are excluded from the denominator β they are neither success nor failure, but a routing instruction. SER = 100 means all non-redirect INVITEs received 200 OK.
SEER (Session Establishment Effectiveness Ratio) β percentage of "effective" responses:
SEER = (INVITE β 200, 480, 486, 600, 603) / (Total INVITE - INVITE β 3xx) Γ 100
The numerator includes responses with a clear outcome: 200 OK (session established), 480 (temporarily unavailable), 486 (busy), 600 (busy everywhere), 603 (declined). SEER is always β₯ SER.
ISA (Ineffective Session Attempts) β percentage of infrastructure errors:
ISA = (INVITE β 408, 500, 503, 504) / Total INVITE Γ 100
408 (timeout), 500 (internal error), 503 (unavailable), 504 (gateway timeout) β server errors. ISA rising means infrastructure is degrading. Unlike SER/SEER, 3xx are NOT excluded from the denominator.
SCR (Session Completion Ratio) β percentage of fully completed sessions:
SCR = (Completed Sessions) / Total INVITE Γ 100
A completed session = INVITE β 200 OK β BYE β 200 OK (or Session-Expires timeout). SCR β€ SER always: not all established sessions terminate correctly.
ASR (Answer Seizure Ratio) β classic telephony metric (ITU-T E.411):
ASR = (INVITE β 200 OK) / Total INVITE Γ 100
Unlike SER, 3xx are NOT excluded. ASR β€ SER when redirect responses are present.
NER (Network Effectiveness Ratio) β network quality (GSMA IR.42):
NER = 100 β ISA
NER = 100 means no infrastructure errors. NER < 95 β time to worry.
Latency at every stage:
Five histograms cover all SIP transaction phases:
β’ RRD β Registration delay: REGISTER β 200 OK
β’ TTR β Time to first response: INVITE β first 1xx
β’ SPD β Session duration: INVITE 200 OK β BYE 200 OK
β’ ORD β OPTIONS response delay: OPTIONS β any response
β’ LRD β Registration redirect delay: REGISTER β 3xx
All histograms support histogram_quantile() for percentile-based alerting: p50, p95, p99.
Example for VictoriaMetrics / Prometheus:
95th percentile registration delay:
histogram_quantile(0.95, sum(rate(sip_exporter_rrd_bucket[5m])) by (le))
99th percentile session duration (specific carrier and device type):
histogram_quantile(0.99, sum(rate(sip_exporter_spd_bucket{carrier="mobile-operator-a",ua_type="yealink"}[5m])) by (le))
Additional metrics:
β’ ISS (Ineffective Session Severity) β absolute count of INVITEβ408/500/503/504 responses. Unlike ISA (percentage), ISS enables alerting on absolute error volume: rate(sip_exporter_iss_total[5m]) > 20
β’ SDC (Session Duration Counter) β Prometheus Counter of completed sessions. Useful for rate queries: rate(sip_exporter_sdc_total[5m])
β’ sip_exporter_packets_total β total parsed SIP packets
PER-CARRIER: METRICS BY TRAFFIC SOURCE
Aggregated metrics hide problems of specific traffic sources. If SER = 85%, it's unclear β are all sources at 85%, or is one at 50% while others are at 95%?
The exporter solves this via CIDR mapping: IP subnets β source name β carrier label on every metric.
Configuration:
carriers:
- name: "telecom-alpha"
cidrs:
- "10.1.0.0/16"
- "10.2.0.0/16"
- "172.16.0.0/12"
- name: "telecom-beta"
cidrs:
- "192.168.10.0/24"
- "192.168.11.0/24"
- "192.168.12.0/24"
How it works:
Carrier is determined at request time (INVITE/REGISTER/OPTIONS) by source IP. If INVITE came from 10.1.5.20 β the exporter finds this IP belongs to 10.1.0.0/16 and labels all metrics for this call (including responses and dialog termination) with carrier="mobile-operator-a".
Responses come from a different IP (the SIP server), but carrier is inherited from the tracker by Call-ID, not determined by response IP. This is correct: metrics belong to the call initiator, not the server.
Result:
sip_exporter_invite_total{carrier="mobile-operator-a",ua_type="other"} 1523
sip_exporter_ser{carrier="mobile-operator-a",ua_type="other"} 95.2
sip_exporter_ser{carrier="sip-trunk-provider",ua_type="other"} 87.4
Now it's clear: the trunk provider has SER = 87.4%, while the mobile operator has 95.2%. You can build separate dashboards and alerts for each traffic source.
IPs not matching any CIDR subnet get carrier="other".
PER-UA-TYPE: METRICS BY DEVICE TYPE
Carrier shows who is calling, but not with what. And device type is often the key factor in problems.
If Yealink phones start getting 408 timeouts while Grandstream works fine β without the ua_type label it would look like a general quality drop. With it β the problem is clearly localized to a specific device type.
Configuration:
user_agents:
- regex: '(?i)^Yealink'
label: yealink
- regex: '(?i)^Grandstream'
label: grandstream
How it works:
The User-Agent header is extracted from each SIP request and matched against regex patterns. When a phone with "User-Agent: Yealink SIP-T46S 66.15.0.10" sends an INVITE β the exporter matches ^Yealink and labels all call metrics with ua_type="yealink".
Like carrier, ua_type is determined at request time and inherited by responses through the tracker by Call-ID.
Result:
sip_exporter_invite_total{carrier="mobile-operator-a",ua_type="yealink"} 1523
sip_exporter_ser{carrier="mobile-operator-a",ua_type="yealink"} 95.2
sip_exporter_ser{carrier="mobile-operator-a",ua_type="grandstream"} 87.4
Combined queries β both labels work together for two-dimensional analysis:
SER for Yealink phones on a specific carrier:
sip_exporter_ser{carrier="mobile-operator-a",ua_type="yealink"}
Active sessions by device type:
sum by (ua_type) (sip_exporter_sessions)
INVITE rate by carrier and device type:
sum by (carrier, ua_type) (rate(sip_exporter_invite_total[5m]))
PERFORMANCE
Load testing was done with SIPp via testcontainers-go β real SIP traffic, not mocks.
Test environment: Debian 12, Linux kernel 6.x, Docker 29.3.1, Intel i7-8665U (4 cores / 8 threads), Go 1.25.9.
Full call lifecycle β each call is a complete SIP dialog: INVITE β 100 Trying β 180 Ringing β 200 OK β ACK β BYE β 200 OK. On loopback each packet is duplicated (send + receive), so 7 messages β 14 packets per call.
With GOMAXPROCS=8 (all cores):
CPS 1,000 β ~11,800 PPS β 8.7% CPU peak, 13 MB RAM, 0% packet loss
CPS 2,000 β ~23,600 PPS β 12.2% CPU peak, 15 MB RAM, 0% packet loss
With GOMAXPROCS=1 (single core):
CPS 2,000 β ~23,600 PPS β 9.2% CPU peak, 12 MB RAM, 0% packet loss
2,000 CPS, 0% packet loss, <12% CPU, ~15 MB RAM.
Scrape performance under 2,000 CPS load (14,000 PPS):
Min: 1.7 ms | Avg: 4.2 ms | P95: 6.4 ms | Max: 8.4 ms
Scraping doesn't interfere with packet processing. You can scrape every 5-10 seconds even at maximum load.
Why it's fast:
β’ eBPF drops 99% of traffic in kernel β only SIP packets on ports 5060/5061 reach userspace
β’ 4 MB socket buffer β fits ~420ms of traffic at 28,000 PPS
β’ Go GC pauses <1ms β 400x smaller than buffer capacity, packets never lost due to GC
β’ SIP parsing ~1ΞΌs β microbenchmarks: INVITE 1.1ΞΌs, BYE 860ns, 200 OK 2.0ΞΌs
System requirements:
Up to 500 CPS β 1 core, 128 MB RAM
Up to 1,000 CPS β 1 core, 128 MB RAM
Up to 2,000 CPS β 2 cores, 256 MB RAM
Above 2,000 CPS β 4 cores, 512 MB RAM
SECURITY: WHY --privileged IS SAFE
The container requires --privileged and network_mode: host. Here's why this is safe.
What capabilities are needed:
β’ CAP_BPF β loading eBPF program into kernel via bpf() syscall
β’ CAP_NET_RAW β creating AF_PACKET raw socket for reading packets
β’ CAP_NET_ADMIN β binding eBPF filter to socket, configuring buffer
These are three specific capabilities for specific operations. All eBPF tools (Cilium, Falco, Pixie) require the same β this is a Linux kernel limitation, not a container one.
What the container does:
β’ Loads eBPF socket filter into kernel (once, at startup)
β’ Creates AF_PACKET raw socket bound to network interface
β’ Reads packets from socket into Go channel (10,000 buffer)
β’ Parses SIP headers
β’ Exports metrics via /metrics endpoint
What the container does NOT do:
β’ Does not modify packets β eBPF filter is passive (read-only)
β’ Does not send SIP traffic β purely a listener
β’ Does not write to host filesystem β all volumes are :ro
β’ Does not access other containers, processes, or system resources
β’ Does not open ports except /metrics (default 2112)
β’ Does not establish outbound connections
The entire eBPF filter is 100 lines of C β fully auditable. Automated vulnerability scanning (govulncheck + Trivy) runs on every push. Current status: 0 vulnerabilities in code and image.
QUICK START
docker run --privileged --network host \
-e SIP_EXPORTER_INTERFACE=eth0 \
frzq/sip-exporter:latest
curl http://localhost:2112/metrics
Or with docker-compose:
services:
sip-exporter:
image: frzq/sip-exporter:latest
privileged: true
network_mode: host
environment:
- SIP_EXPORTER_INTERFACE=eth0
# Optional: per-carrier metrics
# - SIP_EXPORTER_CARRIERS_CONFIG=/etc/sip-exporter/carriers.yaml
# Optional: per-device-type metrics
# - SIP_EXPORTER_USER_AGENTS_CONFIG=/etc/sip-exporter/user_agents.yaml
# volumes:
# - ./carriers.yaml:/etc/sip-exporter/carriers.yaml:ro
# - ./user_agents.yaml:/etc/sip-exporter/user_agents.yaml:ro
Compatible with Prometheus, VictoriaMetrics, and Grafana Cloud β any scraper supporting Prometheus exposition format.
Project: github.com/aibudaevv/sip-exporter (AGPL-3.0)
