在LE Audio的广播音频体系中，BASS的核心设计围绕低功耗蓝牙LE展开，依托GATT完成服务发现与指令交互，但实际的蓝牙设备开发中，跨制式兼容是工业级设备的硬性要求。规范中专门定义的SDP互操作性要求，正是为了让BASS服务能在经典蓝牙BR/EDR制式下被识别、发现和交互，成为BASS跨LE/BR/EDR两大蓝牙制式的互通基石。
SDP作为经典蓝牙的核心服务发现协议，就像BR/EDR设备之间的服务黄页与登记处 ，所有想在BR/EDR下对外提供的蓝牙服务，都必须按规范在SDP中完成标准化登记，其他设备才能通过SDP查询找到对应的服务，并获取访问该服务的协议路径。BASS的SDP互操作性要求，本质就是定义了BASS服务在这张黄页上的标准化登记格式，包括必须填写的基础信息、可选的增强信息，以及登记信息的编码规则，这部分内容虽篇幅不长，却是BASS设备实现全制式兼容的关键，也是很多开发者容易忽略的开发要点。
本文从SDP互操作的设计初衷出发，拆解BASS标准化SDP记录的所有属性要求、必选与条件实现规则，再结合实际的设备交互流程讲透BR/EDR下BASS服务的发现与访问逻辑，最后补充开发实战中的避坑要点，让你既能理解规范设计的底层逻辑，又能落地到实际开发中。
一、SDP互操作：BASS跨制式兼容的底层设计初衷
要理解BASS的SDP互操作性要求，首先要明确蓝牙两大制式LE 与BR/ EDR 在服务发现层的核心差异，这也是规范为何要单独定义这部分内容的根本原因。
在LE蓝牙中，设备的服务发现完全依托GATT（通用属性配置文件）实现，BASS作为LE Audio的核心服务，通过GATT的服务声明、特征声明完成自身标识的暴露，客户端只需扫描设备的GATT服务列表，就能根据BASS的标准UUID识别并建立交互，这也是我们前几期重点讲解的内容。
而在经典蓝牙BR/EDR中，GATT并非原生的服务发现协议，其核心的服务发现依赖SDP （服务发现协议） ，所有对外提供的服务都需要在SDP中创建对应的SDP记录，该记录包含服务的唯一标识、访问该服务的协议栈路径、服务的浏览分类等核心信息。如果BASS服务仅实现LE下的GATT声明，未在SDP中完成标准化登记，那么BR/EDR设备将无法发现该服务，更无法进行后续的指令与状态交互，导致设备只能在LE生态中工作，失去跨制式兼容的能力。
规范定义BASS的SDP互操作性要求，核心目标有两个：一是实现BASS服务的跨制式发现 ，让BR/EDR设备能通过SDP查询找到BASS服务；二是统一BR/EDR下的服务访问路径 ，让不同厂商的BASS设备在BR/EDR下拥有一致的协议交互逻辑，保证互联互通性。同时，SDP记录的设计也遵循最小化实现+可扩展的原则，基础必选属性保证服务能被发现，条件必选属性则为需要高可靠性传输的场景提供EATT增强支持，兼顾开发成本与功能扩展性。
二、BASS的标准化SDP记录：必选+条件的属性体系
BASS的SDP互操作性核心是标准化的SDP记录 ，规范对该记录的属性做了明确的**必选（M）和条件必选（C.1）**定义，所有属性的取值、编码格式都严格遵循蓝牙核心规范的SDP协议要求，不允许厂商自定义。其中C.1的判定规则为：若设备支持EATT（增强型ATT），则该属性必须实现，否则直接排除。
整个SDP记录的属性分为基础必选属性 和EATT增强条件属性两大类，基础必选属性是所有实现BR/EDR下BASS服务的设备都必须完成的登记项，也是服务能被发现的基础；条件属性则是为了提升BR/EDR下ATT连接的传输可靠性，是高阶实现的可选要求。以下对所有属性做逐点拆解，讲清每个属性的核心作用、取值要求和设计逻辑。
2.1 基础必选属性：BASS服务的SDP基础登记项
基础必选属性包含三项，分别是Service Class ID List、Protocol Descriptor List、BrowseGroupList，这三项属性构成了BASS服务在SDP中的核心身份标识与访问基础，缺一不可。
2.1.1 Service Class ID List：BASS服务的唯一身份标识
该属性是SDP记录中最核心的必选属性，作用是在SDP中唯一标识BASS服务 ，相当于BASS在SDP服务黄页中的专属行业代码。规范要求该属性必须包含蓝牙SIG为BASS分配的标准Service Class UUID （Broadcast Audio Scan），且该UUID为第一顺位的服务类标识。
蓝牙SIG为所有标准化蓝牙服务分配了专属的Service Class UUID，BR/EDR设备在发起SDP查询时，可直接指定该UUID进行精准查询，也可通过浏览分类进行模糊查询。如果该属性缺失或使用自定义UUID，BR/EDR设备将无法识别该服务为BASS，直接导致服务发现失败。
2.1.2 Protocol Descriptor List：BR/ EDR 下访问BASS的协议路径
该属性定义了BR/EDR设备访问BASS服务的底层协议栈路径 ，相当于SDP服务黄页中的服务访问地址，规范要求其必须为L2CAP + ATT的双层协议组合，且每个协议层都有明确的取值要求：
第一层为L2CAP协议，其Protocol/Service Multiplexer（PSM）参数必须设为ATT 的标准PSM值，这是BR/EDR下建立ATT连接的核心标识；
第二层为ATT协议，无额外参数要求，直接引用蓝牙核心规范定义的ATT协议UUID。
这一协议组合的设计逻辑与LE下的BASS交互一致：BASS的所有指令和状态交互都基于ATT协议完成，而ATT协议在蓝牙中依托L2CAP协议做底层数据传输，因此BR/EDR下的BASS访问也必须遵循这一协议栈逻辑，保证了LE与BR/EDR下BASS交互层的一致性，降低了厂商的开发成本。
2.1.3 BrowseGroupList：BASS服务的 SDP 公共浏览分类
该属性定义了BASS服务在SDP中的浏览分类 ，相当于BASS在SDP服务黄页中的所属目录，规范要求其必须包含PublicBrowseRoot（公共浏览根），这是蓝牙SDP定义的通用公共浏览分类，也是所有标准化蓝牙服务的默认浏览目录。
设置为PublicBrowseRoot的核心作用是提升服务的可发现性：BR/EDR设备在发起SDP查询时，若未明确指定BASS的Service Class UUID，可通过遍历PublicBrowseRoot目录下的所有服务，找到BASS服务，这为设备的服务发现提供了两种方式，兼顾了查询的精准性与灵活性。同时规范也允许在该属性中添加其他自定义浏览UUID，满足厂商的个性化分类需求。
2.2 条件必选属性：EATT加持的增强型协议路径
该属性为Additional Protocol Descriptor List，是唯一的条件必选属性，其实现与否完全取决于设备是否支持EATT（增强型 ATT ），规范的C.1规则明确：若设备支持EATT，则该属性必须实现；若不支持，则直接排除，无需实现。
EATT是增强型ATT协议，相比原生ATT，其通过L2CAP的增强型基于信用的流控模式，提升了数据传输的可靠性与 吞吐量 ，适合BASS中长数据传输的场景（如Add Source操作的长参数写入）。该属性的协议组合与Protocol Descriptor List一致，为L2CAP + EATT ，其中L2CAP的PSM参数设为EATT的标准PSM值，EATT层引用蓝牙核心规范定义的EATT协议UUID。
该属性的设计是向下兼容的：支持EATT的设备会在SDP记录中同时包含原生ATT和EATT的两条协议路径，BR/EDR客户端可根据自身能力选择对应的路径；不支持EATT的设备仅暴露原生ATT路径，保证基础的交互能力，这一设计让BASS的SDP记录既能满足基础兼容需求，又能为高阶设备提供增强传输能力。
2.3 BASS SDP记录的核心实现规则
除了属性的取值要求，规范还定义了SDP记录的两大核心实现规则，这是开发中必须严格遵循的硬性要求，也是保证SDP互操作性的关键：
属性的完整性：所有必选属性必须完整实现，不能缺失或删减，否则BR/EDR设备在解析SDP记录时会判定为无效记录，拒绝后续交互；
条件属性的一致性：Additional Protocol Descriptor List的实现状态必须与设备的EATT支持状态完全一致，支持EATT则必须实现，不支持则不能出现该属性，避免客户端出现协议能力不匹配的问题；
取值的标准化：所有UUID、PSM值必须使用蓝牙SIG分配的标准值，不允许厂商自定义，这是跨厂商设备互联互通的基础。
为了更直观的展示BASS SDP记录的属性要求，整理核心属性表如下：
|-------------------------------------|----------|----------------------------|--------------------------|
| 属性名称 | 实现要求 | 核心取值/组合 | 核心作用 |
| Service Class ID List | M | 包含BASS标准Service Class UUID | 唯一标识BASS服务 |
| Protocol Descriptor List | M | L2CAP(PSM=ATT标准值)+ATT | 定义原生ATT的访问路径 |
| BrowseGroupList | M | 包含PublicBrowseRoot | 定义公共浏览分类，提升可发现性 |
| Additional Protocol Descriptor List | C.1 | L2CAP(PSM=EATT标准值)+EATT | 定义EATT的增强访问路径（支持EATT时实现） |
三、BR/EDR下BASS的SDP互操作完整流程
掌握了SDP记录的属性要求后，结合蓝牙SDP协议的工作逻辑，就能梳理出BR/EDR设备发现并访问BASS服务的完整交互流程 。该流程分为SDP服务发现 和GATT协议交互两个阶段，其中SDP阶段完成服务的发现与协议路径获取，GATT阶段则与LE下的BASS交互逻辑完全一致，保证了跨制式的交互一致性。
核心流程解读：
-
SDP查询发起：BR/EDR客户端根据自身需求选择查询方式，精准查询则指定BASS的Service Class UUID，模糊查询则遍历PublicBrowseRoot目录，两种方式均可找到BASS服务；
-
SDP记录返回：BASS服务端接收到查询请求后，返回符合规范的SDP记录，记录中包含必选属性，若支持EATT则同时包含条件属性；
-
SDP记录解析：客户端解析SDP记录，提取Protocol Descriptor List中的协议栈信息，确定访问BASS的底层协议路径是原生ATT还是增强型EATT；
-
加密连接建立：客户端基于L2CAP协议，根据解析的PSM值建立ATT/EATT连接，且连接必须满足BASS的安全要求------加密连接，这与LE下的BASS安全要求一致；
-
GATT协议交互：连接建立后，后续的所有交互都与LE下的BASS完全一致，客户端通过GATT的Write/Write Without Response写入控制点指令，通过Read/Notify获取状态特征，服务端按BASS的核心逻辑处理指令并反馈状态。
从整个流程能看出，SDP互操作仅作用于BR/EDR下的服务发现与连接建立阶段，一旦ATT/EATT加密连接建立，后续的交互逻辑与LE下完全相同，这一设计极大的简化了厂商的开发成本，只需一套GATT层的BASS实现，就能同时支持LE和BR/EDR两大制式。
四、BASS SDP记录开发实战：核心避坑要点
将BASS的SDP互操作性要求落地到实际开发中，核心是按规范完成SDP记录的编码与注册，这部分开发虽不复杂，但有很多容易被忽略的细节，一旦处理不当，就会导致BR/EDR设备无法发现或访问BASS服务。结合蓝牙SDP协议的开发经验和BASS规范的硬性要求，总结出四大核心避坑要点，覆盖编码、注册、兼容性三个维度。
4.1 严格遵循SDP数据元素的编码规则
SDP记录的所有属性都必须遵循蓝牙核心规范定义的SDP数据元素编码格式，包括数据元素的类型、长度、值的编码方式，比如UUID的编码需区分16位、32位、128位，PSM值为16位无符号整数，需按大端序编码。若编码格式错误，BR/EDR客户端将无法解析SDP记录，直接判定为无效记录。
4.2 必选属性缺一不可，禁止自定义取值
开发中必须保证Service Class ID List、Protocol Descriptor List、BrowseGroupList三项必选属性完整实现，不能因开发成本而删减。同时，所有UUID、PSM值必须使用蓝牙SIG分配的标准值，比如BASS的Service Class UUID、ATT/EATT的标准PSM值，禁止厂商自定义，否则会导致跨厂商设备的互联互通性问题。
4.3 条件属性与EATT能力保持严格一致
Additional Protocol Descriptor List的实现状态必须与设备的EATT支持状态完全匹配：支持EATT的设备必须实现该属性，且PSM值设为EATT的标准值；不支持EATT的设备则不能在SDP记录中出现该属性。若出现不匹配的情况，比如设备不支持EATT却实现了该属性，客户端会尝试建立EATT连接，最终导致连接失败。
4.4 保证SDP记录注册与GATT服务的同步
BASS的SDP记录注册必须与GATT服务的开启保持同步：设备开启BASS的GATT服务时，必须同时在SDP中注册标准化的SDP记录；设备关闭BASS的GATT服务时，必须同时从SDP中注销该记录。若出现不同步的情况，比如GATT服务已关闭，但SDP记录仍存在，BR/EDR客户端查询到服务后尝试建立连接，最终会连接失败，影响用户体验。
五、测试
问题：BASS规范中定义SDP互操作性要求的核心设计初衷是什么？LE与BR/EDR在BASS服务发现层的核心差异是什么？
答案：
-
核心设计初衷：一是实现BASS服务的跨制式发现，让BR/EDR设备能通过SDP查询找到BASS服务；二是统一BR/EDR下的服务访问路径，保证不同厂商设备的互联互通性；
-
核心差异：LE下BASS的服务发现依托GATT实现，通过GATT服务/特征声明暴露标识；BR/EDR下无原生GATT服务发现能力，核心依赖SDP协议，需通过标准化SDP记录完成服务标识与访问路径的暴露。
问题：BASS的标准化SDP记录包含哪些必选属性？各属性的核心作用和取值要求是什么？
答案：
-
必选属性包含三项：Service Class ID List、Protocol Descriptor List、BrowseGroupList；
-
各属性要求：
①Service Class ID List：核心作用是唯一标识BASS服务，必须包含BASS的标准Service Class UUID；
②Protocol Descriptor List：核心作用是定义BR/EDR下访问BASS的协议路径，必须为L2CAP+ATT的组合，L2CAP的PSM设为ATT标准值；
③BrowseGroupList：核心作用是定义公共浏览分类，提升服务可发现性，必须包含PublicBrowseRoot。
问题：BASS SDP记录中Additional Protocol Descriptor List的实现要求是什么？其核心设计逻辑是什么？
答案：
-
实现要求：该属性为条件必选（C.1），若设备支持EATT则必须实现，若不支持则直接排除；实现时为L2CAP+EATT的组合，L2CAP的PSM设为EATT标准值；
-
核心设计逻辑：一是为BR/EDR下的BASS交互提供增强型传输能力，EATT相比原生ATT提升了传输的可靠性与吞吐量，适合长数据传输场景；二是保证向下兼容，支持EATT的设备同时暴露ATT和EATT两条路径，客户端可根据自身能力选择，不影响基础兼容。