无双的技术博客 记录 AI、Linux、网络架构、FreeSWITCH 与企业数字化实践

归档

2026 年 07 月

隧道建立后小包正常、大文件拉胯,iperf3测速只有标称带宽的30%。排查一圈发现不是设备性能问题,是GRE头+IPSec头+双层IP头加起来把MTU撑爆了,内核被迫在隧道里做分片,性能直接崩掉。
FreeSWITCH多设备注册踩坑经历,客服系统需要坐席分机号在软电话和IP话机上同时注册实现同振,但dual-reg默认是覆盖模式,外呼时From头域还可能选错终端。本文从故障排查到方案落地,完整记录这个看似简单却坑点重重的需求。
freeswitch SIP中继注册头导致的验证,返回403不代表密码错了,问题往往不在认证环节——运营商校验的是 SIP 头域里的域名格式,而不是你的密码。From/To 头域里的 `@your_domain.com` 和 Contact 头域里的 `172.16.1.100` 不匹配运营商的要求,注册请求在认证之前就被拒绝了。
大多数工程师知道端口号是16位,所以认为最多65535个连接。但实际定位瓶颈在文件描述符、系统参数、内存、网络命名空间等多个层面。本文通过实际命令输出和参数对比,展示完整的排查路径。
perf/gprof/Valgrind三者的overhead、准确性、多线程支持有本质差异。延迟敏感服务和高并发服务的选型策略完全不同,本文给出决策矩阵和取舍权重。
跨国出口流量定位:如何从traceroute的IP序列追溯到BGP路由决策,当traceroute显示跨国延迟高时,大部分人盯着TTL递增的IP地址发呆。真正有效的定位方法是把traceroute当作BGP路由表的查询入口——每一跳IP背后都对应AS边界和BGP决策点,理解这些才能判断流量为什么走了当前这条路径,而不是你以为的那条。
将deepseekv4 pro接入claude code,让生产效率翻倍,适合已经在用 Claude Code,但想试试 DeepSeek V4 Pro 的人、想要更长上下文处理大项目的人、想降低 AI 编程工具使用成本的人
可以满足中小型企业自用的呼叫平台,自己配置完话术、asr和tts就可以开始做业务相关的呼叫了,项目已开源。
如果你做过 FreeSWITCH 和业务系统集成,大概率会遇到一个绕不开的问题:ESL 很强大,但业务系统真正接入时,工程复杂度并不低。你需要维护 ESL 长连接,需要处理断线重连,需要从大量底层事件里还原通话状态,还要把 `uuid_kill`、`uuid_transfer`、`uuid_record`、`originate` 等命令再封装成业务接口。等到项目进入 AI 外呼、智能客服、语音机器人这类实时语音场景时,事情会更复杂:呼叫控制、通话状态、音频推流、播放打断、PCM 回灌,往往会分散在多个服务和多层逻辑里。所以我做了一个 FreeSWITCH 原生模块:`mod_fcc`。 它想解决的问题很明确:让业务系统不用直接面对 ESL,而是像调用普通服务接口一样使用 FreeSWITCH 的呼叫能力。
有时候技术交流里最让人无奈的地方,不是对方不知道,而是对方已经被某些“标准答案”占满了脑子。好像只要谈 RAG,就必须谈向量数据库;只要谈向量数据库,就必须谈 Milvus、Qdrant、Weaviate;如果你说 PostgreSQL + pgvector,反而显得你不够“高级”。但工程选型不是品牌崇拜。专业也不是把最重的组件搬进系统里。专业是先看问题,再看工具。