1. AVDTP概念

        AVDTP即 AUDIO/VIDEO DISTRIBUTION TRANSPORT PROTOCOL（音视频分配传输协议），主要负责 A/V stream的协商、建立及传输程序，还指定了设备之前传输A/V stream的消息格式.

        AVDTP的传输机制和消息格式是以 RTP为基础的。RTP由 RTP Data Transfer Protocol (RTP)和 RTP Control Protocol(RTCP)组成。AVDTP是在 L2CAP上传输的。AVDTP有专门的 PSM（0x19）值。

AVDTP和蓝牙协议栈的结构图：

        A/V stream和 A/V signaling都在 L2CAP上传输。Signaling负责 stream的发现、配置、建立和传输控制。

        我们来扩展下整个协议栈的架构，用一个更全面的图示来说明下：

        可以看到上图架构红框内就是 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 connection的两个设备之间最多需要 4个 L2CAP通道。建立顺序（数字决定优先级）如下图所示：

2. AVDTP术语介绍

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：AVDTP的特性集合。ACP会向 INT暴露它的 capabilities，INT启动程序问询 ACP的 capabilities，并选择一些想用的 capabilities进行配置。Application Service Capabilities表示应用层提供的 services，包括：协商和配置 source codecs、内容保护系统、媒体同步等。Transport Service Capabilities更具体的描述 services，包括分帧和分段、封装、传输性能报告、包丢失检测、包恢复、稳健的 header压缩、传输会话到传输通道的多路复用等

Media Packets, Recovery Packets, and Reporting Packets：Media Packets用来封装流媒体数据（可以理解为RTP包），方向是从SRC到SNK。Recovery packets包含恢复数据，由SRC发送给SNK（packet recovery使用时才会有）。Reporting Packets包含QoS reporting数据（当QoS reporting使用时，可以理解为RTCP包），双向的。

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)：弃用

17.3 AVDTP封包格式

17.3.1 AVDTP Signal封包格式

以上就是 Signal的 header format,可以看到分 3种封包格式：

1）单一封包

2）开始封包，一般用于封包大小>MTU的拆包的第一个封包

3）继续封包和结束封包，一般用于封包大小>MTU的继续封包和结束封包

下面我们来讲下参数：

Transaction Label：传输标示，4bit，INT角色来填写一个值，ACP必须回送一样的值

Packet Type：封包类型，有以下几种

 

 Message Type：消息类型，有以下几种

Signal Identifier：信令标识符，有以下几种值

NOSP = Number Of Signal Packets：Start封包会告知后续有多少个封包要传输

17.3.2 AVDTP Media封包格式 AVDTP音视频格式如下：

其中有 12byte是强制的一定要存在的，也就是上图浅灰色，也有可选存在的，也就是上图深灰色，下面我们来看下各个的 field的概念

 

Version:RTP版本，一般值是 2，还有两个值但是一般不用，

值为 1就是 RTP的草案版本值为 0是在最开始的”vat”音频工具中使用

Padding:在包末尾填充 1个或者多个 byte表示填充，这部分忽略

Extension：扩展位，此位如果是 1，那么在固定头部后面加一个 byte扩展位 CSRC count：标示后面的 CSRC有多少 Byte

Marker (M):marke是由一个 profile定义 的。用来 允许 标识在 像报文流 中界定 帧界 等

的 事件。一个 profile 可能定义了附加 的标识位或者通过修改 payload type域中的位数量来指定没有标识位。

Payload Type (PT)：有效荷载类型，占 7位，用于说明 RTP报文中有效载荷的类型，如 GSM音频、JPEM图像等,在流媒体中大部分是用来区分音频流和视频流的，这样便于客户端进行解析。

Sequence Number：占 16位，用于标识发送者所发送的 RTP报文的序列号，每发送一个报文，序列号增 1。这个字段当下层的承载协议用 UDP的时候，网络状况不好的时候可以用来检查丢包。同时出现网络抖动的情况可以用来对数据进行重新排序，序列号的初始值是随机的，同时音频包和视频包的 sequence是分别记数的。

Time Stamp：时间戳

实际上，时间戳增加一并不是我们通常意义上的过了一个微秒，而是增加了一个采样间隔那么长的时间。举个例子来说。不同的采集有不同的采样频率，比如一般的音频是 8K的采样频率，也就是一毫秒采集 8次数据，也就是每次采样间隔是 1/8MS，而 timestamp增加 1也就意味着增加了一个采样间隔。也就是过了1/8MS。换个例子，如果令一种编码的采样频率是 16K，那么 timestamp增加 1也就意味着系统过了 1/16MS。也就是说，再同一个系统中，对不同编码，虽然使用同一个时钟，但 timestamp的增长速度是不同的，在这个例子中，采样频率是 16K的编码要比 8K的快两倍，请记住这个区别。

SSRC：占 32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的 SSRC。

CSRC list：每个 CSRC标识符占 32位，可以有 0～15个。每个 CSRC标识了包含在该 RTP报文有效载荷中的所有特约信源。

后续的 Media payload就是音频数据了