SIPCAPTURE Homer

SIP packet capture and VoIP observability, honestly reviewed. Built for telcos, but what does it take to actually run it?

TL;DR

• What it is: Open-source (AGPL-3.0) VoIP and RTC packet capture and monitoring platform, built around the HEP/EEP protocol — think Wireshark plus a call-flow dashboard, running as a persistent service on your infrastructure [2].
• Who it’s for: VoIP engineers, telecom operators, SIP platform teams, and anyone running Kamailio, OpenSIPS, Asterisk, FreeSWITCH, or Cisco vCube who needs searchable call-flow visibility. Not for non-technical founders [4].
• Cost savings vs. commercial monitoring: Commercial VoIP monitoring vendors (like Voipfuture Qrystal) don’t publish pricing, which is its own answer — Homer is free to self-host, which matters when you’re monitoring millions of calls [5].
• Key strength: Carrier-grade scale. Large enterprises, voice network operators, and traffic carriers worldwide run Homer in production. It handles billions of call records with proper infrastructure [1][2].
• Key weakness: Steep technical bar to deploy, a UI that looks like it was designed for NOC engineers in 2015, and real gaps in RTP analysis compared to commercial alternatives — no automatic root cause detection, no accurate MOS scoring at high temporal resolution [4][5].

---

What is SIPCAPTURE Homer

Homer is a packet and event observability framework for VoIP and RTC infrastructure. The name stands for nothing — it’s been the project name since the SIPCAPTURE team built it in 2008 [2]. The core idea: capture every SIP, RTP, and RTCP packet traversing your network, store it in a searchable backend, and visualize it as interactive call-flow ladder diagrams that make troubleshooting a dropped call look like reading a transcript instead of parsing a 10,000-line pcap [1].

The platform isn’t a single binary. It’s a stack:

• HEPlify — a lightweight capture agent you install on the same host as your SIP proxy. It intercepts packets off the network interface and wraps them in HEP (Homer Encapsulation Protocol) before sending them to the collector [1][3].
• HEPlify-Server — the HEP collector and processor. Receives encapsulated packets, parses them, correlates sessions by Call-ID, and writes them to the database [1].
• Homer-APP — the web UI. Search, call flow visualization, RTP quality charts, dashboard building [1].
• PostgreSQL — primary storage for call records in older Homer 7.x deployments [1].
• Prometheus + Grafana — optional (required in the Homer 10 Docker stack) for metrics and dashboards [3].

Homer 10, the current major version, reimagines the platform as headless — it drops SQL databases entirely in favor of standard observability APIs via qryn (an open-source polyglot observability backend), and leans into Grafana as the primary visualization layer instead of the legacy Homer-APP [README]. If you’re used to Homer 7, this is a significant architectural shift. If you’re starting fresh, the Homer 10 Docker Compose stack bundles Homer, Prometheus, Loki, Grafana, and Alertmanager into a single docker-compose up -d [3].

The project is maintained by QXIP BV, a Netherlands-based telecom software company. It has 1,914 GitHub stars, which is modest compared to general-purpose observability tools, but the user base is narrow and specialized — people running production SIP infrastructure don’t spend much time starring repos [2].

---

Why people choose it

The honest answer is that Homer doesn’t compete in a crowded market. For open-source SIP-specific packet capture and call-flow monitoring, Homer and SIP3 are the two serious options. Homer wins that comparison primarily on maturity, protocol breadth, and community size [4].

For the carrier and VoIP service provider use case, Homer is the default answer for a reason. It speaks HEP natively — the same encapsulation protocol that Kamailio, OpenSIPS, Asterisk, FreeSWITCH, and dozens of other SIP platforms can emit directly, without passive packet capture. That means no SPAN port, no port mirroring, no network tap required. Your SIP proxy sends its own traffic to Homer over UDP port 9060, fully correlated by the platform that originated it [1][3].

For the “I’m drowning in SIP logs” use case, the Medium article [3] captures the real pain point: engineers doing SIP troubleshooting typically end up staring at raw log files or pcaps, manually tracing a call-ID through hundreds of messages across multiple servers. Homer turns that into a clickable ladder diagram where every SIP INVITE, 100 Trying, 200 OK, and BYE is a row in a visual sequence. One engineer set it up specifically because combing through logs to troubleshoot SIPp load test scenarios was “the most cumbersome aspect” of the work [3].

