蓝牙HFP三方通话实战：AT+CHLD与AT+CHUP命令深度解析与状态机设计

1. 项目概述：深入蓝牙HFP的三方通话世界

如果你在开发蓝牙音频设备，尤其是车载蓝牙、蓝牙耳机或智能音箱，那么“三方通话”这个功能你一定不陌生，也一定被它背后的协议细节折腾过。今天，我们就来彻底拆解蓝牙免提协议（HFP）中与三方通话相关的几个核心AT命令：AT+CHLD和AT+CHUP。这不仅仅是协议文档的翻译，而是结合我多年在嵌入式蓝牙音频开发中踩过的坑、调过的bug，为你梳理出一份可直接用于实战的指南。无论是刚接触蓝牙协议栈的新手，还是正在为产品增加通话功能的老手，理解这些命令的细微之处，都能让你在调试通话保持、呼叫等待、多方会议这些复杂场景时，心里更有底。

简单来说，HFP协议定义了蓝牙设备（如耳机，作为音频网关AG）与手机（作为音频终端HF）之间如何进行通话控制。而三方通话，就是指在一条已经建立的语音通话链路上，再接入第三个参与者。这涉及到呼叫保持、呼叫等待、多方合并等一系列状态切换，AT+CHLD和AT+CHUP正是协调这些状态切换的“指挥官”。很多人看协议文档觉得命令就那几个，但实际开发中，手机厂商的实现差异、不同蓝牙芯片的响应时序，才是真正的挑战。接下来，我们就从设计思路开始，一步步把这些命令掰开揉碎讲清楚。

2. 核心命令设计思路与协议逻辑拆解

在深入具体命令之前，我们必须先理解HFP协议设计三方通话功能的底层逻辑。这个逻辑的核心是状态管理。手机（AG端）维护着当前所有通话的状态，而蓝牙设备（HF端）通过发送AT命令来请求改变这些状态。

2.1 通话状态模型与CHLD命令的定位

HFP协议将通话抽象为几种状态：活跃（Active）、保持（Held）、等待（Waiting）、拨号中（Dialing）、告警中（Alerting）等。一次三方通话场景，通常至少涉及两个通话：一个当前正在进行的通话（Call 1），和一个新来电或等待接通的通话（Call 2）。

AT+CHLD命令的全称是“Call Hold and Multiparty handling”，它的根本作用就是让HF端指示AG端如何重新安排这些通话之间的“资源”（主要是语音通道和用户界面焦点）。它不是一个创建新通话的命令，而是一个对现有通话进行“调度”的命令。例如，是保持当前通话去接听新来电，还是把两个通话合并成一个会议电话。

这里有一个关键点：AT+CHLD的执行结果高度依赖于AG端（手机）当前的通话状态和能力。协议定义了一系列操作码（如0，1，2，1x，2x等），但并非所有手机都支持全部操作。因此，一个健壮的蓝牙设备，必须在连接初期通过AT+CCWA、AT+CHLD=?等命令查询手机的支持能力，并据此调整自己的UI逻辑和行为。你不能假设所有手机都支持三方会议，否则功能会失效。

2.2 AT+CHUP的辅助角色与边界

那么AT+CHUP（Call Hang Up）呢？它看起来很简单，就是挂断电话。但在三方通话的上下文中，它的行为会变得微妙。当你处于一个多方会议中，发送AT+CHUP是挂断整个会议，还是仅挂断当前发言方？协议规定，这通常取决于AG的实现，但普遍行为是挂断所有活跃的呼叫。这就意味着，在会议中使用挂断需要格外小心。

更常见的场景是，AT+CHUP用于处理AT+CHLD操作过程中的“异常”或“取消”情况。比如，你发送AT+CHLD=2想将保持的通话与当前通话互换，但操作失败或用户取消了，你可能需要发送AT+CHUP来终止当前尝试，回到一个清晰的状态。理解AT+CHUP与AT+CHLD的边界，是编写稳定通话控制逻辑的基础。

