Posts

维度 opensips kamalio 说明 性能 4.5 5 性能接近 脚本能力 4 5 kmailio脚本更友好，支持预处理，宏 稳定性 4 5 opensips开发更激进，所以稳定性没有kamailio高 特殊能力 5 3 opensips在拓扑隐藏，注册信息同步，动态新增SIP端口方面能力更强 无论从哪些方面，OpenSIPS和Kamailio似乎都可以相互替代。 但是，有几个特别的能力，你可能要提前考虑。 1. 拓扑隐藏能力 1.1. 什么是拓扑隐藏 假设某 VoIP 运营商没有启用拓扑隐藏，对方运营商收到的 INVITE 可能是这样的： INVITE sip:441234567890@carrierB.net SIP/2.0 Via: SIP/2.0/UDP gw3.carrierA.net:5060;branch=z9hG4bK-342343 Via: SIP/2.0/UDP core-switch1.internal.local:5060;branch=z9hG4bK-983423 Via: SIP/2.0/UDP edge1.carrierA.net:5060;branch=z9hG4bK-238472 From: <sip:+12065550123@carrierA.net>;tag=98324 To: <sip:+441234567890@carrierB.net> Call-ID: a98sdasdh23@10.12.0.15 Contact: <sip:fs1.internal.local:5060> Record-Route: <sip:edge1.carrierA.net;lr> Record-Route: <sip:core-switch1.internal.local;lr> User-Agent: FreeSWITCH-mod_sofia/1.10 看起来只是普通 SIP 报文，但实际上信息量非常巨大。 Via头会暴露所有经过的节点， 只靠一个包就能画出你的 SIP 网络图 Call-ID暴露内网地址：Call-ID: a98sdasdh23@10.12.0.15 User-Agent暴露了服务器类型和版本，黑客会直接去查询对应版本的CVE和漏洞 Record-Route暴露dialog经过哪些节点 黑客利用上面的信息，针对弱点攻击： SIP flood REGISTER attack RTP injection SIP scanning 启用拓扑隐藏后，对方只能看到一个对外的SIP Server， 内部网络信息被完全隐藏。 ...

最简单的架构 - 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层。 ...

1. 概述 2. UDP Socket进程处理分析 2.1. UDP端口信息收集 2.2. 端口绑定 2.3. 进程fork阶段 2.4. UDP read 阶段 2.5. UDP 消息进程间负载均衡阶段 3. TCP消息处理分析 3.1. 消息处理模型 3.2. 负载均衡策略 3.3. 调用链分析 4. 举例说明： UDP读TCP发 1. 概述 kamailio SIP消息处理进程主要分为三类。 类别 功能 数量 UDP worker进程 处理以UDP传输的SIP消息 port * children TCP main进程 负责tcp链接管理，生命周期维护，tcp work的消息分发 1 TCP worker进程 处理以TCP传输的SIP消息 children 以下面的配置为例： 则SIP消息处理进程数量为：4 * 2 + 1 + 4 = 13个 children=4 listen=udp:127.0.0.1:5060 listen=udp:127.0.0.1:5080 listen=tcp:127.0.0.1:5061 在生成环境，建议children设置为CPU核数, 这样能最大化利用多核能力，并且避免太多的进程切换。 2. UDP Socket进程处理分析 UDP Socket处理主要分为三个步骤 ...

简介 这里我们把ACK的场景限定到INVITE收到200响应之后，UAC构造ACK消息的URI来自哪里？ 这里的时序图为 sequenceDiagram uac ->> uas: INVITE uas ->> uac: 200 uac ->> uas: ACK 我们要把这个问题讲清楚，不要臆造，并且必须提供RFC3261的原文作为参考。 RFC3261解读 📌 13.2.2.4 The UAC core MUST generate an ACK request for each 2xx received from the transaction layer ✏️ 这里说明，在UAC收到INVITE 200 OK后，必须回复ACK消息。 📌 12.2.1.1 Generating the Request The UAC uses the remote target and route set to build the Request-URI and Route header field of the request. If the route set is empty, the UAC MUST place the remote target URI into the Request-URI. The UAC MUST NOT add a Route header field to the request. If the route set is not empty, and the first URI in the route set contains the lr parameter (see Section 19.1.1), the UAC MUST place the remote target URI into the Request-URI and MUST include a Route header field containing the route set values in order, including all parameters. ...

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

