在LE Audio生态中，Common Audio Profile（CAP）是串联起各类音频设备交互的核心协议。而设备间能否顺畅通信，连接建立是第一道关键关卡。对于耳机、音箱、麦克风等外设来说，如何正确实现CAP协议中的LE传输连接流程，直接决定了用户体验的好坏------毕竟没人愿意面对耳机连不上、断连后无法自动重连的尴尬场景。
目录
[2.1 CAP通告的适用场景](#2.1 CAP通告的适用场景)
[2.2 CAP通告的格式与字段解析](#2.2 CAP通告的格式与字段解析)
[2.3 CAP通告与BAP通告的关系](#2.3 CAP通告与BAP通告的关系)
[3.1 非绑定设备的连接流程：初次见面的破冰](#3.1 非绑定设备的连接流程：初次见面的破冰)
[3.2 绑定设备的连接流程：熟人之间的快速会面](#3.2 绑定设备的连接流程：熟人之间的快速会面)
[3.3 链路丢失重连流程：意外断开后的重新牵手](#3.3 链路丢失重连流程：意外断开后的重新牵手)
[3.4 空闲连接：随时待命的预备状态](#3.4 空闲连接：随时待命的预备状态)
[3.5 多绑定场景：面对多个熟人的选择](#3.5 多绑定场景：面对多个熟人的选择)
这篇文章就聚焦CAP协议中外设侧的连接建立机制，从核心的CAP通告设计，到不同场景下的连接流程，再到实际开发中的踩坑点，吃透这部分复杂的协议逻辑。
一、连接建立的核心前提：角色与GAP的映射关系
在深入流程前，我们得先明确一个基础逻辑：CAP定义的角色（Acceptor、Initiator、Commander）并非孤立存在，而是要与蓝牙核心规范中的GAP角色（Peripheral、Central、Broadcaster、Observer）对应，才能实现实际的连接通信。
简单来说，CAP中的Acceptor（比如耳机、音箱）和部分Commander（比如独立音量遥控器），在GAP层面都属于Peripheral角色------它们是被动等待连接的一方；而Initiator（比如手机、电脑）和部分Commander（比如手机兼任的遥控器），则对应GAP的Central角色------它们是主动发起连接的一方。
这种角色映射不是随意定义的，而是CAP协议为了保证跨设备兼容性强制要求的。比如Acceptor如果要实现音量渲染功能（VCP Volume Renderer角色），就必须使用GAP Peripheral角色；而Initiator要发起 unicast 音频流（BAP Unicast Client角色），则必须使用GAP Central角色。
理解这一点很重要，因为后续所有的连接流程设计，都是基于这个角色映射关系展开的。就像演员要先明确自己的角色定位，才能按照剧本完成表演，设备也必须先明确自身的角色映射，才能正确执行连接逻辑。
二、CAP通告：外设的连接邀请函设计
在CAP协议出现之前，BAP协议已经定义了BAP通告机制，但它只适用于支持BAP Unicast Server角色的设备（比如能接收 unicast 音频流的耳机）。而对于那些不支持BAP Unicast Server的设备，比如仅支持广播音频接收的音箱、独立的麦克风控制器，就无法通过BAP通告发起连接请求------这就像有些设备想参加"音频派对"，却没有收到邀请函模板。
CAP通告（CAP Announcement）的出现，正是为了解决这个问题，它为这类设备提供了专属的"邀请函"，让它们也能主动向Central设备发起连接请求。
2.1 CAP通告的适用场景
CAP通告主要面向两类外设：
仅支持BAP Broadcast Sink（广播音频接收）和BAP Scan Delegator（扫描代理）角色的Acceptor，比如主打广播音频的智能音箱；
纯Commander角色的设备，比如独立的耳机音量遥控器。
这些设备无法发送BAP通告，CAP通告就成了它们与Central设备建立连接的唯一途径。
2.2 CAP通告的格式与字段解析
CAP通告的格式被严格定义在协议中，它以可连接的扩展广播PDU形式传输，核心字段如下表所示：
|---------------------------|------------|-----------------------------------------|
| 字段 | 长度（字节） | 说明 |
| Length | 1 | 类型和值字段的总长度 |
| Type | 1 | 固定为Service Data - 16-bit UUID，由蓝牙分配编号定义 |
| Value | 3 | 包含2字节的服务UUID和1字节的通告类型 |
| Common Audio Service UUID | 2 | CAP协议对应的服务UUID，由蓝牙组织统一分配 |
| Announcement Type | 1 | 0x00=通用通告（General），0x01=定向通告（Targeted） |
这里的关键是通告类型（Announcement Type），它直接决定了外设的连接意图：
通用通告（0x00）：外设处于可连接状态，但不主动请求连接，相当于在门口挂着"欢迎光临"的牌子，等待Central主动上门；
定向通告（0x01）：外设不仅可连接，还主动请求Central建立连接，相当于主动向Central递出"邀请函"，催促对方尽快连接。
协议对通告的传输还有明确要求：非绑定模式（Bondable mode）的外设必须发送CAP通告；而绑定模式的外设则可选择发送------这是为了保证未绑定设备能被Central发现，同时给绑定设备灵活选择的空间。
2.3 CAP通告与BAP通告的关系
CAP通告并非要替代BAP通告，而是对它的补充。很多设备会同时支持BAP和CAP对应的角色，比如既能接收 unicast 音频流（BAP Unicast Server），又能支持音量控制（VCP Volume Renderer）的耳机，就可以同时发送BAP通告和CAP通告。
协议允许外设在同一个广播PDU中包含两种通告，这样既能被支持BAP的Central发现，也能被只支持CAP的Central识别，极大提升了设备的兼容性。
三、分场景拆解：外设连接建立的完整流程
CAP协议针对不同的设备状态（绑定/非绑定）、连接意图（主动/被动），定义了不同的连接流程。下面我们结合实际使用场景，逐一拆解这些流程的核心逻辑和关键要求。
3.1 非绑定设备的连接流程：初次见面的破冰
非绑定设备指的是第一次配对连接的设备，比如新买的耳机和手机。这个流程的核心是让Central能快速发现外设，并建立初始连接。
（1）通告发送规则
-
支持BAP Unicast Server角色的外设：可以发送BAP通用通告或定向通告；
-
支持CAP相关角色（如BAP Scan Delegator、VCP Volume Renderer等）的外设：应当发送CAP通用通告或定向通告；
-
混合角色外设：可同时发送BAP和CAP通告；
-
不发送CAP通告的外设：必须在广播的AD数据中包含CAS（Common Audio Service）的UUID，让Central知道这是支持CAP协议的设备。
这里有个强制要求：BAP和CAP的通用通告必须使用同一个广播集（Advertising Set）。这就像外设的广播频道，通用通告只能在一个频道播出，避免Central扫描时被多个相同类型的通告干扰，提升发现效率。
（2）连接建立的触发
Central设备通过GAP的有限发现流程（Limited Discovery）或通用发现流程（General Discovery）扫描外设。当Central处于INAP模式（有立即建立音频流的需求，比如用户点击"连接耳机"）时，会主动对符合条件的外设发起连接；如果处于RAP模式（无立即需求，比如手机后台扫描），则可能暂时不发起连接，仅记录设备信息。
3.2 绑定设备的连接流程：熟人之间的快速会面
绑定设备指的是已经完成配对，下次可直接连接的设备，比如每天通勤用的耳机和手机。这个流程的核心是提升连接速度，减少用户等待时间。
（1）通告发送与 SID 规则
绑定设备的通告发送规则与非绑定设备类似，但增加了对广播集ID（SID）的严格要求：
无向 广播模式下，BAP/CAP通用通告的SID只能使用一个，且除非设备掉电，否则不能更改；绑定生命周期内尽量保持不变；
定向广播模式下，BAP/CAP定向通告的SID也只能使用一个；定向到特定Central的定向通告，同样只能用一个SID；
通用通告和定向通告的SID可以相同；
外设不能频繁更改SID，否则Central可能无法识别设备，导致连接失败。
为什么要对 SID **做这么严格的限制？**因为Central会通过SID来识别广播集的变化，固定SID能让Central快速判断外设的通告是否有更新，无需重复扫描解析，从而提升连接速度。这就像熟人之间有专属的"暗号"，见面时无需过多沟通，就能快速认出对方。
（2）连接的快速建立
当Central扫描到绑定外设的通告后，会直接使用之前配对时保存的信息，跳过繁琐的配对流程，快速建立连接。如果外设发送的是定向通告，Central还会优先处理，进一步缩短连接时间。
3.3 链路丢失重连流程：意外断开后的重新牵手
实际使用中，设备可能因为距离过远、信号干扰等原因断开连接，CAP协议定义了专门的重连流程，确保设备能快速恢复连接。
当连接因链路丢失中断后，外设会执行以下操作：
-
优先通过绑定设备的连接流程，发送定向通告，使用BAP协议定义的Quick连接参数，快速请求重连；
-
如果通告中包含BAP定向通告，必须将Available Audio Contexts字段全部设为0。这是为了让Central重连时，外设不会主动请求新的音频会话，避免出现重连后自动播放音乐的意外情况；
-
外设可以同时发送BAP通用通告（包含自身可用的用例）和BAP定向通告（全0上下文），既不影响重连，又能让Central知道设备的当前状态；
-
如果在设备定义的时限内未建立连接，外设会切换到Reduced Power（低功耗）参数继续广播，降低功耗消耗；
-
重连时的广播模式需根据设备情况选择，比如仅绑定一个Central的设备，可使用定向可连接模式。
这个流程就像朋友之间不小心走散了，一方会先在原地呼喊（发送定向通告），如果没人回应，就会扩大搜索范围（切换低功耗参数），同时告诉周围的人自己的身份（发送通用通告），直到重新找到对方。
3.4 空闲连接：随时待命的预备状态
空闲连接是CAP协议中一个很实用的设计，指的是设备之间建立了连接，但暂时没有音频流传输，也不使用音频相关服务。这种连接的目的是为了后续快速发起音频会话，减少用户等待时间。
（1）空闲连接的建立
-
外设要建立空闲连接，必须使用绑定设备的连接流程，发送定向通告，使用Quick连接参数；
-
如果通告包含BAP定向通告，Available Audio Contexts字段必须全设为0，避免Central误判设备有立即建立音频流的需求；
-
外设可以在发送定向通告的同时，发送包含实际可用上下文的BAP通用通告，方便Central了解设备状态。
（2）空闲连接的维护
-
外设建立空闲连接后，建议尽量保持连接，不要轻易断开；
-
外设可根据自身资源、功耗、重连延迟等因素，决定是否断开空闲连接。比如电量较低时，可断开连接节省功耗；
-
断开空闲连接前，需等待一段实现特定的无活动时间，避免误判用户意图；
-
即使是空闲连接，外设后续也可以随时通过内容控制客户端请求音频会话，或更新Available Audio Contexts字段告知新的可用状态。
空闲连接就像情侣之间的待机通话，虽然暂时没说话，但电话一直通着，想聊天时随时可以开口，无需重新拨号。
3.5 多绑定场景：面对多个熟人的选择
很多外设会绑定多个Central设备，比如耳机可能同时绑定手机和电脑。这种场景下，外设的连接流程会有特殊处理：
-
无连接偏好时：外设发送可连接的无向广播事件，让任何绑定的Central都能发现并连接；
-
有连接偏好时：外设发送可连接的定向广播事件，只针对特定的Central设备，比如用户最近使用的手机；
-
Central的选择逻辑：如果多个绑定外设同时发送定向通告，Central会根据自身能力（比如是否支持外设的用例）和用户设置，选择是否连接以及连接哪个设备。
这就像一个人同时有多个朋友想约见面，他会根据自己的时间和需求，选择最合适的朋友赴约。
四、可连接模式与通告类型的匹配：外设的沟通策略
CAP协议定义了两种可连接模式（无向可连接、定向可连接），外设需要根据自身的连接意图，选择对应的模式和通告类型，才能高效地与Central建立连接。
1. 模式与通告类型的匹配规则
|----------|------------------------------------------------|------------------------------------|
| 通告类型 | 无向可连接模式 | 定向可连接模式 |
| 通用通告 | 设备对任意进入INAP模式的Central开放连接，比如空闲状态的音箱 | 设备仅接受特定Central的连接，比如仅绑定了一个手机的耳机 |
| 定向通告 | 设备急需任意进入INAP模式的Central连接，可能收到多个连接请求，比如急需配对的麦克风 | 设备急需特定Central连接（如用户要启动音频用例）或链路丢失重连 |
2. 关键约束
-
外设发送BAP/CAP定向通告的时间必须有限制（实现特定），不能一直发送，否则会过度消耗功耗；
-
外设可根据实际情况组合使用BAP和CAP通告，比如发送BAP定向通告+CAP通用通告，提升兼容性。
3. 通告组合使用示例
协议给出了多种通告组合的适用场景，我们整理成下表，方便大家理解：
|-------------|-------------|------------------------------------------|---------------------------|
| BAP通告类型 | CAP通告类型 | 适用场景 | 设备示例 |
| 通用 | 通用 | 支持BAP和CAP角色，空闲状态，对任意Central开放 | 既能接收unicast音频，又能支持音量控制的耳机 |
| 通用 | 定向 | 支持BAP和CAP角色，急需Central连接（如请求广播助理） | 需连接手机开启广播音频的智能音箱 |
| 通用 | 无 | 仅支持BAP Unicast Server角色，不提供音量控制等CAP功能 | 仅支持unicast音频接收的基础款耳机 |
| 定向 | 通用 | 支持BAP和CAP角色，急需对应角色的Central连接（如unicast连接） | 需快速连接手机播放音乐的耳机 |
| 定向 | 定向 | 支持BAP和CAP角色，急需Initiator或Commander连接 | 需连接手机开启媒体流的智能音箱 |
| 定向 | 无 | 仅支持BAP Unicast Server角色，急需unicast连接 | 基础款耳机请求连接手机播放音频 |
| 无 | 通用 | 仅支持CAP角色，对任意对应角色的Central开放 | 仅支持音量控制的独立遥控器 |
| 无 | 定向 | 仅支持CAP角色，急需对应角色的Central连接 | 需连接音箱调节音量的遥控器 |
五、核心规则总结与开发踩坑点
1. 必须牢记的核心规则
-
CAP通告是BAP通告的补充，仅适用于不支持BAP Unicast Server的外设；
-
绑定设备的SID必须固定，掉电前不能随意更改，绑定生命周期内尽量不变；
-
定向通告的Available Audio Contexts字段，在重连和空闲连接场景下需全设为0；
-
通用通告只能使用一个广播集，避免Central扫描干扰；
-
定向通告的发送时长有限制，需控制发送时间；
-
混合角色外设可同时发送BAP和CAP通告，提升兼容性；
-
多绑定场景下，外设可通过无向/定向广播选择连接的Central。
2. 实际开发中的常见踩坑点
-
忽略SID固定要求：频繁修改SID导致Central无法识别通告，连接失败。解决办法：严格按照协议要求，绑定设备的SID掉电前不更改，绑定生命周期内尽量保持不变；
-
非绑定设备未发送CAP通告：仅支持CAP角色的外设未发送CAP通告，也未在AD数据中包含CAS UUID，导致Central无法发现设备。解决办法：非绑定设备强制发送CAP通告，不发送的设备必须包含CAS UUID；
-
重连时上下文未设为0：链路丢失重连时，BAP定向通告的Available Audio Contexts字段未全设为0，导致Central重连后触发无用的音频会话请求。解决办法：重连场景下强制将该字段设为0；
-
一直发送定向通告：外设无限制发送定向通告，导致功耗过高。解决办法：设置定向通告的发送时长上限，超时后停止发送或切换为通用通告；
-
混合角色未同时发通告：支持BAP和CAP混合角色的外设，只发送了一种通告，导致部分Central无法识别。解决办法：混合角色设备同时发送BAP和CAP通告，确保兼容性；
-
空闲连接随意断开：外设建立空闲连接后立即断开，失去快速连接的优势。解决办法：优化空闲连接的断开策略，根据电量、资源等因素合理判断，尽量保持连接。
六、测试
题目：请简述CAP中CAP Announcement的设计目的、格式及两种通告类型的区别？
答案：
-
设计目的：为不支持BAP Unicast Server角色的外设（如仅支持广播接收的音箱、独立遥控器）提供连接请求机制，补充BAP通告的适用范围，确保所有CAP兼容外设都能被Central发现并建立连接；
-
格式：以可连接的扩展广播PDU传输，包含Length（1字节）、Type（1字节，固定为Service Data - 16-bit UUID）、Value（3字节，含CAS UUID和通告类型）三个核心字段，其中CAS UUID为2字节，通告类型为1字节；
-
类型区别：通用通告（0x00）表示外设可连接但不主动请求连接，面向所有符合条件的Central；定向通告（0x01）表示外设可连接且主动请求连接，优先级更高，适用于急需连接或重连场景。
题目：CAP中绑定设备的Peripheral在发送BAP/CAP通告时，对广播集ID（SID）有哪些强制要求？为什么有这些要求？
答案：
-
强制要求：①无向广播模式下，BAP/CAP通用通告的SID只能使用一个，除非设备掉电，否则不能更改；②无向广播模式下，BAP/CAP定向通告的SID只能使用一个，定向到特定Central的定向通告也只能用一个SID；③绑定生命周期内，SID尽量保持不变；④通用通告和定向通告的SID可以相同；
-
设计原因：Central通过SID识别广播集的变化，固定SID能让Central高效检测通告是否更新，无需重复扫描解析，从而提升绑定设备的连接速度；同时避免因SID变化导致Central无法识别设备，确保重连和快速连接的稳定性。
题目：当CAP Peripheral因链路丢失与Central断连后，其重连的核心流程和关键参数配置是什么？
答案：
-
核心流程：①外设优先执行绑定设备的连接流程，发送定向通告，请求重连；②若未在时限内建立连接，切换为Reduced Power参数继续广播；③重连期间可同时发送BAP通用通告（含可用用例）和BAP定向通告（全0上下文）；④根据设备情况选择无向或定向可连接模式；
-
关键参数配置：①使用BAP协议定义的Quick连接参数发起重连；②若通告包含BAP定向通告，Available Audio Contexts字段需全设为0；③超时后切换为Reduced Power低功耗参数；④广播模式根据绑定关系选择，如单绑定设备使用定向可连接模式。