目录
AVDTP协议简述
首先说一下该协议需要掌握的要点：
- 弄清该协议的应用场景
- 协议中定义的两个角色INT和ACP
- 弄清什么是信道通讯及其信道通讯流程，什么是媒体流数据，并知道两类数据包的格式
AVDTP简介
AVDTP协议指定音频或视频分发的传输协议，简称AVDTP，通过蓝牙空中传输流媒体音频或视频。音频和视频数据流需要同步的数据传输能力，什么是同步数据通讯在我的HFP学习笔记中有介绍，不懂得可以去翻看！A/V分发传输协议的传输机制和消息格式，基于《RFC 3350》中定义的RTP，其中由两大协议组成:RTP数据传输协议(RTP)和RTP控制协议(服务器)。
AVDTP在整个协议栈中的结构图如下图所示：
常用术语及定义
首先对协议中常用的一些术语和定义做一个简要说明：
- Stream：两个点对点设备之间的流媒体数据
- Source (SRC) and Sink (SNK)：依赖与应用层的两种角色，音频源和接收方。这两种角色都是在A2DP定义的。
- Initiator (INT) and Acceptor (ACP)：启动过程的设备作为启动者、接受启动的设备为接收者。要注意的是INT和ACP独立于上层应用定义的SRC和SNK，并且不能对应底层L2CAP中的角色
- Application and Transport Service Capabilities：应用服务和传输服务的功能。应用服务功能比如协商、配置音源设备的codec，内容保护系统等；传输服务能力比如数据报文的分割和重组，数据包的防丢检测等等。
- Services, Service Categories, and Service Parameters：服务、服务类别、服务参数
- Media Packets, Recovery Packets, and Reporting Packets：流媒体包，数据恢复包，报告报文
- Stream End Point (SEP)：流端点，流端点是为了协商一个流而公开可用传输服务和A/V功能的应用程序
- Stream Context (SC)：流上下文。指在流设置过程中，两个对等设备达到一个公共的了解流的配置，包括选择的服务，参数，以及传输通道分配。
- Stream Handle (SH)：流句柄。在SRC和SNK建立了连接之后分配的一个独立的标识符，代表了上层对流的引用
- Stream End Point Identifier (SEID)：流端点标识，对特定设备的跨设备引用，该引用用于信令事物
- Stream End Point State：流端点状态
- Transport Session：传输会话。在A/V传输层的内部，在配对的AVDTP实体之间，流可以分解为一个、两个或多个
三个传输会话。 - Transport Session Identifier (TSID)：传输会话标识。代表对一个传输会话的引用。
- Transport Channel：传输通道。传输通道指的是对A/V传输层下层承载程序的抽象，始终对应L2CAP的通道
- Transport Channel Identifier (TCID)：传输通道标识。代表对一个传输通道的引用。
- Reserved for Future Additions（RFA）：保留给将来添加
- Reserved for Future Definitions (RFD)：保留给将来定义
- Forbidden (F)：禁用
AVDTP协议架构
下图显示AVDTP的内部架构，该体系结构包括块和接口功能，本规范涉及的范围仅为理阴影块部分：
上图AVDTP协议部分总共分为四个功能块，信令、流管理，数据恢复和适配层，同时图中的九个数字标号，代表了九类接口功能，如下图所示：
信道通讯流程
在架构图中可以看到信道通讯作为单独的一块被列出来，信道通讯提供了诸如SEP发现、对SEP能力的获取和配置、流的打开/挂起/关闭等功能（详细请看AVDTP_SPEC_V13 第6章）。下图是一个完整的信道通讯流程的通用模型，其他传输流程均与遵循此格式：
从上图可以看出，发起端发出请求（req），最终收到一个确认（cfm）；接收端收到指示（ind），回复响应（rsp）。再如实际获取capabilities通讯流程，如下图：
请求端（INT）发出一个获取流端点能力的请求，接收端（ACP）收到由底层上来的指示事件，内部处理之后给与端点能力的回复，最后INT收到确认。
信道通讯格式以及举例
-
信道消息的格式
信道消息包括l2cap头、信道头和信道消息内容三部分，如下图：
与此同时，avdtp支持信道消息的拆分与重组能力，可以将一个大的消息拆分成几段分包发送，其机制可由下图描述：
L2cap在此不做说明，不懂得去看我l2cap的学习笔记。Signal包头的格式如下图：
上图中分别显示了单一包、起始包和结束包头的数据格式。传输标签指定是属于第几次会话，pcaket type指定包的类型，如下图所示：
Message type参数指定了消息的类型，如下图：
Signal identifier在AVDTP_SPEC_V13协议的8.5节中列举，如下：
-
信道交互实现举例
信道交互流程包括：SEP发现、能力获取、流配置、流建立、流开始、流结束等等一系列的单独打交互过程，再次我们只简单举两个例子进行分析，其他都与此类似，不同的只是具体参数类容。并且其流程都遵循信道通讯流程。
1）、流端点发现
INT向ACP发送AVDTP_DISCOVER_CMD 指令，获取ACP所有的SEP的信息，数据包格式如下图：
当ACP收到该命令时对INT进行回复或者是拒绝，具体格式分别如下：
2）、流配置
当INT从ACP收到其服务能力的回复之后，可以对ACP进行配置，配置的指令为AVDTP_SET_CONFIGURATION_CMD ，具体格式为：
当ACP收到该指令之后，对INT回复ok或者是拒绝INT的配置，并回复错误码：具体格式如下：
数据传输流程
前面我们主要说明如何去建立A/V数据传输通道及其管理，本节主要介绍基于数据传输服务以及数据包的格式。
-
基础服务
AVDTP提供给上层的基本服务只提供信令和流媒体，信令上面已经说过了，下图是流媒体的数据包格式：
参数比较多，我就不一一说了，详细介绍请参考AVDTP_SPEC_V13，第7.2.1节的表格【Table 7.1】。
-
报告服务
报告服务分为四种数据包发送者报告包（SR），接收者报告包（RR），源描述包（SDES），报告反馈包（针对SR和RR）,下面举例发送者报告包（SR）的数据格式：
参数详细介绍以及RR包和SDES数据包的格式请参考AVDTP_SPEC_V13的7.3节。
-
恢复服务
在AVDTP_SPEC_V13没有详细介绍数据格式，其格式都是根据《RFC 2733》第8章，我收集的资料中有这份文档，一并放在了博客<蓝牙学习笔记（序）>的网盘链接中，有兴趣可以去了解一下。
-
混合服务
混合服务是指媒体数据包和恢复数据包会穿插使用，具体的场景如下图所示
关于AL header的描述请参考AVDTP_SPEC_V13的7.5节的表格【Table 7.4】。
AVDTP协议数据分析
下面我们将对avdtp完整的一次建立过程进行数据分析。
以下蓝色为hci部分、绿色为l2cap部分、红色为avdtp部分，这里我只针对avdtp进行解析
1）、Master：查询ACP的端点信息
00000010 00000010 00100000 00000110 00000000 00000010 00000000 01000001 00000001 00000000 00000001
Transaction labal：0000（传输标签，由INT指定）
Packet type：00（单独数据包）
Message type：00（command）
--------------------------------------------
RFA：00（无效数据位，保留给将来使用）
Signal identifier：000001（AVDTP_DISCOVER）
2）、Slave：回复INT有id=1,2,3的三个端点
00000010 00000010 00100000 00001100 00000000 00001000 00000000 01000101 00000000 00000010 00000001 00000100 00001000 00001100 00001000 00001000 00001000
Transaction labal：0000（传输标签，由INT指定）
Packet type：00（单独数据包）
Message type：10（response accept）
--------------------------------------------
RFA：00（无效数据位，保留给将来使用）
Signal identifier：000001（AVDTP_DISCOVER）
--------------------------------------------
First ACP SEID：000001（第一个流端点的id，只有0x01-0x3e为有效值）
In use：0（未使用）
RFA：0（无效数据位，保留给将来使用）
Media type：0000
TSEP：1（SEP属于src还是snk，为零属于src）
RFA：000
--------------------------------------------
ACP SEID：000011（流端点id=3）
In use：0（未使用）
RFA：0（无效数据位，保留给将来使用）
Media type：0000
TSEP：1（SEP属于src还是snk，为零属于src）
RFA：000
--------------------------------------------
ACP SEID：000010（流端点id=2）
In use：0（未使用）
RFA：0（无效数据位，保留给将来使用）
Media type：0000
TSEP：1（SEP属于src还是snk，为零属于src）
RFA：000
3）、Master：查询端点id=1的端点的信息
00000010 00000010 00100000 00000111 00000000 00000011 00000000 01000001 00000001 00010000 00000010 00000100
Transaction labal：0001（传输标签，由INT指定）
Packet type：00（单独数据包）
Message type：00（command）
--------------------------------------------
RFA：00（无效数据位，保留给将来使用）
Signal identifier：000010（AVDTP_GET_CAPABILITIES）
ACP SEID：000001（由上面可知为第一个端点的id）
RFA：00
4）、Slave：给INT回复端点id=1的端点的信息
00000010 00000010 00100000 00010100 00000000 00010000 00000000 01000101 00000000 00010010 00000010 00000001 00000000 00000111 00000110 00000000 00000000 11111111 11111111 00000010 00110101 00000100 00000010 00000010 00000000
Transaction labal：0001（传输标签，由INT指定）
Packet type：00（单独数据包）
Message type：10（response accept）
--------------------------------------------
RFA：00（无效数据位，保留给将来使用）
Signal identifier：000010（AVDTP_GET_CAPABILITIES）
--------------------------------------------
Service Category：00000001（media transport）
Length Of Service Capability：00000000
--------------------------------------------
Service Category：00000111 （media codec）
Length Of Service Capability：00000110 （能力描述长度为6个字节）
Media type：0000
RFA：0000
Media codec type：00000000
Media Codec Specific Information Elements：11111111 11111111 00000010 00110101
--------------------------------------------
Service Category：00000100 （Content Protection）
Length Of Service Capability：00000010（能力描述长度为2个字节）
CP_TYPE_LSB：00000010
CP_TYPE_MSB：00000000
上面我只举了四个协议交互例子进行分析，具体的协议的log以及数据分析，以及相关资料，请到我的博客<蓝牙学习笔记（序）>最下面的网盘链接中下载！