主要介绍下蓝牙协议栈（bluetooth stack）传统蓝牙音频协议之 音视频分布传输协议的概念，包含AVDTP概念，AVDTP组件，AVDTP传输服务，AVDTP的属于介绍。
本专栏文章我们会以连载的方式持续更新，本专栏计划更新内容如下：
第一篇:蓝牙综合介绍 ，主要介绍蓝牙的一些概念，产生背景，发展轨迹，市面蓝牙介绍，以及蓝牙开发板介绍。
第二篇:Transport层介绍,主要介绍蓝牙协议栈跟蓝牙芯片之前的硬件传输协议,比如基于UART的H4,H5,BCSP，基于USB的H2等
第三篇:传统蓝牙controller介绍，主要介绍传统蓝牙芯片的介绍，包括射频层（RF），基带层（baseband），链路管理层（LMP）等
第四篇:传统蓝牙host介绍，主要介绍传统蓝牙的协议栈，比如HCI,L2CAP,SDP,RFCOMM,HFP,SPP,HID,AVDTP,AVCTP,A2DP,AVRCP,OBEX,PBAP,MAP等等一系列的协议吧。
第五篇：低功耗蓝牙controller介绍，主要介绍低功耗蓝牙芯片，包括物理层（PHY），链路层（LL）
第六篇：低功耗蓝牙host介绍，低功耗蓝牙协议栈的介绍，包括HCI,L2CAP,ATT,GATT,SM等
第七篇：蓝牙芯片介绍，主要介绍一些蓝牙芯片的初始化流程，基于HCI vendor command的扩展
第八篇：附录，主要介绍以上常用名词的介绍以及一些特殊流程的介绍等。
另外，开发板如下所示，对于想学习蓝牙协议栈的最好人手一套。以便更好的学习蓝牙协议栈，相信我，学完这一套视频你将拥有修改任何协议栈的能力（比如Linux下的bluez，Android下的bluedroid）。
-------------------------------------------------------------------------------------------------------------------------
CSDN学院链接（进入选择你想要学习的课程）：
蓝牙交流扣扣群：970324688
Github代码：
入手开发板：
蓝牙学习目录：
--------------------------------------------------------------------------------------------------------------------------
AVDTP（ A/V Distribution Transport Protocol）就是音视频分布传输协议，主要用于传输音频/视频数据。在整个协议栈的架构图如下：
在我们整个架构图如下：
可以看到上图架构红框内就是AVDTP协议，AVDTP的底层是L2CAP层。
AVDTP一共有以下几个组件（如下图）：
① Signalling ：命令以及命令响应交互通道
② Stream Manager：流管理组件，一共有以下几种能力：传输流，组合media封包，时间戳管理，media封包序号管理，报告丢包给上层，抖动计算
③ Recovery：封包回复组件
④ Adaptation Layer：这层提供了一下几个能力：多路复用模式，允许在一个传输通道(TCID)上多路复用多个传输会话(TSID)，使用更强劲头压缩
另外，以上图示需要功能如图片：
AVDTP一共分为几个传输服务
1）Basic Service
2）Recovery Service
3）Reporting Service
4）Adaptation Service – Multiplexing
5）Adaptation Service – Robust Header Compression
6）Transport and Signaling Channel Establishment
下面我们来针对每个服务详细讲解下
1）Basic Service
基本服务，当基本服务开启的时候只有两个组件可用（Signalling ,Stream Manager）,如图
AVDTP基本服务确保通过单个传输通道传输每个会话的媒体包。该服务提供了适当的接口，使应用程序能够流进/流出满足传输通道的最大大小要求的包单元。当通道成功配置后，此包大小限制将返回给应用程序。
2）Recovery Service
在basic service的基础上加了Recovery组件
该恢复服务使用SRC端上的一个传输会话的媒体包来生成附加的编码包;这些恢复包可以在SNK端用于重建在空气传输路径上丢失的原始媒体包。
这种服务特别适用于需要巨大带宽和重传能力有限的应用程序。与基带FEC相比，恢复服务实现了一种灵活的随需应变的错误纠正机制:应用程序根据信道条件完全控制服务操作，并可以决定只覆盖媒体流中最敏感的部分。该服务独立于基带包类型执行，可为每个活动传输会话选择。
为了有效地对抗干扰，所有恢复包都通过一个单独的传输通道传送。
3）Reporting Service
用到以上组件
打开时，报告服务向本地用户提供统计信息应用程序和到远程设备的媒体流的时间对齐
包损失。这些报告用于实现适当的媒体流同步和/或调整应用程序的错误隐藏策略。
报告服务可以配置为单向(从SNK到SRC或从SRC到SNK)，也可以配置为双向，这取决于应用程序的需求。服务接口允许应用程序调整报告的周期和激活/停用服务根据上下文。
报告服务可以使用独立的传输通道传输报表数据包到远程端。
4）Adaptation Service – Multiplexing
在多路复用模式中，属于同一种或属于某一种的多个传输会话不同的流，可以共享一个公共传输(L2CAP)通道。此外,一个L2CAP数据包可以包含属于相同或不同传输的多个数据包会话。因此，每个封装头都需要媒体/报告/恢复包。包含在这个头中的TSID允许正确SNK设备上数据包的路由。
在流配置过程中，INT分配了tsid和tcid并通知ACP。避免在多设备配置中发生冲突为了减小其宽度，将TSID和TCID的范围限制在连接上在一对设备之间。建立流程不一定打开一个新的传输(L2CAP)通道。相反，它可以将一个新的传输会话映射到现有的L2CAP信道。这是通过引用一个现有的TCID来实现的。
5）Adaptation Service – Robust Header Compression
健壮的报头压缩是一种传输服务，它可以减少这方面的开销媒体包和恢复包的头引入。这种机制是完全可由应用程序选择，但在两个设置相同的配置要建立的每个流的连接的两端。健壮的头压缩机制允许使用一个反馈通道，这是在谈判媒体流配置的时间。
6）Transport and Signaling Channel Establishment
Stream：两个点对点设备之间的流媒体数据
Source (SRC) and Sink (SNK)：SRC是音视频的发送方，SNK是音视频的接收方。
Initiator (INT) and Acceptor (ACP)：启动过程的设备作为启动者、接受启动的设备为接收者。要注意的是INT和ACP独立于上层应用定义的SRC和SNK，也就是在一个CMD跟RESPONSE中，发送CMD的是INT角色，回送RESPONSE的就是ACP角色，所以他的角色会一直在动态切换中，我个人觉得这个定义有点奇怪并且鸡肋
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)：弃用
