All

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消息丢失 没想到，在防火墙上也遇到了同样的问题。

TL;DR 攻击者伪造DTLS ClientHello消息，在SIP服务器和客户端之间建立一个非预期的连接。导致正常链接被阻断。 影响软件 FreeSWITCH RTPengine asterisk FreePBX 漏洞白皮书 webrtc-hello-race-conditions-paper 表现 应答后呼叫无声 参考 https://github.com/EnableSecurity/advisories/tree/master/ES2023-03-rtpengine-dtls-hello-race https://github.com/EnableSecurity/advisories/tree/master/ES2023-02-freeswitch-dtls-hello-race https://github.com/EnableSecurity/advisories/tree/master/ES2023-03-rtpengine-dtls-hello-race

2025 年 5 月 27 - 5 月 30 日, OpenSIPS Summit 2025 在荷兰阿姆斯特丹举行。 最近我才有时间，看完所有的会议资料，包括 PDF 和 PPT。 下面是我整理的，认为比较有价值的一些内容。以飨读者。 1. 加强 SDP 处理 对 SDP 的处理，如果用 OpenSIPS 脚本来做，将会非常蹩脚。 生产环境一般都是使用 rtpengine 或者 rtpproxy 来处理。 但是，最近的 OpenSIPS 版本，已经可以支持 SDP 处理了。 可以直接在 OpenSIPS 脚本里处理 SDP。 说实话，我看了新的方案，我觉得，还不如用 rtpengine 或者 rtpproxy。 但是聊胜于无吧，感兴趣的可以看看原文。 OpenSIPS Summit 2025 - Liviu Chircu - Enhanced Media Operations with Structured SDP 除此以外，PDF 也提到一些有趣的事情，比如 SDP 随着时间推移，增强和很多功能，包也变得越来越大 时期 内容 包大小 1998 基本媒体行 200-400 bytes 2002 编码协商，rtpmap 500-1000 bytes 2010 ICE/DTLS 1-2 kb 2015 WebRTC, Simulcast, Bound, MID 2-3kb 在线会议，SFU 3-5 kb 可以想象，随着媒体能力的增强，UDP包的SIP信令中的分片几乎成为必然，所以，是否可以考虑有限使用TCP/TLS来传输信令呢？ ...

