Logo

菜单

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

所有标签

#sft 2 #model evaluation 2 #data engineering 2 #LLM fine-tuning 2 #max_length 1 #OOM 1 #vLLM 1 #LoRA 1 #realm 1 #容器化 1 #docker 1 #Iptables 1 #VPN 1 #GRE 1 #eBPF 1 #Gre over IPSec 2 #MTU 1 #Freeswitch多注册 1 #中继网关 1 #Linux 0 #gprof 1 #perf 1 #BGP 1 #origin 1 #AS_PATH 1 #MED 1 #localpref 1 #AI Coding 1 #Claude Code 1 #Deepseek 1 #VOIP 3 #Freeswitch 4 #开源呼叫系统 1 #freeswitch模块 1 #fs_mod 1 #voip 1 #freeswitch 2 #Qdrant 1 #Milvus 1 #pgvector 1 #RAG 1 #Halo 0
不想再写 ESL 网关？我做了一个 FreeSWITCH 原生呼叫控制模块
FreeSWITCH / VoIP #freeswitch#voip#fs_mod#freeswitch模块

不想再写 ESL 网关？我做了一个 FreeSWITCH 原生呼叫控制模块

如果你做过 FreeSWITCH 和业务系统集成，大概率会遇到一个绕不开的问题：ESL 很强大，但业务系统真正接入时，工程复杂度并不低。你需要维护 ESL 长连接，需要处理断线重连，需要从大量底层事件里还原通话状态，还要把 `uuid_kill`、`uuid_transfer`、`uuid_record`、`originate` 等命令再封装成业务接口。等到项目进入 AI 外呼、智能客服、语音机器人这类实时语音场景时，事情会更复杂：呼叫控制、通话状态、音频推流、播放打断、PCM 回灌，往往会分散在多个服务和多层逻辑里。所以我做了一个 FreeSWITCH 原生模块：`mod_fcc`。 它想解决的问题很明确：让业务系统不用直接面对 ESL，而是像调用普通服务接口一样使用 FreeSWITCH 的呼叫能力。

Administrator Administrator 发布于 2026-07-04
RTP语音流穿越NAT的深度排查：从STUN/TURN/ICE机制到媒体端口选择的完整定位链
FreeSWITCH / VoIP #freeswitch#VOIP

RTP语音流穿越NAT的深度排查：从STUN/TURN/ICE机制到媒体端口选择的完整定位链

FreeSWITCH对接传统PBX时，一方在NAT后出现单向通话或无声音。排查过程从STUN绑定响应入手，发现对端是对称型NAT导致的非对称路径拒绝。这篇文章复盘完整的排查链：SDP解析→ICE候选交换→STUN Binding→对称型NAT判定→TURN中继回退，重点剖析为什么最终选了TURN而不是其他方案。

Administrator Administrator 发布于 2026-07-04