【LE Audio】CAP精讲[9]：全流程操盘手，解锁CAP核心交互工序

在前两篇内容里【LE Audio】CAP精讲[7]: 场景为王！Context Type音频协同场景识别全攻略，【LE Audio】CAP精讲[8]：CCID绑定术，打通音频流与控制的任督二脉，我们已经拆解了Context Type这个音频场景的身份证，也搞懂了CCID这个连接音频流与控制服务的唯一密钥。但在实际的LE Audio生态中，光有身份标识和关联密钥还不够------手机如何向耳机发起一次音乐播放？来电时音频流如何无缝切换？多设备协同听音乐时，策略如何同步？网络中断后设备又该如何优雅恢复？

一、前置铺垫：CAP过程的核心框架与底层依赖

[1.1 CAP过程的核心分类](#1.1 CAP过程的核心分类)

[1.2 核心参与角色与通俗比喻](#1.2 核心参与角色与通俗比喻)

[1.3 核心消息载体：基于BAP的流程指令](#1.3 核心消息载体：基于BAP的流程指令)

[1.4 底层依赖：CAP流程的三大支撑服务](#1.4 底层依赖：CAP流程的三大支撑服务)

二、单播音频核心流程：点对点交互的黄金标准

[2.1 单播音频建立过程：音频交互的开工奠基](#2.1 单播音频建立过程：音频交互的开工奠基)

[2.2 单播音频更新过程：音频交互的施工调整](#2.2 单播音频更新过程：音频交互的施工调整)

[2.3 单播音频终止过程：音频交互的项目竣工](#2.3 单播音频终止过程：音频交互的项目竣工)

三、广播音频核心流程：一对多交互的灵活范式

[3.1 广播音频建立过程：电台的开播准备](#3.1 广播音频建立过程：电台的开播准备)

[3.2 监听者加入/退出过程：听众的选台/换台](#3.2 监听者加入/退出过程：听众的选台/换台)

[3.3 广播音频更新与终止过程：电台的节目调整/停播](#3.3 广播音频更新与终止过程：电台的节目调整/停播)

四、协同设备组CAP过程：多设备联动的统筹方案

[4.1 组建立过程：组建音频团队](#4.1 组建立过程：组建音频团队)

[4.2 成员管理过程：团队的人员调整](#4.2 成员管理过程：团队的人员调整)

[4.3 策略同步过程：团队的统一行动](#4.3 策略同步过程：团队的统一行动)

五、异常处理与容错机制：协议健壮性的核心保障

[5.1 错误码机制：异常的标准化标识](#5.1 错误码机制：异常的标准化标识)

[5.2 超时机制：避免无限等待](#5.2 超时机制：避免无限等待)

[5.3 回退机制：异常场景的兜底方案](#5.3 回退机制：异常场景的兜底方案)

[5.4 缓存清理机制：避免旧数据干扰](#5.4 缓存清理机制：避免旧数据干扰)

六、CAP过程与上层服务的联动：从协议到业务的落地

七、开发者实现关键注意事项：从理论到代码的落地

八、测试

这些问题的答案，都藏在CAP的核心部分------CAP procedures里。如果把Context Type和CCID比作搭建音频系统的零件，那么CAP procedures就是一套标准化的施工流程，它定义了零件如何组装、如何运转、如何维护、如何故障修复，确保不同品牌、不同类型的LE Audio设备，都能按照同一套逻辑完成音频交互。

本文全面解锁这套核心交互工序，从单播到广播，从建立到终止，从正常流程到异常容错，带大家掌握LE Audio音频交互的全链路逻辑。本文内容基于CAP规范的核心流程定义，结合实际开发场景做体系化梳理，确保内容的准确性与实用性。

一、前置铺垫：CAP过程的核心框架与底层依赖

在深入具体流程之前，我们需要先建立对CAP procedures的整体认知，明确其分类方式、核心参与角色、消息载体以及底层依赖的关键服务。这就像在学习施工流程前，先要认识施工团队、施工工具和施工材料，只有这样，后续的细节讲解才能更好理解。

1.1 CAP过程的核心分类

CAP procedures根据不同的维度，有三种核心分类方式，这三种分类相互交织，构成了完整的流程体系：

按传输类型划分：单播音频过程（Unicast Audio Procedures）、广播音频过程（Broadcast Audio Procedures）。这是最核心的分类，覆盖了LE Audio的两种核心传输模式。

按生命周期划分：建立过程（Establish）、更新过程（Update）、终止过程（Terminate）。这三类流程贯穿了音频流从诞生到消亡的全生命周期。

按功能场景划分：协同设备组过程（Coordinated Set Procedures）、异常处理过程（Error Handling Procedures）。这两类流程是为了满足多设备协同和协议健壮性的需求而设计。

1.2 核心参与角色与通俗比喻

CAP过程的执行，依赖于不同角色的设备协同工作，规范对每个角色的职责做了严格定义，我们用一个音频项目组的比喻来帮助理解：

|------------------|----------------------|---------------|
| 角色名称 | 核心职责 | 通俗比喻 |
| Initiator（发起设备） | 发起单播音频流的建立、更新、终止请求 | 甲方，提出音频服务需求 |
| Acceptor（接收设备） | 响应Initiator的请求，处理音频流 | 乙方，承接并执行音频服务 |
| Broadcaster（广播源） | 发起广播音频流，发送音频数据与元数据 | 电台，持续播发音频内容 |
| Monitor（监听者） | 扫描、加入、退出广播音频流，接收音频 | 听众，选择并收听电台节目 |
| Coordinator（协同器） | 管理协同设备组，同步组内音频策略 | 项目经理，统筹团队协同工作 |

需要注意的是，设备的角色不是固定的，一台手机既可以是Initiator（向耳机发音乐），也可以是Broadcaster（向全屋音箱广播节目），还可以是Coordinator（管理多耳机协同）。

1.3 核心消息载体：基于BAP的流程指令

CAP procedures并非独立设计消息，而是基于底层BAP（基础音频协议）的核心消息结构，扩展了CAP特有的参数（如Context Type、CCID）。这些消息是CAP流程执行的指令载体，所有的交互都通过这些消息完成。核心消息分为两大类，对应单播和广播两种传输方式：

1. 单播音频核心消息

|----------------------------------|------------------|---------------------------------------|
| 消息名称 | 核心用途 | 关键CAP扩展参数 |
| Unicast Audio Establish | 发起单播音频流建立请求 | CCID、Streaming Audio Contexts |
| Unicast Audio Establish Response | 响应建立请求，返回成功/失败结果 | Result Code、Available Audio Contexts |
| Unicast Audio Update | 发起单播音频流参数更新 | CCID、Updated Streaming Audio Contexts |
| Unicast Audio Update Response | 响应更新请求 | Result Code |
| Unicast Audio Terminate | 发起单播音频流终止 | CCID、Terminate Reason |

2. 广播音频核心消息

|---------------------------|----------------|--------------------------------------------|
| 消息名称 | 核心用途 | 关键CAP扩展参数 |
| Broadcast Audio Establish | 配置广播音频流，生成广播ID | CCID、Streaming Audio Contexts、Broadcast ID |
| Broadcast Audio Update | 更新广播音频流参数 | CCID、Updated Streaming Audio Contexts |
| Broadcast Audio Terminate | 终止广播音频流 | Broadcast ID、Terminate Reason |
| Monitor Audio Join | 监听者请求加入广播 | Broadcast ID、CCID |
| Monitor Audio Leave | 监听者退出广播 | Broadcast ID |

规范中有明确的核心定义：

CAP procedures extend the BAP procedures by adding mandatory and optional parameters related to audio context and content control。

这句话的核心含义是，CAP流程是对BAP流程的扩展，而非重构，通过新增上下文和内容控制相关的参数，实现了场景化、精准化的音频控制。

1.4 底层依赖：CAP流程的三大支撑服务

CAP procedures的执行，离不开三个底层服务的支撑，这三个服务就像施工所需的基础材料，没有它们，CAP流程就无法落地：

PACS（已发布音频能力服务）：提供设备的音频编码能力、场景偏好（Preferred_Audio_Contexts），是音频流建立前的能力协商基础。

ASCS（音频流控制服务）：负责音频流的传输参数配置（如码率、通道数），是CAP流程与实际音频传输的桥梁。

内容控制服务：包括MCS/GMCS（媒体控制服务）、TBS/GTBS（电话承载服务），是CCID关联的核心对象，负责音频的播放、暂停、通话控制等业务逻辑。

接下来，我们将按照**"单播→广播→协同→异常"**的顺序，逐一拆解CAP的核心流程，每个流程都会详细讲解执行步骤、消息交互、参数校验、附录展开以及实际应用场景。

二、单播音频核心流程：点对点交互的黄金标准

单播是LE Audio最常用的传输模式，也是CAP procedures中定义最细致、最复杂的部分。从用户的角度来看，单播就是手机连耳机听音乐、平板连音箱看视频；从技术的角度来看，单播是Initiator与Acceptor之间的点对点音频交互，要求精准、可靠、低延迟。

单播音频的全生命周期，分为建立、更新、终止三个核心阶段，每个阶段都有严格的执行顺序和参数校验规则，同时包含多种异常分支处理。

2.1 单播音频建立过程：音频交互的开工奠基

单播音频建立过程，是整个单播流程的起点，也是最关键的环节。它的核心目标是：Initiator与Acceptor完成能力协商、CCID绑定、Context Type确认，最终建立起可传输、可控制的音频流。

规范将这个过程定义为a mandatory procedure for establishing a unicast audio stream with associated context and content control information，强调了其在单播交互中的必要性。

整个建立过程分为前置协商、核心握手、后置确认三个阶段，共8个核心步骤。

（1）前置协商阶段：确认施工资质

在发起正式的建立请求前，Initiator必须完成与Acceptor的能力协商，确保双方能力匹配，这个阶段就像甲方在开工前，确认乙方是否有承接项目的资质。

步骤1：PACS能力交换

Initiator通过PACS服务，读取Acceptor的核心能力，包括：

支持的音频编解码器（如LC3）及参数（码率、采样率）；

Supported Audio Contexts（设备固有支持的场景）；

Preferred_Audio_Contexts（不同场景的编码偏好，如通话偏好低延迟LC3，音乐偏好高音质LC3）。

这里需要重点展开PAC LTV结构，Preferred_Audio_Contexts是PAC中的一个核心LTV字段，其结构如下：

|-----------|--------|------------------------------------|
| LTV字段 | 长度 | 取值说明 |
| Type | 1字节 | 0x0008（固定标识） |
| Length | 可变 | 后续Context Type的字节数 |
| Value | 可变 | 包含一个或多个Context Type的位域，以及对应的编码配置索引 |

例如，Acceptor的Preferred_Audio_Contexts中，Conversational场景对应编码索引1（低延迟LC3），Media场景对应编码索引2（高音质LC3），Initiator会根据这个偏好，选择最优的编码配置。

步骤2：CCID分配与关联

Initiator的应用层发起音频流建立请求（如用户点击音乐播放按钮），CAP层根据音频流的类型，完成CCID的分配与关联：

若为通话音频（TBS服务），分配SIG保留CCID（0x0001）；

若为媒体音频（MCS服务），从动态区间（0x0100~0xFFFF）分配未被使用的CCID；

将CCID与内容控制服务（如MCS）、Streaming Audio Contexts（如Media）进行绑定，形成"流-服务-场景"三元组。

步骤3：建立请求参数封装

Initiator将以下核心参数，封装进Unicast Audio Establish消息：

音频传输参数（基于ASCS的流ID、编码配置、通道数）；

CAP扩展参数（CCID、Streaming Audio Contexts）；

协商参数（请求的Context Type优先级）。

（2）核心握手阶段：完成合同签订

这是建立过程的核心，Initiator与Acceptor通过消息交互，完成音频流建立的合同签订，确认双方的权利与义务。

步骤4：发送建立请求

Initiator通过蓝牙LE连接，将Unicast Audio Establish消息发送给Acceptor。规范要求，该消息必须在ASCS流建立请求之前发送，确保CAP层参数先于传输层参数确认。

步骤5：Acceptor参数校验

Acceptor收到请求后，会按照严格的顺序进行参数校验，这是保证流程正确性的关键，校验项包括：

CCID唯一性校验：检查该CCID是否已在当前连接中被使用，若已使用，返回错误码0x02（CCID Duplicate）；

Context Type支持性校验：检查请求的Streaming Audio Contexts是否在Acceptor的Supported Audio Contexts中，若不支持，判断是否可替换为Unspecified场景；

Context Type可用性校验：检查请求的Streaming Audio Contexts是否在Acceptor的Available Audio Contexts中，若不可用，返回错误码0x03（Context Unavailable）；

资源充足性校验：检查设备是否有足够的音频资源（如解码单元、声道），若资源不足，返回错误码0x01（Resource Insufficient）。

这里需要展开CAP错误码列表，单播建立过程中常见的错误码及含义如下：

|---------|-----------------------|--------------------|
| 错误码 | 含义 | 处理策略 |
| 0x00 | Success | 建立成功，继续后续流程 |
| 0x01 | Resource Insufficient | 资源不足，终止建立 |
| 0x02 | CCID Duplicate | CCID重复，重新分配CCID后重试 |
| 0x03 | Context Unavailable | 场景不可用，等待场景释放后重试 |
| 0x04 | CCID Invalid | CCID取值超出规范范围，终止建立 |

步骤6：发送建立响应

Acceptor完成校验后，向Initiator发送Unicast Audio Establish Response消息：

若校验通过，Result Code设为0x00，携带Available Audio Contexts的当前状态；
若校验失败，Result Code设为对应错误码，携带失败原因说明。

（3）后置确认阶段：启动项目施工

建立请求响应成功后，双方进入实际的音频传输准备阶段，完成施工启动。

步骤7：控制服务绑定

Initiator：将本地的内容控制服务实例（如MCS）与该音频流的CCID绑定，监听用户的控制指令（如暂停、切歌）；
Acceptor：将本地的内容控制服务客户端与该音频流的CCID绑定，当收到用户控制指令时，通过CCID映射到对应的音频流。

步骤8：音频流启动

Initiator通过ASCS服务，发送流启动请求，Acceptor响应后，音频流开始传输，用户听到声音。此时，单播音频建立过程完成。

单播音频建立过程序列图：

实际案例：TWS耳机连接手机听音乐

我们用一个实际案例，串联起整个建立过程：

用户打开手机蓝牙，连接TWS耳机，双方完成PACS能力交换，耳机告知手机：支持Media和Conversational场景，Media场景偏好高音质LC3编码；
用户打开音乐APP，点击播放按钮，手机（Initiator）CAP层分配CCID 0x0100，关联MCS服务和Media场景；
手机封装Unicast Audio Establish消息，发送给耳机（Acceptor）；
耳机校验：CCID 0x0100未被使用，Media场景支持且可用，资源充足；
耳机发送建立响应（成功）给手机；
手机将音乐APP的MCS服务与CCID 0x0100绑定，耳机将本地MCS客户端与CCID 0x0100绑定；
手机通过ASCS启动音频流，耳机解码并播放音乐，建立过程完成。

2.2 单播音频更新过程：音频交互的施工调整

在音频流的传输过程中，核心参数可能会发生变化，比如：用户切换了音乐APP（控制服务变化）、音乐中混入了导航指令（Context Type变化）、用户调整了音频编码（传输参数变化）。此时，就需要通过单播音频更新过程，完成参数的同步调整。

规范对更新过程的定义是

a procedure for updating the context and/or content control information of an established unicast audio stream

明确了其核心作用是更新已建立音频流的上下文和内容控制信息。

（1）更新过程的触发条件

CAP规范明确规定了三类触发更新过程的核心场景，这也是实际开发中最常见的更新场景：

Context Type变化：如音频流从Media变为Media+Instructional，或从Ringtone变为Conversational；

CCID关联信息变化：如用户在不同音乐APP间切换，导致内容控制服务从MCS1变为MCS2；

场景可用性变化：如Acceptor的Available Audio Contexts发生变化，需要同步给Initiator。

（2）更新过程的核心步骤

更新过程的流程比建立过程简单，分为请求发起、参数校验、响应反馈、策略更新四个核心步骤，同样结合序列图讲解。

步骤1：发起更新请求

Initiator检测到参数变化后，封装Unicast Audio Update消息，核心参数包括：

目标CCID（标识需要更新的音频流）；
更新后的参数（如新的Streaming Audio Contexts、新的内容控制服务关联信息）。

步骤2：Acceptor参数校验

Acceptor收到更新请求后，进行针对性校验，重点校验：

CCID的有效性（是否存在已建立的音频流对应该CCID）；
新参数的兼容性（如新的Context Type是否支持）。

步骤3：发送更新响应

Acceptor完成校验后，向Initiator发送Unicast Audio Update Response消息，返回成功或失败的结果。

步骤4：双方策略更新

若更新成功，双方同步更新本地的CCID绑定关系、Context Type处理策略；
若更新失败，双方保持原有的参数和策略，Initiator可根据失败原因，选择重试或终止音频流。

单播音频更新过程序列图：

关键注意事项

更新的原子性：规范要求，更新过程的参数修改必须是原子性的，即要么所有参数都更新成功，要么都不更新，避免出现部分参数更新的混乱状态；

不中断音频传输：更新过程应在不中断音频传输的前提下完成，确保用户体验的连续性，比如导航指令混入音乐时，不能出现音乐卡顿。

2.3 单播音频终止过程：音频交互的项目竣工

当用户完成音频体验（如关闭音乐APP、断开蓝牙连接），或出现异常场景（如来电、资源不足）时，需要通过单播音频终止过程，释放音频流占用的资源，解除CCID绑定关系。

规范将终止过程定义为a mandatory procedure for terminating an established unicast audio stream and releasing associated resources，强调了其在资源管理中的必要性。

（1）终止过程的触发场景

终止过程的触发场景分为主动终止 和被动终止两类，覆盖了所有可能的音频流结束场景：

|----------|---------------------|-----------|
| 终止类型 | 具体场景 | 发起方 |
| 主动终止 | 用户关闭音频APP、手动断开音频流 | Initiator |
| 主动终止 | 耳机低电量关机、用户手动暂停并关闭音频 | Acceptor |
| 被动终止 | 来电触发高优先级音频流，需要终止当前流 | Initiator |
| 被动终止 | 网络连接中断、解码单元故障 | 双方均可 |

（2）终止过程的核心步骤

终止过程的流程最为简洁，分为请求发起、资源释放、响应反馈 三个核心步骤，对于异常场景（如网络中断），则采用无消息终止的方式。

正常终止流程（有消息交互）

发起终止请求：发起方封装Unicast Audio Terminate消息，核心参数包括CCID和终止原因（如User Initiated、Resource Released）；
接收方资源释放：接收方收到消息后，立即释放该音频流占用的资源（解码单元、CCID绑定、声道资源）；
发送终止响应：接收方向发起方发送终止响应，确认资源已释放；
发起方资源释放：发起方收到响应后，释放本地资源，终止过程完成。

异常终止流程（无消息交互）

当出现网络连接中断、设备断电等异常场景时，双方无法进行消息交互，规范要求：

若Initiator检测到连接中断，立即释放本地资源，标记该CCID为已释放；
若Acceptor检测到连接中断，立即终止音频流，释放资源，清除CCID绑定缓存；
动态分配的CCID，在释放后至少等待10秒才能复用（这一规则在之前的CCID章节中已讲解，此处再次强调，确保流程的完整性）。

单播音频终止过程序列图（正常终止）:

三、广播音频核心流程：一对多交互的灵活范式

广播是LE Audio的革命性功能，打破了传统蓝牙一对一的连接限制，实现了一个广播源，多个监听者 的音频传输模式。从用户的角度来看，广播就是手机向全屋音箱广播音乐、电视向家人的耳机广播节目；从技术的角度来看，广播是Broadcaster向多个Monitor发送音频数据的一对多交互，要求灵活、高效、支持隐私保护。

广播音频的全生命周期，同样分为建立、更新、终止三个核心阶段，同时增加了监听者加入/退出这一特有的流程。与单播不同，广播流程不依赖点对点的蓝牙连接，而是基于广播包的方式传输，因此在参数传递、校验逻辑上有明显差异。

3.1 广播音频建立过程：电台的开播准备

广播音频建立过程，是Broadcaster完成广播流配置、生成广播ID、启动广播的过程，就像电台在开播前，完成节目配置、频率设定、信号发射的准备工作。

规范对广播建立过程的定义是

a procedure for configuring a broadcast audio stream with associated context and content control information and starting the broadcast

明确了其核心是配置并启动广播流。

整个建立过程分为参数配置、广播ID生成、元数据封装、广播启动四个核心步骤，我们结合公共广播和私有广播两种场景，逐一拆解。

（1）核心步骤详解

步骤1：参数配置

Broadcaster的应用层发起广播请求（如用户点击"全屋广播"按钮），CAP层完成核心参数配置：

CCID分配：公共广播分配SIG保留CCID（如0x0003），私有广播分配动态CCID；

Context Type设置：根据广播内容，设置Streaming Audio Contexts（如Media、Ringtone）；

传输参数配置：通过ASCS服务，配置广播音频的编码、码率、通道数等参数。

步骤2：广播ID生成

Broadcaster通过BASS（广播音频扫描服务），生成一个3字节的唯一Broadcast ID，这是广播流的频率标识，Monitor通过这个ID识别并加入特定的广播流。

规范中对Broadcast ID的生成规则做了明确说明：Broadcast ID shall be a 3-octet value generated by the Broadcaster, unique within the current broadcast session，强调了其在广播会话中的唯一性。

步骤3：元数据封装

Broadcaster将CAP核心参数（CCID、Streaming Audio Contexts），封装进广播音频的元数据中。这里需要展开广播元数据LTV结构，核心字段如下：

|--------------------------|---------|--------|-------------------|
| LTV字段 | 类型值 | 长度 | 核心内容 |
| Streaming Audio Contexts | 0x0001 | 可变 | Context Type的位域 |
| CCID | 0x0002 | 2字节 | 16位无符号整数，广播流的CCID |
| Broadcast ID | 0x0003 | 3字节 | 广播流的唯一标识 |

需要注意的是，私有广播的元数据会进行加密处理，只有配对的Monitor才能解析；公共广播的元数据为明文，所有Monitor都能解析。

步骤4：广播启动

Broadcaster通过蓝牙LE扩展广播，发送包含广播元数据和音频数据的广播包，广播音频建立过程完成，进入持续广播状态。

（2）公共广播vs私有广播：建立过程的核心差异

公共广播和私有广播是广播的两种核心模式，其建立过程的差异主要体现在CCID分配、元数据处理和授权方式上：

|---------|-----------------|-----------------------|
| 对比项 | 公共广播 | 私有广播 |
| CCID分配 | SIG保留值（如0x0003） | 动态分配值（0x0100~0xFFFF） |
| 元数据处理 | 明文传输，所有设备可解析 | 加密传输，仅配对设备可解析 |
| 授权方式 | 无需配对，开放加入 | 需提前配对，获取解密密钥 |
| 应用场景 | 商场、机场公共广播 | 家庭聚会、私人音乐分享 |

广播音频建立过程序列图（私有广播）

3.2 监听者加入/退出过程：听众的选台/换台

监听者加入/退出过程，是广播特有的流程，对应听众选择电台收听和关闭电台的操作。这个过程不依赖Broadcaster的响应，而是由Monitor主动完成，体现了广播的灵活性。

（1）监听者加入过程

Monitor加入广播流的过程，分为扫描、筛选、解密、同步四个核心步骤：

广播扫描：Monitor通过BASS服务，扫描周围的LE Audio广播包，获取广播元数据的明文部分（如Broadcast ID）；

筛选匹配：Monitor根据用户的选择（如"连接手机广播"），筛选出目标Broadcast ID的广播流；

元数据解密：若为私有广播，Monitor使用配对时获取的解密密钥，解析加密的元数据，获取CCID和Streaming Audio Contexts；

音频同步：Monitor根据元数据中的传输参数，配置本地解码单元，同步广播音频流，开始接收并播放音频。

规范要求，Monitor在加入广播后，需要向本地CAP层报告加入状态，以便后续的控制操作（如通过CCID关联控制服务）。

（2）监听者退出过程

Monitor退出广播流的过程非常简单，分为主动退出 和被动退出两种方式：

主动退出：用户手动关闭广播接收（如耳机上的"停止广播"按钮），Monitor停止扫描目标Broadcast ID的广播包，释放解码资源；

被动退出：Monitor超出广播范围、广播流终止、解密密钥失效，Monitor自动停止接收音频，释放资源。

3.3 广播音频更新与终止过程：电台的节目调整/停播

广播音频的更新和终止过程，与单播有相似之处，但由于广播的一对多特性，在参数同步方式上有明显差异。

（1）广播音频更新过程

当Broadcaster需要修改广播流的参数（如Context Type变化、CCID变化）时，通过广播音频更新过程完成。核心步骤：

Broadcaster修改核心参数（如新增Instructional Context Type）；
重新封装广播元数据（加密或明文）；
在后续的广播包中，发送更新后的元数据；
Monitor扫描到更新后的元数据，解析并同步本地策略（如开始混音处理）。

与单播不同，广播更新无需Monitor的响应，采用"广播通知"的方式，确保所有监听者都能同步参数。

（2）广播音频终止过程

当Broadcaster需要停止广播时（如用户关闭"全屋广播"），通过广播音频终止过程完成。核心步骤：

Broadcaster发送包含终止原因的广播元数据（如User Initiated）；
停止发送音频数据和广播包；
释放广播流占用的资源（Broadcast ID、CCID、解码单元）；
Monitor扫描到终止元数据，或检测到广播包停止，主动退出广播，释放资源。

对于异常终止（如Broadcaster断电），Monitor会在检测到广播包中断超过超时时间（规范建议10秒）后，自动退出广播，释放资源。

四、协同设备组CAP过程：多设备联动的统筹方案

LE Audio的核心优势之一是支持多设备协同，比如"两个TWS耳机+一个智能音箱"组成协同组，同步播放音乐；多台手机组成协同组，轮流广播音频。协同设备组CAP过程，就是为了实现多设备间的策略同步、成员管理，确保协同组内的所有设备，都能按照统一的逻辑处理音频流。

规范将协同设备组过程定义为

procedures for managing coordinated sets of audio devices and synchronizing audio context and content control strategies across group members

明确了其核心是管理与同步。

协同设备组过程分为组建立、成员管理、策略同步三个核心阶段，Coordinator在其中扮演核心角色，统筹整个组的交互逻辑。

4.1 组建立过程：组建音频团队

组建立过程，是Coordinator创建协同设备组，邀请目标设备加入，完成组初始化的过程，就像项目经理组建项目团队，确定团队成员和核心规则。

（1）核心步骤

组参数配置：Coordinator配置协同组的核心参数，包括组ID（唯一标识）、组类型（单播协同组、广播协同组）、同步策略（Context同步、CCID同步、音量同步）；
成员邀请：Coordinator向目标设备发送组邀请消息，携带组参数和邀请密钥；
成员响应：被邀请设备收到邀请后，根据自身能力，选择接受或拒绝邀请：

接受：返回成功响应，加入协同组；

拒绝：返回失败响应，说明原因（如不支持组类型）；
组初始化：Coordinator收到所有被邀请设备的响应后，完成组初始化，向组内所有成员发送组信息同步消息，包含成员列表、同步策略。

（2）核心规则

规范要求，协同组的组ID必须是全球唯一的6字节值，由Coordinator生成，确保不同协同组之间不会混淆。同时，组内的同步策略可以根据应用场景灵活配置，比如音乐协同组需要开启音量同步，通话协同组需要开启Context同步。

4.2 成员管理过程：团队的人员调整

成员管理过程，包括成员加入、成员退出、成员移除三个子流程，对应团队的新成员加入、成员主动离开、成员被移出团队。

1. 成员加入

除了组建立时的邀请加入，协同组支持动态加入：新设备可以主动向Coordinator发送加入请求，Coordinator根据组策略，选择接受或拒绝（如私有组需要验证密钥，公共组开放加入）。

2. 成员退出

组内成员可以主动向Coordinator发送退出请求，Coordinator收到后，更新成员列表，向组内所有成员同步最新列表，退出的成员释放组相关资源。

3. 成员移除

Coordinator可以主动将组内成员移除（如设备离线超过超时时间），发送移除通知给被移除成员和组内其他成员，更新成员列表，被移除成员释放组相关资源。

4.3 策略同步过程：团队的统一行动

策略同步过程，是协同设备组过程的核心，确保组内所有成员的音频策略保持一致，避免出现同一首歌，不同耳机音量不同、来电时，部分设备响铃，部分设备不响铃的情况。

规范要求，Coordinator必须实时同步以下三类核心策略：

Context同步：当组内某台设备的Available Audio Contexts发生变化时，Coordinator同步给所有成员；

CCID同步：当组内的音频流CCID发生变化时，Coordinator同步给所有成员，确保控制指令的精准映射；

音量同步：当组内某台设备的音量发生变化时，Coordinator同步给所有成员，确保音量一致。

策略同步的流程采用**"发布-订阅"**模式：Coordinator是发布者，组内成员是订阅者，当策略发生变化时，Coordinator立即发布同步消息，成员收到后更新本地策略。

协同设备组策略同步序列图（音量同步）

五、异常处理与容错机制：协议健壮性的核心保障

任何协议的实际应用，都无法避免异常场景的出现，比如网络中断、参数错误、资源不足、设备离线等。CAP procedures专门设计了异常处理与容错机制，确保在异常场景下，设备能优雅处理，避免崩溃、死锁或用户体验受损。

规范将异常处理机制定义为mandatory procedures for handling errors and exceptional conditions during CAP interactions，强调了其在协议健壮性中的必要性。

异常处理机制分为错误码机制、超时机制、回退机制、缓存清理机制四个核心部分，我们结合之前展开的附录错误码，逐一讲解。

5.1 错误码机制：异常的标准化标识

错误码机制是异常处理的基础，规范中定义了完整的CAP错误码体系，分为通用错误码、单播错误码、广播错误码、协同组错误码四类，覆盖了所有可能的异常场景。

除了之前在单播建立过程中讲解的通用错误码，还有以下高频错误码：

|-----------|---------|----------------------|-----------------------------|
| 错误码类型 | 错误码 | 含义 | 应用场景 |
| 广播错误码 | 0x10 | Broadcast ID Invalid | Monitor扫描到的Broadcast ID格式错误 |
| 广播错误码 | 0x11 | Broadcast Encrypted | Monitor尝试加入加密广播，但无解密密钥 |
| 协同组错误码 | 0x20 | Group ID Duplicate | Coordinator生成的组ID已存在 |
| 协同组错误码 | 0x21 | Member Not In Group | 设备尝试执行组操作，但未加入任何组 |

设备在收到错误码后，会根据错误类型执行对应的处理策略，比如：

收到0x11（Broadcast Encrypted），Monitor向用户提示"需要配对才能收听该广播"；
收到0x20（Group ID Duplicate），Coordinator重新生成组ID，重试组建立过程。

5.2 超时机制：避免无限等待

规范为CAP流程的每个关键步骤，都定义了超时时间，避免设备因等待消息而陷入无限阻塞状态。核心超时时间如下：

|----------|----------|----------------------------|
| 流程步骤 | 超时时间 | 处理策略 |
| 单播建立请求响应 | 500ms | 超时后，Initiator重试1次，仍超时则终止建立 |
| 广播加入同步 | 1000ms | 超时后，Monitor重新扫描广播包 |
| 协同组策略同步 | 300ms | 超时后，Coordinator重发同步消息 |

超时机制的设计，兼顾了可靠性和效率：超时时间过短，容易导致正常消息被判定为超时；超时时间过长，会影响用户体验。

5.3 回退机制：异常场景的兜底方案

当异常场景无法通过重试解决时，设备会执行回退机制，采用兜底方案，确保音频服务能继续提供，或优雅终止。核心回退机制包括：

Context回退：当请求的Context Type不被支持时，回退为Unspecified场景，尝试建立音频流；

CCID回退：当动态CCID分配失败时，尝试使用Unspecified CCID（0x0000），建立无控制的音频流；

传输模式回退：当单播建立失败时，回退为广播模式（如手机向耳机单播失败，改为向耳机广播音乐）。

5.4 缓存清理机制：避免旧数据干扰

CAP流程中，设备会缓存大量临时数据（如CCID绑定关系、Context状态、组信息），异常场景下，这些缓存数据可能会失效，导致后续流程出错。规范要求，设备必须执行严格的缓存清理机制：

CCID缓存清理：音频流终止后，立即清除CCID绑定缓存，动态CCID延时10秒复用；

Context缓存清理：设备重启、连接中断后，立即重置Available Audio Contexts为默认状态；

组信息缓存清理：退出协同组或被移除后，立即清除组ID、成员列表、同步策略等缓存。

六、CAP过程与上层服务的联动：从协议到业务的落地

CAP procedures本身是一套底层协议流程，其最终目的是支撑上层业务场景的实现。在实际应用中，CAP流程与MCS/GMCS（媒体控制服务）、TBS/GTBS（电话承载服务）紧密联动，形成了完整的音频业务逻辑。

我们以TWS耳机接电话这个最经典的业务场景，串联起CAP流程与上层服务的联动，让大家理解协议如何支撑实际业务。

业务场景：TWS耳机连接手机，用户正在听音乐，此时有来电，通话结束后继续听音乐

1. 初始状态

手机（Initiator）与耳机（Acceptor）建立单播音频流，CCID=0x0100，关联MCS服务，Context Type=Media；
音频流正常传输，用户听音乐。

2. 来电触发（TBS服务联动CAP流程）

手机的TBS服务检测到来电，向CAP层发送音频流建立请求；
CAP层分配SIG保留CCID=0x0001，关联TBS服务，Context Type=Ringtone；
CAP层发起单播音频更新过程，将当前音频流的Context Type从Media更新为Media+Ringtone（或发起新的音频流建立）；
耳机收到更新请求后，执行场景策略：降低音乐音量，播放来电铃声（带内或带外）。

3. 通话接通（TBS状态切换联动CAP更新）

用户按下耳机的接听键，TBS服务状态从Incoming变为Active；
CAP层发起单播音频更新过程，将Context Type从Ringtone更新为Conversational，CCID保持0x0001；
耳机收到更新请求后，执行场景策略：暂停音乐，优先播放通话音频。

4. 通话结束（TBS服务联动CAP终止）

用户挂断电话，TBS服务状态变为Terminated；
CAP层发起单播音频终止过程，终止CCID=0x0001的音频流；
CAP层发起单播音频更新过程，将原音频流的Context Type从Media+Ringtone恢复为Media；
耳机收到更新请求后，恢复音乐播放，通话流程结束。

这个业务场景充分体现了CAP流程与上层服务的联动逻辑：上层服务的状态变化，触发CAP流程的执行；CAP流程的执行结果，支撑上层服务的业务体验。

七、开发者实现关键注意事项：从理论到代码的落地

对于LE Audio开发者来说，理解CAP procedures的理论后，更重要的是将其落地到代码实现中。结合规范要求和实际开发经验，我们总结了6个关键注意事项，帮助开发者避免常见坑。

（一）严格遵循参数校验顺序

在单播建立、更新过程中，Acceptor的参数校验必须按照"CCID唯一性→Context支持性→Context可用性→资源充足性"的顺序执行，避免出现逻辑错误（如先校验资源，再发现CCID重复，导致资源浪费）。

（二）实现CCID的延时复用机制

动态分配的CCID，在释放后必须至少等待10秒才能复用，开发者需要在代码中实现CCID的缓存池，标记每个CCID的释放时间，确保延时复用。

（三）保证元数据的原子性封装

广播元数据的封装必须是原子性的，避免出现部分参数封装的情况，导致Monitor解析失败。建议采用序列化框架，一次性封装所有核心参数。

（四）处理好协同组的并发同步

协同组的策略同步可能存在并发场景（如同时发生音量变化和Context变化），开发者需要实现同步消息的队列机制，避免消息丢失或覆盖。

（五）完善异常场景的容错处理

开发者需要覆盖所有可能的异常场景，实现错误码的解析、超时的处理、回退的执行，不能只处理正常流程。建议采用状态机的方式，管理CAP流程的不同状态，确保异常场景下的状态切换正确。

八、测试

题目：请详细描述单播音频建立过程的三个阶段及核心步骤，并说明Acceptor的参数校验顺序和核心校验项。

答案：

单播音频建立过程分为前置协商、核心握手、后置确认三个阶段，共8个核心步骤：

前置协商阶段：①PACS能力交换，②CCID分配与关联，③建立请求参数封装；
核心握手阶段：④发送建立请求，⑤Acceptor参数校验，⑥发送建立响应；
后置确认阶段：⑦控制服务绑定，⑧音频流启动。

Acceptor的参数校验必须按照"CCID唯一性→Context支持性→Context可用性→资源充足性"的顺序执行，核心校验项及对应错误码：

CCID唯一性校验：检查CCID是否已被使用，若重复返回错误码0x02；
Context Type支持性校验：检查请求的Context是否在Supported列表中，若不支持则判断是否可回退为Unspecified；
Context Type可用性校验：检查请求的Context是否在Available列表中，若不可用返回错误码0x03；
资源充足性校验：检查解码单元、声道等资源是否充足，若不足返回错误码0x01。

题目：请分析CAP广播音频建立过程与单播音频建立过程的核心差异，包括传输模式、消息交互、CCID分配、元数据处理四个方面。

答案：

两者的核心差异如下：

传输模式：单播是点对点的连接式传输，依赖蓝牙LE连接；广播是一对多的无连接式传输，基于扩展广播包。
消息交互：单播建立需要Initiator与Acceptor的双向消息交互（请求-响应）；广播建立是Broadcaster的单向操作，无需监听者响应。
CCID分配：单播根据服务类型，可分配SIG保留值或动态值；广播分为公共广播（SIG保留值）和私有广播（动态值）。
元数据处理：单播的CAP参数封装在连接消息中，为明文；广播的CAP参数封装在广播元数据中，公共广播明文，私有广播加密。

题目：请简述CAP协同设备组的策略同步过程，包括核心同步策略、同步模式，以及音量同步的具体执行流程。

答案：

CAP协同设备组的策略同步过程是Coordinator将组内的音频策略变化，同步给所有成员，确保策略一致的过程。

核心同步策略包括三类：Context同步、CCID同步、音量同步。

同步模式采用发布-订阅模式：Coordinator是发布者，组内成员是订阅者，策略变化时立即发布同步消息。

音量同步的具体执行流程：

组内某成员检测到音量变化，向Coordinator发送音量变化通知；
Coordinator收到通知后，封装音量同步消息，发送给组内所有成员；
组内成员收到同步消息后，立即更新本地音量参数，执行音量调整；
所有成员完成音量更新，实现组内音量一致的协同体验。