7. SIP 电话系统

开发者导读

在前几章中，我们已经构建了一个能说会道、聪明的 对话式 AI。在实际落地中，对话式 AI 不仅存在于网页或移动端的对话中，也需要与传统的电话网络对接。许多客服中心、金融外呼、销售助理等场景，依然依托于语音电话系统运行，而这些系统的核心协议就是 SIP（Session Initiation Protocol）。

本章将带你了解 对话式 AI 如何通过 SIP 实现与现实世界“打电话”的能力，以及它与 WebRTC 等传输方式的协作关系。我们会从 SIP 的基本原理讲起，逐步过渡到它在 Conversational AI 中的应用设计，让开发者理解如何让 AI 不止能“在网页里说话”，还可以真正“打电话、接电话”，成为企业服务体系的一部分。

本章学习目标

• 理解 SIP（Session Initiation Protocol）的基本原理与通话流程。

• 掌握 SIP 在 对话式 AI 场景中的典型应用方式。

• 理解 SIP 与 WebRTC 的关系：它是 对话式 AI 的重要接入方式之一，而非替代方案。

• 学会设计一个支持 SIP 的 对话式 AI 模块，包括呼叫控制、音频传输与状态同步。

在对话式 AI 的实际落地中，SIP（Session Initiation Protocol） 是不可忽视的一环。

它原本是为 VoIP 电话通信设计的信令协议，如今也广泛用于视频会议、广播对讲等实时音视频通信场景，是传统语音网络与现代 AI 对话系统之间的桥梁。

7.1 什么是 SIP？

SIP 的全称是 Session Initiation Protocol，即会话初始协议。顾名思义，它主要就是用于控制通信会话的建立和销毁的协议。

7.1.1 SIP 的基础概念

SIP 是一个信令协议，它用于在参与通信的双方传输控制信号。SIP 不负责传输语音或视频内容，而是负责 “谁和谁通话、什么时候开始、什么时候结束” 这类“协调工作”。

我们可以用一列火车的旅程来类比：

• SIP 就像调度员，负责安排列车出发、进站和到达。它不会亲自运送乘客，但会告诉各个车站列车何时到达、从哪条轨道进入、开往何处——这些调度信息就叫做 信令（Signaling）。

• UDP 就像铁轨，提供传输通道，让火车能顺利从一站跑到另一站。

• RTP（Real-Time Protocol） 就是那列真正跑在轨道上的 火车，负责运输内容。

• 而火车上装载的“乘客”或“货物”——也就是通信中的实际内容，比如语音或视频数据——就叫做 媒体（Media）。

因此，一个完整的通信过程可以这样理解：SIP 先通过信令完成调度（比如“准备发车”“到站”等），RTP 再在 UDP 轨道上承载媒体数据进行实时传输。

和看电影、听广播这种“单向播放”不同，电话或语音对话是 双向实时通信。这意味着它对延迟极其敏感——如果声音延迟超过 500ms，你就能明显感觉到卡顿；超过 1 秒，双方往往会“抢话”。

不过，人类对语音的容忍度很高。偶尔漏掉几个字，仍能通过语境理解意思。相比之下，如果为了保证每个字都准确而频繁重传，反而会导致延迟更高，对话变得不自然。这也是为什么语音通话普遍选择 UDP 而非 TCP——实时性比完美性更重要。

为了进一步提高稳定性，现代音频系统通常会结合 FEC（前向纠错） 与 拥塞控制 技术，即使在超过 50% 丢包率的极端网络条件下，也能维持可理解、可沟通的语音质量。

7.1.2 一个简单的 SIP 交互示例

在理解了 SIP 在通信体系中的角色之后，我们再来看它在一次“通话”中具体是怎么工作的。

在电话通信的场景中，SIP 用于建立（打电话）和释放通话（挂机），而 RTP 协议用于传输通话的内容（音频本身）。一个大大简化后的 SIP 呼叫示例大概长这样：

INVITE 5678@example.com
From: 1234@example.com
To: 5678@example.com
Content-Type: application/sdp
Content-Length: xxxx

v=0
c=IN IP4 1.2.3.4
m=audio 4000 RTP/AVP 0

SIP 看起来有点像 HTTP ——这并非巧合。SIP 的设计确实参考了 HTTP，包括 Digest（摘要）鉴权 机制。

不同的是，HTTP 是单向协议， 即“客户端-服务器”架构的协议。客户端（通常是浏览器）只能请求服务器，而服务器不能向客户端发起请求。而 SIP 是点对点协议，意味着双方都能主动发起呼叫，“你可以呼我，我也能呼你”。

