OpenSIPS 最近一年版本演进与 Bug 修复：从 3.5 到 3.6.7

OpenSIPS 是 VoIP/SIP 基础设施中非常重要的开源 SIP Server。对于长期运行的生产环境来说，版本升级通常并不只是为了获得新功能，更重要的是获得持续的 稳定性、安全性以及协议兼容性修复。

过去一年，OpenSIPS 的开发重点逐渐从单纯增加 SIP 功能，转向 稳定性、安全性和生产运维能力。

本文基于 OpenSIPS 官方版本及 ChangeLog，对最近一年的版本演进和 Bug 修复进行梳理，并重点分析这些修复对于 SIP Proxy、SBC、FreeSWITCH、RTPengine 等典型 VoIP 架构的影响。

一、最近一年 OpenSIPS 的版本变化

过去一年 OpenSIPS 的主要版本演进集中在 3.6 系列。

版本	时间	主要定位
OpenSIPS 3.5.7	2025-08	3.5 maintenance
OpenSIPS 3.6.0	2025-07	新一代 Stable
OpenSIPS 3.6.1	2025-08	Maintenance
OpenSIPS 3.6.2	2025-10	Maintenance
OpenSIPS 3.6.3	2025-12	Maintenance
OpenSIPS 3.6.4	2026-02	Maintenance
OpenSIPS 3.6.5	2026-05	Stability / Bug Fix
OpenSIPS 3.6.6	2026-05	Security / Bug Fix
OpenSIPS 3.6.7	2026-06	Latest 3.6 Maintenance

其中，3.6 是最后一个 3.x 大版本，后续开发主线进入 4.0。

从生产环境角度来看，3.6.x 更值得关注，因为它已经经过多次 maintenance release 的验证，而 3.6.5 和 3.6.6 又集中修复了大量稳定性和安全问题。

二、最近一年官方 Bug 修复的几个主要方向

如果把 ChangeLog 中大量零散的 Bug 进行分类，可以看到几个非常明显的趋势：

SIP Transaction 和异步处理稳定性
TCP/TLS/WebSocket 的连接和 Buffer 安全
Registrar / mid_registrar 稳定性
RTPengine / SDP 处理
Dialog / B2B / Routing
Parser 和 malformed input 安全
数据库连接稳定性
内存泄漏、Use-after-free 等底层问题

这些问题有一个共同特点：

很多 Bug 并不是普通业务场景下马上能够发现的问题，而是在高并发、长时间运行、异常 SIP 消息或者网络异常情况下暴露。

对于 SIP Proxy 来说，这类 Bug 往往比新增一个业务功能更加重要。

三、TCP 和连接管理：生产环境最值得关注的一类问题

SIP Proxy 在生产环境中通常会长期保持大量 TCP/TLS/WebSocket 连接，因此连接管理问题非常敏感。

3.1 TCP FD Leak

OpenSIPS 3.6.5 修复了 reactor 中的文件描述符泄漏问题。

在某些场景下，例如 RTPengine notification timeout，可能导致 FD 没有被正确释放。

长期运行后可能出现：

复制代码

too many open files

这类问题非常典型：

复制代码

业务开始
   ↓
连接建立
   ↓
异常 / timeout
   ↓
FD 未正确释放
   ↓
FD 数量持续增长
   ↓
最终达到系统限制

对于 SIP Server 来说，这种问题通常不会在简单功能测试中出现，而是在运行数天甚至数周之后才暴露。

因此，生产环境中的 OpenSIPS 升级不能只关注 SIP call 是否正常，还应该关注：

复制代码

lsof -p <opensips_pid>

以及：

复制代码

cat /proc/<pid>/fd

观察 FD 是否持续增长。

四、TCP / WebSocket Buffer 安全问题

3.6.5 对 TCP Content-Length 做了更加严格的检查。

例如收到：

复制代码

Content-Length: 999999999

而实际 read buffer 只有很小的一部分时，不能继续按照异常长度进行处理。

OpenSIPS 对：

复制代码

TCP
WebSocket
WebSocket over TLS
Janus

等路径增加了更加严格的边界检查。

这类修改看起来比较底层，但对于公网 SIP Server 非常重要。

因为 SIP Proxy 接收到的消息并不一定都是：

复制代码

合法 SIP

还可能是：

复制代码

Malformed SIP
异常 TCP packet
错误 Content-Length
异常 WebSocket handshake
恶意输入

因此，一个成熟 SIP Proxy 的安全性，很大程度上取决于：

遇到异常输入时，它能不能安全地拒绝，而不是继续处理。

五、async() 和 Transaction 状态问题

这是最近版本中比较值得 SIP 开发人员关注的一类 Bug。

OpenSIPS 支持：

复制代码

async()

将部分业务逻辑异步化，然后在后续重新 resume。

例如：

复制代码

request
   ↓
async()
   ↓
external service
   ↓
resume
   ↓
