做完端点发现和能力查询，相当于和对端设备完成了一轮全面的能力摸底，知道对方有哪些端点、分别支持什么编码、能达到什么样的性能上限。但摸底只是前提，要真正建起一条能传数据的音视频流，还得把每一项参数都敲定下来，让两端的配置完全对齐——采样率用多少、声道选哪种、编码码率设多大、要不要开内容保护，所有细节都必须一一匹配，差一个比特都可能导致建流失败。

目录

一、SET_CONFIGURATION：全量参数一次性敲定，建流的核心一步

1.1 命令帧结构：寻址头+能力配置列表

1.2 必选与可选能力的配置规则

1.3 核心配置详解：以SBC编码为例

1.4 响应处理与常见错误码

二、GET_CONFIGURATION：读取当前生效配置，校验与恢复的利器

2.1 命令与响应格式

2.2 三类典型使用场景

三、RECONFIGURE：建流后的增量修改，动态调参的核心

3.1 严格的状态约束

3.2 命令与响应格式

3.3 典型应用场景

四、完整流程串联与实战避坑指南

4.1 从发现到就绪的完整配置时序

4.2 开发中最容易踩的五个坑

4.3 实战报文拆解：SET_CONFIGURATION全帧逐字节验证

五、测验

SET_CONFIGURATION、GET_CONFIGURATION、RECONFIGURE这三条信令，就是负责参数敲定、校验、修改的核心指令。它们承上启下，把前期的能力摸底转化为实际可用的流配置，是整个AVDTP状态机从空闲推进到就绪的关键一步。很多新手调试A2DP连接时遇到的无声、卡顿、建流失败，十有八九都出在配置这一步。

本文就把这三条信令彻底讲透，从帧格式的每个比特位，到状态机的流转规则，再到实际开发里的常见坑点，结合真实报文拆解和代码示例，一次性梳理成可落地的知识体系。

一、SET_CONFIGURATION：全量参数一次性敲定，建流的核心一步

SET_CONFIGURATION是建流流程里承上启下的核心节点。发起端拿到对端的能力列表后，和本地支持的能力做交集运算，选出最优的一组参数，通过这条命令下发给接收端。接收端校验通过后，两端的端点就完成绑定，流正式进入就绪状态。

可以用一个很直观的比喻理解：能力查询相当于拿到餐厅的完整菜单，上面列着所有可选的菜品和口味；SET_CONFIGURATION就是正式下单，你只能从菜单里选具体的菜品和固定的口味，不能点菜单上没有的东西。

协议中对这条命令的定位非常明确：

The SET_CONFIGURATION command is used to set the service capabilities of the addressed SEP and to create a stream between the ACP SEP and the INT SEP.

简单来说，这条命令承担了两个核心职责：一是给接收端的目标端点设置具体的服务能力参数，二是在发起端和接收端的两个端点之间建立绑定关系，形成一条完整的双向流。

1.1 命令帧结构：寻址头+能力配置列表

SET_CONFIGURATION的命令载荷分为两大部分：前端的寻址字段，和后端的服务能力配置列表。

寻址字段固定占2字节，分别对应接收端端点编号和发起端端点编号。很多初学者只知道要指定对端的SEID，很容易忽略发起端也要上报自己的SEID。实际上一条流是两端端点的双向绑定，接收端也需要知道发起端用哪个端点和自己通信，后续接收端主动发起信令交互时才能正确寻址。

两个SEID的格式和之前所有信令的SEID完全一致：每个占1字节，高6位是SEID的有效数值，低2位为保留位必须置0。也就是说SEID的有效数值需要左移1位后再填入字节，这是整个AVDTP信令体系里通用的格式规则，也是最容易踩坑的细节。

寻址字段之后，就是连续的TLV格式服务能力条目，格式和GET_CAPABILITIES响应里的结构完全一致，但语义有本质区别：

• 能力查询返回的是位掩码，代表支持的参数范围，一个字段可以同时标记多个支持的选项

• 配置命令里填入的是具体的单值，代表最终选定的参数，每个字段只能有一个有效值

以最常见的SBC编码为例，能力查询返回的采样频率字段是位掩码，同时标记支持44.1kHz和48kHz；但在配置命令里，同样的字段位置只能选其中一个采样率填入，不能同时保留两个值。