Versus commercial alternatives, the Voipfuture comparison page [5] is useful because it’s written by a commercial competitor trying to sell you away from Homer — which means the weaknesses it cites are probably real. Voipfuture claims Homer lacks: RTP monitoring, automatic root cause detection, accurate MOS scoring with high temporal resolution, packet recording with RTP, codec detection at the packet level, and aggregation for trunks and numbering plans [5]. Homer’s own documentation doesn’t rebut these claims. For a telecom operator needing automated impairment detection and per-destination quality trending, Homer requires significant custom work to get there [5].

On the setup friction: VentureGaps [4] cites two reasons users look for Homer alternatives: it “requires significant technical expertise to deploy, configure, and maintain effectively,” and its “user interface is functional but dated and less intuitive than commercial alternatives.” Both are accurate. Homer is not a tool you hand to a support technician — it’s a tool you deploy for support technicians.

---

Features

Based on the README and deployment guides:

Capture and collection:

• HEP/EEP encapsulation — native support in Kamailio, OpenSIPS, Asterisk, FreeSWITCH, and purpose-built capture agents [1][2]
• Passive packet capture via HEPlify agent (no HEP support on the target required) [1]
• SIP signaling, RTCP, RTCP-XR, RTP stats, ISUP, custom protocols [1][2]
• Syslog ingestion and CDR import [README]
• Multi-site, multi-agent deployments — designed for distributed carrier infrastructure [1]

Analysis and visualization:

• Interactive SIP call-flow ladder diagrams with per-message drill-down [1]
• Full-text search across all call metadata [1]
• Session correlation across multiple devices and legs [1]
• Jitter, packet loss, and MOS score monitoring (from RTCP-XR reports — not direct RTP capture) [1]
• Alerting on quality thresholds and error conditions [1]
• Custom dashboard builder [1]

Integration:

• REST API for automation and external integration [1]
• Grafana dashboard export [1][3]
• Prometheus metrics endpoint [3]
• Loki for log aggregation (bundled in Homer 10 Docker stack) [3]

Homer 10 specific:

• Headless observability design — no proprietary UI required, uses Grafana [README]
• qryn backend replaces PostgreSQL for packet storage [README]
• Standard Logs/Metrics/Traces output in realtime [README]
• Full backward compatibility with HEPv3 encapsulation [README]

---

Pricing: SaaS vs self-hosted math

There is no Homer SaaS tier. The software is AGPL-3.0, free to self-host, and the only paid option is professional services from QXIP BV (the company behind the project) for “professional support, remote setups, customizations or commercial licensing” [2].

Commercial VoIP monitoring vendors — the category Homer displaces — do not publish pricing. Voipfuture [5] lists Vodafone UK, Partner Communications, and UTA among its clients. That customer list is a reliable signal that prices start somewhere in the five-figure annual range. Data not available for exact comparison.

Self-hosted Homer infrastructure cost:

For a small to medium VoIP deployment (a few hundred concurrent calls, millions of call records per month):

• VPS or bare metal: $20–80/mo depending on storage and RAM requirements. PostgreSQL for call records grows fast; budget for storage.
• Homer software: $0
• QXIP professional support/deployment: contact qxip.net — no public pricing [2]

For carrier-scale deployments (billions of call records), you’re looking at dedicated infrastructure, possibly object storage backends, and the kind of engineering effort that justifies a QXIP engagement.

The math compared to commercial monitoring: If you have a VoIP engineer on staff who can deploy and maintain Docker stacks, Homer eliminates a monitoring license bill that would otherwise be “contact sales” territory. If you don’t have that person, Homer will cost you the time to find one, which may exceed the commercial license.

---

Deployment reality check

The Docker Compose path is the recommended starting point and it works. The Medium walkthrough [3] documented it in full: clone the homer7-docker repository, cd into the heplify-server/hom7-prom-all directory, run docker-compose up -d, and you get Homer (port 9080), Grafana (9030), Prometheus (9090), Loki (3100), and Alertmanager (9093) as a running stack. Default credentials: admin/sipcapture for Homer, admin/admin for Grafana [3].

What you get out of the box is an empty dashboard waiting for traffic. Getting traffic in requires setting up a capture agent, which is where the complexity lives.

Option 1 — Native HEP client (easiest): If your SIP platform (Kamailio, OpenSIPS, Asterisk) supports HEP natively, you add a few lines of config to start mirroring signaling to Homer’s port 9060/UDP. No additional software needed [1].