3. AT+CHLD命令详解与实战应用

现在，我们进入最核心的部分，逐条解析AT+CHLD的命令参数及其对应的真实场景。我会结合代码片段和状态机图（用文字描述）来帮助你理解。

3.1 基础操作：释放、保持与独奏

AT+CHLD=0

• 动作：释放所有保持的通话（Held calls），并使所有等待的通话（Waiting calls）继续等待。
• 场景：这是最常用的操作之一。假设你正在通话A中，此时通话B打进来并被你保持（Held）。当你和通话A结束后，你需要恢复与通话B的交谈。此时，HF设备（如车载）发送AT+CHLD=0，AG（手机）就会释放（恢复）那个被保持的通话B，使其变为活跃通话。
• 实战注意：这里的“释放”特指从“保持”状态变为“活跃”。它不影响当前活跃的通话（如果有的话）。如果当前没有活跃通话，那么被释放的通话就会成为新的活跃通话。在实现UI时，“接听保持电话”的按钮背后，通常就是发送这条命令。

AT+CHLD=1

• 动作：释放所有活跃的通话，并接受一个等待的通话（如果存在）。所有其他保持的通话将继续保持。
• 场景：经典的“呼叫等待”处理。你正在与A通话，此时B打进来。你听到“嘟嘟”的等待提示音。此时，你按下设备的“接听新来电”键，设备应发送AT+CHLD=1。结果是：与A的通话被保持（Held），与B的通话变为活跃（Active）。
• 实战注意：这个命令隐含着“交换”的概念。它总是假设存在一个等待的通话。如果发送此命令时没有等待的通话，AG通常会返回ERROR。因此，设备UI必须在收到+CCWA指示（表示有呼叫等待）后，才使能对应按钮。

AT+CHLD=2

• 动作：保持所有活跃的通话，并接受一个等待的通话（如果存在）。
• 场景：与CHLD=1类似，但逻辑稍有不同。还是A活跃，B等待的场景。发送AT+CHLD=2后，A被保持，B被接听并变为活跃。这与CHLD=1的效果在单次操作上看起来一样。但关键在于后续：如果你再次发送AT+CHLD=2，它会再次交换，将B保持，恢复A。也就是说，CHLD=2可以在两个通话之间来回切换，而CHLD=1在接听B后，如果再按一次，行为可能是挂断B（取决于实现）或无效。因此，CHLD=2更适合需要频繁在两个通话间切换的场景。
• 实战心得：很多手机对CHLD=1和CHLD=2的支持程度不同。在设备开发中，更安全的做法是优先使用CHLD=2来实现呼叫等待的接听和切换功能，因为它的行为更可预测（切换）。务必通过AT+CHLD=?测试手机的支持情况。

3.2 进阶操作：多方会议与特定控制

AT+CHLD=3

• 动作：建立一个多方会议（Multiparty call），将当前所有保持的通话与当前活跃的通话合并到一个会议中。
• 场景：这是实现三方通话的核心命令。你与A通话，保持后接听了B。现在你希望A和B能互相听到，开一个电话会议。此时，发送AT+CHLD=3。手机（AG）会将A（保持）和B（活跃）合并到一个会议呼叫中。
• 关键细节：会议建立后，AG通常会通过+CIEV指示符（如+CIEV: 2,1）通知HF当前处于会议状态。会议中，通常只有一个参与者是“活跃发言者”，其他人是听众。AT+CHLD=1x或AT+CHLD=2x（见下文）可以用来在会议参与者之间切换。
• 避坑指南：不是所有手机都支持CHLD=3。一些低端机或定制系统可能不支持三方会议。你的产品如果将此作为卖点，必须在兼容性测试中重点验证。当不支持时，AT+CHLD=?的返回结果里不会包含3。

AT+CHLD=4

