【AVRCP】服务发现互操作性：CT 与 TG 的 SDP 协议契约解析

目录

一、服务发现的核心目标：能力画像对齐

二、控制器（CT）服务记录：控制能力的声明

2.1 必选字段：角色与协议的刚性契约

2.1.1 服务类标识（Service Class ID List）

2.1.2 协议描述列表（Protocol Descriptor List）

2.1.3 蓝牙配置文件描述（Bluetooth Profile Descriptor List）

2.1.4 支持的功能特性（Supported Features）

2.2 条件字段：浏览支持的开关（C1 条件）

2.2.1 附加协议描述列表（Additional Protocol Descriptor List）

2.2.2 配置逻辑

2.3 可选字段：设备标识与厂商信息

2.4 版本兼容性：1.4 vs 1.6 的契约差异

2.5 关键实现规则

2.6 示例：CT服务记录配置

2.7 开发者注意事项

三、目标端（TG）服务记录解析

3.1 必选字段（Mandatory, M）

3.1.1 服务类标识（Service Class ID List）

3.1.2 协议描述列表（Protocol Descriptor List）

3.1.3 蓝牙配置文件描述（Bluetooth Profile Descriptor List）

3.1.4 支持的功能特性（Supported Features）

3.2 条件必选字段（Conditional, C1/C2）

3.2.1 附加协议描述列表（Additional Protocol Descriptor List, C1）

3.2.2 Cover Art协议栈（Protocol Descriptor List #1, C2）

3.3 可选字段（Optional, O）

3.4 关键实现规则

3.5 TG与CT服务记录对比

3.6 示例：TG服务记录配置

3.7 开发者注意事项

四、实际应用场景示例

五、总结

六、参考资料

在蓝牙音视频远程控制协议（AVRCP）中，服务发现（Service Discovery Protocol, SDP）是设备间建立通信的关键环节。通过SDP，控制器（Controller, CT）与目标设备（Target, TG）能够交换服务能力信息，确保功能兼容性。本文基于AVRCP规范中的服务记录表（Table 8.1与Table 8.2），深入解析CT与TG的服务发现机制，并探讨其互操作性设计逻辑。

一、服务发现的核心目标：能力画像对齐

AVRCP 的 SDP 记录本质是设备的「数字名片」，CT 通过它回答「我能控制什么」，TG 回答「我支持什么」。服务记录通过属性-值对定义，核心字段包括：

• 服务类（Service Class ID）：声明角色（CT 为 Controller，TG 为 Target）

• 协议栈（Protocol Descriptor）：指定 AVCTP 通道（控制 / 浏览）的 L2CAP PSM

• 功能标志（Supported Features）：枚举支持的 AVRCP 特性（如浏览、封面艺术）

二、控制器（CT）服务记录：控制能力的声明

CT（控制端，如手机、遥控器）通过 SDP 服务记录声明 「我能控制什么样的 TG」，而非自身功能。

核心目标：告知 TG「我的控制协议版本、期望的 TG 能力」，确保连接前的能力对齐。

2.1 必选字段：角色与协议的刚性契约

2.1.1 服务类标识（Service Class ID List）

• 作用：声明设备支持的服务类型。

• 必选字段：是（M）。

• 结构：

  • Service Class #0：UUID = A/V Remote Control 兼容旧 TG（如 2016 年前的车载音响）。

  • Service Class #1：UUID = A/V Remote Control Controller 明确 CT 角色，新 TG 优先识别。

开发红线：

• 必须同时声明新旧服务类，缺一将导致部分 TG 无法识别（如仅支持旧类的车载无法连接新 CT）。

• AVCTP 版本必须为 0x0104（当前唯一标准化版本），否则 TG 可能拒绝连接。

2.1.2 协议描述列表（Protocol Descriptor List）

定义设备通信所需的协议栈层级，包含L2CAP、AVCTP等协议参数。

• 必选字段：是（M）。

• 协议层级：

  • L2CAP层：

    1. UUID = L2CAP 基础传输协议。

    2. 参数 #0：PSM = AVCTP（Uint16类型），PSM（Protocol/Service Multiplexer）：标识逻辑通道类型。 指定逻辑通道用于AVCTP控制命令传输。

  • AVCTP层：

    1. UUID = AVCTP 音视频控制传输协议。

    2. 参数 #0：Version = 0x0104（Uint16类型） 对应AVCTP 1.4版本。

2.1.3 蓝牙配置文件描述（Bluetooth Profile Descriptor List）

• 必选字段：是（M）。

• 结构：

  • Profile #0：UUID = A/V Remote Control 标识遵循AVRCP规范。

  • 参数 #0：Version = 0x0106（Uint16类型） 对应AVRCP 1.6版本。

2.1.4 支持的功能特性（Supported Features）

• 必选字段：是（M）。

• 类型：16位无符号整数（Uint16），通过位标志声明功能。

