SIPCAPTURE Homer 11.0.369 介绍与选型指南

SIPCAPTURE Homer 11（homer eleven）开源 SIP/VoIP 抓包监控平台介绍与选型指南：单体四模块架构、DuckLake 湖仓、版本演进、与 SIP3 及 Homer 7 遗产版对比，基于 11.0.369 官方渠道溯源。

SIPCAPTURE HomerSIPVoIP2026/10/27

SIPCAPTURE Homer 11.0.369 介绍与选型指南

SIP/VoIP 通信链路一旦出现"电话接不通、语音单通、注册掉线"这类问题，靠逐台服务器翻日志效率极低。SIPCAPTURE Homer 是业界最知名的开源 SIP/VoIP 抓包监控平台，通过 HEP 协议集中采集信令与媒体质量数据，提供全量事务检索、呼叫流图与 QoS 分析能力。本文基于 Homer 11 系列（homer eleven）的最新稳定版本 11.0.369，从架构、特性、部署形态到同类竞品逐一梳理，帮助读者快速判断它是否适合自己的 VoIP 监控场景。本文所有信息均来自官方渠道联网溯源，并标注来源与查询日期； hands-on 实操内容见本专栏后续安装、部署与配置各篇。

一、环境信息

本文为组件介绍与选型篇，信息来源与查询时间如下：

项目内容
组件名称SIPCAPTURE Homer（homer eleven）
溯源版本11.0.369（2026-10-25 发布，GitHub Releases 最新稳定版）
软件许可AGPL-3.0
维护方QXIP BV（SIPCAPTURE 社区，2010 年至今）
官网https://sipcapture.org
源码仓库https://github.com/sipcapture/homer
本文撰写日期2026-10-26
信息来源GitHub 仓库/Releases、官方 README 与 docs/ 目录、sip3.io 官网（详见文末参考链接）

说明：Homer 11 系列（代号 homer eleven）与广泛流传的 Homer 7 架构完全不同，选型时务必以本文描述的 11.x 为准，历史版本差异见「二、软件概述」。

二、软件概述

2.1 项目定位

HOMER（SIPCAPTURE Homer）是一个运营商级（carrier-grade）的开源 VoIP/RTC 抓包与监控平台，基于 HEP/EEP（Homer Encapsulation Protocol）协议采集信令、RTC 事件、日志与统计数据，提供即时检索、端到端分析与逐层下钻（drill-down）能力。项目由 QXIP BV 自 2010 年前后启动并持续维护至今，已被大量企业、语音网络运营商、VoIP 服务商与流量承载商用于生产环境（来源：GitHub 仓库 README，查询日期 2026-10-26）。

截至 2026-10-26，项目 GitHub 主仓库约 2k stars、292 forks，最新稳定版本为 11.0.369（2026-10-25 发布），发版节奏保持在数日一版的活跃状态（来源：GitHub Releases Atom 源与 shields.io徽章数据，查询日期 2026-10-26）。

2.2 版本演进：从"多组件套件"到"单体数据湖"

理解 Homer 的版本线是选型的第一步，其架构在十多年间经历了四次重大重构：

版本线架构形态核心组件
Homer 5抓包探针 + Kamailio HEP 投递 + MySQL + PHP Web UIcaptagent / kamailio / homer UI
Homer 7模块化组件套件heplify-server（HEP 采集）+ homer-app（API/UI）+ PostgreSQL + InfluxDB + heplify 采集代理
Homer 10无头（headless）可观测方案heplify-server + Grafana 可视化，不再内置自有 UI
Homer 11（homer eleven）Go 语言单体全栈单二进制 homer-core 集成 Ingest + Storage + Node + Coordinator 四模块，存储引擎全面转向 DuckDB + DuckLake 数据湖

（来源：GitHub 仓库各版本 README 与 docs/ 目录，查询日期 2026-10-26）

11.x 的关键转变在于：不再依赖 PostgreSQL/InfluxDB 等外部数据库，改为内置 DuckDB 分析引擎与 DuckLake 湖仓架构（Parquet 数据文件 + SQLite catalog），并将采集、存储、查询节点与协调器合并为一个二进制。这意味着部署半径大幅缩小，而横向扩展能力通过 Coordinator 多节点路由实现。

2.3 采集代理

Homer 平台自身不抓网卡包，而是接收由采集代理通过 HEP 协议投递的数据。官方维护的采集代理为 heplify（Go 编写，当前 2.0.x 系列），可在目标主机上以极低开销采集 SIP/RTP/RTCP 流量并封装为 HEPv3 投递到 Homer；Kamailio、FreeSWITCH、Asterisk 等软交换也普遍内置 HEP 投递能力，可直接向 Homer 发送信令副本（来源：GitHub 仓库 README 与 heplify 发布页，查询日期 2026-10-26）。