1.2 必选与可选能力的配置规则

服务能力分为必选和可选两类，配置时的规则完全不同。

Media Transport和Media Codec是两条必选能力，必须完整出现在配置命令里，缺一不可。其中Media Transport的长度为0，没有额外参数，很多新手觉得它没有实际内容就省略不写，结果接收端直接返回参数错误。实际上Media Transport代表媒体传输的基础能力，是流存在的底层基础，即使没有额外参数，也必须通过TLV条目显式声明启用，这是协议的强制要求。

其余的Delay Reporting、Content Protection、Header Compression、Multiplexing等都属于可选能力，根据实际业务需求选择是否启用。启用的前提是对端的能力列表里包含对应能力，不能配置对端没有声明支持的可选能力，否则会直接返回不支持错误。

这里有一个非常重要的校验原则：配置命令里的所有能力和参数，必须是对端能力列表的子集。无论是必选能力还是可选能力，只要配置了对端能力范围之外的参数，接收端都有权直接拒绝配置。实际开发中绝大多数配置失败的问题，都违背了这个基本原则。

1.3 核心配置详解：以SBC编码为例

我们以最通用的SBC编码为例，详细拆解Media Codec能力的配置规则，同时对比能力掩码和配置值的差异，帮助理解两者的区别。

SBC的编码参数固定占4字节，加上1字节媒体类型和1字节编码类型，整个Media Codec的Value部分共6字节。前两字节分别是媒体类型和编码类型，音频SBC对应的值均为0；后四字节是具体的编码参数，每一位的定义都有严格规范。

第一参数字节的高4位为采样频率，低4位为声道模式：

• 采样频率位从高到低依次对应16kHz、32kHz、44.1kHz、48kHz，能力查询时可以多位同时置1代表支持多种采样率，配置时只能有一位置1

• 声道模式位从高到低依次对应单声道、双声道、立体声、联合立体声，同样是能力用掩码、配置用单值

第二参数字节依次分为块长度、子带数量、分配方式三部分：

• 高4位对应块长度，支持4、8、12、16四种取值

• 中间2位对应子带数量，支持4、8两种取值

• 低2位对应分配方式，支持SNR和Loudness两种

最后两字节分别为最小比特池和最大比特池，定义了编码码率的可调范围。配置时两个值可以相同，代表固定码率；也可以设置范围，代表可变码率。

下面给出一段C语言代码，演示如何根据选定的参数组装SBC的配置字节，同时做基础的合法性校验，实际开发中可以直接参考使用：