• 动作：连接（Combine）两个通话，但将除指定索引外的所有其他通话挂断。
• 场景：这个命令较少见，用于更精细的控制。例如，你有通话1、2、3，其中1是活跃的，2和3是保持的。发送AT+CHLD=4可能的行为是，将活跃通话与其中一个保持通话连接，并挂断另一个保持的通话。由于实现非常不统一，在实际产品开发中，我强烈建议避免依赖CHLD=4，除非你只为特定品牌和型号的手机做定制开发。

AT+CHLD=1x与AT+CHLD=2x(x为通话索引)

• 动作：
  • AT+CHLD=1x: 仅与指定索引（x）的通话进行私人交谈，将其他所有通话保持。
  • AT+CHLD=2x: 从会议中移除指定索引（x）的通话（即挂断该方）。
• 场景：这两个命令用于会议中的精细管理。假设一个三方会议包含A（索引1）、B（索引2）、你（HF）。你想私下和A说句话，不让B听到，可以发送AT+CHLD=11。此时，B被保持，你只和A连接。说完后，再发送AT+CHLD=3可以恢复会议。如果你想踢掉B，可以发送AT+CHLD=22。
• 实战难点：通话索引（x）的分配和管理是难点。AG通过+CLCC（列出当前通话）命令返回每个通话的索引和状态。HF端必须解析和维护这个列表，才能正确使用带索引的CHLD命令。索引是动态的，挂断一个通话后，其他通话的索引可能会变。

3.3 能力查询与兼容性处理

在所有操作之前，AT+CHLD=?（测试命令）是必须执行的。手机会返回它支持的CHLD参数列表，例如：+CHLD: (0,1,2,3)。这是你设备逻辑的“地图”。

兼容性策略表格：

重要提示：永远不要假设支持3就一定支持1x/2x，反之亦然。必须通过AT+CHLD=?的返回值逐一确认。在代码中，应该将这些支持能力解析并存储为位标志或枚举，后续所有UI显示和命令发送逻辑都基于此标志进行判断。

4. AT+CHUP命令在复杂场景下的行为解析

AT+CHUP看似简单，但在多方通话场景下，其行为需要仔细界定。

4.1 标准挂断行为

在单路通话中，AT+CHUP就是挂断当前活跃通话，行为明确。

4.2 在通话保持与等待场景下的行为

当存在一个活跃通话和一个保持通话时：

• 发送AT+CHUP：通常会挂断当前活跃的通话。之后，AG可能会自动将那个保持的通话变为活跃（这取决于手机实现），也可能只是结束所有通话。更可靠的做法是，如果你想挂断活跃通话并切换到保持的通话，应该按顺序发送：AT+CHUP（挂断活跃） -> 等待+CIEV状态更新 -> 再发送AT+CHLD=0（释放保持的通话）。不要依赖手机的自动行为。

4.3 在多方会议中的行为

这是最容易出问题的地方。当处于一个三方会议中时：

• 多数实现：发送AT+CHUP会挂断整个会议，即结束与所有参与方的连接。
• 少数实现：可能会挂断当前“焦点”通话，但会议仍然存在（其他方仍在通话）。这种行为不符合主流规范，但确实存在。

因此，给开发者的明确建议是：在会议状态下，避免直接使用AT+CHUP来挂断某一方。正确的做法是：

1. 使用AT+CLCC获取当前会议中所有通话的索引。
2. 使用AT+CHLD=2x（如果支持）来移除特定参与者。
3. 如果只想自己退出会议但让其他两方继续通话（这需要AG支持“退出会议”功能，但HFP标准未明确定义），这可能无法通过标准AT命令实现，需要看手机厂商的扩展。

4.4 作为错误恢复机制

在发送AT+CHLD命令后，如果AG返回ERROR，或者HF端超时未收到响应，通话状态可能进入一个不确定的情况。此时，一个安全的恢复策略是发送AT+CHUP来终止当前所有通话尝试，让系统回到空闲（Idle）状态。这相当于一个“总复位”操作，虽然会挂断电话，但保证了状态机的干净，避免后续操作出现更诡异的问题。

5. 实战开发流程与状态机设计

理解了命令，我们来看如何把它们用到实际产品开发中。核心是设计一个健壮的通话控制状态机。

