夜雨聆风语音AI代理已经从演示视频走向了实际的电话号码。AI接待员接听牙科诊所的电话，Vapi、Retell和Bland的外呼拨号器每小时触达数千名消费者，联络中心在人工客服介入前，将每个客户电话的第一段路由到语音转文本和语言模型管道。语音AI集群是技术栈中受到市场关注的部分。会话边界控制器（SBC）是决定所有这些是否能在公共交换电话网络（PSTN）上实际运行的部分。
AI技术大背景
AI加CC或者UC如果离开了用户体验基本上就没有新的商业价值。在AI语音的应用中，厂家需要面临各种技术挑战。
并且，在VOIP场景中的AI应用应该形成闭环，其中一环断裂就无所谓智能。
在以下的分享中，将介绍当SIP中继另一端的终点是一个语言模型而不是人类时，会发生哪些变化，SBC在流程中的位置，以及影响延迟、认证、欺诈风险和容量规划的实际配置选择。
另外，本文章是为评估如何将AI代理投入生产的语音基础设施运营商输出的报告，也问语音机器人供应商的AI产品团队提供技术参考。
AI语音代理如何改变流量模式
传统的联络中心具有相当稳定的曲线。呼叫在一整天内到达，座席登录轮班，并发会话计数在可预测的范围内移动。AI语音代理引入了几种联络中心容量规划通常无法涵盖的流量模式，并且它们首先都落到SBC上。
突发式外呼拨号
一个AI外呼活动可以从冷启动开始，每秒触发数百个呼叫，保持数万个并发会话的峰值一小时，然后降至零。拨号器不会像一屋子的真人那样控制速度。根据日平均值确定SBC的大小是这里的失败模式；突发峰值才是决定您的SIP中继线组、NAP容量和每秒呼叫数(CPS)限制是否能保持的关键。针对每个运营商配置的每NAP CPS限制通常是生产环境中第一个失效的约束，应在启动前设置。
永远在线的呼入
AI接待员在每个小时接听每个电话，没有下班后队列，也没有溢出到语音信箱。SBC的SIP OPTIONS心跳、注册健康状况和证书有效期都必须在没有维护窗口的情况下保持，并且适用于Teams Direct Routing部署的相同信任存储卫生也适用于机器人连接的任何TLS端点。
短语，长通话
AI代理以短而频繁的轮换方式进行对话。媒体流是许多小RTP突发，由沉默分隔，语音活动检测经常切入。针对人类对话调整的抖动缓冲行为与这种模式交互不良，尤其是在SBC还在编解码器之间进行转码时。使用SBC的每NAP抖动和编解码器配置文件来匹配AI平台实际发出的内容，并在上线前通过数据包捕获进行验证。猜测这一层是最常见的切断式插话的原因。
会话式AI通话的延迟预算
当端到端响应时间保持在约800毫秒以下时，会话式AI感觉自然。超过这个时间，呼叫者会开始询问“你还在吗？”或者在机器人之上说话。超过1.5秒，通话听起来就断断续续了。延迟预算由几个阶段构成，而SBC负责其中两个阶段。
毫秒级的路径
一个典型的往返行程大致分为以下几个部分：50-150毫秒的从呼叫者到AI集群的网络传输，150-350毫秒的ASR以产生可用的文本，150-800毫秒的语言模型推理，200-600毫秒的TTS合成，以及50-150毫秒返回给呼叫者。SBC负责第一和最后阶段，以及它在每个 leg 上执行的任何转码。
SBC在该预算中控制的内容
三个SBC设置最为重要。编解码器选择决定了SBC是解码并重新编码每个RTP数据包（硬件上的Opus到G.711转码），还是直接传递流（两个leg 上都是G.711）；硬件转码每个 leg 会增加约20毫秒，而直通增加几毫秒。抖动缓冲区深度在延迟和对丢包的容忍度之间进行权衡，AI 通话需要最浅的缓冲区，同时还要能够承受您的运营商的实际抖动，这通常低于默认值。媒体锚定与直通决定了SBC是否可以分叉音频以进行录音（锚定），还是放弃中间跳，从而放弃通话中的录音（直通）。
SBC无法修复的是AI平台本身。如果机器人感觉缓慢并且SBC配置干净，则问题出在上游。在责怪网络之前，请先测量平台上自己的指标中的ASR到首个令牌（first-token）和TTS到首个音频（first-audio）的时间。
AI-PSTN 边界的编解码器选择
编解码器不匹配是新型语音 AI 部署中最常见的生产问题。运营商提供 G.711 或 G.729。 AI 平台更喜欢 Opus，有时接受 L16 宽带，如果被要求，可能会悄悄降级到 G.711。 SBC 位于中间，决定在何处协商什么。
PSTN端想要什么
在北美，绝大多数入站 PSTN 流量以基于 RTP 的 G.711 PCMU 或 PCMA 形式到达。 运行到呼叫中的 SIP 中继提供商也经常提供 G.729 以节省中继端的带宽。 这两种编解码器都是窄带的，并且往返处理成本低廉。 ProSBC 提供软件原生的 G.711（ALAW 和 ULAW）； Opus、G.729 和 AMR 转码需要通过 Ttrans 产品线使用硬件 DSP。 额外编解码器的软件转码已在 2026 年底的路线图上，因此当前需要在运营商端使用 Opus 的纯云部署属于“需要硬件转码”的范畴。 围绕该约束构建部署计划，而不是围绕未来路线图上的内容构建。
AI端想要什么
大多数商业语音 AI 平台直接在 SIP 腿上接受 G.711，并在内部将其上采样到它们首选的采样率。 基于 WebRTC 的平台默认情况下期望 Opus 和 DTLS-SRTP，但大多数平台也公开了一个接受 G.711 的 SIP 端点。 实际模式是在 G.711 上终止运营商的呼叫（使用 SDES-SRTP），在 G.711 上终止 AI 的呼叫（使用 TLS/SRTP），并让 SBC 在每条腿上独立处理 TLS 和 SRTP。 仅当特定 AI 平台拒绝 G.711 或音频质量要求推动端到端 Opus 时，才需要转码。
DTMF问题
提示按键输入的 AI IVR 依赖于 DTMF 在编解码器跳转中幸存下来。 RFC 4733（以前的 RFC 2833）将 DTMF 作为 RTP 流中的带外电话事件发送，而不是作为带内音频音调发送。 如果 SBC 的 SDP 协商在编解码器提供/应答期间丢弃了 telephone-event 有效负载类型，则机器人将停止听到“按 1”。 在启动之前，请在测试呼叫中确认 telephone-event 有效负载已端到端协商，并且 AI 平台已配置为侦听它。
可编程路由：向编排器询问呼叫去向
语音AI部署很少使用静态路由表。哪个座席应答给定的呼叫取决于拨打的号码、活动、一天中的时间、首次语音识别到的语言、呼叫者与品牌的历史记录，以及越来越多的AI编排器，它实时决定是将呼叫路由到机器人、升级到人工座席，还是转交给专门处理该主题的不同机器人。SBC需要一种方法来询问这个问题，而无需在每次更改时都重建路由表。
HTTP查询模式
ProSBC的REST API呼叫路由集成直接处理这个问题。当收到INVITE时，路由脚本向编排器发出HTTP查询，其中包含呼叫号码、拨打号码、NAP标识符以及任何其他重要的呼叫参数。编排器返回一个JSON响应，指定目标NAP、可选的头部重写和路由优先级。整个交换发生在媒体协商之前的信令阶段，因此不会增加音频延迟。
这为语音AI带来了什么
单个SBC可以服务于十几个AI座席活动，每个活动都有自己的路由逻辑，而无需静态配置更改。新的活动成为编排器数据库中的新条目，而不是新的ProSBC NAP。从机器人到人工座席的故障转移发生在编排器，而无需SBC重新加载。两种语音模型的A/B测试成为路由规则，而不是部署更改。
需要设置的边界
保持编排器查询超时时间较短（500-1500毫秒），并在查询失败时定义显式的回退方案。回退应该落在一个安全的地方：一个通用的IVR、一个默认的人工座席队列或一个忙音处理，具体取决于用例。在等待缓慢的编排器响应时让呼叫挂起是最糟糕的故障模式。 ProSBC支持HTTP查询的主要和辅助URL，因此编排器本身可以冗余部署。
人工智能语音边缘的欺诈与信任
生成式语音模型引入了SBC层历史上不需要考虑的攻击模式。有些是披着新外衣的电信欺诈问题，有些是真正全新的，而SBC是控制这些问题的最佳位置。
深度伪造来电显示和语音克隆
攻击者克隆首席执行官的声音，并使用合成的、PASSporT签名的呼叫来对付财务团队，其说服力远胜于任何人工智能之前的网络钓鱼活动。防御方法与任何来电显示欺骗相同：SBC层的STIR/SHAKEN认证，再加上欺诈评分合作伙伴，以便在呼叫响铃之前捕获高风险呼叫。ProSBC的生产级STIR/SHAKEN集成使用基于SIP的重定向到TransNexus ClearIP或Neustar，其中STI-AS充当SIP重定向服务器，并在成功路径上返回带有Identity标头的302。终端方获得关于发起方对呼叫号码的信任程度的明确信号，这是运营商层对深度伪造的唯一诚实答案。
人工智能发起的呼出和认证
监管机构关心人工智能发起的呼出呼叫是如何被认证的。由人工智能拨号器代表未经验证的终端客户拨打的呼叫不应带有A级认证；这是一种虚假陈述，可能会导致声誉和FCC风险。ProSBC的可编程路由引擎根据每次呼叫、每个活动或每个NAP设置认证级别，因此，处理多个AI租户流量的单个SBC可以按照适合该租户验证状态的级别签署每个租户的呼叫。认证级别路由模式对此进行了深入介绍。
提示注入和人工智能特有的滥用
语音AI代理具有独特的攻击面：呼叫者可以说出语言模型解释为系统命令的指令。SBC不能直接解决提示注入问题，但它可以控制哪些呼叫首先到达机器人。动态黑名单、注册扫描保护和每个NAP的CPS限制减少了AI层需要看到的探测流量。相同的控制措施适用于AI特定的长途欺诈，即被劫持的拨号器可以产生大量欺诈性的国际呼叫；每个NAP的目标过滤器、高费率前缀阻止以及与TransNexus、SecureLogix或YouMail的欺诈评分集成是标准防御措施。
语音AI代理在SBC上的部署方式
几乎所有生产环境中的语音 AI 流量都遵循三种部署方式。每种方式都对 SBC 有不同的影响。
适用于中小型企业或 MSP 客户的 AI 接待员
最简单的情况：一个呼入号码，一个 AI 代理，一个租户。运营商侧一个 NAP，AI 侧一个 NAP，基本的 SIP 和编解码器处理。对于 MSP 而言，其按租户交付 AI 语音代理，其倍增因素是客户数量，而不是每个客户的复杂性。一个具有 1,024 个可用 NAP 的 ProSBC 实例可以并排托管数百个 AI 接待员，每个接待员都有自己的路由、录音和 STIR/SHAKEN 处理。
具有 AI 前端的联络中心
机器人处理每个呼叫的前 30 秒，识别呼叫者，分类请求，并解决问题或转交给人工。这是应用于 AI 代理的云通信模式。SBC 的作用与传统联络中心相同，此外还在 INVITE 时进行协调器查询，以根据拨打的号码、时间或呼叫者之前的历史记录来决定使用机器人队列还是人工队列。与 Teams Direct Routing 部署相比，联络中心 AI 流程更受益于媒体锚定以进行录音，而较少受益于媒体旁路。
外呼AI拨号器
最具挑战性的方式。活动驱动的拨号器生成前面描述的突发模式，并且每个呼叫都必须携带正确的认证级别、呼叫者 ID 和选择退出处理。ProSBC 的可编程路由引擎为每个呼叫设置所有三个参数，并且每个 NAP 的 CPS 限制保护运营商免受冲击。如果 AI 平台由第三方托管，则拨号器到 SBC 的线路通常使用 WebRTC 或基于公共互联网的 SIP/TLS，TLS/SRTP 在 SBC 处终止。容量规划以活动突发峰值为目标。
录音、合规性和双方同意
AI 辅助呼叫流程必须处理其运营所在辖区的同意规则。双方同意的州要求告知呼叫者该呼叫正在被录音或由 AI 系统处理，并且 SBC 通常是证明披露发生的层。实际模式是在 SBC 处锚定媒体，将音频（或仅是呼入线路）分叉到安全录音目标，并记录同意提示和呼叫者响应的时间戳。如果稍后呼叫受到质疑，录音会显示已进行披露并且呼叫者继续。
PII和PCI修正存在于 AI 平台层或单独的修正服务中，但 SBC 控制着原始音频是否首先到达它们。直通模式节省了 SBC 媒体负载，但放弃了审计跟踪。对于托管在 AWS、Azure 或 KVM 上运行的软件 SBC 上的部署，录音分叉目标可以是云存储端点或专用录音服务；SBC 不关心字节落在哪里，只关心是否配置了分叉。
结论
当AI平台与电话网络之间的层级表现得像一个严肃的电信基础设施，而非简单的SIP演示时，语音AI代理才能在生产环境中发挥作用。 SBC的作用是将AI集群转变成运营商可以信任、认证并路由到的东西。它还能保护AI层免受PSTN流量带来的混乱影响：编解码器差异、认证漂移、欺诈探测以及AI推理集群不希望直接吸收的突发流量。
适用于语音AI的SBC不是“AI SBC”。 它是一个可编程、多租户的SBC，具有清晰的REST API、每个NAP的编解码器和路由控制、符合实际生产模式的STIR/SHAKEN集成，以及足够容纳AI工作负载产生的突发行为的容量。 语音AI部署的基础设施问题与任何严肃的语音部署的问题相同，只是在延迟、认证和信任方面有更高的容忍度。
资料来源：
https://telcobridges.com/sbc/products/prosbc/