三、核心架构

3.1 四模块单体架构

homer eleven 将原先分散的组件收敛为四个模块，可拆可合——单机 all-in-one 运行，或按 writer/edge/coordinator/node 角色拆分部署：

capture agent (heplify / Kamailio / FreeSWITCH ...)
        │  HEPv2 / HEPv3 / protobuf
        ▼
┌────────────────────────── homer-core 单进程 ──────────────────────────┐
│                                                                       │
│  Ingest 模块          Storage 模块            Node 模块               │
│  UDP/TCP :9060   ──►  DuckLake 数据湖   ◄──   Airport gRPC :50051      │
│  HTTP    :9080        (Parquet + SQLite         (查询服务,            │
│  TLS     :9061         catalog)                  HTTP /query :50052)  │
│                              │                                        │
│                      Coordinator 模块                                  │
│                      REST API + Web UI :8080                          │
│                      Prometheus /metrics :9090                        │
└───────────────────────────────────────────────────────────────────────┘
  • Ingest（采集）：监听 UDP/TCP 9060 接收 HEPv2/HEPv3/protobuf 报文，HTTP 9080 接收 JSON/批量投递并支持 WebSocket，支持多核放大与去重，可对 SIP 方法做脱敏或丢弃策略。
  • Storage（存储）：基于 DuckDB 1.5 与 DuckLake 湖仓格式，数据以 Parquet 列式文件落盘，SQLite 作为 catalog；支持批量化写入（batch_size）、定时 flush、分区压缩（compaction）与按表数据保留（retention）策略，并可将冷分区归档到 S3 兼容对象存储实现冷热分层。
  • Node（查询节点）：对外暴露 Airport gRPC 服务（默认 50051，配套 HTTP /query 在 50052），接收 Coordinator 下发的查询并返回 Apache Arrow 结果集；可选启用 FlightSQL 端口（50055，默认关闭）供外部 BI 工具直连。
  • Coordinator（协调）：面向 UI 与外部调用方的 REST API 网关（8080 端口，v1/v3/v4 三代端点并存），负责 JWT 认证、用户/仪表盘设置存储（内置 DuckDB settings 库）、多节点查询路由与结果汇聚，并内置可选的 Web 静态界面与 MCP server。

（来源：GitHub 仓库 README、docs/COORDINATOR.md、examples/homer.json 默认配置，查询日期 2026-10-26）

3.2 数据流与查询路径

写入路径上，HEP 报文经 Ingest 解析后进入内存缓冲，按 batch_size 或 flush_interval_sec 定期以列式 Parquet 追加进 DuckLake；查询路径上，Coordinator 收到 REST 搜索请求后，按时间窗口将查询路由（可启用 smart_routing 按节点数据范围裁剪）到一个或多个 Node 的 Airport 端口，Node 直接对 Parquet/湖仓执行向量化查询并回传 Arrow 结果，由 Coordinator 聚合后返回 JSON。这种"一写多读、列存直查"的路径避免了传统方案中 OLAP 数据库的中转开销（来源：docs/COORDINATOR.md、docs/SEARCH.md，查询日期 2026-10-26）。

3.3 多节点与智能路由

Coordinator 可配置多个远端 Node（按 name/host/port/token/priority），将查询扇出并汇聚；可选开启 smart_routing，依据各节点上报的数据时间范围（GET /metadata/stats）跳过与查询窗口不重叠的节点，例如"最近 15 分钟"的检索不会再唤醒只存冷归档的节点，但带历史回灌（pcap 回放）场景需关闭该选项以免漏查（来源：docs/COORDINATOR.md，查询日期 2026-10-26）。

四、功能特性