5.1 初始化与能力协商

设备上电并与手机配对连接后，在建立服务级连接（SLC）时，必须进行能力查询。

# 示例初始化查询序列 AT+BRSF=? # 查询支持的AG特性 AT+CIND=? # 查询指示器状态 AT+CMER=? # 启用指示器更新 # 关键的三方通话能力查询 AT+CCWA=? # 查询是否支持呼叫等待通知 AT+CHLD=? # **核心**：查询支持的CHLD操作列表

解析AT+CHLD=?的响应，并保存在设备的全局变量中，例如：

// 伪代码示例 typedef struct { bool support_chld_0; bool support_chld_1; bool support_chld_2; bool support_chld_3; bool support_chld_1x; bool support_chld_2x; } hfp_ag_capabilities_t; hfp_ag_caps_t ag_caps; // 解析AT+CHLD=?的响应字符串，例如“(0,1,2,3)” parse_chld_response(“(0,1,2,3)”, &ag_caps); // 结果：ag_caps.support_chld_3 = true;

5.2 状态机设计与命令触发

你的设备内部需要维护一个简化版的通话状态模型，这个模型基于AG通过+CIEV和+CLCC主动上报的信息来更新。

核心状态：IDLE（空闲）、SINGLE_ACTIVE（单路活跃）、ACTIVE_AND_HELD（活跃+保持）、MULTIPARTY（会议中）。

事件：用户按键（接听、挂断、保持、交换、合并）、AG通知（+CCWA来电等待、+CLCC通话列表更新）。

当用户按下“接听等待来电”按钮时，状态机的处理逻辑应该是：

1. 检查当前状态是否为SINGLE_ACTIVE。
2. 检查是否收到过+CCWA指示（表示有等待来电）。
3. 检查ag_caps.support_chld_1或ag_caps.support_chld_2是否为真。
4. 根据产品设计，选择发送AT+CHLD=1或AT+CHLD=2。
5. 发送命令后，等待AG的+CIEV状态更新（如callheld状态从0变为1），再更新内部状态为ACTIVE_AND_HELD。

5.3 关键代码实现示例

以下是一个基于状态机处理“合并通话”（开启三方会议）的简化代码逻辑：

// 伪代码：处理用户点击“合并通话”按钮 void on_merge_call_button_pressed(void) { // 1. 检查当前状态：必须是一个活跃+一个保持 if (current_state != STATE_ACTIVE_AND_HELD) { show_message(“无法合并：需要两个通话”); return; } // 2. 检查手机能力：是否支持CHLD=3 if (!ag_caps.support_chld_3) { show_message(“您的手机不支持三方通话功能”); return; } // 3. 发送合并命令 send_at_command(“AT+CHLD=3\r”); // 4. 设置超时计时器，等待AG响应 start_response_timer(3000); // 3秒超时 // 5. 状态机转移到“等待合并确认”状态 current_state = STATE_WAITING_FOR_MERGE_CONFIRM; } // 在AT响应解析线程中 void process_ag_response(char *response) { if (strstr(response, “OK”)) { if (current_state == STATE_WAITING_FOR_MERGE_CONFIRM) { // 命令被接受，等待+CIEV状态更新来确认会议已建立 stop_response_timer(); } } else if (strstr(response, “ERROR”)) { if (current_state == STATE_WAITING_FOR_MERGE_CONFIRM) { // 合并失败，退回原状态，并提示用户 current_state = STATE_ACTIVE_AND_HELD; show_message(“合并通话失败”); stop_response_timer(); } } else if (strstr(response, “+CIEV: 2,1”)) { // 假设2是callheld状态，1表示会议 if (current_state == STATE_WAITING_FOR_MERGE_CONFIRM) { // 确认会议已建立 current_state = STATE_MULTIPARTY; show_message(“会议通话已开始”); } } }

6. 常见问题排查与调试技巧实录

在实际开发和调试中，你会遇到各种各样的问题。下面是我总结的一些典型问题及其排查思路。