t_relay()

3.6.5 修复了 chained async resume 场景下 $rd 恢复不正确的问题。

这类问题非常隐蔽。

因为：

复制代码

$rd

决定请求后续的目标 destination。

如果 async resume 后 $rd 恢复错误，就可能出现：

复制代码

正常请求
   ↓
async()
   ↓
resume
   ↓
错误 $rd
   ↓
t_relay()
   ↓
请求发送到错误节点

这不是简单的 crash，而是更加危险的 错误路由。

对于复杂的：

复制代码

OpenSIPS
   ↓
Route Service
   ↓
Dispatcher / Load Balancer
   ↓
FreeSWITCH

架构，这类问题尤其值得关注。

六、Push Notification / Registrar 相关修复

OpenSIPS 的 Registrar 和 Push Notification 近年来也是持续演进的方向。

在 PN assisted call 中，一个 INVITE 可能需要：

复制代码

INVITE
   ↓
检测 contact
   ↓
发现设备休眠
   ↓
发送 Push Notification
   ↓
等待设备唤醒
   ↓
创建新的 SIP branch
   ↓
继续呼叫

3.6.5 修复了 t_wait_for_new_branches() 对 branch 数量计算不完整的问题。

原来的逻辑可能导致 transaction 在真正的 PN branch 建立之前就结束。

对于移动端 SIP Client 来说，这可能表现为：

复制代码

用户点击呼叫
        ↓
Push 已发送
        ↓
手机开始唤醒
        ↓
SIP transaction 已经结束
        ↓
最终手机没有正常响铃

因此，这种 Bug 虽然属于 Registrar/PN 模块，但最终表现出来的是一个非常典型的"偶现呼叫失败"。

七、mid_registrar 的 Memory Bug

3.6.5 还修复了 mid_registrar contact trimming 过程中的 memory management 问题。

特别是在：

复制代码

max_contacts

配置下进行 contact 清理时，之前可能出现：

复制代码

use-after-free

同时还修复了 usrloc 的一个 memory leak edge case。

这类问题对长期运行的 SIP Registrar 非常重要。

因为 Registrar 的特点是：

复制代码

高频 REGISTER
+
大量 Contact
+
长时间运行

任何微小的 memory leak，都可能在长时间运行后放大。

八、RTPengine：媒体控制也有重要修复

OpenSIPS 并不是媒体服务器，但很多部署会通过：

复制代码

OpenSIPS
    ↓
RTPengine
    ↓
Media

进行 RTP relay。

3.6.5 修复了 RTPengine module 对 key=value 类型 flag 的处理问题。

例如：

复制代码

media-address=xxx

在某些路径下存在 buffer 生命周期管理问题。

如果 buffer 已经释放，但后续仍然被用于构造 RTPengine command，就可能产生：

复制代码

corrupted command

甚至进一步导致 crash。

另外，rtp_relay 对非 SDP request 的 in-dialog RTP handling 也进行了修复。

这说明 OpenSIPS 最近的修复已经不仅仅集中在 SIP transaction，而是开始大量覆盖：

复制代码

SIP
SDP
RTP
RTPengine

整个 VoIP signaling/media control 链路。

九、3.6.6：安全修复值得重点关注

如果说 3.6.5 更偏向稳定性，那么：

3.6.6 可以看作最近一年非常重要的一次安全修复版本。

这一版本集中修复了大量：

复制代码

bounds checking
malformed input
buffer handling
parser validation
protocol parsing

十、SIP Parser 的安全强化

3.6.6 对多个 SIP parser 路径进行了加强，包括：

复制代码

Base64 output sizing
multipart delimiter parsing
TCP Content-Length arithmetic
SIP → JSON header names
URI construction

这些问题的共同特点是：

输入数据来自网络，因此必须假设输入是不可信的。

例如：

复制代码

SIP Message
   ↓
Parser
   ↓
Header
   ↓
URI
   ↓
内部 Buffer

如果某一个环节对长度计算不准确，就可能出现：

复制代码

buffer overflow
memory corruption
crash

因此，3.6.6 的大量修改实际上是在提高 OpenSIPS 对异常 SIP 消息的"容错能力"。

十一、SDP Parser 也进行了强化

SDP 是 VoIP 系统中非常重要的一部分。

OpenSIPS 3.6.6 对 SDP 增加了更多限制，例如：

复制代码

SDP line 数量限制
malformed bandwidth line 检查

这类修改的核心思路是：

复制代码

正常 SDP
   ↓
正常解析

异常 SDP
   ↓
尽早拒绝

而不是：

复制代码

异常 SDP
   ↓
进入复杂 parser
   ↓
产生异常状态
   ↓
最终 crash

对于：

复制代码

OpenSIPS + FreeSWITCH
OpenSIPS + RTPengine
OpenSIPS + SBC

这种架构，SDP parser 的稳定性非常重要。

