AVDTP简介（AUDIO/VIDEO DISTRIBUTION TRANSPORT PROTOCOL）
AVDTP协议指定音频或视频分发的传输协议，简称AVDTP，通过蓝牙空中传输流媒体音频或视频。音频和视频数据流需要同步的数据传输能力，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)：禁用
A/V架构：
AVDTP协议架构（Architecture ）
上图AVDTP协议部分总共分为四个功能块，信令、流管理，数据恢复和适配层，同时图中的九个数字标号，代表了九类接口功能，如下图所示：
流端点体系架构
A/V设备可以提供一个或多个流资源，这意味着源或媒体流的接收器。从概念上讲，流的终点（源或汇）连接位于设备的应用层。但是，终点是在AVDTP层中表示，用于协商和操作流。如所示图，AVDTP使用抽象流端点（SEP）的概念表示设备的资源和功能。
例如，假设设备A有2个SEP标记为u和v，其中SEP u表示视频接收器，SEP v表示音频接收器。设备B有三个SEP，标记为x、y和z，代表音频源。设备A应该与设备B中的一个音频源建立音频流连接。
设备A和设备B分别为其SEP维护本地流端点标识符（SEID，见第4.10节）。第一设备A使用AVDTP服务来发现对等设备的资源。从这个过程中，设备A学习设备B中的三个SEP的（设备B本地）SEID和媒体类型（这里：音频源）。在续集中，设备A使用另一个AVDTP服务来收集其中一个远程SEP的应用程序和传输服务能力，例如SEP z.在这个事务中，设备B通过设备B之前呈现的SEID来引用SEP z。在了解了B公开的所有功能并将其与自己的本地功能进行比较之后，设备A可以使用另一个AVDTP服务来配置流连接。注意，如何选择服务的评估和决策发生在设备A的应用层，因此在AVDTP之外。存在本地SEP v（具有自己的本地SEID），它具有匹配能力和因此可以与设备B的SEP z连接，是隐式假设的。因此，设备A的AVDTP实体不需要知道本地SEP v的能力。但是，通过启动配置过程，设备A隐式地承认它在本地SEP中具有匹配能力，并将本地SEP v（带有本地SEID）映射到远程SEP z（具有远程SEID），这样两个设备都知道各自的远程SEID，以备将来相互参考。当配置过程成功终止时，设备A和设备B中的资源都应被分配（锁定），并且设备A中的SEP v和设备B中的SEP z都不能被配置为另一个流连接，例如通过第三个设备。
注意，尽管这两个设备在概念上都有sep，但它们的关系遵循非对称的客户机-服务器模型，应用程序使用AVDTP服务来管理远程设备中的流资源。设备B向设备A公开其所有能力，但设备A不向设备B公开其能力。在随后的信令过程中，流连接应由远程设备的SEID引用。在设备A中，必须存在本地SEP（资源），并且具有足够的能力来建立可互操作的流连接。状态机属于每个流终结点，并且存在于AVDTP层中。所有对应用程序有重要意义的状态变化都应通过上部暴露出来接口。每个应用程序支持的编解码器应使用单独的流端点，但是同一个编解码器可以有多个流端点。
状态机属于每个流端点，并且存在于AVDTP层中。所有对应用程序有重要意义的状态更改都应通过上层接口公开。应用程序支持的每个编解码器应使用单独的流端点，但同一编解码器可以有多个流端点。
信令过程
一般要求
信令过程需要一对互连设备之间的ACL链路。事务在通信设备之间建立的面向连接的通道上执行，并由双向异步消息交换组成。
L2CAP信道用于信令，由L2CAP信令命令建立和释放。为L2CAP处理的AVDTP事务分配了一个特定的协议/服务多路复用器（PSM）值。
处理模型
AVDTP遵循L2CAP中定义的事务模型（请参阅蓝牙核心规范中L2CAP的第3节）。
如上图显示了一个消息序列图（MSC），以说明信令事件的正常顺序。两条外部垂直线表示INT和ACP内的AVDTP信令实体。当AVDT_Signal_Req从上层（UL）发送时，INT的AVDTP向ACP的AVDTP发送AVDTP_Signal_CMD。之后接收到AVDTP_SIGNAL_CMD，ACP的AVDTP将AVDT_SIGNAL_Ind传递到其上层（UL）。当上层处理了AVDT_信号_Ind时，AVDT_信号_Rsp被发送回AVDTP层。这会产生一个AVDTP_信号_RSP返回到INT的AVDTP。在接收到AVDTP_RSP之后，INT信号的AVDTP以AVDT_信号_Cfm的形式返回到上层。
- AVDT_Signal_Req：从上层到远程设备
- AVDT_Signal_Cfm：确认从远程设备到上层的请求
- AVDT_Signal_Ind：表示已从远程设备接收到请求上层
- AVDT_Signal_Rsp：从上层向远程设备响应。
当远程端对信令请求没有响应时，使用响应超时过期（RTX_SIG_计时器，由配置文件指定）计时器来终止信令。
流管理信令概述
显示了管理流连接的总体过程。一个或两个设备可以发起流，流由流配置过程、延迟报告过程、流建立过程和流组成启动程序。流端点发现过程在这里标记为可选，用于返回一个流端点的类型和标识符（SEID），或为多个流端点联合返回类型和标识符（SEID）溪流终点。由于在以下程序中需要SEID作为参考，因此发现程序应事先触发。然而，对于每个单独的流端点，或者例如，重复的配置尝试，不需要发现过程。
Get All Capabilities/Get Capabilities过程也是可选的，因为INT可以“猜测”ACP的功能并直接尝试流配置过程。Get All Capabilities/Get Capabilities过程可以由任何设备触发，并且不会影响流的端点状态。然而，由于在流配置之前不存在任何资源预留，因此，在对等流端点之间的关系中，触发获取所有能力/获取能力过程的设备应该已经触发了一个发现过程来检索SEID以供参考。
此外，由于流配置过程，两个设备都知道本地SEP和远程SEP的映射，并且两个设备中的对等流端点之间存在专用关系。
信号命令集
参考文献：《蓝牙协议5.0》