6.1 命令无响应或返回ERROR

• 问题：发送AT+CHLD=3后，手机返回ERROR或根本无响应。
• 排查步骤：
  1. 确认能力：首先检查连接初始化时AT+CHLD=?的返回结果，确认手机是否真的支持3。很多问题源于能力查询遗漏或解析错误。
  2. 确认状态：发送合并命令时，必须满足“一个活跃通话 + 一个保持通话”的状态。通过AT+CLCC?主动查询当前通话列表，或检查最近收到的+CIEV/+CLCC通知，来确认状态是否满足条件。
  3. 检查时序：AT命令的发送需要在上一条命令收到响应（OK/ERROR）之后。确保没有命令堆积或竞争。在嵌入式系统中，确保你的AT串口发送缓冲区是空的，并且解析线程是健康的。
  4. 日志记录：在调试阶段，将设备与手机之间所有的HFP AT命令和响应（包括以+开头的主动通知）完整地记录下来。这是定位问题最直接的证据。

6.2 通话状态显示不同步

• 问题：设备屏幕上显示的通话状态（如谁在保持，谁在活跃）与手机屏幕或实际通话情况不一致。
• 根本原因：设备内部状态机没有正确同步AG通过+CIEV和+CLCC上报的状态变化。
• 解决方案：
  • 确保AT+CMER已正确配置：这个命令用于启用AG的事件报告。通常需要设置为AT+CMER=3,0,0,1，以确保所有指示器变化和通话列表变化都能主动上报。
  • 正确处理所有主动通知：你的AT解析器必须能识别并处理+CIEV、+CLCC、+CCWA、+BVRA等所有可能影响通话状态的主动通知。不能只处理自己发送命令的响应。
  • 状态机复位：在检测到AT+CIND查询的call和callsetup指示器都为0时，应将内部所有通话相关状态复位到IDLE。这是一个重要的安全网。

6.3 特定手机型号兼容性问题

• 问题：在A品牌手机上功能正常，在B品牌手机上“合并通话”无效或行为怪异。
• 处理策略：
  • 建立手机型号数据库：记录不同手机品牌/型号/系统版本对AT+CHLD命令的支持情况和行为差异。这是长期积累的宝贵财富。
  • 降级处理：如果检测到某款手机不支持三方会议（CHLD=3），则在UI上彻底隐藏或禁用该功能入口，避免用户点击后产生困惑。
  • 使用最广泛兼容的命令：对于呼叫等待接听，如果AT+CHLD=?返回支持(1,2)，优先使用CHLD=2，因为它的“切换”行为比CHLD=1更通用。
  • 主动测试：购买主流型号的手机进行真机测试，是保证兼容性的不二法门。模拟器或单一手机无法覆盖所有情况。

6.4 音频路径与SCO链路管理

三方通话不仅涉及信令（AT命令），还涉及音频。当进行通话保持、交换、合并时，蓝牙SCO（同步面向连接）链路的管理也至关重要。

• 问题：通话保持后，听不到保持方的声音是正常的，但有时恢复通话后音频没有切回来。
• 检查点：确保设备在收到+CIEV: callheld状态变化时，正确地与AG重新建立或切换SCO链路。这通常由芯片的底层协议栈自动处理，但你需要确认上层应用发出的AT+BIA（指示器激活）或AT+BCC（发起编解码器连接）等命令是否正确。有些芯片需要你在特定状态变化后，手动触发一次SCO连接请求。

最后，分享一个调试“必杀技”：使用一个支持HFP协议日志抓取的蓝牙嗅探器（如Frontline、Ellisys的设备），或者利用Android手机的“蓝牙HCI日志”功能（开发者选项里开启）。你可以清晰地看到设备与手机之间交互的每一个比特，包括所有的AT命令、响应以及底层链路控制消息。当逻辑问题百思不得其解时，抓一次日志，真相往往一目了然。虽然设备昂贵，但对于复杂问题的定位，它是无可替代的。