• 位定义：

• 保留位：Bit4-5、Bit10-15标记为RFA（Reserved for Future Addition），必须置0。

2.2 条件字段：浏览支持的开关（C1 条件）

2.2.1 附加协议描述列表（Additional Protocol Descriptor List）

• 条件必选字段：当Supported Features的Bit6（支持浏览）设为1时必选（C1）。

• 协议层级：

  • L2CAP层：

    1. UUID = L2CAP

    2. 参数 #0：PSM = AVCTP_Browsing 专用通道用于媒体文件系统浏览。

  • AVCTP层：

    1. UUID = AVCTP

    2. 参数 #0：Version = 0x0104 保持与主通道版本一致。

2.2.2 配置逻辑

if (SupportedFeatures.Bit6 == 1) {
  必须包含浏览通道协议描述符；
  else 禁止包含；
}

错误案例：某手机声明 Bit6=1 但未配置浏览通道，导致车载 TG 无法响应 Browse 命令。

互操作性设计：通过分层协议描述，设备可动态协商多通道共存，满足不同场景需求（如控制命令与媒体浏览分离）。

2.3 可选字段：设备标识与厂商信息

最佳实践：

• Provider Name（显示名称）：建议与设备蓝牙名称一致，避免用户混淆。

• Service Name（服务名称）：字符串类型，可体现角色（如「AV Remote Controller」），增强可读性。

2.4 版本兼容性：1.4 vs 1.6 的契约差异

开发建议：CT 统一声明 0x0106（1.6 版），向下兼容旧 TG（仅忽略新增位）。

2.5 关键实现规则

• 功能依赖关系：

  • 若声明支持浏览功能（Bit6=1），必须包含Additional Protocol Descriptor List（C1）。

  • Cover Art功能（Bit7-9）需依赖动态分配的OBEX通道（C2）。

• 分类控制逻辑：

  • Supported Features中声明的Category（Bit0-3）表示CT希望控制的TG能力范围，不要求CT自身支持所有强制命令。 例如：CT声明支持Category 2（音量控制），但实际可能仅支持静音功能。

2.6 示例：CT服务记录配置

Service Record:
- Service Class ID List:
  - UUID 0x110E (A/V Remote Control)
  - UUID 0x110C (A/V Remote Control Controller)
- Protocol Descriptor List:
  - L2CAP(PSM=AVCTP)
  - AVCTP(Version=1.4)
- Additional Protocol Descriptor List (if Bit6=1):
  - L2CAP(PSM=AVCTP_Browsing)
  - AVCTP(Version=1.4)
- Profile Descriptor List:
  - AVRCP v1.6
- Supported Features: 0x0141 (二进制 0000 0101 0000 0001)
  - Bit0=1（Category1）
  - Bit6=1（支持浏览）
  - Bit8=1（支持Cover Art图像获取）
- Provider Name: "AudioTech"
- Service Name: "Smart Controller"

Air log报文示例：

2.7 开发者注意事项

• 位标志校验：实现时需检查功能依赖（如Bit6与C1的关联性）。

• 动态通道分配：Cover Art需动态分配L2CAP PSM，避免端口冲突。

• 兼容性测试：确保与不同TG设备的Category声明兼容，即使CT未完全实现相关命令。

三、目标端（TG）服务记录解析

在AVRCP里，目标端（TG）服务记录是设备展示自身能力的关键。通过这些记录，控制端（CT）能了解 TG 所支持的功能和协议，从而建立有效的通信。

TG服务记录同样遵循SDP规范，但角色定位与功能声明与CT存在显著差异。

3.1 必选字段（Mandatory, M）

所有TG设备必须包含以下字段，无论功能支持情况如何。

3.1.1 服务类标识（Service Class ID List）

• 作用：明确设备为被控端（Target）角色。

• 必选字段：是（M）。

• 结构：

  • Service Class #0：UUID = A/V Remote Control Target 标识设备为TG角色，区别于CT的Controller标识。

3.1.2 协议描述列表（Protocol Descriptor List）

定义TG通信的协议栈，基础结构与CT一致，但附加通道存在差异：

• 必选字段：是（M）。

• 基础协议层级：

  • L2CAP层：PSM=AVCTP（同CT）。

  • AVCTP层：Version=0x0104（AVCTP 1.4，与CT一致）。

3.1.3 蓝牙配置文件描述（Bluetooth Profile Descriptor List）

• 必选字段：是（M）。

• 结构：

  • Profile #0：UUID = A/V Remote Control（同CT）。

  • 参数 #0：Version = 0x0106（AVRCP 1.6，与CT一致）。

3.1.4 支持的功能特性（Supported Features）

• 必选字段：是（M）。

通过16位标志位（Uint16）声明功能，按支持情况分类如下：

①基础控制分类（Category）

②高级功能（功能位，对比CT）：