基于官方 README 与 docs/ 目录（查询日期 2026-10-26），homer eleven 的主要特性如下：

  • 多协议采集：SIP 信令、RTP/RTCP 流统计、RTCP-XR、SIPREC（内置录音流解析）、QoS 指标、syslog、CDR 与自定义协议，兼容 HEPv2/HEPv3/protobuf 三代封装。
  • 湖仓存储：DuckLake（Parquet + SQLite catalog）单机或对象存储（S3 兼容）后端，冷热分层与 tiering 策略内置。
  • 数据生命周期：分区压缩（compaction）按 check_interval 周期合并小文件；按表粒度的保留天数（retention_days_by_table）自动清理过期数据；快照定期过期。
  • 完整 REST API：v1/v3/v4 三代端点覆盖认证（JWT/OAuth2）、事务搜索、消息详情、QoS、仪表盘、告警、用户、映射、统计与健康检查，官方提供 openapi.yaml 描述文件。
  • 内置 Web UI：镜像内打包 UI 静态资源（static_path 指向 dist），开箱即得事务搜索、呼叫流、QoS 视图与仪表盘。
  • MCP server：内置 MCP（Model Context Protocol）服务端，可被 AI 助手直接调用检索话务数据。
  • 多角色部署向导：homer wizard 提供 all-in-one / writer / edge / coordinator / node 五种配置档案，一键生成对应 homer.json。
  • 运维友好：Prometheus /metrics 指标端点、结构化 JSON 日志、homer system 子命令执行压缩/快照过期/配置重载、homer catalog 备份恢复湖仓目录。
  • 安全基线：管理员口令支持 SHA-256 哈希环境变量注入（HOMER_COORDINATOR_AUTH_ADMIN_PASSWORD_HASH），首次启动未注入时自动生成一次性随机口令并仅在日志打印一次；历史默认口令 sipcapture 已废弃；镜像默认以 uid 1000 非 root 运行并 drop 全部 capabilities。

五、快速开始

以下为官方 README 与 examples/docker 目录给出的两条主路径概览（来源：GitHub 仓库 README 与 examples/docker/README.md，查询日期 2026-10-26；逐命令实操见本专栏安装与部署篇）：

5.1 方式一：软件包安装（单机 all-in-one）

官方发布 .deb/.rpm 软件包，安装后得到 /usr/local/homer-core/bin/homer 单二进制与 systemd 单元（homer-core.service）。以 Debian/Ubuntu 为例的要点：

# 安装 deb 包后，复制示例配置并启动
cp /usr/local/homer-core/etc/homer.json.example /usr/local/homer-core/etc/homer.json
systemctl enable --now homer-core
# 健康检查
curl http://127.0.0.1:8080/health

Web 界面默认在 8080 端口。首次登录的管理员口令二选一：启动前通过 HOMER_COORDINATOR_AUTH_ADMIN_PASSWORD_HASH（口令的 SHA-256 hex）注入，或首次启动后从日志 bootstrap_password 行读取一次性随机口令。

5.2 方式二：Docker Compose（官方示例栈）

官方 examples/docker/docker-compose.yaml 提供"本地 Parquet 热存储 + RustFS S3 冷存储"的完整栈，包含 homer 主容器、rustfs 对象存储与两个初始化容器：

cd examples/docker
docker compose -f docker-compose.yaml up -d

栈内 homer 容器约需 8GB 内存（DuckDB writer 默认 MEMORY_LIMIT=4GB）。Web UI 在 8080，HEP 采集端口为 UDP/TCP 9060 与 HTTP 9080，RustFS 控制台在 9001。首次登录口令获取方式同上。

5.3 注入第一条流量

在被监控主机上安装 heplify 并指向 Homer：

heplify -i eth0 -pr 5060-5090 -hs <homer服务器IP>:9060

此后任何 SIP 流量（注册、呼叫、OPTIONS 心跳）都会出现在 Web UI 的搜索结果中。

六、适用场景与限制

6.1 适用场景

  • VoIP 运营商/ITSP：SIP 中继与落地质量监控，故障话单逐条回溯。
  • 企业统一通信：FreeSWITCH/Asterisk/Kamailio 集群的注册异常、单通、回铃异常排查。
  • 呼叫中心：SIPREC 录音流采集与通话质量（RTCP-XR/MOS）分析。
  • SBC/会话边界排障：结合 aleg/bleg 关联 ID（X-CID 等自定义头）做跨段呼叫关联。
  • 多站点集中监控：各机房部署 Node 边缘节点，Coordinator 集中检索与 smart routing 裁剪。

6.2 限制与注意事项

  • 资源占用：官方明确 all-in-one 容器建议约 8GB 内存（DuckDB writer 默认 MEMORY_LIMIT=4GB，可调）；高并发 SIPREC/大流量场景建议上调至容器内存的 50%（来源：examples/docker/README.md、docs/OOM.md，查询日期 2026-10-26）。
  • 许可约束：AGPL-3.0 对网络服务场景有传染性要求，商用集成（尤其二次开发后对外提供服务）需法务评估；QXIP 提供商业授权与支持渠道。
  • DuckLake 单写者：DuckDB 数据库文件为单写锁模型，运维脚本与运行中服务并发操作 settings 库（如重置管理员口令）需先停服务再执行，否则报 Conflicting lock 错误。
  • 口令策略：历史默认口令 admin/sipcapture 已废弃，新装必须使用哈希注入或首启随机口令，登录后应立即修改。
  • 历史回灌与 smart_routing：回放历史 pcap 会破坏节点数据范围单调性，需关闭 smart_routing 以避免最多一个健康检查周期内的漏查。