STUN 请求处理 flowchart TD __wildcard_endpoint_map-->__assign_stream_fds monologue_offer_answer-->__assign_stream_fds monologue_publish-->__assign_stream_fds monologue_subscribe_request1-->__assign_stream_fds call_make_transform_media-->__assign_stream_fds __wildcard_endpoint_map -->__get_endpoint_map monologue_offer_answer -->__get_endpoint_map monologue_publish -->__get_endpoint_map monologue_subscribe_request1 -->__get_endpoint_map call_make_transform_media -->__get_endpoint_map __assign_stream_fds --> stream_fd_new __get_endpoint_map --> stream_fd_new stream_fd_new --> stream_fd_recv stream_fd_new-->stream_fd_readable stream_fd_readable-->__stream_fd_readable stream_fd_recv--> __stream_fd_readable--> stream_packet--> media_demux_protocols --> stun --> __stun_request --> ice_request 从SDP Offer之后，stream_fd_new 函数里做了几个事件订阅， 当对应的的媒体端口收到包之后，这个包可能是好几种协议，例如RTP, DTLS, STUN等。 在media_demux_protocols() 中决定了这个包是以上包的哪一种， 如果是STUN包，则进入stun()中处理。 STUN包也分为请求和响应，当消息是响应时，进入ice_request(). 1int ice_request(stream_fd *sfd, const endpoint_t *src, 2 struct stun_attrs *attrs) 3{ 4 struct packet_stream *ps = sfd->stream; 5 struct call_media *media = ps->media; 6 struct ice_agent *ag; 7 const char *err; 8 struct ice_candidate *cand; 9 struct ice_candidate_pair *pair; 10 int ret; 11 12 ilogs(ice, LOG_DEBUG, "Received ICE/STUN request from %s on %s", 13 endpoint_print_buf(src), 14 endpoint_print_buf(&sfd->socket.local)); flowchart TD ice_update-->__do_ice_checks ice_agents_timer_run-->__do_ice_checks __do_ice_checks --> __do_ice_check

1. 简介 DTLS（Datagram Transport Layer Security，数据报传输层安全协议）是一种为基于数据报的应用（如UDP）提供安全通信的协议。它是TLS（传输层安全协议）的扩展，专门设计用于不可靠的传输协议（如UDP），以实现数据加密、身份认证和消息完整性保护。DTLS常用于VoIP、视频会议、WebRTC等实时通信场景。 DTLS在WebRTC音视频中是强制必须使用的，否则媒体协商阶段就会失败。 使用DTLS后，就算中间人从网络中抓包，抓到了RTP流，在播放RTP流时，里面也全是噪声，无法播放的。 今天要讲的是就是DTLS协商失败导致电话即使接通，也无声的问题。 2. 网络结构说明 UAS: sip server, OpenSIPS + RTPEngine组成 UAC: WebRTC 分机 F1. UAS ----> UAC: INVITE (SDP) F2. UAS <---- UAC: 180 F3. UAS <---- UAC: 200 Ok (SDP) F4. UAS ----> UAC: ACK 从SIP信令上看，被叫应答后，UAS和UAC之间的双向媒体流应该建立起来，但是实际上却无声。 3. ICE/STUN/DTLS ICE: WebRTC中的ICE（Interactive Connectivity Establishment，交互式连接建立）是一种网络协议，用于帮助WebRTC客户端在不同网络环境下建立点对点（P2P）连接。ICE的主要作用是解决NAT穿透和防火墙问题，使两个终端能够找到最佳的通信路径。 STUN: WebRTC中的STUN（Session Traversal Utilities for NAT，NAT会话穿越实用工具）是一种网络协议，主要用于帮助客户端发现自己的公网IP地址和端口。由于很多设备处于NAT（网络地址转换）或防火墙之后，直接通信会遇到障碍，STUN可以让客户端知道外部网络如何访问自己 在分机应答后，并在WebRTC发送本地媒体流前，还需要两个步骤协商完成UAC才会发送语音流 3.1 STUN协商 UAC收到来自UAS的SDP, 里面一般有如下内容 m=audio 54322 UDP/TLS/RTP/SAVPF 111 0 8 a=ice-ufrag:abcd a=ice-pwd:1234567890abcdef a=ice-options:trickle a=fingerprint:sha-256 12:34:56:78:90:AB:CD:EF:12:34:56:78:90:AB:CD:EF:12:34:56:78:90:AB:CD:EF:12:34:56:78:90:AB:CD:EF a=setup:actpass a=candidate:1 1 udp 2130706431 1.2.3.4 54322 typ host STUN是一个请求响应模型的协议。UAC将会向a=candidate里的1.2.3.4:54322 发送UDP消息 ...

场景说明 如下图所示 Offer阶段，F1, F2 步骤里PCMU编码有个fmtp参数abc=no, 这个参数可能只对呼叫发起方有意义，对被叫方来说，只会被忽略。 Answer阶段, 例如被叫是个FreeSWITCH, 它不认识abc=no, 就直接忽略，然后应答编码是PCMU。但是rtpengine认为不带abc=no的参数，就认为这个PCMU的编码是不可能被选中的，然后就直接删掉了PCMU编码， 只保留了一个101编码 由于主叫收到101的编码，而没有语音的编码，所以主叫收到200 Ok后立马就发送了BYE // F1: send offer to rtpegnine m=audio 2000 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=fmtp:0 abc=no a=rtpmap:8 PCMA/8000 a=fmtp:8 abc=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 // F2: receive offer from rtpengine m=audio PORT RTP/AVP 0 8 101 c=IN IP4 203.0.113.1 a=rtpmap:0 PCMU/8000 a=fmtp:0 abc=no a=rtpmap:8 PCMA/8000 a=fmtp:8 abc=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 // F3: send answer to rtepngine m=audio 2002 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 // F4: expect receive answer from rtpengine m=audio PORT RTP/AVP 0 101 c=IN IP4 203.0.113.1 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 问题原因 刚开始我以为是， https://github.com/sipwise/rtpengine/commit/9c00f30 这次commit引起的问题，我尝试注释代码，然后进行测试，发现可以解决问题。 ...

简介 VoIP高可用包含很多方面，主要包括： 接入层高可用：怎么保证某个接入点出现问题，不会影响到整个平台不可用？ 核心层高可用：怎么保证路由选择的高可用，某个网关不可用，继续尝试其他网关？ 存储层高可用：怎么保证不会丢失录音文件，怎么保证录音文件的完整性？ 数据库层高可用：怎么保证注册信息能够在集群中同步？ 接入层高可用 最简单的场景， 只有一个fs, 无论是ua还是gw都接入到fs1上 ua1 ----> fs1 ua2 ----> fs1 gw1 ----> fs1 gw2 ----> fs1 如果要实现高可用，最简单的做法就是再加一个fs2。但是加了fs2之后，ua和gw的接入策略就需要改变了。 为了保持客户端的接入策略不变，最简单的做法加上一个负载均衡器，然后由负载均衡器来做信令转发。 ua1 ----> op1 ----> fs1 ua2 ----> | ----> fs2 gw1 ----> | gw2 ----> | op1是单节点的，也会存在单点故障问题，因此引入op2。 ua1 ----> op1 ----> fs1 ua2 ----> op2 ----> fs2 gw1 ----> | gw2 ----> | 引入op2之后，有两个方案来保证高可用： 方案1, 主备: op1和op2用VIP来对外提供服务，op1和op2的VIP是一样的。实际只有一个在工作，另外一个处于备份状态。 一旦op1出现问题，op2接管VIP对外提供服务。 - 优点: 简单 - 缺点: - 兼容性：不是所有云平台都支持VIP - 成本：需要额外的硬件成本，而且还是闲置状态 - 负载：op1和op2都需要对外提供服务，但是实际上只有一个在工作，一个节点的处理能力有限，总会达到瓶颈 ...

简化网络模型 A 硬件话机 S SIP 服务器/媒体服务器 B 客户手机 A <-SIP/RTP> S <-SIP/RTP> B 问题说明 通话接通后，双方听不到对方的声音。 呼叫流程 S 发起呼叫，A 接听后，bridge B 排查思路 检查S在INVITE A时，SDP里携带的c=行，是否是S的公网IP。检查后无问题 在A上抓包，发现有 S->A的RTP包，也有 A->S 的 RTP 包。 将第二步的抓包文件拿到wireshark中分析。发现S->A方向的包是正常的，能播放出声音；A->S方向虽然有RTP包，但是看波形是一条直线，非常奇怪。 S->A方向的RTP包，在wireshark中能播放出声音，理论上A应该能听到B的声音的。但是用户反馈听不到。 咨询用户，用户是如何接听电话的。用户反馈是通过话机手柄接听的电话 让后让客户使用免提的方式拨打接听电话，发现可以听到声音。 让客户拍照话机手柄插入话机的接口，发现手柄插入的接头插入了耳麦的接口。 让客户将手柄插入正确的手柄接口，问题解决。 延伸思考 这次问题排查，让我想起了之前看过的思科的排除语音质量问题 这篇文章把语音质量问题分为三类： 网络相关(包括网关(GW)和PSTN问题) 电话型号/固件相关 设备(例如头戴式耳机)相关 在步骤上： 步骤1.隔离语音质量问题的第一步是找出确切的用户体验并与他们交谈（无论是面对面还是通过电话），以获得对语音质量问题的准确描述。如果有大量用户报告问题，请与他们的样本（可能是5-10个）交谈，以获得对症状的准确描述。 但是实际情况下，我们有时候迫于形势，往往只从一两个客户那里获得只言片语的信息，然后就开始排查了。客户的只言片语如果带有误导性，那么排查的方向就错了。 步骤2.记录物理位置(例如站点A，2楼)、用户名（用户的电话）、目录号码(DN)、电话型号（例如8865）、电话固件(例如11.5.1)和遇到语音质量问题的电话的IP地址。创建一个按物理位置排序的电子表格。在开始排除故障时创建此电子表格需要30分钟（或更短时间），可节省数小时甚至数天的故障排除时间。 记录信息很重要，但是实际操作中，往往因为时间紧迫，而没有记录这些信息。或者这些信息记录在头脑中，但是排查到最后才发现，自己忘记了某些信息。 步骤3.创建电子表格后，查看电话列表，了解电话有哪些共同之处，以及它们与没有语音质量问题的其他电话有何不同。之后，您可以意识到所有有问题的电话都位于同一栋大楼和同一楼层，您可以意识到有问题的电话连接到最近升级的交换机，或者您可以看到所有有问题的电话都位于特定固件上。 总结 搞VoIP这么久，碰到过很多疑难杂症。排查思路往往都是从软件或者网络策略层面去排查。 很少考虑到终端的固件和硬件设备上。 但是这次排查通话无声的问题，让我印象深刻的是，排查到最后才发现是硬件问题。 从声音的输出输出上，有不同的设备，例如有线耳机、蓝牙耳机、话机手柄、免提等。 排查这类问题，需要多方面考量。需要挖掘客户的实际使用场景，才能定位到真正的问题。 反思 客户的硬件话机，有两个接口。 手柄的接口和耳麦的接口是共用一套接口的。虽然接口上标注的很清楚，但是客户在接线的时候，没有注意到这点。 这要怎么避免呢？ 骂客户是傻逼吗？ 是不是在设计接口的时候，就应该使用不同形状的接口。 比如手柄接口是圆形，耳麦接口是方形。 这样就能避免这种问题了。 或者说，接口是通用的。无论是手柄还是耳麦，插上都能用呢。 还有一种方案，就是只保留一个接口，手柄和耳麦共用一套接口。两者是互斥关系。