Routr 2.25.1 介绍与选型指南

面向初次接触 SIP 服务器基础设施的运维与后端工程师，讲清 Routr 是什么、"信令与配置分离"的 gRPC 微服务架构如何组成、能承接哪些 VoIP 场景，并用量化数据对比 Routr 与 openSIPS、Kamailio、Asterisk 的定位差异，帮助读者在"可编程 SIP 基础设施"选型时做出正确决策。本篇为认知篇，全部事实与数据均来自官方渠道联网溯源，未做本地部署实测。

RoutrRoutrSIPVoIP2026/10/26

Routr 2.25.1 介绍与选型指南

目标：面向初次接触 SIP 服务器基础设施的运维与后端工程师，讲清 Routr 是什么、"信令与配置分离"的 gRPC 微服务架构如何组成、能承接哪些 VoIP 场景，并用量化数据对比 Routr 与 openSIPS、Kamailio、Asterisk 的定位差异，帮助读者在"可编程 SIP 基础设施"选型时做出正确决策。本篇为认知篇，全部事实与数据均来自官方渠道联网溯源，未做本地部署实测。

一、取证说明

本篇为认知溯源篇：全部版本号、星数、提交数均来自官方渠道联网查证，取证来源与查询日期统一为 2026-10-26：

取证项来源取证结果（查询日期 2026-10-26）
最新稳定版GitHub Releases（fonoster/routr）v2.25.1，发布于 2026-10-26（UTC 02:12）
官方文档站https://docs.routr.io/Mintlify 构建，含 Concepts/Guides/Reference 全套（llms.txt 索引可机读）
GitHub 主仓github.com/fonoster/routr（GitHub API）星数 1,716，MIT 许可证，open issues 23，主仓创建于 2017-01-18，近 30 天提交 272
开发语言官方 FAQEdgePort 与 Requester 用 Java（基于 JAIN-SIP），其余服务（Dispatcher、Location、Connect、API Server、Registry、中间件）用 TypeScript/Node.js
发行物GitHub Releases 页 + Docker HubReleases 不提供二进制资产（仅 release-card 图）；官方发行形态为镜像：all-in-one fonoster/routr-one:2.25.1（压缩体积约 360 MB，内置 PostgreSQL）与 fonoster/routr-* 模块化镜像族；另有 npm 包 @routr/ctl、@routr/sdk 与 Helm chart routr/routr-connect
管理面协议官方架构文档API Server 仅提供 gRPC 接口（外部端口 51908），无 REST 网关，rctl 与 SDK 均走 gRPC

版本命名说明：官方主版本线为 2.x，本文统一以官方最新稳定版 2.25.1（取证日 2026-10-26 发布）为基准展开；涉及版本线泛指时以"Routr 2.x"表述。

二、Routr 是什么

2.1 一句话定位

Routr 的官方自我定义是：一个可编程的 SIP 代理（proxy）、注册服务器（registrar）与位置服务（location server）。它接收来自话机、浏览器、PBX 与运营商的 SIP 请求，决定每个请求的去向并转发——只处理信令，不处理媒体：不放音、不录音、不混音、不转码。

它和 openSIPS/Kamailio 属于同一类工具（信令层），但实现范式完全不同：Routr v2 不是"一个进程 + 一份路由脚本"，而是一组通过 gRPC 互相协作的小服务。每个服务只做一件事，可以独立伸缩、重启或替换。

2.2 项目背景

  • Routr 由 Fonoster 开源，是 Fonoster 云通信平台的信令引擎，作者为 Pedro Sanders；
  • 主仓创建于 2017-01-18（GitHub API），2.x 是一次彻底重构：从 1.x 的单体服务转向"gRPC 微服务 + 可插拔 Processor"架构；
  • 采用 MIT 许可证——在四大主流开源 SIP 项目（Routr/Kamailio/openSIPS/Asterisk 均为 GPL 系）中，MIT 是显著差异点，对商业集成与闭源分发更友好；
  • 截至 2026-10-26，GitHub 星数 1,716、open issues 仅 23、近 30 天提交 272，是活跃维护中的项目。

2.3 能力边界：只做信令