看上面的 SIP 消息，可以简单理解为一次“拨号邀请”。INVITE 表示发起通话，From 是主叫方，To 是被叫方，它们都使用类似电子邮件的地址格式（即 SIP URI）来标识身份。

消息体（Body）部分是一个 SDP（Session Description Protocol，会话描述协议），用于描述通话的具体参数，比如：

• 通信地址与端口：示例中音频的 IP 地址是 1.2.3.4，端口是 4000。

• 音频编码方式：示例中的编码是 PCMU（编号 0）。与之类似的还有 PCMA，两者略有差异。一般来说，欧洲和中国使用 PCMA，北美和日本使用 PCMU。为了确保兼容性，SIP 标准要求所有设备必须支持这两种编码。

• 媒体类型：即通话中要传输的是音频、视频还是其他数据。

简单来说，SIP 用于“建立会话”，而 SDP 则用于“描述会话”。前者负责让两端“接上电话”，后者负责说明“通话该怎么进行”。

7.1.3 一个完整的 SIP 交互示例

下面，我们是一个完整的 SIP 信令交互流程。

在一次完整的通话中，SIP 的流程大致如下：

1. 呼叫建立（INVITE 阶段）

   • 主叫方（如 Alice）通过 INVITE 消息发起通话请求。

   • 被叫方（如 Bob）收到请求后，会先返回一个临时响应（1xx 消息，例如“正在振铃”）。

   • 当 Bob 接听时，返回 200 OK，表示同意接通。

2. 确认与连接（ACK 阶段）

   • Alice 收到 200 OK 后，会回发 ACK 消息作为确认。

   • 至此，双方的 SIP 握手完成，会话（Session）正式建立。

3. 媒体传输（RTP 阶段）

   • 双方通过前面 SDP 中约定的 IP、端口和编码参数，建立起 RTP 通道，

   • 开始传输真实的音频数据，进行实时语音通话。

4. 通话结束（BYE 阶段）

   • 当任意一方挂断时，会发送 BYE 消息；

   • 对方收到后返回 200 OK，表示通话释放完成。

可以看到，SIP 自始至终都不直接承载语音内容，它的职责是 “建立通道” 和 “拆除通道”，

真正的语音数据传输仍由 RTP 完成。

SIP 协议可以在多种网络传输方式上运行：它既可以使用 UDP（低延迟）、也可以使用 TCP（更可靠）、甚至通过 TLS（加密传输）。

随着互联网和 Web 技术的发展，浏览器端也逐渐需要具备实时音视频通信能力。但浏览器中并不能直接使用 UDP 或 TCP，因此，一般采用 WebSocket 来承载 SIP 消息。这种方式被称为 SIP over WebSocket。

7.2 SIP 的使用场景

SIP 诞生于运营商体系之中。

在传统电话网络中，通信依赖电路交换，使用 TUP、ISUP 或 ISDN（PRI）等专有协议。随着通信系统逐渐向 IP 化演进，出现了两条重要的分支：

• H.323：是 ISUP 和 ISDN 协议向 IP 演进的第一次尝试，使用二进制表示，用二进制协议在 IP 网络上模拟传统电话信令。

• SIP：在 H.323 的基础上演化而来，参考了 HTTP 协议，改用“文本格式”描述信令，更加互联网化，也更容易理解和扩展。

7.2.1 运营商网络中的 SIP —— 通话的中转逻辑

自 4G 起，VoLTE（Voice over LTE）就使用 SIP 建立语音通话；在 5G 新通话（NR）中，同样采用了 SIP 体系。这意味着，你现在用的手机，在拨打电话时，背后其实正在运行 SIP 协议，只是你看不见它。

在最基础的通信模型中，Alice 与 Bob 可以直接通过各自的 IP 地址建立 SIP 呼叫（例如直接发送 INVITE 消息），实现点对点的通话。

但在真实的电话网络中，手机之间并不能直接这样通信——它们需要一个“中间人”来完成信令转接和会话管理。这个“中间人”就是电信运营商，而运营商用于通话转接的设备被称为 交换机（Switch）。

7.2.2 企业场景下的 SIP —— 从分机到 PBX

在企业通信中，Bob 可能不再是个人，而是公司的某个分机。公司内部通常会部署一套 PBX（Private Branch eXchange，专用分支交换机），它相当于企业的小型电话网络，负责管理内部的所有分机。

• 公司内部的分机之间可以直接通话；

• 对外通话则通过 SIP 中继线（Trunk） 连接到运营商。

“中继线”这个概念其实源自传统电信，SIP 本身并没有物理“线”的概念，它更像是一条逻辑连接，用来汇聚多路通话。

