在LE Audio的CAP生态中，Acceptor作为直接面向用户的音频终端（耳机、音箱、麦克风等），是所有协同逻辑的最终执行者。如果把CAP协同比作一场团队协作，Acceptor就是一线执行者，它的操作是否合规、能力是否达标，直接决定了用户能感受到的音频体验。而Acceptor角色要求的核心，就是给这个执行者制定了一份详细的合规操作手册------明确了必须掌握的核心操作、可灵活选择的拓展操作、有前提条件的条件性操作，以及额外的配置要求，确保它能和Initiator、Commander精准配合，不出现能力不匹配、操作不合规的问题。本文就拆解这份手册，看看Acceptor要想上岗，到底需要满足哪些要求。
目录
[2.1 音频流转换程序：Acceptor的音频收发核心操作](#2.1 音频流转换程序：Acceptor的音频收发核心操作)
[2.2 捕获与渲染控制程序：Acceptor的控制响应能力](#2.2 捕获与渲染控制程序：Acceptor的控制响应能力)
[2.3 内容控制程序：Acceptor的控制服务查找能力](#2.3 内容控制程序：Acceptor的控制服务查找能力)
[3.1 服务要求：CAS是必备服务](#3.1 服务要求：CAS是必备服务)
[3.2 基础交互要求：无额外负担，遵循底层规范](#3.2 基础交互要求：无额外负担，遵循底层规范)
[4.1 协同集相关要求：加入设备团队的规则](#4.1 协同集相关要求：加入设备团队的规则)
[4.2 服务器发起的BAP更新元数据限制](#4.2 服务器发起的BAP更新元数据限制)
[4.3 铃声状态判断要求](#4.3 铃声状态判断要求)
一、基础认知：Acceptor的操作等级符号
在解读具体要求前，先重温CAP的操作等级符号------这是理解所有程序要求的关键，就像交通信号灯一样，明确了每个操作的执行优先级，避免开发者混淆必须做和可选择做：
|-------------------|----------------|----------------------|-----------------------------------------------------------------------------|
| 符号 | 核心含义 | 实操解读 | Acceptor场景示例 |
| Mandatory (M) | 必须实现，不可或缺 | 设备出厂前必须完成的功能，否则不合规 | 必须支持Common Audio Service（CAS） |
| Optional (O) | 可选实现，灵活拓展 | 根据产品定位选择，不影响核心合规性 | 内容控制中的Find Content Control Service |
| Conditional (C.n) | 条件性实现，满足前提才需支持 | 设备具备特定能力后，才需要实现对应的操作 | 支持BAP Broadcast Sink和BAP Scan Delegator后，需支持Broadcast Audio Reception Start |
| Excluded (X) | 禁止实现，不可使用 | 无需且不能实现，避免冲突 | 无需支持Initiator的BAP Broadcast Source功能 |
这些符号贯穿整个Acceptor要求体系，所有操作的支持程度都通过它们定义，开发者只需对照自身设备的功能定位，就能快速判断需要实现哪些操作。
二、核心能力：Acceptor的必做/可选/条件性程序清单
CAP将Acceptor的操作程序分为三大类：音频流转换程序（负责音频流的启动、停止、切换）、捕获与渲染控制程序（负责音量、麦克风等控制）、内容控制程序（负责查找控制服务）。每类程序都明确了支持要求，确保Acceptor能响应其他角色的指令，完成协同流程。
2.1 音频流转换程序：Acceptor的音频收发核心操作
这类程序直接关系到音频流的正常传输，是Acceptor的核心能力，大部分为条件性要求，需根据设备支持的BAP组件判断是否实现：
|-----------------------------------------|----------|-------------------------------------------------------------------------------|----------------------------------|
| 程序名称 | 支持要求 | 核心条件/解读 | 实际应用场景 |
| Unicast Audio Start（单播音频启动） | C.1 | 条件：支持BAP Unicast Server； 必须实现，否则无法接收单播音频 | 耳机接收手机的音乐单播流 |
| Unicast Audio Update（单播音频更新） | C.1 | 条件：支持BAP Unicast Server； 需响应Initiator的场景（Context Type）或控制标识（CCID）更新 | 音乐流切换为通话流时，更新元数据 |
| Unicast Audio Stop（单播音频停止） | C.1 | 条件：支持BAP Unicast Server； 需响应Initiator的停止指令，释放音频端点（ASE） | 手机暂停音乐，耳机停止接收单播流 |
| Broadcast Audio Reception Start（广播接收启动） | C.2 | 条件：同时支持BAP Broadcast Sink和BAP Scan Delegator； 需响应Commander的广播接收指令 | 音箱接收电视的全屋广播音频 |
| Broadcast Audio Reception Stop（广播接收停止） | C.2 | 条件：同时支持BAP Broadcast Sink和BAP Scan Delegator； 需响应Commander的停止指令 | 关闭音箱的电视广播接收 |
| Unicast to Broadcast Handover（单播转广播切换） | C.3 | 条件：同时支持BAP Unicast Server、BAP Broadcast Sink和BAP Scan Delegator； 可选实现，提升场景灵活性 | 耳机接收的音乐流切换为全屋音箱广播流 |
| Broadcast to Unicast Handover（广播转单播切换） | C.3 | 条件：同上；可选实现 | 音箱接收的广播流切换为耳机单播流 |
| Distribute Broadcast_Code（分发广播码） | C.2 | 条件：同时支持BAP Broadcast Sink和BAP Scan Delegator； 需接收Commander分发的加密广播码 | 会议室耳机接收加密会议广播流前，获取Broadcast_Code |
这里的核心是条件性要求的判断逻辑------比如C.1要求的前提是"支持BAP Unicast Server"，意味着所有需要接收单播音频的设备（如耳机、耳塞）都必须实现Unicast Audio Start/Update/Stop程序，否则无法与Initiator建立单播连接。而C.3的切换程序是可选的，开发者可根据产品定位（如高端耳机需支持多场景切换）决定是否实现。
2.2 捕获与渲染控制程序：Acceptor的控制响应能力
这类程序对应用户的控制操作（调音量、静音等），是提升体验的关键，支持要求同样与底层组件（VCP、MICP）强关联：
|-----------------------------------------|----------|---------------------------------------------------|---------------------|
| 程序名称 | 支持要求 | 核心条件/解读 | 实际应用场景 |
| Change Volume（音量调节） | C.4 | 条件：支持VCP Volume Renderer； 必须实现，响应Commander的音量控制指令 | 手机调节耳机音量，耳机同步响应 |
| Change Volume Offset（音量偏移调节） | C.5 | 条件：支持VCP Volume Renderer；可选实现，用于微调单个设备音量偏移 | 多音箱协同时，单独调高卧室音箱音量偏移 |
| Change Volume Mute State（音量静音切换） | C.4 | 条件：支持VCP Volume Renderer；必须实现，响应静音/取消静音指令 | 遥控器一键静音所有协同集内的音箱 |
| Microphone Mute State（麦克风静音切换） | C.6 | 条件：支持MICP Microphone Device；必须实现，响应麦克风静音指令 | 会议麦克风接收静音指令，停止音频输入 |
| Change Microphone Gain Setting（麦克风增益调节） | C.7 | 条件：支持MICP Microphone Device；可选实现，调节麦克风灵敏度 | 演讲时调高麦克风增益，提升收音效果 |
需要注意的是，这类程序的必须实现是基于底层组件的------比如设备支持VCP Volume Renderer（音量渲染），就必须同时实现Change Volume和Change Volume Mute State，确保音量控制的完整性；而Volume Offset和麦克风增益调节是可选的，可根据产品的功能复杂度决定。
2.3 内容控制程序：Acceptor的控制服务查找能力
这类程序仅包含Find Content Control Service（查找内容控制服务），支持要求为Optional（O）。其核心作用是通过CCID（内容控制标识符），找到Initiator上对应的控制服务（如MCS媒体控制服务、CCP通话控制服务），从而实现对音频内容的精准操控。
例如：耳机收到包含MCS服务CCID的音频流后，可通过该程序找到MCS服务，进而实现"播放/暂停"等媒体控制操作。虽然该程序是可选的，但实现后能提升设备的控制灵活性，建议中高端音频设备优先支持。
三、基础支撑：Acceptor的服务与交互要求
除了核心程序，Acceptor还需满足服务要求和基础交互要求，这些是与其他角色正常通信的前提，也是合规性的基础。
3.1 服务要求：CAS是必备服务
CAP明确规定，Acceptor必须支持Common Audio Service（CAS），支持要求为Mandatory（M）。CAS就像Acceptor的信息交互中枢，所有与协同相关的关键信息（如协同集的CSIS实例、Context Type支持情况、CCID列表）都通过CAS交换。
原规范中提到Common Audio Service (CAS) [1]为Mandatory，意味着任何想接入CAP生态的Acceptor设备，都必须集成CAS服务------没有CAS，Acceptor无法告知Initiator自己支持的场景，也无法加入协同集，更无法接收包含CCID的控制信息，相当于失去了与其他角色沟通的语言。
3.2 基础交互要求：无额外负担，遵循底层规范
CAP对Acceptor的GATT子流程、服务发现、特征发现没有额外要求，只需遵循底层依赖profile（如BAP、VCP、MICP）的相关规定即可。这对开发者来说是个好消息------无需额外开发新的交互逻辑，只需复用已有的底层profile实现，就能满足CAP的合规要求，大大降低了开发成本。
例如：服务发现流程遵循BAP的要求，Acceptor无需额外暴露新的服务接口；GATT子流程沿用蓝牙核心规范的通用逻辑，无需定制化开发。
四、Acceptor的额外合规要求
除了程序和服务要求，CAP还为Acceptor制定了三项关键的额外要求，这些要求直接影响多设备协同的稳定性和兼容性，是容易被忽略但至关重要的部分。
4.1 协同集相关要求：加入设备团队的规则
当Acceptor需要加入协同集（如一对真无线耳机、多台全屋音箱）时，必须满足以下要求：
-
必须实现CSIP（协同集识别配置文件）的Set Member角色，这是加入协同集的身份凭证；
-
协同集中的所有Acceptor共享同一个Set Identity Resolving Key（SIRK），确保它们被识别为同一个团队；
-
一个Acceptor只能加入一个协同集，避免身份混淆；
-
协同集的CSIS（协同集识别服务）实例必须包含在CAS服务中，让Initiator和Commander能通过CAS发现协同集；
-
必须支持CSIS的两个核心特征：Rank（协同集成员排序，如左耳机Rank=1、右耳机Rank=2）和Size（协同集大小，如一对耳机Size=2），支持要求均为Mandatory（M）。
这些要求确保了协同集中的设备能同步响应指令------比如Commander调节音量时，所有成员同时调整，不会出现部分设备响应、部分不响应的情况。
4.2 服务器发起的BAP更新元数据限制
Acceptor作为BAP Unicast Server时，不能自行修改CCID_List（内容控制标识符列表），只能通过两种方式更新：一是接受Initiator发起的BAP Enable操作；二是接受Initiator发起的包含CCID_List的BAP Update Metadata操作。
这一限制的核心目的是确保音频流与控制服务的关联一致性------CCID_List是音频流与MCS、CCP等控制服务的绑定凭证，如果Acceptor自行修改，会导致控制服务无法识别音频流，出现无法暂停音乐、无法挂断通话等问题。
4.3 铃声状态判断要求
实现CCP Call Control Client角色的Acceptor（如支持通话的耳机、音箱），必须支持Read Status Flags程序（支持要求为M）。该程序用于读取TBS（电话承载服务）的状态标志，判断铃声类型：
-
带内铃声（Inband）：由Initiator通过音频流传输（如手机发送的来电铃声）；
-
带外铃声（Out-of-band）：由Acceptor本地生成（如耳机自带的来电铃声）。
具体判断逻辑如下：
-
TBS Call State为Incoming（呼入），Status Flags Bit 0为1（带内铃声启用），且Acceptor支持并可用Ringtone Context Type → 带内铃声；
-
TBS Call State为Incoming，Acceptor不支持或不可用Ringtone Context Type → 带外铃声；
-
TBS Call State为Incoming，Status Flags Bit 0为0（带内铃声禁用） → 带外铃声。
这一要求确保了通话场景下铃声的正常播放，避免出现"无铃声"或"铃声冲突"的问题。
五、实际落地：Acceptor合规开发的避坑指南
结合前面的要求，以真无线耳机（Acceptor+协同集成员）为例，总结合规开发的关键要点，避免踩坑：
-
核心程序：必须实现BAP Unicast Server相关的C.1类程序（Unicast Audio Start/Update/Stop），确保能接收手机单播流；
-
服务集成：必须集成CAS服务，并将协同集的CSIS实例包含在CAS中；
-
协同集配置：实现CSIP Set Member角色，配置SIRK，确保Rank和Size特征为必填；
-
控制响应：建议实现VCP Volume Renderer（可选），支持Change Volume和Change Volume Mute State程序，提升用户体验；
-
元数据限制：严禁自行修改CCID_List，仅通过Initiator的操作更新；
-
通话支持：若支持通话（CCP Call Control Client），需实现Read Status Flags程序，正确判断铃声类型。
遵循这些要点，耳机就能满足CAP合规要求，与手机（Initiator/Commander）实现稳定协同------左右耳同步响应音量调节、通话时自动切换Context Type、加入协同集后同步接收音频流。
六、测试
问题：Acceptor的服务要求中，哪个服务是必须支持的？简述其核心作用。
答案：
必须支持Common Audio Service（CAS），支持要求为Mandatory（M）。
核心作用：CAS是Acceptor与Initiator、Commander的信息交互中枢，主要功能包括：
-
承载协同集的CSIS实例，让其他角色发现Acceptor所属的协同集；
-
交换Context Type（场景）、CCID（控制标识）等关键协同信息；
-
集成必要的服务接口，确保与其他角色的通信合规。没有CAS，Acceptor无法接入CAP协同生态，无法与其他角色正常配合。
问题：Acceptor参与协同集需要满足哪些关键要求？
答案：
Acceptor参与协同集需满足4点核心要求：
-
必须实现CSIP（协同集识别配置文件）的Set Member角色；
-
与协同集内其他成员共享同一个Set Identity Resolving Key（SIRK）；
-
一个Acceptor只能加入一个协同集；
-
协同集的CSIS（协同集识别服务）实例必须包含在CAS服务中；
-
必须支持CSIS的Rank（成员排序）和Size（协同集大小）特征，且均为Mandatory要求。
问题：Acceptor的Unicast Audio Start程序的支持要求是什么？触发该要求的前提条件是什么？
答案：
-
支持要求：Conditional（C.1）；
-
前提条件：Acceptor支持BAP Unicast Server角色；
-
核心含义：当Acceptor支持BAP Unicast Server（即具备接收单播音频的能力）时，必须实现Unicast Audio Start程序，否则无法响应Initiator的单播音频启动指令，无法建立单播连接。