VoIP

最简单的架构 - 1架构 1架构: 1台FS节点 在一个最简单的VoIP架构里，你只需要部署一台具有公网IP的FreeSWITCH, 就可以开始呼叫业务。 分机直接注册到FS上，然后FS直接对接线路。 但是要不了多久，你就会发现下面的问题： 安全问题： FS直接公网暴露，必然面临被攻击的事实。因为对接线路虽然可以设置网络策略，但是分机的IP往往是动态变化的。小型的攻击例如恶意的注册扫描，大型的攻击就是DDOS, 直接打满带宽，导致业务必然中断。 一些简单的安全防范，比如默认端口改成非5060的端口，但是使用现代化的端口扫描工具，6W个端口基本上几秒就能扫描完。 高可用问题: 单台FS挂掉，业务就中断了 停机维护， 业务也会中断 扩展问题: 当业务上量，一台FS就无法满足，必然要增加新的FS节点。 这时候问题就来了 分机信息保存在FS节点中，多FS节点分机注册信息如何同步？ 在呼入的时候，是否要通知SIP-线路去增加新的FS节点信息？ 网络策略是不是又要开一遍？ 支持FS动态扩展架构 2+N架构 2+N架构: 2台SIP Proxy，N台FS节点 这种架构特点 SIP Proxy层具有公网IP，无论分机注册，还是对接线路，SIP信令都需要经过SIP Proxy层 分机注册信息也保存在SIP Proxy层，FS不再关心分机的注册地址 SIP Proxy层可以用keep-alive保活，一主一备部署 FS可以无感扩容，由Proxy层来做负载均衡。 在这个架构图里，我没有引入rtpproxy或者rtpengine的，这时候媒体流的走向就比较尴尬。 每台FS还必须要要有公网地址， 只有这样分机才能直接对接FS。 而原因也很简单，因为opensips或者kamailio没有媒体处理能力。 这种架构还是无法节约EIP, FS还是可能遭受到公网攻击。 2+N+N架构 2+N+N架构: 2台SIP Proxy，N台MediaPrxyo节点, N台FS节点 为了彻底让FS不再供网暴露，我们引入媒体代理层。 这次基于架构2， 引入媒体代理集群，例如使用多台rtpengine机群，用来转发UAC <> FS <> 线路 之间的媒体流 三明治架构 可以参考 SIPSwse C5架构 https://wdd.js.org/posts/2025/sipwise-c5-arch/ 这种架构在媒体层和SIP Proxy层之间又增加一层，我称之为SIP Router层。 ...

天下苦 VOS 久矣。 此言非怒而发，乃久用之后，积怨成理也。 VOS3x、VOS5x，曾有其功。 当年软交换荒芜，SIP 规范未成体系，工程师多凭经验行事。VOS 以一套封装良好的系统，解“能跑”之急，立一时之功，不可不认。 然功成之后，不思进化； 市占既稳，便少革新。 天下之患，莫大于此。 一、垄断既久，问题反成常态 今之 VOS，已非“可选方案”，而成“默认答案”。 选型之时，不问架构，只问“是不是 VOS”； 排障之时，不查协议，只等“厂商回复”。 于是，奇景频出： SIP 行为异于 RFC，而曰“产品设计如此” 性能瓶颈不可测，而曰“经验上差不多” 复杂需求难以实现，而曰“VOS 不支持” 简单需求可实现，而曰“得加钱” 故障定位止于日志，而曰“已提交工单” 久而久之， 问题不再被解决， 只是被习惯。 二、用 VOS，工程师何其卑微 用 VOS 者，常有此感： 系统在跑， 却不知为何如此跑； 问题已现， 却不知从何而断。 工程师所做者，不过： 点配置 调参数 猜行为 等回复 软交换本该是工程， 却活成了玄学。 三、OpenSIPS / Kamailio：让系统“讲人话” 或问： “不用 VOS，又当用谁？” 曰：OpenSIPS，Kamailio。 二者之道，不在“省钱”，而在透明： SIP 即 SIP，不自创私货 路由即代码，行为白纸黑字 性能可压测，瓶颈可定位 出问题先看脚本，而非先写邮件 在此体系之中， 系统不再“猜你想要什么”， 而是“严格执行你所写之逻辑”。 这是工程， 不是占卜。 四、开源之苦，在前；开源之利，在后 诚然，OpenSIPS / Kamailio 不好上手。 学习曲线陡峭，踩坑在所难免。 ...