官方 FAQ 明确：Routr 不是媒体服务器。它的典型用法是放在 Asterisk/FreeSWITCH 等媒体服务器前面：负责话机注册、呼叫路由、运营商对接与负载分发；媒体直接在端点之间流动，或经外挂的 RTPEngine 转发（WebRTC 场景）。要 IVR、会议、留言，需要对接媒体服务器——Routr 补位而不替代。

三、架构：一套 gRPC 微服务

3.1 组件构成

Routr v2 的行为规范写在两份草案里（CORE.md 与 CONNECT.md）。核心组件及默认端口：

组件职责默认端口
EdgePort网络边缘：终结 UDP/TCP/TLS/WS/WSS 五种传输的 SIP 连接，持有事务与连接，把每条 SIP 消息转成 protobuf MessageRequest 发往下游5060–5063
Message Dispatcher从 EdgePort 收消息，依次过 Middleware，交给第一个方法匹配的 Processor51901
Connect Processor内置路由处理器，实现 SIP Connect 1.1 的 PBX 部分（Domain/Agent/Peer/Trunk/Number/Credentials/ACL 资源模型）51904
Middleware与 Processor 同接口的可选服务，在路由前后加副作用（鉴权 SimpleAuth、媒体控制 RTPRelay 等）51903
Location Service存注册信息（端点在哪个 EdgePort 可达），并对 Peer 做负载均衡；数据存 memory 或 redis51902
API Server存取 Connect 资源：simpledata 后端读 YAML/JSON 文件，pgdata 后端连 PostgreSQL；对外 gRPC 端口 5190851907 内部 / 51908 外部
Registry代表开启 sendRegister 的 Trunk 向运营商发 REGISTER51910
Requester让 Registry 等内部服务能经由 EdgePort 发出 SIP 请求51909

3.2 有状态与无状态的划分

这是 Routr 架构里最重要的运维结论：

  • EdgePort 是唯一有状态服务。它持有 SIP 事务和客户端连接（TCP/TLS/WS 要求响应走原连接）。EdgePort 停止，其上的呼叫中断、客户端需重新注册；
  • Dispatcher、Processor、Middleware 全部无状态：每条消息自带处理所需的全部上下文（SIP 消息 + EdgePort 引用、监听点、外部地址、本地网段等元数据），任意副本可处理任意消息；
  • 数据落在请求路径之外两处：注册信息在 Location Service（memory 模式下单实例私有，redis 模式可多实例共享），资源数据在 API Server 背后（YAML 文件或 PostgreSQL）。

这个划分直接决定了伸缩方式：无状态服务用普通副本横向扩；EdgePort 按 StatefulSet 方式谨慎扩（多 EdgePort 之间通过 cooperation 机制互通端点）；媒体由 RTPEngine 与后端媒体服务器承担。

3.3 语言构成（常见误传澄清）

社区流传"Routr 是 Go 编写的"，这不准确。官方 FAQ 原文：处理 SIP 的 EdgePort 与 Requester 用 Java（JAIN-SIP 协议栈），其余服务（Dispatcher、Location、Connect、API Server、Registry、中间件）为 TypeScript / Node.js。因此：

  • 二次开发 Processor/Middleware 不需要碰 Java——它们走 gRPC，任何支持 gRPC 的语言（TypeScript、Go、Python、Java……）均可；
  • 若要从源码构建全套服务，需要 Node.js 22+ 与 JDK 17 两套工具链；
  • 官方 SDK 目前提供 Node.js SDK（@routr/sdk），rctl CLI 亦为 npm 包（@routr/ctl）。

3.4 两种部署形态

官方给出两种拓扑（概念文档 Deployment topologies）：

形态组成适用
routr-one（all-in-one 镜像）EdgePort + Dispatcher + Connect + Location + 内置 PostgreSQL 塞进一个容器开发、演示、单主机小部署（家庭/办公室电话系统）
routr-connect（Helm chart）各服务独立工作负载：EdgePort StatefulSet（默认 2 副本）+ 无状态服务 Deployment + HPA，附带 PostgreSQL/Redis 子图Kubernetes 生产部署，各组件独立伸缩

all-in-one 形态的限制官方写得很直白：注册存内存（重启即失、话机需重新注册）、无法单独伸缩、重启掉线呼叫。