SIPWISE C5 架构分析 Sipwise C5（又称NGCP——下一代通信平台）是一款基于SIP的开源Class 5 VoIP软交换平台 整体架构上，sipwise C5 是一个三明治架构， 除了sipwise, 我也看到过类似的VoIP架构， 可见英雄所见略同。 接入层 接入层是整个平台的信令出入口，主要的职责是安全检测和负载均衡。 并不具有业务上的功能，另外也不会使用数据库。 职责 外部SIP信令的入口和内部信令的出口 SIP信令完整性检查 拒绝环回SIP信令 DOS攻击检测 暴力攻击检测 TLS转UDP转换 NAT穿透映射 端口 5060, SIP/TCP+UDP, 对外接收SIP消息 5061, SIP/TLS， 对外接收TLS消息 5060, XMLRPC/TCP, 对内处理RPC调用，来控制kamailio 这里有个风险，5060/TCP端口同时用来对外处理SIP消息和对接处理RPC调用，难道 实现 参考 https://www.sipwise.com/doc/mr6.5.8/sppro/ar01s02.html https://www.sipwise.com/doc/mr10.3.1/spce/ce/mr10.3.1/architecture/architecture.html

demo 代码仓库 ： https://cnb.cool/eddie2072/opensips-forum/-/tree/main/how-to-use-m4 使用m4给opensips脚本增加预处理能力 为什么要预处理？ 运维便利。有预处理，脚本里的IP地址，端口，密码，用户名等信息，可以由运维人员统一配置，脚本只需要引用配置文件，就可以完成脚本的运行。否则，运维人员只能手工去修改每个配置写死的地方。容易出错，且非常麻烦。 所以，我们在写脚本的时候，需要从脚本中抽离配置性质的数据。例如监听的IP地址，端口，数据库的用户名和密码等信息。 这样脚本就变层两个部份，配置文件 + 脚本本身。 运维人员只需要修改配置文件就可以。 以本demo为例子， 运维在线上部署脚本，只需要修改env.prd.m4文件就可以。 预处理可以增加脚本的复用性。 不同环境，往往需要的功能不同。A环境需要X功能，B环境不需要X功能，那么怎么维护呢。 不用怕，有了m4条件分支，可以根据不同不配置，渲染出不同的结果。 m4基本在所有linux都已经安装好了，不用额外在安装依赖。 很多有经验的程序员，往往也不知道什么是m4, 其实大名顶顶的autoconf, 底层就依赖了m4。 m4难不难学？ m4语法简单，语法强大，但是我们能用到的，基本不超过5个语法。 定义宏 下面是定义宏的语法，这样写之后，所有字符串ENV_LISTEN_IP都会被替换为127.0.0.1 define(ENV_LISTEN_IP, 127.0.0.1) 引用其他文件 有了引用，我们就不需要把所有功能放到一个大文件中。 include(<<src/loadmodule.m4>>) include(<<src/request.m4>>) include(<<src/relay.m4>>) include(<<src/per_branch_ops.m4>>) include(<<src/handle_nat.m4>>) include(<<src/missed_call.m4>>) ifelse(cond1,cond2, yes, no) 如果cond1和cond2相同，则展开第三个参数yes, 否则展开第四个参数no ifelse(ENV_ENABLE_NAT,yes,use nat, not use nat) 引号 引号，就是用来告诉m4, 引号里的内容应该看作是一个整体。 m4默认的引号是``’’, 看起来很怪异，很难从视觉上做配对。 所有有强迫症，或者视觉洁癖的人，会非常讨厌m4。 define(`ENV_LISTEN_IP', `127.0.0.1') 但是这个引号是可以修改的，我们用changequote去修改默认的引号, 将引号改为<<>> changequote(<<,>>) define(<<ENV_LISTEN_IP>>, <<127.0.0.1>>) 如何调试宏, 使用-dV 参数 m4 -dV opensips.m4 解决宏冲突问题 如果脚本里有个变量和m4的宏名字冲突，那么往往会出现一些怪异的问题。 m4早就想到了解决方案， 在执行m4时候，可以加上-P参数，m4所有内置的宏就会必须写成以m4_开头。 例如 m4_define(<<ENV_LISTEN_IP>>, <<127.0.0.1>>) m4 -P opensips.m4 m4的劣势 m4没有类似foreach的循环，但是可以通过m4的递归实现。 m4做简单的字符串替换，但是对于复杂字符串处理，m4的效率会比较低，而且语法比较复杂。 但是对于处理opensips的配置文件，m4则是刚刚好的完美工具。 有意思的几个扩展 检查宏是否未定义，或者是否为空字符串，空则报错退出 m4_divert(-1) m4_define(<<ASSERT_NOT_EMPTY>>,<< m4_ifelse($1,,<< m4_errprint(<<$1 is empty >>) m4_m4exit(1) >>,) >>) m4_divert(0)m4_dnl ASSERT_NOT_EMPTY(this_is_empty) foreach 循环 m4_changequote(<<,>>)m4_dnl m4_divert(-1) m4_define(<<X_FOREACH>>, <<m4_pushdef(<<$1>>)_foreach($@)m4_popdef(<<$1>>)>>) m4_define(<<_arg1>>, <<$1>>) m4_define(<<_foreach>>, <<m4_ifelse(<<$2>>, <<()>>, <<>>, <<m4_define(<<$1>>, _arg1$2)$3<<>>$0(<<$1>>, (m4_shift$2), <<$3>>)>>)>>) m4_divert(0)m4_dnl X_FOREACH(x,(a.com,b.com,c.com), alias=udp:x ) 上面会输出 ...