七、同类选型对比

SIP/VoIP 监控领域可选方案不多，以下与两个代表性方案对比：SIP3（同样定位全流量 VoIP 监控的开源平台）与 Homer 7 遗产版（大量存量部署仍在此版本线），另附通用抓包工具的定位差异。

7.1 与 SIP3 对比

SIP3 是 sip3.io 团队推出的开源 VoIP 实时监控与排障方案，采用组件化架构：Captain（采集代理与协议适配）、Salto（基于 Vert.x 多响应器模式的高性能事件管道）、Twig（API 引擎，负责搜索聚合与呼叫关联）、Hoof（Web 界面，提供简单/高级搜索与业务仪表盘），社区版与企业版（Enterprise）双轨发布，Salto 社区版亦支持 HEPv3 数据源接入（来源：sip3.io 官网 Features 页，查询日期 2026-10-26）。

维度Homer 11.0.369SIP3（2025.2.1 ~ 2025.3.2）
架构形态Go 单体四模块，可拆多节点Captain/Salto/Twig/Hoof 四组件分布式
存储引擎内置 DuckDB + DuckLake（Parquet），可选 S3 冷分层事件管道 + 外部数据源（组件各自处理）
采集协议HEPv2/v3/protobuf、SIPREC、RTCP-XR、syslog、CDR本机 libpcap 抓包（DPDK 企业/Beta）、SIP、RTCP/RTP（Beta）、SS7/CAP/ISUP；Salto 兼容 HEPv3 接入
服务指标QoS/RTCP 报表RFC 6076 服务指标（社区版）、媒体 QoS（Beta）
授权体系JWT/OAuth2，内置用户体系OAuth/LDAP 等（Twig，社区版）
AI 集成内置 MCP server未见同类能力
版本策略单仓库滚动发版（11.0.x 高频迭代）社区版/企业版双轨，企业版含 UI 升级 agent 等运维增强

选型建议：追求部署简单、单机即用、需要 MCP/AI 集成与内置湖仓的中小规模场景选 Homer 11；已有分布式组件运维经验、需要 SS7/信令网采集与商业支持的大型运营商场景可评估 SIP3（部分高级能力集中在其企业版）。

7.2 与 Homer 7 遗产版对比

大量教程与存量部署仍基于 Homer 7（heplify-server + homer-app + PostgreSQL + InfluxDB）。两者关系与差异：

维度Homer 11（homer eleven）Homer 7
进程模型单二进制 homer-core（四模块合一）heplify-server 与 homer-app 两个独立服务
外部依赖无（DuckLake 内置，可选对象存储）PostgreSQL + InfluxDB 必装
API/UI单端口 8080 统一 REST + 内置 UIAPI 与前端分离部署
查询引擎DuckDB 向量化直查 ParquetSQL 转发 PostgreSQL / InfluxQL
配置方式homer.json 单文件 + HOMER_* 环境变量多服务各自配置文件
现状官方主线，高频发版仅安全维护，官方推荐迁移 11

选型建议：新部署一律选 11.x；存量 Homer 7 可按"先并行建 11 节点、heplify 双写、验证后切换"的路径平滑迁移。两者 HEP 采集端口均为 9060，代理侧迁移成本很低。

7.3 与通用抓包工具定位差异

Wireshark/tshark、sngrep、VoIPmonitor 常被拿来与 Homer 比较，但定位不同：前两者是单机抓包/分析工具（sngrep 专注终端侧 SIP 事务可视化，无集中存储与多人协作）；VoIPmonitor 是 pcap 落盘型单机监控（PHP UI + MySQL/MariaDB），横向扩展与集中检索能力弱于 HEP 架构。Homer/heplify 的 HEP 模式将"抓包"与"存储分析"解耦，适合多点采集、集中分析的生产监控体系。若仅需临时排查单机 SIP 问题，sngrep/tshark 更轻量；需要持续监控、历史回溯与团队协作，则应选 Homer 这类平台。

八、参考链接

（以上参考链接内容查询日期均为 2026-10-26）

本文为专栏开篇。后续篇章将基于 homer-core 11.0.369 展开完整实操：Ubuntu 22.04 安装、Docker Compose 部署、配置参数详解与 API 使用，敬请参阅本专栏其余文档。