FTS抓包看AVDTP

1.概述

  测试过程为打开Audio连接，没有听音乐，人后断开Audio连接，主要目的是为了测试AVDTP的工作流程。

 

2.Frame分析

   首先贴出抓取的关于AVDTP的包：

在L2CAP层，分别由Maste和Slave建立了两条关于AVDTP的L2CAP连接，并完成了configure的过程，如下：

我们可以看到AVDTP的主要Signaling的过程：

1.DISCOVER 2.GET_CAPABILITIES 3.SET_CONFIGURATION 4.OPEN 5.START

 

下面分析一下具体的内容：

Frame62：Master->AVDTP_DISCOVER

00000001 00000000  00000001

前面的是HCI和L2CAP的封装，这里也顺带看一下吧。

首先是HCI的：

Connection Handle:00000001 00000000 = 0x01 = 1

Broadcast Flag: No broadcast, point-to-point

Packet Boundary Flag: First non-automatically-flushable L2CAP packet

Total Length: 0x06 = 6

 

L2CAP部分：

PDU Length: 0x02 = 2

Channel ID: 0x0042  //注意：这个ID是远端Slave的CID

 

AVDTP部分：

Transaction Label: 0

Packet Type: Single Packet

Message Type: Command

Signaling Identifier: AVDTP_DISCOVER

注：这就是一个Master发出的Discover command

 

Frame65：Slave->AVDTP_DISCOVER RESPONSE

00000001 00100000 00001000 00000000 00000100 00000000 01000000 00000000 00000010 0000000100000100 00000000

HCI和L2CAP简单看下，主要看AVDTP分部分：

Packet Boundary Flag: First automatically-flushable L2CAP packet

Channel ID: 0x0040  //注意：这个ID是本地Master的CID

Message Type: Response Accept

Signaling Identifier: AVDTP_DISCOVER

ACP Stream Endpoint ID: 1

In-use: No

TSEP: SRC

Media Type: Audio  //由bluetooth分配的bumber

注：具体的resposne结构可以参考AVDTP的Spec。这个主要是远端的Slave响应本地的AVDTP_DISCOVER command，本地接收的CID为0x40,发现了远端Slave的一个值为1的SEID，而且没有使用。需要指出的是，packet baoundary flag为 automatically-flushable L2CAP packet，而AVDTP_DISCOVER command中为non-automatically-flushable L2CAP packet。这是为什么呢？？？查Spec，说这个automatically-flushable会根据automatic flush timeout参数来自动刷新，还是不明白，先放着。

 

Frame66 Master->GET_CAPABILITIES

00000001 00000000 00000111 00000000 00000011 00000000 01000010 00000000 00

看AVDTP的部分：

Transaction Label: 1

Signaling Identifier: AVDTP_GET_CAPABILITIES

ACP Stream Endpoint ID: 1

注：利用DISCOVER中找到的远端SEID=1的端口发送GET_CAPABILITIES来获取对方信息。

 

这里先讲一下AVDTP的Service是如何描述的。首先分为几个Service category：

其次，Service是以以下结构来进行描述的：

即第一个字节是所属的Service category，然后是capability的length，最后是Service capability的information element。

 

Frame68：Slave->GET_CAPABILITIES RESPONSE

00000001 00100000 00010000 00000000 00001100 00000000 01000000 00000000 00010010 00000010 0000000100000000 00000111 00000110 00000000 00000000 00100001 00010101 00000010 00110101

看AVDTP的部分：

Service Category: Media Transport

Length Of Service Capability (LOSC): 0

Service Category: Media Codec

Length Of Service Capability (LOSC): 6

information element部分:参考IETF RFC3550 / RFC1889标准。这里大概的信息是SBC编码，44100采样率等。

注：这里获取的是远端SEID的Media Transport和media codec信息。

 

Frame69：Master->SET_CONFIGURATION

00000001 00000000 00010010 00000000 00001110 00000000 01000010 00000000 00100000 00000011  00000000 00000000 00100001 00010101 00000010 00110101

ACP Stream Endpoint ID: 1

INT Stream Endpoint ID: 2

Service Category: Media Transport

Length Of Service Capability (LOSC): 0

Service Category: Media Codec

Length Of Service Capability (LOSC): 6

注:主要是对远端的Slave进行configure，貌似没怎么配置，不和get-capability的一样嘛。。。

 

Frame71：Slave->SET_CONFIGURATION RESPONSE

注:远端Slave接受了configure

 

Frame72：Master->OPEN

00000001 00000000 00000111 00000000 00000011 00000000 01000010 00000000 00110000 00000110 00000100

ACP Stream Endpoint ID: 1

注:打开远端的SEID=1的端口。

 

Frame73:Slave->DISCOVER

注：远端的Slave向本地的master发送discover command。Spec上貌似没有写是否需要双向的discover，不过这样貌似也没有什么坏处不是吗

 

Frame74:Master DISCOVER RESPONSE

00000001 00000000 00001010 00000000 00000110 00000000 01000010 00000000 00000010 00000001 00000000 00001010 00001000
ACP Stream Endpoint ID: 1 

In-use: No

TSEP: SRC

ACP Stream Endpoint ID: 2
In-use: Yes 

TSEP: SNK 

注：本地的Master有两个SEID，其中SEID1未使用，可作为SRC，SEID2正在使用，可作为SNK。

 

Frame76 Slave->OPEN RESPONSE

注:对Frame72的回应，接受了本地Master的打开端口的command。

 

Frame79是远端Slave的GET_CAPABLIYY command，本地Master在Frame89回应。

 

Frame88:Master-〉START

注：本地Master开始Stream。

 

Frame92：Slave->START RESPONSE

注：远端Slave接受了START的command，做出resposne。

Frame93：Slave->SUSPEND

注：远端Slave挂起本地SEID=2的端口。

 

Frame94：Master SUSPEND RESPONSE

注：本地接受SEID=2的端口挂起。

Frame134：Master->CLOSE

注：本地UI上手动断开AVDTP连接，出发本地MASTER的CLOSE command，关闭了本地SEID=1的端口。远端Slave在Frame138接受了这个命令。

 

3.总结

  AVDTP连接的建立首先依赖于L2CAP连接的建立，它会在同一条ACL Link上建立两条L2CAP Channel，一条是用来Signaling，另一条用来进行Stream，report和recovery的传输。Signaling的主要过程为：1.DISCOVER 2.GET_CAPABILITIES 3.SET_CONFIGURATION 4.OPEN 5.START。SEID在DISCOVER的过程中发现，并且具有相应的service capability，这些capability在过程GET_CAPABILITY中发现，Service capability的描述为第一个字节是所属的Service category，然后是capability的length，最后是Service capability的information element。然后对远端的SEID进行configure，配置的结构依然为service capability结构。最后Open相应的端口并START stream，就可以进行Audio Stream的传输了。上面的例子中，Slave也对本地进行了DISCOVER和GET_CAPBILITY

的过程，但是没有configure和open，这个操作的目的还不清楚，但是至少没有社呢么坏的影响。