在配置 SIP Trunk 时，认证方式的选择直接影响接入效率、安全性和运维复杂度。尤其对于 Voice AI 云平台(如 ElevenLabs、LiveKit、Retell)而言，**Digest 认证和 IP 白名单(IP ACL)的适用场景截然不同**。选错了，轻则配置繁琐，重则在生产环境中频繁断线。
**IP 白名单(IP ACL)** 是一种**基于源 IP 地址的信任机制**。你将自己的服务器公网 IP 提供给运营商，运营商将其加入允许列表。此后，来自该 IP 的所有 SIP 请求都被信任，无需每次通话验证用户名和密码。它的核心特征是：**信任绑定在“地址”上，而非“凭证”上**。
**Digest 认证** 则是一种**基于用户名和密码的挑战-响应机制**。当 SIP REGISTER 或 INVITE 请求到达运营商时，运营商会返回一个 nonce 挑战。客户端使用 `username:realm:password` 结合 nonce 计算哈希值并发回，运营商验证通过后建立通话。**没有任何明文密码在网络上传输，信任绑定在“凭证”上**。
| 对比维度 | IP 白名单（IP ACL） | Digest 认证 |
|---|---|---|
| 信任基础 | 源 IP 地址 | 用户名+密码 |
| 适用 IP 类型 | 静态公网 IP | 动态/未知 IP |
| 每次通话开销 | 极低（无认证握手） | 标准挑战-响应开销 |
| IP 变化影响 | 所有 Trunk 立即中断 | 无影响 |
| 密码泄露风险 | 无（无需密码） | 有（需安全管理凭证） |
| 典型适用场景 | 本地 PBX、固定数据中心 SBC | 云 Voice AI 平台、动态 SBC |
**Digest 认证是为“动态 IP”而生的。** Exotel 的官方文档明确指出：当你的 SIP 端点是云 Voice AI 平台(或任何源 IP 动态/未知的环境)时，应使用 Digest 认证，以避免管理 IP 允许列表。
**为什么云平台不能用 IP 白名单?** 云 Voice AI 平台(如 ElevenLabs、LiveKit、Retell)运行在共享的 AWS 或 GCP 基础设施上，使用动态出口 IP。Exotel 在发布 Digest 认证功能时，直指这一痛点：“云 Voice AI 平台没有静态 IP。它们运行在共享的 AWS 或 GCP 基础设施上，出口 IP 是动态的。唯一的变通方法是收集所有可能的出口 IP 范围，全部加入允许列表，然后祈祷云基础设施不会变化。”
一旦 IP 变化，所有依赖 IP 白名单的 Trunk 会**同时中断**，需要在生产环境中紧急调试、添加新 IP、再次祈祷。
**Digest 认证的配置极简**：Voice AI 平台只需要三个东西——**username、password，以及你的 Exotel SIP 域名**。Exotel 的 SIP 边缘地址为：TCP `in.voip.exotel.com:5070`，TLS `in.voip.exotel.com:443`。
**Exotel 官方推荐**：Digest 认证“推荐用于 Voice AI 直接中继、动态 SBC、多租户提供商网络”，特别点名了 ElevenLabs、LiveKit、Retell 等平台的 SIP Trunking 配置。
**IP 白名单是为“固定 IP”而设计的。** Exotel 文档指出：当你的 Trunk 连接到客户控制的、具有稳定已知出口 IP 的 PBX/SBC 时，应使用纯 ACL 模式。
**IP 白名单的核心优势**：**没有每次通话的认证握手开销**。VICIdial 的文档解释了其工作原理：“运营商信任来自已知 IP 地址的任何呼叫，而不是每次通话都检查用户名和密码。信任是双向的：你的服务器接受来自运营商 IP 的入站呼叫，运营商接受来自你的 IP 的出站呼叫。”由于没有注册字符串，也就没有凭证过期的问题。
**IP 白名单的致命局限**：**信任完全绑定在地址上**。如果服务器 IP 发生变化，所有 IP 认证 Trunk 会**同时中断**，直到运营商重新白名单新地址。这在固定 IP 的机器上几乎不会发生，但正是运营商为“会移动的服务器”提供注册认证替代方案的原因。
**典型适用场景**：本地部署的 PBX(Asterisk、FreeSWITCH)、固定数据中心内的 SBC、受控的企业网络环境。
**当你有稳定的 IP 且需要更严格的安全姿态时，可以同时启用 IP 白名单和 Digest 认证。** Exotel 文档建议：“当你同时拥有凭证和稳定 IP，并希望采用更严格的安全姿态时，使用两者。这减少了攻击面——仅凭凭证不足以通过，除非同时匹配允许列表，反之亦然。”
这种组合模式适用于生产环境 Trunk 且拥有固定 IP 范围的企业，在安全性和可管理性之间取得平衡。
| 你的情况 | 推荐认证方式 | 原因 |
|---|---|---|
| 使用云 Voice AI 平台（ElevenLabs/LiveKit/Retell） | 仅 Digest 认证 | IP 动态变化，无法维护白名单 |
| 本地 PBX/SBC，固定公网 IP | 仅 IP 白名单 | 无每次通话开销，配置简单 |
| 固定 IP + 高安全要求 | IP 白名单 + Digest 认证 | 双重验证，减少攻击面 |
| 服务器可能迁移或 IP 会变化 | Digest 认证 | IP 变化不会导致 Trunk 中断 |
**一个关键提醒**：即使使用 Digest 认证，也需注意 **Plivo 等平台对共享 IP 的警告**——如果你的 SIP 提供商处于运营商级 NAT 或共享 IP 平台上，仅靠 IP ACL 可能不足，应使用 `ip_acl_and_credential` 实现纵深防御。
**Digest 认证和 IP 白名单不是“哪个更好”的问题，而是“哪个匹配你的基础设施”的问题。** 云 Voice AI 平台的动态 IP 特性决定了它们**必须使用 Digest 认证**，这是唯一不需要持续维护 IP 列表的方案。本地 PBX 和固定数据中心 SBC 则更适合 IP 白名单，以换取更低的信令开销。在安全要求极高的场景中，两者组合使用可以构建最严格的接入控制。
