深入解析A2DP音频流建立：从SDP发现到AVDTP配置的完整流程

1. 引言：为什么你需要看懂btsnoop日志里的A2DP握手？

如果你正在开发蓝牙音频产品，比如无线耳机、音箱，或者在做手机蓝牙模块的调试，那你肯定遇到过音频连接不稳定、音质差或者连接失败的问题。这时候，光看应用层的日志往往一头雾水，真正的“案发现场”其实在底层协议交互的btsnoop日志里。

btsnoop日志就像是蓝牙协议栈的“黑匣子”，它忠实记录了从蓝牙芯片（Controller）到主机协议栈（Host）之间所有的原始数据包。而A2DP（高级音频分发协议）的建立过程，就是这个黑匣子里最精彩的一段“连续剧”。它不像点一下播放按钮那么简单，背后是一系列精密的协议握手：设备之间要先互相“摸底”（SDP），建立可靠的“对话通道”（L2CAP），然后为音频流“谈判”编码格式和参数（AVDTP），最后才把音乐数据流送过去。

我处理过不少棘手的蓝牙音频案例，比如耳机只能接电话不能听歌，或者连接特定手机时音质自动降级。最后都是靠深入分析btsnoop日志，定位到是SDP信息不全、AVDTP配置错误还是L2CAP通道参数不对，才把问题解决。这篇文章，我就带你化身“协议侦探”，手把手教你解读btsnoop日志，把A2DP从搜索服务到播放音乐的完整流程，特别是关键的SDP发现和AVDTP配置，彻底搞明白。

2. 必备背景：A2DP架构与核心协议三巨头

在深入日志之前，我们得先快速统一“语言”。A2DP不是一个孤立的协议，而是一个建立在好几层协议之上的“应用场景”。你可以把它想象成一座房子：

• 地基（L2CAP）：逻辑链路控制与适配协议。它负责在上层应用和底层蓝牙射频之间，建立和管理一条条可靠的“数据通道”。就像家里的水管和电线管道，A2DP的音频流和控制信令都需要自己的“管道”。
• 寻址簿（SDP）：服务发现协议。两个蓝牙设备初次见面，怎么知道对方能干什么？SDP就是用来查询和宣告自身能力的。比如，手机会问耳机：“嘿，你支持A2DP音频接收吗？支持哪些编码格式？” 耳机通过SDP回答。这是整个A2DP连接的起点。
• 施工队（AVDTP）：音频/视频分发传输协议。这是A2DP的“直系下属”，专门负责音频流的建立、配置和传输。AVDTP自己又分为两个部分：
  • 信号通道：用于“谈判”，比如发现对方有哪些音频端点、协商用哪种编码（SBC、AAC还是aptX）、设置参数（采样率、码率）。
  • 媒体通道：谈判成功后，真正传输音频数据包的“高速公路”。

角色定义也很重要：

• Source（SRC）：音频源，通常是手机、电脑等播放设备。
• Sink（SNK）：音频接收端，通常是耳机、音箱。

在btsnoop日志中，我们看到的绝大部分交互，都是AVDTP协议在L2CAP建立的通道上，按照严格的命令/响应模式进行的。

3. 第一阶段：SDP服务发现——设备间的“能力摸底”

连接建立后，在播放音乐之前，双方必须先通过SDP搞清楚对方到底能干什么。这个过程在日志里非常活跃。

3.1 SDP交互流程详解

SDP采用客户端/服务器模型。发起查询的一方是客户端（通常是手机，即Source），响应的一方是服务器（耳机，即Sink）。一个完整的SDP查询流程在日志中是这样的：

1. L2CAP通道建立：首先，手机会为SDP协议建立一个专用的L2CAP通道。在日志中，你会看到类似下面的Connection Request，其中PSM（协议/服务多路复用器）字段的值为0x0001，这正是SDP的专属“门牌号”。

   Bluetooth L2CAP Protocol
       Length: 8
       CID: L2CAP Signaling Channel (0x0001)
       Command: Connection Request (0x02)
       PSM: SDP (0x0001)  # 关键！指明为SDP建立通道
       Source CID: 0x0040 # 手机端分配的临时通道ID
   

   对方设备会回复一个Connection Response，如果成功，其中的Result字段会是Successful (0x0000)。

2. SDP查询交易：通道建好后，真正的查询开始。最重要的查询PDU（协议数据单元）是SDP_ServiceSearchAttributeRequest。这个请求非常强大，它的意思是：“请查找所有符合我给出的特征的服务，并且把它们的属性都返回给我。”

   在A2DP场景下，手机（Source）最关心的是对方是否支持A2DP Sink角色。因此，它会在请求中携带一个服务搜索模式（Service Search Pattern），这个模式里包含了一个或多个UUID。对于A2DP Sink，其服务Class UUID是 0x110B（Audio Sink）。在日志的请求包中，你能在参数部分找到这个UUID的踪迹。