当听到分机无法挂断电话时，通常有以下几种可能的原因： 在做Record-Route时，使用了错误的内外网IP地址。导致BYE请求按照route头发送时，无法正确找到对应的服务器。 Contact头部的URI不正确，导致BYE请求无法找到对应的服务器。 时序图如下； sequenceDiagram autonumber participant u1 as user1 participant o as opensips participant u2 as user2 u1->>o: INVITE o->>u2: INVITE u2-->>o: 200 OK o-->>u1: 200 OK u1->>o: ACK o->>u2: ACK u2->>o: BYE o-->>u2: 477 Send failed (477/TM) 477错误一般是按照route头或者contact转发时，找不到对应的socket。 在使用tcp作为传输协议时，例如tcp/tls/wss注册的分机比较常见。 有以下可能 分机到opensips的tcp连接断开 contact使用错误的transport参数 从过观察第2个信令的Conact头，发现transport=ws, User-Agent=JSSip。 正常情况下，jssip应该使用wss作为transport。 所以解决办法是，在jssip的配置中，将transport改为wss。 还有一个解决方案， 就是让jssip通过nginx转发wss请求，让nginx转发到opensips的ws端口, 也能解决问题。 sequenceDiagram autonumber jssip ->> nginx: wss nginx ->> opensips: ws

案例分享 最近有客户反馈，自己的话机最近一两周都没有收到来电了，感觉很奇怪，他自己呼叫400号码，然后转分机，也接不通。 组网结构 flowchart LR ua1(分机) fw1(防火墙) uas1(SIP服务器) ua1 --> fw1 fw1 --> uas1 排查思路 首先排查服务端，从日志来看，分机的注册是正常的，每隔30多秒就注册一次。 然后排查呼叫信令图，发现发送给分机的INVITE， 分机那边没有任何反应 接着请求客户远程协助，在分机上抓包，发现只能抓到注册包，没有INVITE的回应。 询问客户，他们公司有没有使用防火墙，客户说有。 然后让客户检查他们防火墙的设置，关闭SIP ALG功能，但是也无效 然后让客户找网络负责人，在防火墙上抓包，发现防火墙收到了INVITE，但是没有转发给内部分机, 原因未知 最后找防火墙厂商，发现是防火墙的UDP组包没有开启，开启UDP分片重组后，呼入电话能正常进线 总结 此刻，我回想起曾经写的 UDP分片导致SIP消息丢失 没想到，在防火墙上也遇到了同样的问题。

为什要用 RTPEngine 来录制 PCAP 文件？ 一般我们用 Freeswitch 来作为录音服务器， 但是某些场景，例如备份录音，需要在不同节点进行录音。 如果直接录制成 wav 文件，那么比较占用资源，而且备份录音用的几率也是比较小的。 因此录制成 PCAP 文件，可以节省资源，后期 pcap 转语音也能比较容易的实现。 实现步骤 配置rtpengine启动参数 --pcaps-dir=/var/log/records --record-method=pcap --recording-format=eht 在opensips在做SDP Offer rtpengine_offer("record-call=yes"); 录音文件位置 录音文件在/var/log/records目录下，文件名是呼叫的sip Call-ID-16hex随机数.pcap call1-1234567890abcdef.pcap call2-1234567890abcdef.pcap 录音文件内容 录音文件用wireshark分析，可以听到主被叫双方的声音。 其他 除了录音文件，一些录音的元数据，例如SDP之类的信息，会被记录到录音的目录下。