四、核心特性清单

以下特性均摘自官方 README 与文档站（取证日 2026-10-26）：

传输与协议

  • SIP over UDP / TCP / TLS / WS / WSS 全套传输（端口 5060–5063）；
  • 支持 IPv4 网段声明（localnets）与多外部地址通告（externalAddrs），适配 NAT 与多网卡环境。

Connect 资源模型（多租户 PBX）

  • 内置 Connect Processor 实现 SIP Connect 1.1 的 PBX 部分（官方注明未做认证）；
  • 资源模型：Domain（租户）、Agent（话机用户）、Peer（媒体服务器）、Trunk（运营商线路）、Number（号码）、Credentials、ACL；
  • Domain 级 ACL 控制接入网段，Credentials 独立管理认证凭据。

路由与负载均衡

  • 可编程路由：Routing 处理器按规则改写目的地；
  • 对 Asterisk/FreeSWITCH 集群做负载均衡（Peer 池 + 会话亲和 session affinity），支持 least-sessions 等算法（Redis 模式）。

数据与 API

  • 双数据源：simpledata（YAML/JSON 文件，只读，零依赖）与 pgdata（PostgreSQL，支持写入与迁移）；
  • 全套资源通过 gRPC API（端口 51908）管理，配套 rctl CLI 与 Node.js SDK；
  • create/update 走 rctl 交互式 prompt，脚本化场景用 SDK。

WebRTC 与媒体

  • RTPRelay Middleware 驱动外置 RTPEngine，桥接 WebRTC 与 SIP 媒体（WebRTC 场景必须外挂 RTPEngine）；
  • 支持 SDES-SRTP。

安全与可观测

  • JWT 认证（API 面）、Domain ACL（信令面）；
  • STIR/SHAKEN 呼叫者身份框架支持；
  • OpenTelemetry 埋点、heplify→Homer 抓包镜像（HEPLIFY_OPTIONS）、呼叫录制与回放。

依赖策略

官方 FAQ 明确：核心服务零外部依赖（Location 默认 memory）。按需追加：Redis（多 Location 实例共享注册）、PostgreSQL（pgdata 数据源）、RTPEngine（仅 WebRTC 需要）。这种"按需加依赖"的梯度在同类项目中最平滑。

五、与 openSIPS/Kamailio/Asterisk 量化对比

5.1 数据总表

（除注明外，数据均于 2026-10-26 取自各项目 GitHub API / 官网）

维度Routr 2.25.1Kamailio 6.1.5openSIPS 4.0.2Asterisk 23.x
定位可编程 SIP 代理/注册/位置服务（仅信令）可编程 SIP 服务器（仅信令）可编程 SIP 服务器（仅信令）PBX/媒体服务器（信令+媒体）
最新版本2.25.1（2026-10-26 发布）6.1.5（2026-10-15 发布）4.0.2（2026-09-08 发布；LTS 3.6.9 线同步维护）certified 22.8-cert5；主线 23.x（24.0 处于 RC）
开发语言TypeScript(Node.js) + Java(EdgePort/Requester)CCC
许可证MITGPL 系GPL 系GPL 系
GitHub 星数1,7162,9801,5433,646
近 30 天提交（GitHub 主仓）272300≈126/月（shields.io 徽章口径）29（Asterisk 主开发在 Gerrit，GitHub 为镜像）
扩展方式gRPC Processor/Middleware，任意语言内嵌 kamailio.cfg 路由脚本 + C 模块内嵌 opensips.cfg 路由脚本 + C 模块拨号计划 + C 模块/AGI/AMI
媒体处理无（外挂 RTPEngine）无（外挂 rtpengine）无（外挂 rtpengine）内置（混音/转码/会议/录音）
运维范式服务编队（每组件独立伸缩）单进程多 worker单进程多 worker单进程

5.2 Routr vs Kamailio / openSIPS：范式之争而非能力高下