3. SDP响应与Continuation机制：耳机的响应包SDP_ServiceSearchAttributeResponse里包含了丰富的属性列表。一个服务的属性可能很多（比如服务名、提供商、支持的协议描述符列表等），如果数据量超过单次传输的能力（受L2CAP MTU限制），SDP会使用Continuation State机制分包。 在日志里，你可能会看到多个连续的SDP响应包。第一个包的Continuation State字段非零，表示还有后续数据。手机会在下一个请求中带回这个状态值，直到最后一个响应包的Continuation State为0，表示传输结束。这是分析时容易混淆的地方，需要把多个包的数据拼接起来才能得到完整的服务记录。

3.2 关键信息提取：从SDP响应中看什么？

从SDP响应中，我们主要提取两个对A2DP至关重要的信息：

1. 协议描述符列表（Protocol Descriptor List）：这个属性描述了访问该服务（A2DP Sink）需要经过的协议栈。对于A2DP，它通常会显示为 L2CAP -> AVDTP。这告诉手机：“要想用我的音频接收服务，你需要先建立L2CAP通道，然后在上面跑AVDTP协议。” 更重要的是，它会给出AVDTP信号通道所使用的PSM值，通常是 0x0019。这是后续建立AVDTP连接的钥匙。

   Attribute: Protocol Descriptor List
       Data Element Sequence
           Data Element Sequence
               UUID: L2CAP (0x0100)
               Unsigned Integer: 0x0019  # AVDTP的PSM
           Data Element Sequence
               UUID: AVDTP (0x0019)
               Unsigned Integer: 0x0100  # AVDTP版本
   

2. 服务Class ID列表（Service Class ID List）：这里会明确列出 UUID: Audio Sink (0x110B)，确认了该服务是A2DP接收端。

实战踩坑：我曾遇到一个音箱，手机连上后只能免提通话（HFP），却无法播放音乐。查btsnoop日志发现，手机的SDP请求正常，但音箱的SDP响应里根本没有包含A2DP Sink的服务记录。问题根源是音箱的SDP数据库配置不全，漏掉了A2DP服务声明。手机自然就“不知道”这个音箱能听歌，A2DP连接流程也就无从发起。

4. 第二阶段：L2CAP通道建立——铺设两条“专用管道”

SDP成功后，手机知道了对方是A2DP Sink，并且知道了AVDTP的PSM。接下来，就要为AVDTP建立专用的L2CAP通道。这里有个关键点：AVDTP需要两条独立的L2CAP通道。

4.1 信号通道建立

第一条建立的是AVDTP信号通道，用于传输配置、控制命令。这个过程和建立SDP通道非常相似。

在日志中，你会看到手机发起一个新的L2CAP Connection Request，这次PSM字段的值变成了0x0019（即从SDP中获取的AVDTP PSM）。

Bluetooth L2CAP Protocol
    Command: Connection Request (0x02)
    PSM: AVDTP (0x0019)      # 关键！指明为AVDTP建立通道
    Source CID: 0x0045       # 手机为信号通道分配的新CID

耳机回复Connection Response，并分配自己的Destination CID（例如0x004B）。至此，CID 0x0045（手机端）和 0x004B（耳机端）之间就形成了一条可靠的信号通道。后续所有的AVDTP命令（DISCOVER, SET_CONFIG等）都在这条通道上传输。

4.2 媒体通道建立

第二条通道是AVDTP媒体通道，用于传输编码后的音频数据流。这条通道的建立时机比较特殊，它是在AVDTP信号协商的后期，具体是在AVDTP_OPEN命令成功之后才建立的。

在日志里，当你看到AVDTP_OPEN的响应成功后，紧接着就会出现第二个L2CAP Connection Request，它的PSM同样是0x0019，但会分配一个全新的Source CID（例如0x0060）。这意味着在同一条物理蓝牙链路上，为同一个AVDTP协议建立了第二个逻辑通道。这条通道的CID将专门用于传输负载很大的音频数据包。

为什么分两条通道？ 这是为了服务质量（QoS）隔离。控制信令要求绝对可靠、不能丢失，但可以容忍一些延迟。而音频数据流要求低延迟、连续，允许在拥塞时丢弃少量数据包（取决于编码）。分开处理可以避免音频大数据堵塞控制命令，也让协议栈更容易管理优先级。

5. 第三阶段：AVDTP信号交互——音频流的“建设谈判”

这是A2DP建立过程最核心、步骤最多的部分，全部发生在刚刚建好的AVDTP信号通道上。整个过程像一场精心安排的谈判。

5.1 DISCOVER：发现对方有哪些“施工队”

手机（INT， Initiator）首先发送AVDTP_DISCOVER命令。这个命令很简单，就是问耳机（ACP， Acceptor）：“你有几个音频流端点（SEP）可以用的？” 每个SEP代表一种音频处理能力。