SIP 天然支持多路并发通信，受限的只是设备的处理能力。例如，一台话机只能有一个麦克风，即使同时有多路通话请求，也只能有一路进行，其他通道会处于 Hold（保持） 状态。

7.2.3 AI 时代的 SIP —— 智能分机与机器人坐席

进入 AI 时代后，企业的分机逐渐被 AI Agent（智能体） 所取代。这些 AI 语音机器人通过 SIP 接入 PBX 系统，就能完成：

• 自动接听与问候；

• 实时语音识别（ASR）与语音合成（TTS）；

• 智能应答、转接与对话分析。

在这样的架构中，每一个“分机”都可能是一个 AI 智能体，而不是人类坐席。SIP 在这里继续承担“信令控制”的角色，连接 PBX 与语音 AI 系统。

7.2.4 SIP 与媒体传输的关系

需要注意的是，SIP 只负责“信令”部分，也就是通话的建立与释放。

真正传输语音或视频内容的，是通过 SDP（Session Description Protocol） 描述、由 RTP（Real-Time Protocol） 承载的媒体流。SIP 交换 SDP 信息后，双方即可通过 RTP 建立实时媒体通道。为了保证低延迟，RTP 一般基于 UDP 进行传输。

在其他领域，SIP 的思想也被广泛借鉴：

• RTSP（Real-Time Streaming Protocol）：常见于监控与流媒体播放，结构类似 SIP + SDP + RTP；

• GB28181：中国安防标准协议，在 SIP 基础上扩展了访问控制与云台操作等；

• VoLTE / 5G NR：移动网络中用于语音与视频通话；

• 企业 SIP Server：通过对接 SBC（边界网关控制器） 和 IMS（多媒体子系统），实现公网与企业内部 AI 通话互联。

7.3 SIP 与 WebRTC——信令与媒体的协作体系

在前文中我们了解到，SIP 负责“通话的建立与释放”，而媒体内容（语音、视频）的传输则依赖 RTP 协议。WebRTC（Web Real-Time Communication）正是 RTP 的一个更现代化、面向浏览器的实现。

7.3.1 WebRTC 的角色

WebRTC 是一个 实时媒体传输协议栈，主要用于在浏览器中实现音视频通信。它本身并不定义信令机制——也就是说，WebRTC 只负责“怎么传”，不负责“跟谁传”。信令（例如“我要呼叫谁”“对方是否接听”）由其他协议负责，这正是 SIP 擅长的部分。

在通信建立的过程中，WebRTC 与 SIP 都会使用 SDP（Session Description Protocol，会话描述协议） 来描述媒体参数，比如：

• 双方的 IP 地址与端口；

• 使用的音视频编码；

• 是否加密传输等。

当双方通过某种方式交换 SDP 后（例如通过 SIP 信令），WebRTC 就能建立点对点（Peer Connection）的媒体通道，完成音视频的实时传输。

7.3.2 SIP over WebSocket：两者的衔接

浏览器环境中无法直接使用 UDP 或 TCP 套接字，因此 SIP 信令通常通过 WebSocket 进行传输。这种方式被称为 SIP over WebSocket。

换句话说：

• SIP 的信令部分通过 WebSocket 通道进行传输；

• SDP 在 SIP 消息中携带；

• 媒体部分则由 WebRTC 在 UDP 之上以 RTP 的方式承载。

可以理解为：

SIP 决定“是否发车”，WebSocket 是“调度电话线”，

而 WebRTC 则是那辆真正跑在 UDP 轨道上的“高铁”，负责以加密、低延迟的方式传输语音和视频。

7.3.3 WebRTC 的安全与传输特性

出于安全考虑，WebRTC 要求所有通信必须加密：

• 信令通道使用 TLS 加密（例如 SIP over WebSocket）

• 媒体通道使用 DTLS 加密（Datagram TLS）

此外，WebRTC 还内置了完善的 回声消除、噪声抑制、拥塞控制 等机制，使其在复杂网络环境下也能保持良好的音视频质量。

这使得它不仅适用于浏览器场景，也被广泛编译为 SDK 使用，做成 Native 的 App。脱离了 Web 的 WebRTC 就只好叫 RTC 了。

7.4 SIP 与 AI 的互动

随着 ASR（语音识别）与 TTS（语音合成）技术的成熟，AI 已经可以在语音对话中实现与真人几乎无异的交互体验。

这让 “AI 电话机器人” 成为现实：它们能实时接听、识别语音、理解语义并做出自然回应。

7.4.1 基于 RTC 的 AI 对话流程

让我们再来回顾一下，在互联网场景下，AI 通常通过 WebRTC 或 RTC 技术与用户进行实时语音通信。

