**AI语音对话的自然轮转，有一条清晰的感知红线。** 人类在约500ms的静默后开始感到“停顿”，在约1秒后开始抢话或挂断。500–800ms的端到端延迟被定义为“好”，800ms–1.2s为“可接受”，超过1.5s则被来电者感知为“电话等待音”。对于美国市场的AI外呼，**SIP Trunking不是“接通就行”的管道，而是800ms预算中一块可以被压缩、也最容易被忽视的固定成本**。
延迟的时钟从用户停止说话开始，到回复的第一个音频字节抵达用户耳朵结束。以下是各环节的典型预算范围：
| 环节 | 典型范围 | 可控性 | 备注 |
|---|---|---|---|
| 端点检测（VAD） | 20–300ms | 中 | 阈值过保守是常见错误；700ms的静默阈值在测试中“安全”，在真实通话中“很糟糕” |
| ASR最终转录 | 100–300ms | 中 | 流式ASR将最后一部分刷入最终结果 |
| LLM首Token（TTFT） | 200–700ms | 中 | 常被过度优化，但并非总是最大头 |
| TTS首音频块 | 80–300ms | 中 | 必须流式合成，不能等完整句子 |
| 网络与电话（含SIP Trunking） | 50–300ms | 高 | 运营商腿、SBC、jitter buffer、跨区域跳转 |
| 合计 | 约800ms–1.5s | — | 这就是来电者感知到的“停顿” |
**关键认知**：SIP Trunking所在的“网络与电话”环节，是**唯一不依赖模型质量、只依赖架构选择**的延迟来源。Exotel的分析直指核心：“延迟优化主要是一个拓扑决策。把提示词模板削减30ms，远不如不把媒体路由跨越大洋”。
每一次额外的中继跳数都在800ms预算中划走固定份额。一个典型的“低效路径”是：VICIdial → Asterisk → SIP Trunk → Twilio → Media Streams WebSocket → AI Worker。**Twilio仅作为中继层就增加了约90ms的往返延迟，并附带$0.0105/min的中继成本**。将同一路径改为直接SIP桥接(Asterisk → SIP Extension → RTP → AI Bridge)后，**90ms延迟和全部中继成本被同时消除**，总响应时间降至sub-500ms。
**原则**：每一层不直接参与AI推理的中继，都是延迟和成本的叠加项。能用一次SIP INVITE直达AI端点的，不要绕经额外的媒体中继。
美国SIP Trunking提供商的网络类型，直接决定p95延迟的稳定性。Twilio的公共互联网路径在p95延迟上方差更大，而**Telnyx的私有IP骨干网在大多数区域通常给出低50–100ms的p95 SIP延迟**。在AI语音场景中，p95比p50更重要——偶发的延迟尖峰正是“打断感”和“抢话”的触发点。
| 网络类型 | p95延迟特征 | 对800ms预算的含义 |
|---|---|---|
| 私有骨干网 | 更低、更稳定（Telnyx典型<100ms SIP延迟） | 为模型侧留下更多余量 |
| 公共互联网路径 | 方差更大，尖峰更频繁 | 需要更保守的jitter buffer，基线延迟被抬高 |
Jitter Buffer是平滑RTP包到达波动的缓冲区，但配置不当会系统性抬高基线延迟。**默认范围60–200ms适用于大多数网络条件**，调优的核心原则是：**对高抖动路由增大最大值，而不是提高最小值**。提高最小值会给每一通呼叫增加基线延迟，而增大最大值只在抖动发生时付出延迟代价。
| 场景 | 最小值 | 最大值 | 逻辑 |
|---|---|---|---|
| 稳定低抖动网络 | 60ms（默认） | 200ms（默认） | 无需调整 |
| 已知高抖动路由 | 保持60ms | 提升至250–300ms | 用峰值容忍换取基线稳定 |
| 全球/跨云路径 | 保持默认 | 提升最大值 | 避免为偶发尖峰永久加延迟 |
**实操提醒**：如果SIP Trunking提供商支持按连接启用jitter buffering，**只对实际存在抖动的路由开启**，而不是全局开启。
**“所有环节都流式化，包括你认为小到不值得流的环节”**。部分转录立即送入提示词构建器，TTS在第一个句子边界出现时就开始接收token。**任何一个环节等待前一环节“完成”，800ms预算就已经输了**。
**编解码选择**：G.711是AI语音中最稳妥的选择。窄带编解码器(如G.729)虽然节省带宽，但会剥离语音AI所需的声学细节，且转码本身引入10–40ms的SBC/媒体处理延迟。在800ms的预算中，**为了带宽而牺牲音频质量和增加转码延迟，通常不划算**。
| 预算环节 | 未优化典型值 | 优化后目标 | 主要杠杆 |
|---|---|---|---|
| 运营商腿（单向） | 40–150ms | 40–100ms | 就近接入、私有骨干 |
| SIP中继/SBC/媒体处理 | 10–40ms + 额外跳数（每跳可达90ms） | 10–40ms，零额外跳数 | 减少中继层、直接SIP桥接 |
| Jitter Buffer | 基线被最小值抬高 | 60ms最小值，峰值容忍200–300ms | 增大最大值而非最小值 |
| 传输到AI栈 | 5–60ms（取决于跨区域跳转） | 5–20ms | 区域本地端点，避免跨洲 |
| SIP侧合计 | 50–300ms+ | 50–150ms | 拓扑决策优先于参数调优 |
**架构层面**：
1. **画出你的中继路径**，数一数从PSTN到AI Worker之间有几个不参与推理的媒体中继层。每一层都在800ms中划走固定份额。
2. **优先选择私有骨干网的SIP Trunking提供商**，关注**p95 SIP延迟**而非仅看p50。
3. **确认AI端点与SIP中继提供商网络的对等或就近互联**，避免媒体跨越大洋。
**配置层面**：
4. **Jitter buffer保持默认最小值(60ms)，只在高抖动路由上增大最大值**。
5. **流式化每一个环节**，VAD触发后立即输出部分转录，TTS首token到达即开始合成。
6. **使用G.711**，除非带宽约束迫使你接受转码延迟和声学质量损失。
**测量层面**：
7. **从来电者侧测量**，而不是从服务器到服务器。运营商腿和跨云往返是“没人做预算的那部分等待”。
8. **监控p95而非p50**，AI对话的“打断感”由尾部延迟触发，而非均值。
**把美国AI对话延迟控制在800ms以内，SIP Trunking侧的核心不是“调一个参数”，而是做对三个拓扑决策：减少中继跳数、选择私有骨干网络、将媒体锚定在离AI栈最近的位置。** 在这三个决策之后，Jitter Buffer调优和流式传输才是有意义的精细化操作。反过来，如果中继路径本身绕了远路，再激进的模型优化也无法把预算拉回800ms以内——**运营商腿和跨云往返，才是那个“没人做预算、但每个人都在等”的沉默成本**。
