1.概述
2.Frame分析
我们可以看到AVDTP的主要Signaling的过程:
1.DISCOVER 2.GET_CAPABILITIES 3.SET_CONFIGURATION 4.OPEN 5.START
下面分析一下具体的内容:
Frame62:Master->AVDTP_DISCOVER
00000001 00000000 00000110 00000000 00000010
00000000 01000010 00000000 0000000000000001
00000000 01000010 00000000 0000000000000001
前面的是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
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参数来自动刷新,还是不明白,先放着。
L2CAP packet。这是为什么呢???查Spec,说这个automatically-flushable会根据automatic flush timeout参数来自动刷新,还是不明白,先放着。
Frame66 Master->GET_CAPABILITIES
00000001 00000000 00000111 00000000 00000011 00000000 01000010 00000000 00010000 0000001000000100
看AVDTP的部分:
Transaction Label: 1
Signaling Identifier: AVDTP_GET_CAPABILITIES
ACP Stream Endpoint ID: 1
注:利用DISCOVER中找到的远端SEID=1的端口发送GET_CAPABILITIES来获取对方信息。
这里先讲一下AVDTP的Service是如何描述的。首先分为几个Service category:
Frame68:Slave->GET_CAPABILITIES RESPONSE
00000001 00100000 00010000 00000000 00001100 00000000 01000000 00000000 00010010 0000001000000001 00000000 00000111 00000110 00000000
00000000 00100001 00010101 00000010 00110101
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 0000001100000100 00001000 00000001
00000000 00000111 00000110 00000000 00000000 00100001 00010101
00000010 00110101
00000000 00000111 00000110 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 0000011000000100
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 0000000100000100 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.总结
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,这个操作的目的还不清楚,但是至少没有社呢么坏的影响。