一、AI 外呼机器人的链路全景

现代 AI 外呼机器人是一条典型的"端—边—自建"实时语音链路:

客户手机 → 运营商 IMS/PSTN → SIP 中继 → 中继网关
→ RTP 上行(PCMA/PCMU/Opus) → 协议封装(WebSocket/gRPC)
→ 自建 ASR → 自建大模型推理 → 自建 TTS 流式下行 → RTP 下行 → 客户听筒

链路里每一个节点的编解码、抖动、抗丢包、抗噪策略,都会直接决定最终的通话质量(MOS)与首播延迟。要做出可商用、听得清、听得顺的机器人,必须把线路适配和通话降噪这两块打磨到极致。

---

二、线路适配：让机器人"接得进、放得稳"

1. 运营商 SIP 中继对接

外呼场景常见的线路类型有三种:

• IMS 线路(移动/电信 VoLTE):SIP over UDP, 支持 Opus/G.722 等宽带编解码,音频质量最好,但运营商侧常启用转码,落地后多半变成 PCMA。
• PSTN 模拟中继(传统固话):仅支持 G.711 a-law/u-law(8kHz 采样,64kbps),延迟低但频带窄。
• 第三方呼叫中心中继:协议各异,经常夹带运营商侧的录音/转码网关,链路不透明。

工程实践要点:

1. 统一 SIP 信令超时与重传参数,避免在高并发外呼时被运营商判定为攻击。
2. 号码轮询与失败重拨,对 486/487/503 等忙/拒接码做快速分类。
3. DTMF 检测采用 RFC 2833(telephone-event),不要依赖 in-band,因为 G.711 压缩 + 模拟线路会破坏 in-band 识别率。

2. 编解码协商策略

外呼机器人在编码上,建议遵循"能宽则宽、能窄则窄"原则:

场景	推荐编解码	备注
客户主叫(IMS/VoLTE)	Opus 宽带	16kHz/24kHz 采样,语音自然度高
固话/落 PCMA 的中继	G.711 a-law	兼容性最好,延迟最低
高并发自建外呼	G.729	带宽省 8 倍,需授权 license
兜底	PCMA	所有运营商必通

工程上要注意:

• 不要在 SIP SDP 里同时声明 G.729A 和 G.729B(有些运营商会拒绝非标准 annex)。
• 在中继网关侧配置 inbound-codec-negotiation,避免被运营商的 offer 牵着走。
• TTS 流式下行必须做编码适配,自建引擎给的是 Opus/Silk,但落地是 PCMA,中间要做一次转码 + 重采样,这一段最容易引入额外延迟。

3. RTP 抖动缓冲与抗丢包

外呼通话常因运营商 NAT、跨网传输出现抖动和丢包。建议:

• jitter buffer:典型配置 60~120ms 动态缓冲,根据 RTT 自适应调整。
• PLC(Packet Loss Concealment):用波形延拓 + 频域修复,在 5% 以内的随机丢包可"听不出"。
• FEC / RED:在 4G/5G 弱网下开启 Redundancy,牺牲一点带宽换稳定。
• RTCP 反馈:监听 NACK / RR,触发降码率或重传。

⚠️ 常见坑:PCMA 在 8kHz 下做 PLC 时,补出来的静音段会被听感放大成"电流声/嗞嗞声",建议在 PLC 后接一道低频高通滤波器,过滤掉 50Hz 以下的伪信号。

---

三、通话降噪:让机器人"听得懂、不串音"

1. 端侧 VAD(WebRTC VAD)

外呼场景里,客户端(麦克风)是已知的——通常是手机 Mic 或呼叫中心耳麦,但环境噪声往往是未知的(街道、办公室、家庭电视)。所以必须在客户端就做一次 VAD,把"无效音频"挡在链路之外。

WebRTC VAD 的四档模式(0~3),外呼推荐:

• mode 3(激进档):误识最低,但对弱语音(如老年用户、轻声细语)会漏检。
• 实际项目里通常双阶段确认:Candidate → ASR Confirm,先用 mode 2 抓候选,再用 ASR partial 校验,200ms 内给到打断响应。

参数调优方向(经验值,需根据实测数据调整):