耳机的响应中会列出所有SEP，每个SEP用SEID标识，并附带基本信息：媒体类型（肯定是Audio）、端点类型（Sink）、是否正在使用。通常，一个简单的耳机只有一个A2DP Sink SEP，SEID为 0x01。

5.2 GET_CAPABILITIES / GET_ALL_CAPABILITIES：评估“施工队”的资质

知道有哪些SEP后，手机需要详细了解每个SEP的具体能力。它会对感兴趣的SEID（比如0x01）发送AVDTP_GET_ALL_CAPABILITIES命令。

耳机的响应是重中之重，它包含了该SEP支持的所有媒体传输和编解码能力。我们主要关注Media Codec部分：

Service: Media Codec - SBC
    Service Category: Media Codec (0x07)
    Media Type: Audio (0x0)
    Media Codec Type: SBC (0x00) # 编码格式
    # 以下是SBC编码的具体参数
    Sampling Frequency: 44100 Hz (1), 48000 Hz (1) # 支持的采样率
    Channel Mode: Mono (1), Dual Channel (1), Stereo (1), Joint Stereo (1) # 声道模式
    ... # 还有块长度、子带数、分配方法、码率池范围等

可能还会看到支持其他编码，比如AAC (MPEG-2,4 AAC (0x02))。这些参数决定了后续音频流的质量和兼容性。

5.3 SET_CONFIGURATION：敲定“施工图纸”

手机在拿到所有能力列表后，会根据自身的支持和优先级（比如优先选择音质更好的AAC），选择一组特定的参数，然后通过AVDTP_SET_CONFIGURATION命令发送给耳机。

这个命令包含了之前选择的SEID，以及一个具体的服务能力列表。例如，它可能选择Media Transport服务和Media Codec服务，并在Codec中指定使用SBC编码、44100Hz采样率、Joint Stereo声道模式、以及一个特定的Bitpool值（影响码率和音质）。

这一步是兼容性问题的高发区。如果手机选择的参数不在耳机之前声明的能力范围内，耳机会回复AVDTP_BAD_ACPT等错误码，导致配置失败。我在实际项目中就遇到过，手机端代码错误地配置了一个耳机不支持的Bitpool值，导致音频流始终无法打开。

5.4 OPEN、START与媒体通道建立：开工并输送“原料”

配置成功后，手机发送AVDTP_OPEN命令。这个命令的目的是将之前配置好的SEP（音频流端点）从“就绪”状态切换到“打开”状态，并触发建立之前提到的第二条L2CAP媒体通道。

AVDTP_OPEN成功后，日志里立即会出现建立第二个PSM为0x0019的L2CAP连接的流程。这条媒体通道建立好后，手机就可以发送AVDTP_START命令。耳机响应成功后，真正的音频数据包（AVDTP Media Packet）就开始通过媒体通道源源不断地从手机流向耳机了。

至此，一个完整的A2DP音频流建立流程全部完成。你可以看到，从SDP发现到音频播放，是一个环环相扣、层层递进的协议握手过程。任何一个环节的失败或参数不匹配，都会导致连接中止或功能异常。

6. 实战演练：对照btsnoop日志分析一个真实案例

让我们把上面的知识串联起来，模拟分析一段日志。假设我们遇到的问题是：手机连接蓝牙耳机后，播放音乐无声。

1. 定位起点：在Wireshark中打开btsnoop文件，过滤 btl2cap 和 btavdtp。首先找到SDP的L2CAP连接请求（PSM=0x0001），确认SDP过程完整，并且响应中包含了Audio Sink (0x110B)服务和AVDTP PSM (0x0019)。（检查通过）

2. 检查AVDTP信号通道：查找PSM为0x0019的第一个L2CAP连接请求和响应，确认信号通道建立成功。（检查通过）

3. 追踪AVDTP信号交互：在信号通道上，按顺序查找：

   • DISCOVER命令/响应：确认耳机报告了SEP。
   • GET_ALL_CAPABILITIES命令/响应：这里发现异常！ 耳机的响应中，Media Codec部分只列出了SBC编码，但其Sampling Frequency字段只标记了48000 Hz (1)，而44100 Hz (0)未支持。
   • SET_CONFIGURATION命令：查看手机发出的配置。发现关键问题！ 手机的配置命令中，在SBC编码的详细参数里，选择了Sampling Frequency: 44100 Hz (1)。

4. 分析结论：问题根源在于参数不匹配。耳机明确表示只支持48kHz的SBC，但手机却试图用44.1kHz去配置。这很可能导致耳机在SET_CONFIGURATION的响应中回复了拒绝（如NOT_SUPPORTED_CONFIG），或者虽然接受了配置，但在后续处理音频数据时无法正确解码，导致无声。解决方案是修改手机端的配置逻辑，在协商时选择双方都支持的参数（本例中即48kHz）。

通过这样一步步地跟随协议流程、核对关键字段，再复杂的问题也能被定位和分解。掌握这套分析方法，你就能真正读懂btsnoop日志，从协议层面洞悉蓝牙音频连接的每一个细节。