三者解决同一类问题（信令路由），差异在架构范式：

  • Kamailio/openSIPS：二十年级别的成熟项目，C 语言单进程 + 内嵌路由脚本。脚本语言为服务器专有 DSL，函数密集、性能极高，生态模块极多（presence、IMS、rtpengine 对接、反攻击等应有尽有）。代价是：路由逻辑被锁死在服务器进程内，团队必须掌握专有配置语言；扩容即复制整台服务器。
  • Routr：把"边缘/分发/路由/位置/数据"拆成独立 gRPC 服务。路由逻辑是通用语言写的普通程序（TypeScript/Go/Python 皆可），能像测普通服务一样做单元测试、灰度、回滚；无状态组件可独立横向伸缩；替换任一组件（比如自研鉴权 Middleware）不需要 fork 上游。代价是：组件数多、部署面复杂（K8s 是它的主战场），单机小场景反而不如 openSIPS 一份配置文件轻；生态模块数量与 C 层性能调优深度不及两位前辈，社区规模也小一档（星数与提交量可见）。

一句话：要极致 CPS、海量注册、防攻击边界、IM/presence 等大生态 → Kamailio/openSIPS；要"用熟悉的语言写路由逻辑、云原生分体伸缩、商业友好许可证" → Routr。 两者也可混用：Routr 的官方负载均衡特性本身就常用来把话机流量分发给 Asterisk/FreeSWITCH，而 Kamailio/openSIPS 的部署经验（NAT、ALG、Record-Route 语义）对运维 Routr 同样适用。本站已有《openSIPS 4.0 介绍与选型指南》与《Kamailio 介绍与选型指南》可对照阅读。

5.3 与 Asterisk / FreeSWITCH：分层而非竞争

这是选型的核心叙事：Routr 与 Asterisk/FreeSWITCH 不是竞争关系，而是分层关系（可参考站内《Asterisk 22.11.0 介绍与选型指南》与《FreeSWITCH 介绍与选型指南》）：

  • 只需要注册/路由/运营商对接、不碰媒体 → Routr（或 openSIPS/Kamailio）单层即可；
  • 要转码、会议、IVR、录音、话机即插即用 → Asterisk/FreeSWITCH；但它们直面公网扛不住海量 SIP 扫描与高并发注册；
  • 生产级 VoIP 平台常见形态：Routr（信令边缘：注册/路由/ACL/LB）+ Asterisk/FreeSWITCH 集群（媒体与应用）+ RTPEngine（WebRTC 媒体桥），各司其职。Routr 的 Connect 模式（Peer 池 + session affinity）就是为这种分层设计的。

5.4 选型结论速查

  • 用代码（而非专有 DSL）控制呼叫路由、团队是 Node.js/云原生技术栈 → Routr；
  • Kubernetes 生产环境、各组件独立伸缩、多 EdgePort 边缘 → Routr（routr-connect Helm chart 即为此设计）；
  • 对许可证敏感（MIT 允许闭源集成） → Routr 是四大项目中唯一选择；
  • 极致性能、海量注册、防攻击 SBC、presence/IMS 大生态、商业支持 → Kamailio/openSIPS；
  • 企业内线 PBX、呼叫中心、快速搭一套能打电话的系统 → Asterisk/FreeSWITCH（Routr 可作其前置信令层）；
  • 家用/小型办公室一套全包 → routr-one all-in-one 形态（本专栏部署篇实测）。

六、本专栏阅读路线

本专栏按"认知 → 部署 → 配置 → 运维"组织，后续篇章均含本地实测：

  1. 《Routr 2.25.1 Docker Compose 部署指南》——用官方 all-in-one 镜像在单机跑通 Routr：compose 编排、资源创建、SIP 注册验证、升级与排障，全部命令实测；
  2. 《Routr 2.25.1 配置参数详解》——逐文件解析 config/*.yaml（EdgePort 监听、Dispatcher、Location、Connect、API Server）与 routr-one 环境变量表；
  3. 《Routr 2.25.1 常用 CLI 命令与工具详解》——rctl 全资源组（acl/agents/credentials/domains/numbers/peers/trunks）实测：增删改查、分页、SDK 脚本化替代方案；
  4. 《Ubuntu 22.04 安装 Routr 2.25.1 指南》——不走容器的裸机路线：源码构建（Node 22 + JDK 17）、systemd 托管、在线与离线两种安装方案。

七、参考链接