typedef enum { SBC_SAMP_16K = (1 << 7), SBC_SAMP_32K = (1 << 6), SBC_SAMP_44K1 = (1 << 5), SBC_SAMP_48K = (1 << 4) } sbc_samp_t; typedef enum { SBC_CH_MONO = (1 << 3), SBC_CH_DUAL_CHANNEL = (1 << 2), SBC_CH_STEREO = (1 << 1), SBC_CH_JOINT_STEREO = (1 << 0) } sbc_channel_t; typedef enum { SBC_BLOCK_16 = (1 << 7), SBC_BLOCK_12 = (1 << 6), SBC_BLOCK_8 = (1 << 5), SBC_BLOCK_4 = (1 << 4) } sbc_block_t; typedef enum { SBC_SUBBAND_8 = (1 << 3), SBC_SUBBAND_4 = (1 << 2) } sbc_subband_t; typedef enum { SBC_ALLOC_SNR = (1 << 1), SBC_ALLOC_LOUDNESS = (1 << 0) } sbc_alloc_t; int avdtp_build_sbc_config(sbc_samp_t samp, sbc_channel_t ch, sbc_block_t block, sbc_subband_t sub, sbc_alloc_t alloc, uint8_t min_bitpool, uint8_t max_bitpool, uint8_t *out_buf, uint8_t buf_len) { // 缓冲区长度校验，至少需要6字节 if (out_buf == NULL || buf_len < 6) { return -1; } // 参数合法性校验：配置值必须是单bit，不能是多bit掩码 if (__builtin_popcount(samp) != 1 || __builtin_popcount(ch) != 1 || __builtin_popcount(block) != 1 || __builtin_popcount(sub) != 1 || __builtin_popcount(alloc) != 1) { return -2; } // 前两字节：媒体类型=音频，编码类型=SBC out_buf[0] = 0x00; out_buf[1] = 0x00; // 第三字节：采样频率 + 声道模式 out_buf[2] = (uint8_t)samp | (uint8_t)ch; // 第四字节：块长度 + 子带数量 + 分配方式 out_buf[3] = (uint8_t)block | (uint8_t)sub | (uint8_t)alloc; // 第五、六字节：比特池范围 out_buf[4] = min_bitpool; out_buf[5] = max_bitpool; return 6; }

代码里特意加入了单bit校验，就是为了防止误把能力掩码当成配置值填入。实际开发中很多兼容性问题，都是因为直接把能力掩码抄进了配置参数里，导致接收端解析失败。

1.4 响应处理与常见错误码

SET_CONFIGURATION的响应分为接受和拒绝两种。

如果接收端校验通过、接受配置，响应只有信令头部，没有任何载荷。收到接受响应后，两端的流端点就完成了绑定，状态从Idle切换到Open，流配置正式生效，后续可以随时启动数据传输。

如果接收端拒绝配置，响应载荷会包含错误码和出错的服务类别，方便快速定位问题。错误码的完整定义在协议附录中，开发中最常见的有以下几类：

• Bad ACP SEID / Bad INT SEID：端点编号无效，通常是SEID格式错误或者编号不存在

• Bad Service Category：服务类别不支持，也就是配置了对端能力列表里没有的能力

• Bad Payload Format：载荷格式错误，通常是参数长度不对、字段值非法

• Not Allowed：当前状态不允许执行该命令，一般是状态机顺序错误导致

• Bad Length：总长度不匹配，多半是TLV长度字段填写错误

调试配置失败问题时，先看错误码和对应的服务类别，基本就能快速缩小排查范围。比如返回Bad Service Category，就直接核对对端的能力列表，看配置的能力是否在支持范围内，不用浪费时间排查其他字段。

二、GET_CONFIGURATION：读取当前生效配置，校验与恢复的利器

很多初学者容易把GET_CONFIGURATION和GET_CAPABILITIES搞混，觉得都是查参数，没必要做两条独立的信令。实际上两者的定位完全不同，一个查能力边界，一个查当前配置，对应完全不同的使用场景。

可以用手机屏幕刷新率做类比：GET_CAPABILITIES相当于问手机最高支持多少赫兹的刷新率，是硬件能力范围；GET_CONFIGURATION相当于问当前系统设置的是多少赫兹，是实际生效的运行参数。

2.1 命令与响应格式

GET_CONFIGURATION的命令结构非常简单，载荷只有1字节的SEID，指定要查询的目标端点，格式和其他信令的SEID完全一致。

响应载荷是TLV格式的服务能力列表，格式和SET_CONFIGURATION的命令载荷完全一致，返回当前已经生效的全量配置参数。和能力查询响应不同，这里返回的所有参数都是具体的单值，不是位掩码，代表当前正在使用的配置。

需要特别注意的是，这条命令只能对已经完成配置的端点使用。如果目标端点还处于空闲状态，没有任何生效配置，查询会直接返回错误。只有处于Open或者Streaming状态的端点，才能返回有效的配置结果。

2.2 三类典型使用场景

虽然这条命令结构简单，但在实际工程里用处非常大，是很多高级功能和调试手段的基础。

（1）第一类场景是配置校验。下发SET_CONFIGURATION之后，主动发送一次GET_CONFIGURATION，把返回的配置和自己下发的配置做对比，可以确认对端是否真的按照要求生效了配置。有些设备的协议栈实现不规范，会静默修改部分参数，比如把高码率自动降成低码率，如果不做校验，上层根本感知不到，只会觉得音质不对。关键业务场景下增加一步配置校验，能避免很多隐性问题。

（2）第二类场景是断连快速恢复。蓝牙连接因为干扰、距离等原因临时断开后，重连时不一定需要重新走完整的发现-配置流程。可以先发送GET_CONFIGURATION查询对端的当前配置，如果配置还在、和本地一致，就可以直接启动流，大大缩短重连时间，提升用户体验。

（3）第三类场景是问题排查。遇到音频异常、音画不同步、卡顿等问题时，分别查询两端的当前配置，对比参数是否一致，是非常高效的排查手段。很多看似复杂的音频问题，本质就是两端配置不匹配，比如一端是48kHz采样率，另一端是44.1kHz，声音自然会出现杂音、变速等异常。

三、RECONFIGURE：建流后的增量修改，动态调参的核心

了解完SET_CONFIGURATION之后，很多人会产生疑问：既然已经可以配置参数了，为什么还要单独做一条RECONFIGURE命令？两者的核心差异到底在哪里？

答案在于状态机阶段和修改范围的不同。SET_CONFIGURATION是在空闲状态下从零建立一条流，必须提供全量必选参数，是全量覆盖式的配置；RECONFIGURE是在流已经建立完成的Open状态下，对现有配置做局部修改，只需要提供要修改的能力条目，是增量更新式的配置。

继续用之前的比喻：SET_CONFIGURATION相当于买新电脑时选全套配置，从CPU到内存到硬盘全部敲定；RECONFIGURE相当于电脑到手后升级内存，只换要改的部件，不用重新买整台电脑。

协议中对这条命令的约束非常明确：

The RECONFIGURE command is used to modify the service capabilities of an already established stream. Only service capabilities that do not affect the media type or codec type may be reconfigured.

也就是说，重配置有明确的边界：不能修改媒体类型和编码类型这些核心属性，只能修改编码参数、保护机制等不改变底层编码框架的能力。比如SBC编码可以修改采样率、比特池、声道模式，但不能直接换成AAC编码。要更换编码类型，必须先关闭当前流，重新走完整的SET_CONFIGURATION流程。

3.1 严格的状态约束

RECONFIGURE对发送时机有严格要求，必须在流处于Open状态时发送。如果流正在Streaming状态传输数据，必须先发送Suspend命令暂停传输，等状态回退到Open之后，才能发送重配置命令。

这是实际开发中非常容易踩的坑。很多产品想做播放过程中的动态音质切换，直接在播放状态下发RECONFIGURE，结果次次被对端拒绝，就是因为违背了状态机的流转规则。想要无感切换音质，必须先暂停、再重配、再恢复播放，整个过程控制在几十毫秒以内，用户基本感知不到停顿。

3.2 命令与响应格式

RECONFIGURE的命令载荷由1字节SEID和若干TLV能力条目组成。和SET_CONFIGURATION不同，它不需要带全量能力，只需要携带想要修改的能力条目即可，没有提到的能力会保持原有配置不变。

比如只想调整SBC的比特池值，就只带Media Codec一个能力条目，Media Transport、Delay Reporting等其他能力都不用带，接收端会保留原来的配置。这种增量设计既减少了报文长度，也降低了出错概率，不用每次修改都重传全量参数。

响应格式和SET_CONFIGURATION完全一致：接受则无载荷，拒绝则返回错误码和出错的服务类别。

3.3 典型应用场景

RECONFIGURE是很多高级音频功能的基础，在实际产品中应用非常广泛。

最常见的是动态音质调节。设备可以根据蓝牙链路的信号质量、剩余电量、业务场景动态调整编码参数：信号好、电量充足的时候用高码率高音质，信号差、电量低的时候降低码率保证流畅和续航。整个切换过程通过RECONFIGURE完成，不需要断开重连，用户几乎感知不到变化。

其次是场景化参数切换。比如同一条音频流，音乐模式下用立体声高码率，语音助手模式下自动切换到单声道低码率，适配不同的业务需求；或者根据播放内容动态切换声道模式，最大化音质和功耗的平衡。

还有一类场景是自适应链路优化。蓝牙链路受环境干扰波动很大，协议栈可以实时统计丢包率、延迟等指标，通过RECONFIGURE动态调整编码参数，在音质和稳定性之间做动态平衡，保证复杂环境下的播放体验。

四、完整流程串联与实战避坑指南

讲完了三条信令各自的细节，我们把整个配置流程串联起来，形成完整的时序认知，再总结几个开发中最高频的坑点，最后用一组真实的HCI空口抓包做逐字节验证，把理论落地到实际报文。

4.1 从发现到就绪的完整配置时序

一条流从无到有完成配置，完整的步骤如下：

1. 发起端发送DISCOVER命令，获取接收端所有流端点的基础信息

2. 发起端筛选出符合需求的目标端点，发送GET_CAPABILITIES或GET_ALL_CAPABILITIES获取能力范围

3. 发起端将对端能力与本地能力做交集运算，选出最优的一组配置参数

4. 发起端发送SET_CONFIGURATION命令，携带目标SEID、本地SEID和全量配置参数

5. 接收端校验参数合法性，通过则返回接受响应，流进入Open状态

6. 可选步骤：发起端发送GET_CONFIGURATION读取当前配置，校验与下发参数是否一致

7. 后续需要修改参数时，先暂停流回到Open状态，发送RECONFIGURE增量修改指定参数

8. 参数修改完成后，重新启动流进入Streaming状态

整个流程环环相扣，每一步都有严格的前置状态要求，必须按顺序执行，跳步或者顺序错误都会被对端拒绝。

4.2 开发中最容易踩的五个坑

这部分是从大量实际项目中总结出来的高频问题，几乎每个蓝牙音频开发工程师都踩过其中至少一个。

（1）第一个坑是SEID格式错误。所有信令里的SEID都需要左移1位填入高6位，很多新手直接把SEID数值当作字节值填入，导致对端解析出错误的端点编号，返回SEID不存在错误。这个问题隐蔽性很强，因为有些抓包工具会自动修正显示，看起来是对的，但实际原始字节是错的，遇到校验严格的设备就会失败。

（2）第二个坑是配置参数超出能力范围。配置了对端能力列表里没有的参数，比如对端只支持44.1kHz采样率，硬发48kHz的配置，必然会返回不支持错误。调试的时候一定要先核对对端返回的能力掩码，再确认配置值是否在掩码范围内，不能想当然地默认对端支持某些参数。

（3）第三个坑是必选能力缺失。觉得Media Transport没有参数就省略不写，或者漏了Media Codec条目，导致接收端参数校验不通过。记住必选能力哪怕长度为0，也必须显式携带TLV条目，这是协议的强制要求，没有商量的余地。

（4）第四个坑是状态机顺序错误。在Streaming状态下发送RECONFIGURE，或者在Idle状态下发送GET_CONFIGURATION，都会直接返回Not Allowed错误。AVDTP是严格的状态机驱动模型，每条信令都有对应的合法状态，发送时机不对必然失败。

（5）第五个坑是重配置修改核心属性。试图用RECONFIGURE修改编码类型、媒体类型，结果次次失败。重配置只能修改编码参数这类非核心属性，核心属性的变更必须销毁流之后重新建立。

4.3 实战报文拆解：SET_CONFIGURATION全帧逐字节验证

前面讲了这么多规则和坑点，我们用一组真实的HCI空口抓包来落地验证，从最底层数据包开始逐层剥离，对照协议定义还原每一个字段，建立字节级的协议认知。本次场景为发起端向SEID=3的音频Sink端点下发配置，启用SBC编码与延迟报告功能，接收端返回接受响应。

4.3.1 命令包逐层拆解

（1）第一层：HCI ACL数据帧

前4字节为HCI ACL数据包头，是蓝牙控制器与主机交互的标准封装：

• 字节0-1：32 20，小端解析后连接句柄为0x0032，分组边界标志为首自动刷新包，广播标志为点对点，与抓包详情完全一致。

• 字节2-3：14 00，小端序表示后续载荷总长度为0x0014即20字节，对应抓包中的Data Total Length字段。

（2）第二层：L2CAP数据帧

HCI载荷部分为完整L2CAP帧，负责数据通道路由：

• 字节4-5：10 00，小端序表示L2CAP载荷长度为0x0010即16字节。

• 字节6-7：44 00，小端序表示目标通道ID为0x0044，即AVDTP专用信令通道，协议栈通过该字段将报文分发至AVDTP模块。

• 字节8-23：共16字节，为完整的AVDTP信令报文。

（3）第三层：AVDTP信令固定头部

前2字节为AVDTP通用信令头，所有单包信令格式统一：

• 字节8：60，二进制为0110 00 00。高4位值为6，对应事务标签6，用于匹配请求与响应；中间2位为00，对应单包类型；低2位为00，对应Command命令类型。

• 字节9：03，低7位值为3，对应信号标识符SET_CONFIGURATION，最高位为保留位恒置0。

（4）第四层：端点寻址字段

接下来2字节为SET_CONFIGURATION特有的双向寻址字段，用于完成两端流端点的绑定：

• 字节10：0C，对应接收端端点ACP SEID。高6位值为3，即目标端点编号为3，低2位为保留位置0。这里正好对应前面提到的SEID格式坑点，SEID占用字节的高6位，实际编号需要将字节值右移2位计算，直接用0x0C当作SEID就会出错。

• 字节11：08，对应发起端端点INT SEID。高6位值为2，即发起端自身的端点编号为2，低2位保留置0。接收端也需要记录发起端的端点ID，用于后续主动发起信令交互。

（5）第五层：TLV格式能力配置列表

寻址字段之后是连续的3个服务能力条目，采用标准TLV格式组织，依次为媒体传输、媒体编解码、延迟报告。

①Media Transport 媒体传输能力

对应字节00 00：服务类别0x00，长度0，无额外参数。作为必选能力，即使没有可配置参数，也必须显式携带TLV条目，代表启用基础媒体传输功能，正好对应前面提到的必选能力不能省略的规则。

②Media Codec 媒体编解码能力（SBC）

对应字节02 06 00 00 21 15 02 35：

• 服务类别0x02，长度6，载荷共6字节。

• 前2字节00 00：媒体类型为Audio，编码类型为SBC。

• 第3字节21：二进制0010 0001。高4位0010对应采样频率44.1kHz，低4位0001对应声道模式联合立体声，均为单bit有效值，符合配置参数的单值要求。

• 第4字节15：二进制0001 0101。高4位0001对应块长度16，中间2位01对应子带数量8，低2位01对应分配方式Loudness。

• 最后2字节02 35：最小比特池值为2，最大比特池值为53，完全符合SBC标准取值范围。

③Delay Reporting 延迟报告能力

对应字节01 00：服务类别0x01，长度0，无额外参数。属于可选扩展能力，启用后支持链路延迟统计与上报，用于音画同步等高级场景。

4.3.2 响应包拆解

接收端返回的配置接受响应非常简洁，完整L2CAP报文仅6字节：

• 前4字节为L2CAP帧头：02 00表示载荷长度2字节，08 8C小端解析为目标通道ID 0x8C08。

• 后2字节为AVDTP信令头：62 03。

  • 62：高4位事务标签为6，与命令一一对应；中间2位为单包类型；低2位为10，对应Response Accept接受响应。

  • 03：信号标识符为SET_CONFIGURATION，与请求命令匹配。

接受响应没有任何载荷，代表接收端已完成全部参数校验，配置正式生效，两端流端点完成绑定，流状态从Idle切换为Open，后续可随时启动音频传输。

五、测验

问题：SET_CONFIGURATION与RECONFIGURE有什么核心区别？分别在什么状态下使用？

答案：

核心区别体现在两个方面。一是作用阶段不同，SET_CONFIGURATION用于流建立阶段，在Idle状态下使用，从零完成全量配置并建立端点绑定；RECONFIGURE用于流建立完成后，在Open状态下使用，对已有配置做增量修改。二是修改范围不同，SET_CONFIGURATION需要携带所有必选能力，是全量覆盖；RECONFIGURE只需要携带待修改的能力，是增量更新，且不能修改媒体类型、编码类型等核心属性。

问题：AVDTP的SET_CONFIGURATION命令中，必选的服务能力有哪两个？为什么长度为0的能力也必须显式携带？

答案：

必选服务能力为Media Transport和Media Codec。即使Media Transport长度为0、没有额外参数，也必须显式携带TLV条目，因为它代表媒体传输的基础能力，是流存在的底层标志，是协议强制要求的必选项。省略必选能力会导致接收端参数校验失败，直接拒绝配置。

问题：GET_CAPABILITIES与GET_CONFIGURATION返回的参数有什么本质区别？

答案：

GET_CAPABILITIES返回的是能力范围，参数以位掩码形式呈现，一个字段可同时标记多个支持的选项，代表设备能支持的所有能力边界。GET_CONFIGURATION返回的是当前生效的具体配置，参数为单值形式，每个字段只有一个有效值，代表设备当前实际运行的参数。