• 能量门限(RMS):把"低于该阈值的语音不认为是说话",在嘈杂环境里可以适当抬升。
• 最短语音帧数:防止单个噪声脉冲触发打断,典型 8~12 帧(对应 120~180ms 持续)。
• 最短静音帧数:防止尾音切掉,典型 15~20 帧(对应 200~300ms)。

2. 噪声抑制(NS)

WebRTC 自带的 NS 是基于频域谱减法的,在平稳噪声(空调声、风扇)下效果好,在非平稳噪声(键盘声、电视人声)下会"吃音"。

更先进的方案:

• RNNoise(基于 GRU 的深度学习 NS),开源、CPU 占用低,适合实时流。
• 推理侧二次降噪:把上行音频送入自建 ASR 引擎时,自建引擎会再做一次自适应降噪,可以兜底端侧的失效。

工程建议:不要过度依赖单一链路——端侧挡 80% 的稳态噪声,推理侧再清 15% 的非稳态噪声,剩下的 5% 通过 ASR 上下文纠错。

3. 回声消除(AEC)

外呼是单向为主——机器人下行 TTS 占 70% 以上时间,客户只是短暂说话。这种"长下行 + 短上行"的特点,对 AEC 是极大考验。

关键点:

• 延迟对齐:AEC 的核心是估计"下行播放出去后,多久会被麦克风拾回来"。如果 RTP 下行的 jitter buffer 设置过大,延迟估计会偏,AEC 会把客户语音当成回声吃掉。
• 非线性残余回声抑制(ERLE):AEC 只能处理线性回声,实际听筒的微小非线性(喇叭失真)需要 ERLE 算法兜底。
• 双讲检测(DT):在客户说话 + 机器人同时说话时,要降低 AEC 收敛速度,否则会"吃字"。

外呼场景里一个隐藏杀手是:运营商侧的回声(IP 中继转 PSTN 时的 2/4 线转换),这一段回声路径上 SIP 中继完全透明,只能靠中继网关端做 robust AEC 兜底。

4. 静音检测与 PLC 的边界

“无语音 ≠ 静音”。链路里常被忽视的几个静音来源:

• RTP 静音帧(CN):RFC 3389 定义的 Comfort Noise,中继网关默认会注入,客户听到的是底噪而非死寂。
• 丢包补静音:PLC 失败时的纯静音填充,听感上会有"咔嗒"声。
• ASR/TTS 等待间隔:大模型推理 + TTS 首包之间,如果超过 800ms 还没有下行,客户会以为掉线。

工程经验:补静音的极限是 1.2 秒,超过这个时长必须触发兜底策略(快速应答、主动问候、提前结束)。

---

四、工程化与可观测性

技术方案最终要落到配置 + 指标 + 兜底三件套上:

1. 配置层:把 VAD mode、能量门限、jitter buffer、AEC 强度、PLC 策略全部参数化,通过配置中心动态下发,A/B 实验验证。
2. 指标层:必须能追踪
   • mos 通话质量分
   • asr_first_pkg_ms 首字延迟
   • barge_response_ms 打断响应延迟(目标 < 200ms)
   • vad_trigger_n / vad_false_positive_n 误识统计
   • plc_fill_ms PLC 补帧时长
3. 兜底层:
   • 打断响应延迟兜底:不论哪条路径异常,200ms 内必须停 TTS 下行。
   • 回复超时兜底:自建推理 / TTS 长时间无响应时,主动清理 pending 状态,避免客户长时间听静音(典型阈值 8s)。
   • 链路降级:在自建 ASR 故障时,可降级到端侧 KWS 兜底关键指令(“转人工”、“再见”)。

---

五、写在最后

AI 外呼的"通话质量"从来不是单一技术问题,而是线路适配 + 降噪 + 编解码 + AEC + 指标的全链路工程。每多一个优化点,就少一次投诉。

真正拉开差距的不是用了多贵的自建 ASR,而是:

• 能否在 200ms 内完成打断
• 能否在 5% 丢包下保持 MOS > 3.8
• 能否在客户说"再见"时,不让机器人卡死在自己的告别语里

把这三个问题答好,机器人才真的"听得清、听得懂、会接话"。