Option 2 — HEPlify passive capture (more complex): If your SIP platform doesn’t support HEP, you install the HEPlify capture agent on the same host and configure it to listen on the SIP port range and mirror traffic to the Homer collector. The Medium walkthrough [3] shows the full ERSPAN port-mirroring setup for Cisco vCube — which required ESXi vSwitch configuration, ERSPAN tunnels, secondary network interfaces, and netplan configuration before even touching Homer itself. That’s not Homer’s fault, but it’s the reality of capturing traffic from appliances that don’t speak HEP.

What can go sideways:

• The Klutch.sh guide [1] lists PostgreSQL as a prerequisite you bring yourself (“managed or self-hosted”) — but the Docker Compose stack from the homer7-docker repo bundles it. The documentation fragmentation between Homer 7 and Homer 10 deployment paths is a real friction point. Check which version you’re deploying.
• Homer 10’s headless architecture (no homer-app, Grafana instead) is more powerful but requires Grafana knowledge to build useful dashboards. If you just want the ladder diagrams from Homer 7, you may prefer the older stack [README][3].
• The last commit on the homer7-docker repository was January 2023 according to libreselfhosted [2]. Homer 10 is the actively maintained path — but Homer 10’s documentation and community resources are thinner than Homer 7’s.
• AGPL-3.0 licensing means if you embed Homer in a SaaS product you sell, you must open-source your entire application. This is not an issue for internal monitoring, but it matters for anyone building a commercial VoIP monitoring product on top of Homer [2].

Realistic time estimate: VoIP engineer comfortable with Docker: 2–4 hours to a working Homer instance with traffic flowing. Non-VoIP engineer who knows Docker: 1–2 days including understanding the architecture. No Linux background: this tool is not for you without a specialist.

---

Pros and Cons

Pros

• Carrier-grade, battle-tested. Used in production by large enterprises, voice network operators, and traffic carriers worldwide — this isn’t a hobbyist project [1][2]. The HEP protocol it’s built around is a genuine industry standard supported natively by Kamailio, OpenSIPS, Asterisk, and others.
• Free software for a problem where commercial tools are expensive. Commercial VoIP monitoring doesn’t have a free tier — Homer eliminates that cost entirely if you have the engineering capacity [5].
• HEP protocol is ubiquitous. Native HEP support in every major open-source SIP platform means zero-friction integration for anyone already running Kamailio or OpenSIPS. No SPAN ports, no passive captures required [1].
• Full observability stack in one Docker Compose. The homer7-docker setup brings Homer, Prometheus, Loki, Grafana, and Alertmanager up together — you get metrics, logs, traces, and SIP capture in one command [3].
• Multi-protocol. SIP, RTCP, RTCP-XR, RTP statistics, ISUP, custom protocols, syslog, CDRs — most of what a VoIP platform emits, Homer can ingest [1][2].
• REST API for external automation and integration [1].

Cons

• High technical bar. VentureGaps rates it 7.5/10 and explicitly lists “requires significant technical expertise to deploy, configure, and maintain effectively” as the primary reason users look for alternatives [4]. This is not a tool for non-technical operators.
• Dated UI. The Homer-APP interface looks like a monitoring tool from 2015, because it largely is. VentureGaps flags it as “functional but dated and less intuitive than commercial alternatives” [4]. Homer 10’s answer is to replace homer-app with Grafana, which trades familiarity for flexibility.
• No RTP monitoring. Voipfuture documents this explicitly: Homer “does not support RTP monitoring” — it works from SIP signaling and RTCP-XR reports, not direct RTP stream analysis [5]. For operators who need in-call audio quality visibility at the packet level, this is a meaningful gap.
• No automatic root cause detection. Manual investigation is the workflow — Homer shows you the call flow, you figure out what broke [5]. Commercial tools that auto-detect impairments (silent calls, dropped calls, codec mismatches) require significant custom work to replicate.
• MOS accuracy limitations. Homer can surface MOS scores from RTCP-XR reports if your endpoints send them. It cannot compute accurate MOS with high temporal resolution from raw packet analysis the way Voipfuture claims to [5].
• Documentation fragmentation. Homer 7 and Homer 10 have different architectures, different deployment paths, and documentation scattered across GitHub wikis, Medium posts, and third-party guides. The official wiki is the right starting point, but expect to reconcile conflicting information.
• AGPL-3.0 copyleft. Not a problem for internal use, but a hard blocker for anyone building a commercial product on top of Homer without a commercial license from QXIP [2].
• Activity concerns. Some satellite repositories (like homer7-docker) show last commits in early 2023 [2]. The core project is still maintained, but the cadence is slow compared to general-purpose observability tools.

---

Who should use this / who shouldn’t

Use Homer if:

• You’re running a SIP-based platform (Kamailio, OpenSIPS, Asterisk, FreeSWITCH, Cisco vCube) and you need searchable call-flow visibility for troubleshooting.
• You have VoIP engineering staff who can deploy and maintain Docker stacks and understand SIP enough to interpret what Homer shows them.
• You’re currently paying a commercial monitoring vendor or are evaluating one, and the cost is a problem.
• Your SIP platform already speaks HEP — integration is then a configuration change, not an infrastructure project.
• You’re a telecom startup building out monitoring infrastructure from scratch and you want carrier-grade tooling without the carrier-grade license bill.

Skip it if:

• You’re a non-technical founder who wants visibility into a VoIP or UCaaS stack. The deployment and operational complexity will consume more time than the insight is worth.
• You need automated impairment detection, per-trunk quality trending, or accurate RTP-level MOS scoring. Homer’s capabilities stop at signaling correlation and RTCP-XR report visualization [5].
• Your SIP infrastructure is hosted entirely on a managed UCaaS platform (Twilio, RingCentral, Vonage) with no self-hosted SIP proxy. Homer has nothing to capture.
• You’re building a commercial VoIP monitoring product and need to keep your source code proprietary — AGPL-3.0 makes that complicated [2].
• Your compliance or legal team won’t approve running monitoring software under AGPL without an assessment.

---

Alternatives worth considering

From the VentureGaps alternatives list [4] and the Voipfuture comparison [5]:

• SIP3 — the other serious open-source VoIP monitoring option. Rates 6.5/10 on VentureGaps [4]. Smaller community than Homer, but actively maintained and purpose-built for the same use case. Worth evaluating if Homer’s architecture doesn’t fit your stack.
• Routr — open-source SIP proxy and registrar [4]. Solves a different problem (SIP routing, not monitoring), but often deployed alongside Homer in small SIP infrastructure setups.
• Voipfuture Qrystal — the commercial alternative Homer is explicitly compared against [5]. Has RTP monitoring, automatic root cause detection, accurate MOS scoring, and enterprise support. No public pricing, but trusted by Vodafone UK and Partner Communications. The right choice if you have the budget and need the automation that Homer doesn’t provide.
• Grafana + Prometheus + Loki — Homer 10 actually uses this stack for metrics and logs. For teams already deep in Grafana observability, the question is whether you need Homer’s SIP-specific correlation layer or whether your existing stack is sufficient.
• Commercial UCaaS platform analytics — if you’re running on Twilio, RingCentral, or similar, their built-in analytics dashboards eliminate the need for self-hosted monitoring infrastructure entirely.

---

Bottom line

Homer is the right tool for a specific, narrow audience: VoIP and telecom engineers who run open-source SIP infrastructure, have the Linux and Docker skills to deploy it, and want carrier-grade call-flow visibility without a vendor contract. For that audience, it’s genuinely strong — battle-tested at scale, HEP-native, and free. For anyone outside that audience, the deployment complexity and the UI age are real costs that compound against Homer’s advantages. The gap between what Homer does (SIP correlation and call-flow visualization) and what commercial tools do (automated impairment detection, RTP-level analysis, root cause attribution) is real and documented [5]. If you need those capabilities, Homer will require significant engineering work to approximate them. If you don’t — if you just need to answer “why did this call fail” by looking at a ladder diagram — Homer does that job reliably and for free.

---

Sources

1. Klutch.sh Docs — “Deploying SIPCAPTURE Homer” (deployment guide with architecture overview). https://docs.klutch.sh/guides/open-source-software/sipcapture-homer/
2. Libre Self-hosted — SIPCAPTURE Homer project listing (community stats, license, core feature summary). https://libreselfhosted.com/project/sipcapture-homer/
3. Jeremy Worden, Medium / Automate Builders — “Capturing Cisco vCube SIP messages with Homer” (Aug 5, 2023, hands-on deployment walkthrough). https://medium.com/automate-builders/capturing-cisco-vcube-sip-messages-with-homer-9b4beb10df70
4. VentureGaps — “Best SIPCAPTURE Homer Alternatives in 2026” (ratings and user-cited limitations). https://www.venturegaps.com/alternatives/sipcapture-homer
5. Voipfuture — “Voipfuture vs. Homer” feature comparison (commercial competitor comparison documenting Homer capability gaps). https://www.voipfuture.com/voipfuture-vs-homer/

Primary sources:

• GitHub repository and README: https://github.com/sipcapture/homer (1,914 stars, AGPL-3.0)
• Official website: https://www.sipcapture.org/
• QXIP commercial support: https://qxip.net