• 关键规则：

  • Bit6（浏览支持）：仅当TG实际支持"媒体播放器虚拟文件系统"浏览时置1，与Category无关。

  • Bit4-5：若设置，必须同时设置Bit0（Category1支持），确保基础控制能力。

③保留位（RFA）

• Bit9-15：保留位，必须置0。

3.2 条件必选字段（Conditional, C1/C2）

根据设备支持的功能，动态包含以下字段。

3.2.1 附加协议描述列表（Additional Protocol Descriptor List, C1）

• 触发条件：

  • 支持 Category 1（播放控制） 或 Category 3（设备信息查询），或

  • Supported Features中 Bit6（支持浏览） 置1。

• 协议层级：

  • Protocol #0 (L2CAP层): PSM = AVCTP_Browsing（浏览专用通道）。

  • Protocol #1 (AVCTP层): Version = 0x0104（AVCTP 1.4）。

3.2.2 Cover Art协议栈（Protocol Descriptor List #1, C2）

• 触发条件：Supported Features中 Bit8（支持Cover Art） 置1。

• 协议层级：

  • Protocol #0 (L2CAP层): 动态分配PSM（用于Cover Art数据传输）。

  • Protocol #1 (OBEX层): UUID = OBEX（图像传输协议）。

3.3 可选字段（Optional, O）

可选择性包含的字段，不影响核心功能：

• Provider Name：设备制造商名称（字符串类型）。

• Service Name：自定义服务名称（字符串类型）。

3.4 关键实现规则

• 功能完整性要求：TG必须实现声明Category的所有强制命令。 例如：若声明支持Category2（音量控制），必须实现全部相关强制指令（如SetVolume）。

• 条件性协议栈：

  • C1：当TG支持Category1或3，或声明Bit6=1时，必须包含浏览通道协议描述。

  • C2：若支持Cover Art（Bit8=1），需动态分配PSM并声明OBEX协议栈。

• Cover Art实现差异：TG使用OBEX协议传输图像数据，而CT通过AVCTP获取元数据（如GetImageProperties）。 体现TG作为数据源的主动传输角色。

3.5 TG与CT服务记录对比

3.6 示例：TG服务记录配置

Service Record:
- Service Class ID List:
  - UUID 0x110C (A/V Remote Control Target)
- Protocol Descriptor List:
  - L2CAP(PSM=AVCTP)
  - AVCTP(Version=1.4)
- Additional Protocol Descriptor List (C1触发):
  - L2CAP(PSM=AVCTP_Browsing)
  - AVCTP(Version=1.4)
- Protocol Descriptor List #1 (C2触发):
  - L2CAP(PSM=0x1001)  // 动态分配
  - OBEX
- Profile Descriptor List:
  - AVRCP v1.6
- Supported Features: 0x01C1 (二进制 0000 0111 0000 0001)
  - Bit0=1（Category1）
  - Bit6=1（支持浏览）
  - Bit7=1（支持多播放器）
  - Bit8=1（支持Cover Art）
- Provider Name: "MediaPlayer Corp"
- Service Name: "Car Audio System"

Air log报文示例：

3.7 开发者注意事项

• 严格功能实现：TG必须完整实现声明Category的所有强制命令，否则会导致控制失败。

• 动态PSM管理：Cover Art通道的PSM需动态分配并确保唯一性，防止端口冲突。

• OBEX协议集成：需实现OBEX协议栈以支持Cover Art图像传输，包括连接建立、数据分片等逻辑。

• 虚拟文件系统要求：浏览功能（Bit6=1）需实现"Media Player Virtual Filesystem"结构，如文件夹层级、文件属性等。

• 依赖关系校验：

  • Bit4和Bit5需检查Bit0是否已置1。

  • C1触发需同时检查Category支持和Bit6状态。

四、实际应用场景示例

手机（CT）与车载音响（TG）的连接

1. 服务发现阶段：手机通过SDP查询车载音响的服务记录，确认其支持AVRCP 1.6、Category 1（播放控制）及Cover Art。

2. 协议通道建立：

   1. 默认通道（PSM=AVCTP）用于传输播放/暂停指令。

   2. 动态分配Cover Art通道，通过OBEX获取专辑封面。

3. 功能交互：若车载音响支持浏览（Bit6=1），手机可进一步访问其媒体库。

五、总结

AVRCP的服务发现机制通过标准化的服务记录表，实现了设备角色（CT/TG）、协议版本、功能特性的透明协商。其设计充分考虑了扩展性（如位掩码定义功能）与兼容性（版本号控制），为蓝牙音视频设备的互操作性提供了坚实基础。开发者需深入理解服务记录的字段含义及条件约束，以确保设备在复杂场景下的可靠交互。

六、参考资料

Advanced Audio Distribution Profile, Version 1.4 or later

Assigned Numbers | Bluetooth® Technology Website