以一个典型的 Conversational AI 流程为例：

其中，红色线条为语音通道，黑色为文本通道。AI Agent（智能体）作为一切业务逻辑的总管，负责对话逻辑。ASR/TTS通常由专门的服务提供。

此时，通过 RTC 的典型对话逻辑如下：

1. RTC 终端（如网页、App）连接 RTC 服务端，建立双向语音传输；

2. RTC 服务端通知 AI Agent 有新的 RTC 终端接入；

3. AI Agent 指示 SIP 服务器播放欢迎音（如“你好”，可能是事先录好的或通过 TTS 生成的）并开始语音识别；

4. ASR识别到的内容（文本）返回给 AI Agent。

5. AI Agent 连接大模型，并且返回应答文本。

6. AI Agent通知 TTS 服务将文本转成语音，然后返回给 RTC 服务器，并播放给 RTC 终端。

7.4.2 基于 SIP 的 AI 对话流程

尽管 WebRTC 能让 AI 直接在 IP 网络上传输语音，但传统电话依旧是语音交互最普遍的入口。

在营销、客服等场景中，通过 SIP 电话系统 接入 AI 能极大提升效率与覆盖面。

这里的关键，就是 SIP 与 AI 的互通。

在一个典型的的电话场景中：

1. 电话呼入 SIP 服务器；

2. SIP 服务器通知 AI Agent 有新通话；

3. AI Agent 指示 SIP 服务器对电话进行应答，播放欢迎音（如“你好”）并开始语音识别；

4. ASR 识别到的内容（文本）通过（或不通过）SIP 服务器通知 AI Agent；

5. AI Agent 调用大模型，并生成回复；

6. AI Agent通知 SIP 服务器调用 TTS 将文本转成语音，并播放给来电方；

如此，便完成了一轮基于 SIP 的 AI 语音对话。

有的 SIP 服务器具有连接 ASR/TTS 的能力。传统的 ASR/TTS 服务有一个标准的协议——MRCP（Media Resource Control Protocol）。有趣的是，MRCP 协议也是通过 RTSP/SIP/RTP 来进行通信的。

不过，MRCP 协议比较古老，它其实并不适合互联网应用。如今，大多数云端 ASR/TTS 服务已改用 HTTP 或 WebSocket 协议，更适合云原生架构，并能轻松实现流式识别与实时合成。

7.4.3 基于 SIP-to-RTC 的 AI 对话流程

在上面我们讨论了两种与 AI 进行对接的方式。既然 WebRTC/RTC 在数据传输上更加优越，我们能否让 SIP 接入 WebRTC/RTC，再提供对话式 AI呢？

当然可以！

以声网为例，他们提供了 Linux SDK，可以在服务端支持大并发的 RTC 通信。我们只需把 SDK 嵌入到 SIP Server 中，作成一个 SIP-to-RTC 的网关就可以了。示意图如下，读者可以与上面的两个图对比理解。

上面的人与AI的通信过程由于涉及ASR、TTS、大模型，因而称为三段式对话智能体。由于环节比较多，由此需要小心地处理以最大程度的降低不必要的延迟，主要有以下几点需要注意：

1. ASR 使用流式识别，实时返回结果

2. ASR 通过 VAD、尾音检测等技术判断用户一句话否说完

3. 智能体通过一些智能手段，通过中间结果检测用户说话一句话是否说完

4. 智能体将用户说话内容送给大模型

5. 大模型流式返回响应结果文本，智能体通过标点符号等断句，一句一句的“喂”给TTS，TTS流式返回音频

6. 目前，也有一些TTS接受字符级的流式投喂，流式返回音频

整体而言，在有了 SIP-to-RTC 的网关之后， 无论来电者是网页端、移动端，还是传统电话线路，都能通过同一个 AI Agent 实现自然语音交互。这让 AI 能真正“听到”来自任何设备的声音，也能“回应”回去。

在实践中，越来越多的平台也在探索让传统通信直接接入智能体的方式。例如，OpenAI 已推出自己的 SIP Gateway，让开发者可以通过标准的 SIP 协议直接与其实时大模型进行语音交互，这进一步模糊了传统电话网络与 AI 系统的边界。

但如同任何技术一样，不会有“一统天下”的方案。不同的通信架构有其各自的适用场景——有的更适合大规模语音呼叫，有的更强调实时交互体验。可以预见，在相当长的一段时间里，这些 SIP 体系和 AI 架构都将并行共存。而 SIP 协议，也会继续作为传统通信与智能语音系统之间的重要桥梁，在“人—机—网”互联中发挥核心作用。