十二、HEP / BIN / SMPP 等协议也进行了安全加固

OpenSIPS 并不只处理 SIP。

例如 HEPv3 用于：

复制代码

Homer
HEP Capture
SIP Trace

3.6.6 对 HEPv3 增加了：

复制代码

packet length validation
chunk length validation
payload validation

避免非法 HEP packet 进入后续解析。

类似地，BIN protocol 也增加了 packet bounds checking。

SMPP 则针对：

复制代码

sm_length
GSM7
UCS2

等字段进行了长度限制。

这反映出一个明显趋势：

OpenSIPS 官方正在逐渐把"异常输入安全"作为核心基础能力。

十三、B2B / Dialog / Topology Hiding

3.6.6 还修复了一些 B2B、Dialog 和 Routing 相关问题。

例如：

b2b_logic

修复 Replaces rewrite 可能产生 oversized header 的问题。

b2b_entities

对生成的：

复制代码

RAck

header 增加长度保护。

topology_hiding

对 encoded Contact 增加 bounds protection。

rr

对：

复制代码

maddr URI

增加长度保护。

这些修改说明 OpenSIPS 官方不仅关注：

复制代码

底层 parser

同时也在检查：

复制代码

高层 SIP feature

在异常输入下是否安全。

十四、数据库连接：一个非常实用的修复

对于大型生产环境，OpenSIPS 经常依赖 MySQL。

3.6.5 修复了 MySQL / Aurora prepared statement 失效的问题。

例如：

复制代码

OpenSIPS
   ↓
MySQL / Aurora

数据库连接本身还保持着，但 server-side prepared statement 已经被数据库端删除。

OpenSIPS 收到：

复制代码

ER_UNKNOWN_STMT_HANDLER (1243)

后，现在可以重新：

复制代码

connect
   ↓
prepare
   ↓
retry

而不是直接让业务请求失败。

这对于：

复制代码

AWS Aurora

等云数据库环境尤其有价值。

十五、从这些 Bug 可以看到 OpenSIPS 的技术方向

如果不看具体 ChangeLog，而是从过去一年的 Bug 进行总结，可以发现 OpenSIPS 的重点已经越来越明显：

复制代码

                  OpenSIPS 3.6
                       │
       ┌───────────────┼───────────────┐
       │               │               │
       ↓               ↓               ↓
    Stability        Security       Operations
       │               │               │
       ↓               ↓               ↓
     TCP/FD          Parser         Dynamic
     Memory          Buffer         Sockets
     Transaction     Bounds         Monitoring
     Dialog          Input          Management
     RTP             Validation     Cloud

也就是说，OpenSIPS 最近的开发重点已经从：

"增加更多 SIP 功能"

逐渐转向：

"让 SIP Server 在复杂、异常、高并发、长期运行环境下更加可靠。"

这对于生产环境其实是一个非常积极的信号。

十六、对于生产环境，是否值得升级？

如果当前使用的是 OpenSIPS 3.4 / 3.5，我认为至少应该认真评估 3.6。

特别是以下场景：

复制代码

TCP / TLS
WebSocket
async()
Registrar
mid_registrar
B2B
RTPengine
SDP manipulation
HEP
MySQL / Aurora

如果使用了其中多个模块，那么最近一年的 Bug Fix 与自己的业务场景有较高的重合度。

尤其是：

复制代码

3.6.5
3.6.6
3.6.7

值得重点关注。

对于生产环境，则需要同时评估：

复制代码

模块兼容性
配置兼容性
SIP routing 行为变化
性能
长连接
数据库
RTPengine
FreeSWITCH

不能仅仅因为 ChangeLog 中出现了 Bug Fix 就直接升级。

十七、总结

过去一年 OpenSIPS 的版本演进，可以概括为三个关键词：

1. Stability

重点解决：

复制代码

FD leak
Memory leak
Use-after-free
TCP connection
Transaction
Async
Registrar
RTPengine

2. Security

重点解决：

复制代码

Buffer overflow
Bounds checking
Malformed SIP
Malformed SDP
TCP Content-Length
HEP validation
Protocol parser

3. Production Readiness

重点增强：

复制代码

Cloud database
Dynamic sockets
WebSocket
AWS integration
Operational tools
Monitoring

所以，如果只用一句话总结 OpenSIPS 最近一年的变化：

OpenSIPS 3.6 的价值并不只是增加了多少新功能，更重要的是官方正在持续解决 SIP Server 长期运行、高并发以及异常输入场景下容易暴露的稳定性和安全问题。

对于已经运行 OpenSIPS 多年的生产系统来说，这些看起来比较底层的 Bug Fix，实际上往往比新功能更加值得关注。

参考资料：

OpenSIPS 官方版本信息
OpenSIPS 3.6 ChangeLog
OpenSIPS 3.6.5 ChangeLog
OpenSIPS 3.6.6 ChangeLog
OpenSIPS 3.6 Release Information