经典蓝牙 A2DP

最新推荐文章于 2025-03-12 23:00:00 发布

可真哥

最新推荐文章于 2025-03-12 23:00:00 发布

阅读量4.2k

点赞数

分类专栏： BR/EDR 文章标签：笔记 iot 物联网

本文链接：https://blog.csdn.net/weixin_42623551/article/details/130716534

版权

BR/EDR 专栏收录该内容

2 篇文章

订阅专栏

本文详细阐述了蓝牙AVDTP协议，涉及音频和视频流的传输、控制、错误恢复和多路复用服务。AVDTP包括流管理、信令过程、传输服务和信令命令，如发现流端点、配置流、建立和关闭流。此外，还介绍了流端点的状态机、信号包格式以及各种服务能力，如媒体传输、报告和恢复服务。AVDTP的实现还包括报头压缩和内容保护，以确保高质量的音频/视频分发。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

术语和定义

表格

	符合	解释
1	M	强制支持（用于配置文件中应使用的功能）
2	O	可选支持（用于配置文件中可能使用的功能）
3	C	有条件支持（用于支持某些其他功能时应使用的功能）
4	X	排除（用于单元可能支持的功能，但绝不能在配置文件中使用）
5	N/A	不适用（在给定的上下文中不可能使用此功能）
6	RFA	Reserved for future additions 留作将来增加之用，具有这种名称的位应设为零。接收方应该忽略这些位元
7	RFD	Reserved for future definition 保留给以后的定义
8	SRC	源 (Source SRC) SRC设备充当传送到微微网 SNK 的数字音频流的源 (是 A2DP中定义的角色)
9	SNK	接收器（Sink SNK）SNK设备充当从同一微微网上的 SRC 传送的数字音频流的接收器(是 A2DP中定义的角色)
10	INT	发起方 (Initiator INT) 这是发起信令程序的设备 (GAVDP中定义的角色)
11	ACP	接受器(Acceptor ACP)这是响应来自 INT 的传入请求的设备(GAVDP中定义的角色)

1 Stream (流)

流（Bluetooth A/V Stream）代表流媒体数据（音频或视频）在两个 A/V 设备之间逻辑上的端到端连接。

A/V 传输层向应用程序提供此流连接。更严格地说，流数据是源编码数据，因为音频或视频编码器和解码器在概念上位于上层。在多媒体应用程序上下文中，流通常对应于单个媒体通道。例外情况适用于将多个媒体通道编码为聚合比特流的情况；例如，在联合立体声编码的情况下。尽管流连接是单向的，但在传输层交换反馈信息的情况下，传输信道的双向使用是可能的。流句柄（SH Stream Handle）用于唯一区分一个流。

stream 中有三种数据包：media packet、recover packet 和 Reporting packet

2 Stream End Point (SEP 流端点)

流的端点 SEP 是一个概念，用于公开应用程序的可用传输服务和 AV 功能，以便协商流 negotiate a stream。应用程序在 AVDTP 中注册其 SEP，以允许其他设备发现并连接到它们。

3 Stream Context (SC 流环境)

在 Stream 设置过程中，需要两个对等设备对 Stream 的配置达成共识，配置包括选择的服务、参数和传输信道分配。
从概念上讲，流环境 stream context 存在于流的两个端点中。与单个流相关联的 stream context 可以被视为一种表，用于收集和维护所有这些信息（包括选择的服务、参数和传输信道分配）。

两个设备中的 stream context 保持一致和同步很重要。

4 Stream Handle (SH 流句柄)

流句柄 (SH) 表示对流的顶级(应用层)引用。流句柄暴露给应用层。此外，流句柄指的是与该流关联的 stream context。

流句柄是设备本地标识符，由INT和ACP的AVDTP 实体在 Stream 连接建立过程中独立分配。流句柄的范围不是与特定对等设备的连接的本地范围（不是本地连接）。流句柄永远不会在空中接口上交换。

5 Stream End Point (SEP 流端点)

6 Stream End Point Identifier((SEID 流端点标识符)

与流句柄相反，流端点标识符 (SEID) 表示对特定流的跨设备引用。该引用用于信令事务；即，在空中接口上，对等 AVDTP 实体之间。
SEID 是在应用程序级别分配的，用于响应流发现过程的设备。在这里，响应设备公开其基本流端点和基本能力、音频/视频、SNK/SRC，并分配 SEID 作为进一步交易的唯一参考。应用程序负责分配 SEID，该 SEID 未在与同一对等设备的连接上使用。

在流设置过程中，两个 AVDTP 实体都会创建本地 SEID 和本地SH之间的关联，并且通常将其存储在SC中。 SEID 和SH都出现在上层信令接口上。
注意：在每个 AVDTP 实体中，Stream Handle 与远程设备地址和 SEID 对之间存在唯一映射。

7 Stream End Point State (流端点状态 Idle/Open/Streaming)

流端点状态，应用于流的各种操作和事务。状态机与每个流相关并用于控制这些操作。

影响流状态的方面是，例如：协商过程是否正在进行或完成 Idle、是否正在建立和分配传输信道 Open、是否希望应用程序在可用的流连接上发送或接收数据 Streaming。

8 Stream End-point Type (TSEP 流端点类型)

该字段指示SEP是 SNK 还是 SRC，0 = SRC；1 = SNK

9 Transport Session (传输会话)

在 A/V 传输层内部，一个 stream 可以分解为一个、两个或三个 transport sessions，它们存在于对等 AVDTP 实体之间。 每个transport session 只能用于一个 AVDTP 数据包类别（ Media packet, Recovery packet 恢复包, or Reporting packet 报告包）

因此，每个流连接包括至少一个包含 Media packet 的传输会话。如果流连接支持数据包恢复 (RTP-FEC)，则另一个传输会话包含恢复数据包。如果流连接支持 QoS 报告 (RTCP)，则另一个传输会话将包含报告数据包。传输会话标识符（TSID，参见第 4.13 节）用于指代传输会话。

10 Transport Session Identifier (TSID 传输会话标识符)

传输会话标识符 (TSID) 表示对传输会话的引用。 仅在复用模式的情况下，TSID 在空中接口上交换（作为媒体、恢复或报告包头的一部分）。换句话说，如果没有在流连接上配置多路复用模式，则不会明确使用 TSID。
TSID 是跨设备引用，但其范围是本地连接。它由INT的AVDTP实体分配，并由ACP的AVDTP实体采用。特定传输会话（媒体、恢复或报告数据包）的内容类型的关联在流建立过程中由 INT 发出信号。之后，在两个设备的 SC 中维护关联。

11 Transport Channel

传输信道的概念意味着 A/V 传输层底层承载的抽象。目前，传输信道始终对应于 L2CAP 通道（具有指示 AVDTP 的 PSM）。
如果不支持 AVDTP Multiplexing Mode，则一个传输信道只能承载一个传输会话的数据包。如果配置了多路复用模式，传输信道可以携带属于不同传输会话（相同或不同流）的数据包。

12 Transport Channel Identifier (TCID)

传输信道标识符 (TCID) 表示对传输信道的引用。 只有在 Multiplexing Mode 的情况下，TCID 才会在空中接口上进行交换（在流建立事务期间）。换句话说，如果没有在流连接上配置多路复用模式，则不会明确使用 TCID。
TCID 与一个底层 L2CAP 通道及其连接的 L2CAP 通道的本地通道标识符 (LCID) 唯一相关。与 LCID 相比，TCID 是跨设备引用，尽管是本地连接。
在多路复用模式中，TCID 将在流配置事务期间使用，以指示传输会话到传输信道的映射。

13 表格

RTP	Real-time Transport Protocol
RTCP	Real-time Transport Control Protocol
SSRC	Synchronization Source
INT/ACP	Initiator (INT 发起者) and Acceptor (ACP 接收者)
RFA	Reserved for Future Additions 保留项
M	must 必须
O	optional可选
C1	这几种其中一种

AVDTP

Audio/Video Distribution Transport Protocol 音/视频分发传输协议

1. 概述

本文件规定了音频和/或视频分发连接以及通过蓝牙空中接口传输音频或视频媒体的传输协议。音频和视频数据流需要同步数据传输能力。

1.1 AVDTP Stack

A/V 分发传输协议（以下简称AVDTP）的传输机制和消息格式基于RTP，它由两大协议组成：RTP数据传输协议（RTP）和RTP控制协议(RTCP)。该文件 A/V 分发传输协议规范，定义了适用于 L2CAP 连接的 ACL 链路上的 RTP 协议使用机制。

用于执行流设置过程的命令和响应被定义为蓝牙特定的。 AVDTP 定义了蓝牙设备之间的二进制事务，用于使用 L2CAP 进行音频和视频的流设置和媒体流。A/V 流和流设置信令通过 L2CAP 数据包传输。专用的协议/服务复用器 (PSM) 值用于识别用于 AVDTP 的 L2CAP 数据包。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jAP09gL8-1684252728305)(D:\BLUETOOTH\a2dp\企业微信截图_20210902172732.png)]

1.2 AVDTP 与其它profile的架构

下图显示了 AVDTP、蓝牙协议栈和上层是如何集成在一起的。 AVDTP 向上层公开了三个接口（2，3，4），向蓝牙协议栈公开了两个接口（5，6）。为了检索 A/V 设备的详细信息，上层使用蓝牙协议栈提供的 SDP 接口（1）。当 A/V 应用程序通过蓝牙链接传输音频和/或视频流时，AVDTP 执行 A/V 参数协商。基于此协商的结果，A/V 应用程序传输音频和/或视频内容。

1.2.1 AVDTP 提供的接口

接口	描述
1	服务发现协议 (SDP) 消息接口用于从远程设备发现 AVDTP 属性
2	用于在两个互连设备之间交换 stream 的报告数据包 Reporting packet 的应用程序接口（QoS reporting）
3	用于在两个互连设备之间为 stream 建立阶段、重新配置、拆除流的交换信令消息的接口。此通道的目的是在 A/V 分发应用程序中提供通道配置协商
4	在两个蓝牙设备之间的 A/V 分发会话期间，通过一个或多个 L2CAP 面向连接的通道传输音频/视频内容的 A/V 基本 media packet 。媒体数据包 A/V elementary media packets 格式在配置文件级别定义
5	为 AVDTP 信令分配的 L2CAP 通道。 L2CAP通道通过第一级协议路由 PSM值=AVDTP 来区分
6	为 media packet、recover packet 和 Reporting packet 的 AVDTP 传输分配的 L2CAP 通道。 L2CAP 通道通过第一级协议路由 PSM 值 = AVDTP 来区分。

1.3 设备之间的操作

AVDTP 在面向连接的 L2CAP channel 上应用点对点信令 point-to-point signaling。 L2CAP channel 预先设置在两个参与 A/V stream 数据分发的设备之间。 L2CAP channel 最适合支持 A/V stream 数据分发链路。这是因为可以灵活配置 L2CAP channel ，以在 A/V 内容stream 之间共享带宽。 A/V stream 在伪同步 L2CAP channel 中传输。 A/V signaling 也通过 L2CAP channel 传输。 Signaling 提供 stream 发现、配置、建立和传输控制。

1.4 功能要求

以下功能已被确定为 A/V Distribution Transport 协议的要求。

AVDTP 应提供发现设备能力 capabilities 的方法，以及协商 A/V stream 设置的方法
AVDTP 应提供建立和拆除 stream 的机制
AVDTP 应提供实时 stream 的机制和消息格式，它们是：
 最小化传输延迟的机制
 附加数据的机制，这些数据提供在接收方播放媒体流所需的时间信息
 向应用层报告服务质量Quality of Service 和媒体数据包传输状态的机制
 优化可用带宽使用的机制
AVDTP 应具有灵活的独立功能，可用于复杂性有限的设备。
AVDTP 应提供恢复机制。
AVDTP 应提供减少传输协议中头部开销的机制

1.5 角色 (SRC/SNK INT/ACP)

1.5.1 Source (SRC) and Sink (SNK)

由于流表示单向的媒体数据，对等设备显式地承担SRC或SNK的角色，这取决于应用程序。

1.5.2 Initiator (发起者 INT) and Acceptor (接收者 ACP)

启动一个 procedure 的设备被认为是这个 procedure 的INT。处理的设备是过程的ACP。流的INT/ACP角色与设备的SRC/SNK角色无关，不要将A/V传输协议中的INT和ACP角色与底层L2CAP层中的相应角色混淆

2. 架构 Architecture

2.1 块的功能

2.1.1 Stream Manager

	功能
1	Streaming
2	Media framing 媒体帧格式
3	Time stamp management 时间戳管理
4	Media packet sequence numbering 媒体包顺序编号
5	Reporting of packet loss to peer and to higher layer 向上层和同层报告数据包丢失
6	Jitter calculation 抖动的计算

2.1.2 Recovery

可恢复有两种模式：No FEC、Equal FEC

2.1.3 Adaptation Layer

1、报头压缩使用健壮报头压缩 Robust Header Compression

2、多路复用模式，允许多个传输会话(TSID)在一个传输通道(TCID)上复用

2.2 接口的功能


1	Application Service Capabilities Discovery 应用服务能力发现 Transport Service Capabilities Discovery 运输服务能力发现 Stream Negotiation 流协商 Stream Establishment 流建立 Stream Destruction 流摧毁 Stream Suspend and Resume 流暂停和恢复
2	Media Streaming Timing information relative to streams 与流相关的时间信息
3	Quos reporting for media streams 媒体流的 Quos 报告
4	如果流是 SRC： 1媒体有效载荷加定时信息 2 报告丢包的原语如果流是 SNK：媒体有效载荷加上发送和接收的时间信息
5	Media transport framing
6	Recovery transport framing
7	Reporting
8	L2CAP channel for signaling entity
9	L2CAP channels for transport entity

2.3 SEP 架构

2.4 传输服务 Transport Services

2.4.1 Basic Service

AVDTP 基本服务确保每个会话session 的 Media packets 通过单独的 transport channel 传输。该服务提供了一个适当的 API 使应用程序的 stream packet 符合 transport channel 规定的 MTU。成功配置 transport channel 后，此数据包大小限制将返回给应用程序。

2.4.2 Recovery Service

恢复服务使用SRC端一个传输会话的媒体包来生成额外的编码包，这些恢复包可以在SNK端用于重建在空气传输路径上丢失的原始媒体包。

这种服务特别适用于有巨大带宽需求和有限重传能力的应用程序。与基带FEC相比，恢复服务实现了灵活的按需纠错机制；

为了有效地对抗干扰，所有的恢复数据包都通过一个单独的传输通道传输

2.4.3 Reporting Service

作用：

报告服务向本地应用程序和远程设备提供有关媒体流的时间对齐和包丢失的统计信息；这些报告用于实现适当的媒体流同步和适配应用程序的错误隐藏策略；

特性：

1）根据应用需求，报告服务可以配置为单向的 (从SNK到SRC或从SRC到SNK) 或双向的；

2）服务接口允许应用程序调整 report的周期性，并根据 context 激活或关闭报告服务；

3）报表服务可以使用独立的传输通道将报表包传输到远程端

2.4.4 Adaptation Service – Multiplexing

复用的实现原理：

在多路传输模式下，多个传输会话可以共享一个L2CAP (common transport)通道，它们可以属于同一个流，也可以属于不同的流。而且一个L2CAP包可以包含多个属于相同或不同传输会话的包，因此每个包都需要一个封装头 header，header 中的 TSID 可以在 SNK 设备上正确路由数据包。

在流配置过程中，INT已经分配 TSIDs 和 TCIDs，并与ACP通信。流建立过程不一定打开一个新的传输(L2CAP)通道，它可以将新的传输会话映射到现有的L2CAP通道，这是通过引用现有的 TCID 来实现的。

复用的应用：

复用模式功能位于AVDTP的适配服务层，它只在流建立时生效，并不影响流向上层公开的端点概念和流和会话的组织。

如果媒体包的大小超过了传输通道的MTU要求，复用模式可以配置一个可选的分片服务，将媒体包传输成更小的块，以适应传输通道的要求。

2.4.5 Adaptation Service – Robust Header Compression 鲁棒性报头压缩

健壮报头压缩是一种传输服务，它可以减少媒体包和恢复包的报头引入的开销。应用程序完全可以选择这种机制，但是对于要建立的每个流，在连接的两端应该设置相同的配置。

Robust Header Compression 机制允许使用在配置媒体流时协商的反馈通道。

2.4.6 Transport and Signaling Channel Establishment

参与流连接的两个设备之间最多需要四个L2CAP通道；

因为 L2CAP signaling 没有提供正确的信息来区分哪个 L2CAP channel 用于特定的传输信道，所以规定了关于 L2CAP channel 的建立顺序，如下图：

(1)Signalling Channel —> (2)Media Transport Channel —> (3) Reporting Channel —> (4)Recovery Channel

信令通道只在两个流设备之间建立一次；媒体、报告和恢复传输通道是根据每个 stream 建立的；

3. Signaling Procedure

1、通过 L2CAP 的 signaling channel 去管理 AVDTP 的 stream。

2、蓝牙链路上的 A/V Stream 由蓝牙设备通过抽象的流端点 (SEP) 发送或接收，该流端点由流端点标识符 (SEID) 引用。设备可

以发现远程设备的 SEP；即，通过"Stream End Point Discovery procedure"，流连接的潜在 SRC(s) 和/或 SNK(s)。此过程的结果提供 SEP 列表以及远程设备支持的媒体类型。

3.1 stream Management Signaling Overview

下图是从 Stream End Point Discovery 到 stream release

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ojckSWs3-1684252728306)(D:\BLUETOOTH\a2dp\企业微信截图_20210902164336.png)]

3.2 Signaling Command

下表显示了为AVDTP定义的 Signaling Command 集。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cO8HEOI9-1684252728307)(D:\BLUETOOTH\a2dp\企业微信截图_20210902170545.png)]

3.3 状态概述

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-E20tSeZ2-1684252728307)(D:\BLUETOOTH\a2dp\企业微信截图_20210902170819.png)]

3.4 Signal Packet 格式

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2mzs6IaZ-1684252728308)(D:\BLUETOOTH\a2dp\企业微信截图_20210906095236.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CccpRAUG-1684252728308)(D:\BLUETOOTH\a2dp\企业微信截图_20210906095356.png)]

4. Transport Procedure

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zCdc3Sc7-1684252728308)(D:\BLUETOOTH\a2dp\企业微信截图_20210902172732.png)]

4.1 Basic Service

4.1.1 概述

4.1.2 媒体数据包格式

定义了媒体传输包的结构，并定义了每个包的功能和信息内容。下图显示了媒体数据包头格式，媒体包头有 12 字节的强制字段（带 SSRC 字段）和可选字段（CSRC）。 SSRC 字段仅用于多播应用，因为 SSRC 字段标识特定媒体传输会话上的源节点 ID。

本文档中描述的报头和数据的传输顺序被解析为八位字节级别。每当图表显示一组八位字节时，这些八位字节的传输顺序就是它们在英语中的正常阅读顺序。如下图中，八位字节按编号顺序传输。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-l5RRl5m2-1684252728309)(D:\BLUETOOTH\a2dp\企业微信截图_20210902174014.png)]

空中包：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-u8Qe8aYM-1684252728309)(D:\BLUETOOTH\a2dp\企业微信截图_20210902174124.png)]

4.2.3 媒体数据包头的格式

	描述	长度
Version (V)	RTP 的版本 (Real-time Transport Protocol )	2 Bits
Padding §	填充位，如果设置了填充位，则数据包的末尾包含一个或多个额外的填充八位字节，它们不是有效载荷的一部分。填充的最后一个八位字节包含应该忽略多少个填充八位字节的计数	1 Bit
Extension (X)	扩展位，如果设置了扩展位，则固定报头后紧跟一个报头扩展。	1 Bit
CSRC count (CC)	CSRC 计数，包含跟随固定标头的 CSRC 标识符的数量。	4 Bits
Marker (M)	标记，标记的解释由配置文件定义。它意味着允许在数据包流中标记重要事件，例如帧边界	1 Bit
Payload Type (PT)	该字段标识 RTP payload 的格式并确定应用程序对其的解释。配置文件指定了负载类型代码到负载格式的默认静态映射。	7 Bits
Sequence Number	序列数，每发送一个媒体包，序列号加一，接收端可以用它来检测丢包，恢复包序列。	16 Bits
Time Stamp	时间戳，反映了媒体包中第一个八位字节的采样时刻。	32 Bits
SSRC	该字段标识 synchronization source，区分 transport session。这个标识符是随机选择的，目的是在同一个媒体传输会话中没有两个同步源应该具有相同的 SSRC 标识符。SSRC 字段仅用于多播应用，因为 SSRC 字段标识特定媒体传输会话上的源节点 ID。
CSRC list	CSRC list 标识了此数据包中包含的有效载荷的贡献源。

空中包：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-i2XNNScs-1684252728310)(D:\BLUETOOTH\a2dp\企业微信截图_20210902175241.png)]

4.2 Reporting Service

4.2.1 概述

Media and Reporting 直接使用 L2CAP。 RTP 在 L2CAP 上实现了 A/V data stream 的传输，RTCP 监控服务质量 Qos 并在正在进行的传输会话中传达有关参与者的必要信息。

对于每个打开的媒体传输会话，应关联一个报告通道。因此，一个流会话( stream session) 应包括两个传输通道(transport channel)，一个用于媒体数据包 Media packets ，另一个用于报告数据包 Reporting packets。

该解决方案利用不同的传输会话(transport sessions) 进行报告和媒体传输。根据不同类型的传输会话（音频、视频等），每个通道承载不同的数据包格式。可以为同一个视频应用打开不同的媒体传输会话；每个流对应于媒体流之一（对象、增强层等）。

在 AVDTP 中，只能使用 SR、RR 和 SDES 三种数据包。它们在以下各节中进行了描述。

4.2.2 Sender report packet (SR 发送方报告包 200)

图 7.4 显示了 Sender Report 数据包。它由三个部分组成，如果定义，可能后面跟着第四个特定于配置文件的扩展部分。header 有八个八位字节长。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Nezo2SIz-1684252728310)(D:\BLUETOOTH\a2dp\企业微信截图_20210906111141.png)]


Version (V)
Padding §
Reception Report Count (RC)	当前包中接收的 report blocks 的数量	5 Bits
Packet Type (PT)	设置为 200 以将其标识为 RTCP SR 数据包	8 Bits
Length	此 RTCP (Real-time Transport Control Protocol) 数据包的长度（以 32 位字为单位）减去一，包括标头和任何填充	16 Bits
SSRC
NTP Time Stamp	指示发送此报告时的 wall clock time，以便它可以与其他接收器的接收报告中返回的时间戳结合使用，以测量到这些接收器的往返传播	64 Bits
RTP Time Stamp	与 NTP 时间戳（上）对应的时间相同，但与数据包中的 RTP 时间戳具有相同的单位和相同的随机偏移量	32 Bits
Sender’s Packet Count	从开始传输到生成此 SR 数据包的这段时间里，发送方传输的 RTP 数据包总数	32 Bits
Sender’s Octet Count	从开始传输到生成此 SR 数据包的这段里时间，发送方在 RTP 数据包中传输的有效载荷八位字节总数（即，不包括报头或填充）。	32 Bits
SSRC_n (Source Identifier)	此接收报告块中的信息所属的源的 SSRC 标识符。	32 Bits
Fraction Lost	丢包率，自前一个 SR 或 RR 数据包发送以来，来自源 SSRC_n 的 RTP 数据包丢失的部分，表示为一个定点数，二进制小数点位于字段的左边缘。	8 Bits
Cumulative Number of Packets Lost	累计的包丢失数，源SSRC_n自接收开始以来丢失的RTP数据包的总数	24 Bits
Extended Highest Sequence Number Received	序列号，低16位包含从源SSRC_n接收到的RTP数据包中的最高序列号，最高16位将该序列号扩展为相应的序列号循环计数	32 Bits
Inter-arrival Jitter	RTP数据包到达时间间隔的统计方差的估计，以时间戳单位度量，表示为无符号整数	32 Bits
Last SR Timestamp (LSR)	作为来自源SSRC_n的最新RTCO发送者报告(SR)包的一部分接收的NTP时间戳中64位中的中间32位	32 Bits
Delay since Last SR (DLSR)	从源SSRC_n接收到最后一个SR报文到发送这个接收报告块的延迟时间，单位为1/65536秒	32 Bits

4.2.3 Receiver report packet (RR 接收方报告包 201)

RR (Receiver Report)报文的格式与SR报文的格式相同，只是报文类型PT (packet Type)字段中包含常量 201，并且省略了发送方信息的5个字

4.2.4 Source description packet (SDES 源描述包 202)

每个数据块由一个 SSRC 或 CSRC 标识符组成，后跟零个或多个项目的列表，这些项目携带有关 SSRC 或 CSRC 的信息。

Version (V)	同上
Padding §	同上
Source Count (SC)	SDES 报文中 SSRC/CSRC 块的个数	5 Bits
Packet Type (PT)	设置为 202，代表 Reporting SDES packet	8 Bits
Length	同上
SSRC_n (Source Identifier)	同上

4.3 Recovery Service

恢复服务应独立于要保护的媒体包类型和底层传输特性执行：

4.3.1 概述

1、FEC 理论上可以保护AV stream data

ACL链路提供基带的可选纠错服务(FEC)，这种保护方案可以在生成额外奇偶码的每10位序列中纠正一个位错误。在原理上，FEC始终可用来保护AV流数据。

2、FEC 在保护AV stream data的局限性

(1)基带FEC的目的是限制在不利的无线电传输中需要的重传输的数量，在重大突发错误的情况下，这个特性没有很大的帮助，因为受影响的基带包丢失。

(2)另外每个逻辑通道的基带FEC业务不能单独选择。

3、其它

当重传既不可取也不适用时，可以选择在AV传输层直接保护媒体包的前向纠错方案作为备用恢复机制。

恢复服务基于 RFC2733“用于通用纠错的 RTP 有效负载格式”[3]。 本文档提供了用于生成和封装 Recovery Packet 的完整规范,它还规定了在接收端用于媒体包重建的程序。一旦配置好，该服务将永久可用，以下列方式处理媒体包保护的应用程序请求

4.3.2 Recovery Service 作用

(1)通常需要 重新传输损坏的基带包来完全恢复丢失的媒体包。

(2)Recovery Service 的另一个好处是为应用程序提供了根据媒体包类型或内容区分保护的方法。例如，应用程序可以决定保护视频包或音频包，这取决于它们各自的错误恢复能力，或者将保护限制在流的某些脆弱部分。

4.3.3 Recovery Service 实现原理

在接收端，每次在受保护的传输会话中检测到丢失的媒体包时，流管理器实体都会直接触发恢复服务，丢失媒体包的检测是基于序列号控制的。

恢复服务尝试使用一个或多个后续恢复数据包来恢复丢失的数据包，这些数据包在范围内具有丢失的媒体数据包。在主动恢复阶段不需要应用程序的干预。在 [3] 中可以找到重建丢失媒体数据包过程的完整规范。

1）如果成功 重建原始媒体包，则恢复服务会调用回流管理器函数以 在流输出接口插入媒体包；

2）如果恢复失败，则将丢失的媒体数据包发送给应用程序，并且不会为丢失的数据包流出数据；

4.3.4 Recovery transport channel

一致的 L2CAP 实现保证后续的 L2CAP 数据包永远不会共享相同的基带负载，即使在应用分段时：因此单个基带数据包的丢失只会影响序列中单个传输的 L2CAP 数据包。

为了减少媒体和恢复数据包同时丢失的可能性，AVDTP 应将这些数据包封装为单个 L2CAP 数据包的有效载荷。当传输信道没有配置为多路复用时，这个要求实际上得到满足。在源设备中结合多路复用和恢复服务的实现需要额外的会话和传输管理来实现它。

4.3.5 RTP payload type

1）AVDTP 要求在公共或单独的 stream 中传输媒体数据包和恢复数据包。在目标设备中，每个有效载荷由其传输会话或通道 ID 标识，而无需在数据包头中使用不同的 RTP 有效载荷类型。

2）选择 RTP 有效载荷类型并使用它在符合蓝牙标准的设备之间传输恢复数据包：在 AVDTP 中，每个恢复数据包的 RTP PT 值应设置为源媒体流数据包之一 .

4.3.6 Parity codes 奇偶校验码

恢复分组有效载荷包括附加的FEC报头，该报头通过基本序列号和掩码提供受保护媒体分组序列的标识。这种识别方法将覆盖窗口扩展到从所指示的基本数据包开始的 24 个媒体数据包上，用于生成恢复数据包的一组媒体数据包的组合称为奇偶校验码。可以使用任何奇偶校验码：通过基本序列号和恢复数据包头中的掩码信息，宿设备总是可以根据所使用的奇偶校验码重建一个或多个丢失的数据包。

由于奇偶码信息包含在恢复包报头中，因此不需要特殊奇偶码使用的信道的信令或配置。源设备可以动态地使奇偶码适应信道条件，而无需使用额外的带外信号。选择最佳合适的奇偶校验码，取决于测量的交通条件，并留给应用程序。

4.3.7 Recovery Window 恢复窗口(可恢复的范围)

恢复窗口大小是接收设备SNK 可以缓冲的媒体数据包的数量，以保证覆盖序列的任何单个数据包的重建。

INT 和 ACP 应在 SEP 配置过程中协商最大恢复窗口大小。在 stream 传输期间，源设备只能选择与配置值兼容的编码方案。
当需要恢复损坏的数据包时，限制窗口大小往往还可以减少潜在的延迟和抖动影响。

4.3.8 Recovery SEP capabilities

为了应对源设备和接收设备可能的资源限制，在恢复服务的上下文中公开和配置了以下功能：
1）恢复窗口的最大大小，宿端应分配以确保任何单个媒体包的重建。 范围是 1…24
2）可用于计算恢复数据包的最大媒体数据包数。
范围是 1 到 24。值为 1 表示该服务实际上是作为按需数据包重传服务运行的。
为了相对于协商的恢复窗口正确地服务宿设备，源设备被要求在奇偶校验码生成中使用的最后一个原始数据包之后立即调度每个恢复数据包传输。

4.3.9 Applicable coding schemes 适用的编码方案

源设备可以使用[3]中所有与流端点功能兼容的编码方案。最佳编码方案的选择取决于应用程序策略和设备功能。选择标准也可以随着会话 session 而变化。
 用于生成单个恢复数据包的媒体数据包数量越少，丢失媒体数据包的可能性就越大。原因是一个覆盖集(covered set) 出现多个丢包时，服务无法重构原始包。
 应用零星编码方案或动态改变方案可用于以有选择的方式调制数据包保护。这对于减少总开销很有用，并且在媒体流源使用执行比特分类的编码方法时更具体地适用。

4.4 Multiplexing Service

4.4.1 概述

多路复用服务，概念上位于适配层，AVDTP (AVDTP- AL) 的特点是更灵活地使用底层传输通道(L2CAP通道)及其包(L2CAP包)，可以提高底层数据包使用的效率。这是通过在适配层 (Adaptation Layer) 中启用分段 (作为多路复用的一部分) 来实现的。

**启用多路复用服务应在流配置期间进行配置程序，**特别是如果应用程序希望有两个按顺序建立的流来共享相同的传输通道，则从一开始就应该为两者配置多路复用服务。

4.4.2 Adaptation Layer PDU packet format (AL-PDU)

未开启多路复用时：

当没有配置多路复用模式时，一个L2CAP负载，即AVDTP的一个PDU，由单个媒体、报告或恢复包组成，AVDTP的每个传输会话使用一个不同的 transport channel (L2CAP)。

多路复用：

一个AL-PDU（包含AVDTP-AL多路复用服务的一个PDU）可以包含一个或多个数据包(媒体包、报告包或恢复包)，即多路复用数据包中的数据可以属于不同的传输会话，甚至属于不同的流。这意味着在多路复用服务中，需要一个额外的 报头(AL报头)，它封装每个贡献到AL_PDU的包。 AL报头提供了可变长度传输(媒体/报告/恢复)数据包的帧，并确保到接收端相关传输会话的正确映射。

AL-PDU的格式如图7.8所示。本例中，AL-PDU中包含两个媒体报文和一个恢复报文。一般情况下，AL-PDU中媒体/报告/恢复报文的顺序是任意的、动态的。源AVDTP-AL实体负责为不同的传输会话提供服务并以适当的方式填充AL-PDU。在这样做时它可以，例如在较低的层考虑预期的数据包大小，从而有助于提高蓝牙链路的带宽利用。

4.4.3 Adaptation Layer Header format (AL包头)


1	TSID	Transport Session ID，00000 = 表示 AL 头的扩展：在 TSID=00000 的情况下，第二个 AL 头字节，在长度字段之前，是预期的，包含实际的 TSID，与 MSB 对齐。
2	F	适配层分片，0 = 未分片的传输数据包；1 = 后面的数据代表传输包的连续块
3	LCODE	长度字段编码： 00 = 不存在长度字段 01 = 16 位长度字段（在后面的 2 个长度八位字节中） 10 = 9 位长度字段，MSB = 0，1 个八位字节中的 8 个 LSB 11 = 9 位长度字段，MSB = 1，1 个八位字节中的 8 个 LSB

会话，即媒体、报告或恢复部分传输特定流的会话。注意，TSID作用域是跨会话的，用于给定一对设备之间的一个或多个流的媒体/报告/恢复包。

可变长度字段编码的作用是最小化开销，同时适应典型的包长度(例如，适应DH5包长度需要9位)。可以使用LCODE=00(没有长度字段)来为每个L2CAP包保存至少一个字节。在AL-PDU内的最后一个传输报文中，不需要配置长度字段，因为AL-PDU的总长度已经在L2CAP头中说明了。

4.5 鲁棒性报头压缩服务 (Robust Header Compression Service)

该服务基于ROHC，即健壮的报头压缩，可以在IETF RFC[4]。IETF标准包括IP、UDP和RTP报头的压缩。在AVDTP协议中，只使用RTP压缩部分。

5. Signaling Messages

5.1 建立 SEP connection

5.1.1 发现 ACP 中的 SEP (流端点)

通过命令：AVDTP_DISCOVER_CMD

5.1.2 选择 SEP

5.1.3 收集目标SEP 的服务功能

使用目标SEID 收集服务功能(Service capabilities)，通过命令：AVDTP_GET_CAPABILITIES_CMD / AVDTP_GET_ALL_CAPABILITES_CMD

5.1.4 为 SEP 选择目标设备上的 capability

通过命令：AVDTP_SET_CONFIGURATION_CMD

5.2 Signaling Message format

本节定义了 Signaling Message 的格式， Signaling Message 用于收集有关 Stream Capabilities 和媒体流建立的信息。

图8.2显示了向下传递的信令消息流程。一个信号请求从上层到达AVDTP。 AVDTP格式化请求并添加AVDTP信令头。然后将AVDTP信令消息传递给L2CAP，以便传送给对等体。 一个L2CAP包中只能有一条AVDTP信令 。

5.3 信令分片 Signal Fragmentation

为了满足接收单元的MTU要求，可能需要对信令消息进行分片和重组。

5.3.1 分片后包的类型

第一个数据包是 Start 数据包，其格式如表8.2所示。“开始包”后面的包称为“continue 继续包”，格式如表中所示；当信号的最后一个包 end结束包 到达时，它的格式如表8.3所示。每个包类型以一个L2CAP包的形式发送。

在 signaling packet 的 header 中的 Packet Type 字段表示信令消息由单包或多包组成。在多包的情况下，该字段还表示该信令的报文类型(起始包、继续包或结束包)。

5.3.2 分片的规则

1、发送方被要求在处理来自下一个消息的包之前，依次传输属于同一消息的所有包，不允许在 air 中交错来自不同 signaling message 的数据包。

2、注意，只有当 Abort 命令消息的 SEID 与分片消息的SEID相同时，才允许分解包序列(命令或响应消息)，以此在相同的方向发送 Abort命令消息。在这种情况下，发送方应刷新连续到中止消息的其余数据包。

5.4 Signal command and response headers

下面显示的是通用信令命令和响应信号的格式，为了能够使用大尺寸信号，使用了两种报头格式：

1、一种格式提供信息元素来标识片段信号的起始和信号的长度；

2、另一种提供适合于继续包、结束包和单包的信息元素；

5.4.1 Transaction Label 事务标签

INT 的每个未完成的事务都会指定一个唯一的标记 事务标签（Transaction Label ）。事务标签字段的长度为四位。

在 ACP 端，信令命令帧(signaling command frame)应该使用接收到的事务标签作为在相应的信令响应帧中 返回的事务标签。

5.4.2 Packet Type

如上图中 Packet Type 字段表示信令消息由单包或多包组成。在多包的情况下，该字段还表示该信令的报文类型(起始包、继续包或结束包)。

5.4.3 Message Type

在 command packet 中，Message Type 字段指定 信令命令的命令类型。

在 signaling packet 中，Message Type 字段指定 ACP 上对应的信令命令的结果。

5.4.4 Signal Identifier 信令标识符

“Signal Identifier”字段表示从INT到ACP的信令命令。在ACP侧，将从信令命令消息中接收到的信号标识字段值作为相应信令响应消息中的信号标识字段值。

5.4.5 packet size requirements 数据包大小要求

分片消息的接收方可以根据起始包长度和第一个包提供的包信息元素的数量去分配用于消息重组的资源。因为这个原因：

1、一个分片消息的起始包和所有继续包的L2CAP有效负载长度应该相同；

2、结束包的L2CAP有效负载不应大于属于同一消息的开始包和任何可能的继续包；

5.4.6 接收端消息完整性验证 (Message integrity verification at receiver side)

AVDTP信令消息的接收者不应解析损坏的消息。

如果没有适用的错误码，这些消息将被丢弃，并且不会向发送方返回任何信令消息。可能被损坏的消息有：

1、事务标签(TSID) 与发送到远程设备的前一个命令不匹配的响应消息

2、序列中带有意外包类型的消息 (比如第一个包的包类型字段设置为“continue”或“end”)

3、不完整的分片报文(收到的报文数与起始报文的NOSP字段值不匹配)

4、信号标识符设置为保留的消息

5.6 Stream End Point Discovery (AVDTP_DISCOVER 01 = signal identifier)

5.6.1 Command

AVDTP_DISCOVER_CMD 从 INT 发送到 ACP，请求获取 ACP(接收者) 上所有 SEP(stream end point) 的信息；

5.6.2 Response

1、响应中应该包含ACP支持的所有 SEP 的信息概述；

2、注意，此信息仅对一个流建立过程有效，因为ACP中的流资源是动态的，可以被其他设备使用。

3、为每个SEP返回的 Media Type 值定义在蓝牙号码分配文档，参见[5]。

4、AVDTP_DISCOVER_RSP 里应至少有一个SEP。

5.6.3 Reject

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HcKLTpVx-1684252728311)(D:\BLUETOOTH\a2dp\企业微信截图_20210910153719.png)]

5.7 Get Capabilities (AVDTP_GET_CAPABILITIES)

5.7.1 Command

AVDTP_GET_CAPABILITIES_CMD 从INT向ACP发送，用于获取ACP的特定SEP的信息。SEID字段值指定ACP中的目标SEP。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XFBDpG7K-1684252728311)(D:\BLUETOOTH\a2dp\企业微信截图_20210910155148.png)]

5.7.2 Response

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xU29VNVx-1684252728311)(D:\BLUETOOTH\a2dp\企业微信截图_20210910155342.png)]

5.7.3 Reject

从INT接收 AVDTP_GET_CAPABILITIES_CMD 后，ACP尝试收集流端点的能力。如果命令失败，则发送AVDTP_GET_CAPABILITIES_REJ 给INT。数据包包含一个错误代码，说明命令被拒绝的原因。消息类型 (Message Type) 为 Respone Accept。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gJhdJH1C-1684252728312)(D:\BLUETOOTH\a2dp\企业微信截图_20210910155743.png)]

5.8 Get ALL Capabilities (AVDTP_GET_ALL_CAPABILITIES 0C)

5.8.1 Command

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VhOK6drt-1684252728312)(D:\BLUETOOTH\a2dp\企业微信截图_20210910155930.png)]

查询 ACP 中 SEID = 3的 SEP的 All Capabilities：

5.8.2 Response

消息类型 (Message Type) 为 Respone Accept。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-aILG1VbA-1684252728313)(D:\BLUETOOTH\a2dp\企业微信截图_20210910160021.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XudJBz9B-1684252728313)(D:\BLUETOOTH\a2dp\企业微信截图_20210913091326.png)]

5.8.3 Reject

同上

5.9 Stream Configuration (AVDTP_SET_CONFIGURATION 03)

5.9.1 Command

在接收到 AVDTP_GET_CAPABILITIES的 Resp 后，INT选择需要的 SEP 和它的业务能力去完成发送/接收 stream 从ACP 。 INT 通过发送 AVDTP_SET_CONFIGURATION 命令将 选择的SEP及其服务能力 通知给 ACP。 AVDTP_SET_CONFIGURATION命令表示SEP所需的所有服务能力。服务能力的详细定义在后面章节。

INT 请求 ACP 配置指定的Steam (SEID = 2) 的能力。

5.9.2 Response

从INT接收AVDTP_SET_CONFIGURATION_CMD后，ACP尝试按照要求去配置流端点。如果配置成功，则使用

AVDTP_SET_CONFIGURATION_RSP 从ACP发送到INT。

5.9.3 Reject

从INT接收AVDTP_SET_CONFIGURATION_CMD后，ACP尝试按照要求去配置流端点。如果配置失败，则使用

AVDTP_SET_CONFIGURATION_REJ从ACP发送到INT。数据包中携带 拒绝原因和拒绝命令的详细信息(error_code)。

5.10 Get Configuration (AVDTP_GET_CONFIGURATION)

5.10.1 Command

AVDTP_GET_CONFIGURATION 数据包用于 查询指定的SEP的当前能力配置。

5.10.2 Response

ACP收到查询配置数据包后，ACP 发送 AVDTP_GET_CONFIGURATION_RSP 给 INT。响应包含所请求流端点的当前配置。

5.10.3 Reject

ACP在处理请求时出现了错误，然后AVDTP_GET_CONFIGURATION_REJ被发送回INT。响应包含一个拒绝原因，说明为什么命令被拒绝。

5.11 Steam Reconfiguration (AVDTP_RECONFIGURE)

5.11.1 Command

参与流中的设备可以更改应用程序服务功能，如果设备需要重新配置应用服务能力，则使用 AVDTP_RECONFIGURE_CMD，并且发出命令的设备将成为INT。

Steam Open 之后未关闭 Stream 时，可以发送此命令配置能力，但是仅媒体编解码器功能和内容保护能力可以用此命令进行重新配置。

5.11.2 Response

当ACP接收到AVDTP_RECONFIGURE_CMD时，Steam 将使用提供的配置参数重新配置。在成功地重新配置流之后AVDTP_RECONFIGURE_RSP被发送回INT。

Reconfigure命令的作用域是有限的：一旦 Steam Open 之后，只有 Application Service Capabilities (编码器配置和内容保护) 可以被寻址进行重新配置。例如：如果reconfigure命令请求重新配置 Media Transport 能力，ACP应该返回一个带有’ INVALID_CAPABILITIES ’ ERROR_CODE 的拒绝消息。

5.11.3 Rejeect

如果ACP不能重新配置流，那么AVDTP_RECONFIGURE_REJ将被发送回INT。拒绝信号包含一个关于请求被拒绝原因的错误代码。

5.12 Open Steam (AVDTP_OPEN 06，建立 Steam )

5.12.1 Command

AVDTP_OPEN_CMD 用于为已配置的 SEP 建立传输通道。INT打开流，并在必要时打开相关的传输通道。在需要多路复用模式的情况下，显式传输会话标识符应与相关的传输通道标识符一起提供。

5.12.2 Response

ACP从INT接收AVDTP_OPEN_CMD后，根据配置的流连接服务来验证流连接是否可以建立。如果可以建立连接，则回复AVDTP_OPEN_RSP给INT，这个响应向INT发出流打开的信号。

INT在接收到 AVDTP_OPEN_RSP 后根据配置的服务去建立 L2CAP transport channel。如果未配置多路复用服务，则为每个传输会话建立单独的传输通道，如果配置了多路复用服务，则只在必要时根据配置设置建立新的传输通道。

5.12.3 Reject

ACP从INT接收AVDTP_OPEN_CMD后，根据配置的流连接服务来验证流连接是否可以建立。如果无法建立连接，则回复 reject，此这个拒绝响应包含一个 error code。

5.13 Stream Start (AVDTP_START 07,启动 Steam)

5.13.1 Command

5.13.2 Response

从INT接收AVDTP_START_CMD后，the ACP puts the stream(s) into streaming mode, ready to accept streaming media。如果 Stream 启动成功，则 AVDTP_START_RSP被发送回INT。此响应包含流已启动的确认。

5.13.3 Reject

从INT接收AVDTP_START_CMD后，the ACP puts the stream(s) into streaming mode, ready to accept streaming media。如果 Stream 启动失败，则AVDTP_START_REJ将被发送回INT。这个拒绝包含一个关于为什么命令被拒绝的错误代码。

5.14 Stream Release (AVDTP_CLOSE 08,关闭 Steam)

5.14.1Command

1、AVDTP_CLOSE_CMD 请求可以由流中参与的任何设备发送。

2、启动流闭包的设备扮演INT的角色。

3、当INT发出AVDTP_CLOSE_CMD时，ACP接收到该命令后，将对AVDTP_CLOSE_CMD进行操作，并关闭它自己对流端点的引用。

5.14.2 Response

从INT接收到AVDTP_CLOSE_CMD后，AVDTP_CLOSE_RSP从ACP发送到INT。此响应包含ACP中关闭流的确认。

5.14.3 Reject

如果AVDTP_CLOSE_CMD是由INT类型发送的，并且流不能被关闭AVDTP_CLOSE_REJ被发送回INT，表示为什么流不能被关闭。

5.15 Stream Suspend (AVDTP_SUSPEND)

5.15.1 Command

从INT接收AVDTP_SUSPEND_CMD后，ACP挂起对应的 Steam。

5.15.2 Response

从INT接收AVDTP_SUSPEND_CMD后，ACP尝试挂起由SEID(s)标识的这些流，如果挂起成功，则发送AVDTP_SUSPEND_RSP 给INT。此响应是对流已挂起的确认。

5.15.3 Reject

从INT接收AVDTP_SUSPEND_CMD后，ACP尝试挂起由SEID(s)标识的这些流，如果挂起失败，则发送AVDTP_SUSPEND_REJ 给INT。拒绝包含不能挂起的第一个SEID和相应的错误代码，用于解释流为什么不能挂起。

5.16 Steam Abort (AVDTP_ABORT 终止建立 Steam)

5.16.1 Command

在流建立过程中，如果任何一个设备不再想继续，使用AVDTP_ABORT_CMD 命令发出流建立终止的信号。AVDTP_ABORT_CMD可以在任何状态下使用。

5.16.2 Response

AVDTP_ABORT_RSP 在确认 AVDTP_ABORT_CMD 时发送，如果AVDTP_ABORT_CMD包含无效的SEID，则不发送响应，此时没有 reject。

5.17 Security Control (AVDTP_SECURITY_CONTROL 内容保护)

5.17.1 Command

安全控制命令从INT向ACP发送，用于向ACP发送内容保护 (content protection) 命令。SEID字段值指定ACP中的目标SEP。

5.17.2 Respone

安全控制响应从ACP发送到INT，以确认安全控制命令;它还用于将内容保护控制响应发送给INT。SEID字段值指定ACP中的目标SEP。

5.17.3 Reject

5.18 General Reject (singnal ID无效)

一般拒绝消息由ACP用于响应包含无效信号标识符的命令消息。消息类型应设置为一般拒绝。

5.19 Delay Report (AVDTP_DELAYREPORT 13 报告延迟值)

5.19.1 Command

1、Delay Report命令SNK用来向SRC设备上报SNK设备的延迟值。这使得音频和视频能够同步播放。延迟报告从SNK发送到SRC。因此SNK总是延迟报告过程的INT, SRC总是ACP。这与其他信令命令不同，在这些命令中，INT/ACP角色独立于SRC/SNK角色。

2、延迟值 (delay value) 是在1/10毫秒内给出的两个字节的值

3、SEP配置完成后，应立即发送第一个延迟报告。这是在从IDLE/CONFIGURED(连接建立过程)进入OPEN状态之前。

**4、**在发送第一个延迟报告后，当延迟超出先前报告延迟的精度范围时，应发送后续延迟报告。

**5、**SNK侧抖动缓冲区的瞬时填充状态的变化不应直接影响报告的延迟。相反，SNK应该补偿时钟漂移，以保持延迟在报告延迟的精度范围内然而，填充状态可能会间接影响报告的延迟。

6、SNK 的 SEP可以根据蓝牙链路的质量动态改变缓冲区的操作范围，以优化性能和避免音频退出 (audio dropouts)。

**7、**缓冲器的操作范围包括所有被认为是正常抖动变化且不会引起任何时钟漂移补偿动作的填充状态，如帧丢失/复制或播放速度调整。 抖动缓冲区的操作范围的改变是发送延迟报告的唯一原因。

5.19.2 Response

从INT接收AVDTP_DELAYREPORT_CMD后，ACP尝试解析接收到的延迟值。如果解析成功，ACP将发送AVDTP_DELAYREPORT_RSP。

5.19.3 Reject

从INT接收AVDTP_DELAYREPORT_CMD后，ACP尝试解析接收到的延迟值。如果解析失败，ACP将发送AVDTP_ DELAYREPORT _REJ。数据包包含一个错误代码，说明命令被拒绝的原因。

5.20 Information Elements (数据包中携带的信息元素)

5.20.1 Stream End-point IDentifier (SEID, INT SEID, ACP SEID)

这个信息元素为SEP标识一个唯一的标识符。在流会话过程中，SEP连接的每一边都有一个本地SEID。

SEID总是在设备的本地空间中分配。启动信令过程以寻址一个特殊的流端点的设备应该总是使用远程设备的SEID分配。在Discovery过程中，只有ACP设备将自己的SEID分配暴露给INT设备。

当角色改变时，原始ACP希望依次发起信令过程来解决配置的SEP，例如启动或挂起流。为了实现它，原始ACP设备应该知道原始INT设备已在本地分配给编址流端点的SEID。该信息将作为AVDTP_SET_CONFIGURATION_CMD消息的附加信息元素由原始INT设备传输。之后，每个端都能够使用远端设备SEID来寻址流端点。

在所有信令过程中，INT SEID和ACP SEID指的是执行INT响应的设备的SEID。已分配ACP在本程序上下文中的角色。

5.20.2 Length of Service Capability (LOSC)

个人服务能力的总长度。LOSC字段仅提供此LOSC信息元素之后的服务功能的长度。

5.20.3 Stream End-point Type, Source or Sink (TSEP)

该字段表示流的端点是SNK还是SRC。TSEP字段的位赋值如下所示：

0 = Stream End Point (SEP) is of type SRC

1 = Stream End Point (SEP) is of type SNK

5.20.4 Number of Signal Packets (NOSP)

表示在一个分片的信令包中有多少包。

5.20.5 Stream End Point in Use (In Use)

此信息元素指示流端点当前是否在使用中：0 = SEP is Not In Use；1 = SEP is In Use

5.20.6 Signaling Errors (ERROR_CODE)

Error ID	相关的 Signaling Command
0x01	All messages	BAD_HEADER_FORMAT	数据包的报头格式错误
0x11	All messages	BAD_LENGTH	请求报文长度与规定长度不匹配
0x12	All messages	BAD_ACP_SEID	请求的命令指示无效(不可寻址)的ACP SEID
0x13	Set Configuration	SEP_IN_USE	SEP 正在使用中
0x14	Reconfigure	SEP_NOT_IN_USE	SEP 没有在使用
0x17	Set Configuration / Reconfigure	BAD_SERV_CATEGORY	请求报文中的“服务类别”没有在AVDTP中定义
0x18	All messages	BAD_PAYLOAD_FORMAT	请求的命令的有效负载格式不正确(此ERROR_CODE中不指定具体格式错误)
0x19	All messages	NOT_SUPPORTED_COMMAND	请求的命令不被设备支持
0x1A	Reconfigure	INVALID_CAPABILITIES	reconfigure命令只允许重新配置应用服务能力 (编码器、内容保护)
0x22	Set Configuration	BAD_RECOVERY_TYPE	请求恢复的类型在AVDTP中没有定义
0x23	Set Configuration	BAD_MEDIA_TRANSPORT_FORMAT	“Media Transport Capabilities”的格式不正确
0x25	Set Configuration	BAD_RECOVERY_FORMAT	请求恢复的 Service Capabilities 格式不正确
0x26	Set Configuration	BAD_ROHC_FORMAT	报头压缩服务能力的格式不正确
0x27	Set Configuration	BAD_CP_FORMAT	内容保护服务能力的格式不正确
0x28	Set Configuration	BAD_MULTIPLEXING_FORMAT	多路复用服务能力的格式不正确
0x29	Set Configuration	UNSUPPORTED_CONFIGURAION	配置不支持
0x31	All messages	BAD_STATE	指示ACP状态机为了处理信号所以正处于无效状态。这也包括当一个INT接收到一个请求的相同的命令，它正在等待响应的情况

6 Service Capabilities

服务能力指示每个流端点可以提供的可能服务。服务类别是前八位。这是因为如果用户不需要属于特定服务类别的服务能力，则只需要查看前八位元即可跳过该信息。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-siN5TMwe-1684252728313)(D:\BLUETOOTH\a2dp\企业微信截图_20210910161450.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-u7Rc2a66-1684252728314)(D:\BLUETOOTH\a2dp\企业微信截图_20210910162218.png)]

不同类别的服务能力用 Service Category (服务分类)区分。

6.1 Media Transport Capabilities

媒体传输能力是基于rfc3550[2]的，并定义了一些特定的字段。视频和音频服务类别的媒体传输应使用下列服务能力值。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XxoFzWfv-1684252728314)(D:\BLUETOOTH\a2dp\企业微信截图_20210910161756.png)]

6.2 Reporting Capabilities

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IEafM04s-1684252728315)(D:\BLUETOOTH\a2dp\企业微信截图_20210910162415.png)]

6.3 Recovery Capabilities

支持恢复服务的ACP设备应暴露以下传输能力:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UT7IneMN-1684252728315)(D:\BLUETOOTH\a2dp\企业微信截图_20210910163249.png)]

6.4 Media Codec Capabilities

SEP 的媒体编解码器功能有以下格式:

1、媒体类型(Media Type) 和媒体编解码器类型(Media Codec Type) 字段在“蓝牙号码分配”文档中定义，请参见[5]。

2、媒体编解码器特定信息元素(Media Codec Specific Information Elements ) 在相关的AV应用程序配置文件中定义。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qmNNHAt1-1684252728315)(D:\BLUETOOTH\a2dp\企业微信截图_20210910170005.png)]

6.5 Content Protection Capabilities (内容保护)

当ACP设备具有内容保护能力时，流支持的内容保护类型信息将在“内容保护能力”中显示。这些功能还可以包括与内容保护类型相关的字段。

CP_TYPE_MSB 和 CP_TYPE_LSB 是响应，一个信息元素的MSB和LSB部分；

CP_Type 内容保护类型，它是由蓝牙分配号码见[5]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2Tk8YgIQ-1684252728316)(D:\BLUETOOTH\a2dp\企业微信截图_20210910170535.png)]

6.6 Header Compression Capabilities (报头压缩)

标题压缩能力值的定义如表8.54所示。当在 Set Configuration 命令中使用时，它通知 INT是否对某种类型的流(媒体包，恢复包)可用。它还通知INT关于ACP支持回发通道的可能性。

当在Set/Get配置和Reconfigure命令中使用时，位表示是否支持报头压缩服务和应使用。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-auQ7b5Ny-1684252728316)(D:\BLUETOOTH\a2dp\企业微信截图_20210910172357.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-55zpEBhH-1684252728316)(D:\BLUETOOTH\a2dp\企业微信截图_20210910172437.png)]

6.7 Multiplexing Capabilities

如果ACP支持多路复用服务，则在 Respone 中包含表8.56中定义的服务能力字段到INT。INT 如果也支持多路复用服务和同意使用它，使用相同格式的条目 SET_CONFIGURATION_CMD，它可能会改变参数设置。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-26paOdRg-1684252728317)(D:\BLUETOOTH\a2dp\企业微信截图_20210910172623.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0X3uouiB-1684252728317)(D:\BLUETOOTH\a2dp\企业微信截图_20210910172727.png)]

6.8 Delay Reporting Capabilities (延迟报告)

通过从 SEP 提供延迟报告来实现音频和视频的同步播放。

当SRC提供延迟上报功能时，支持延迟上报的SNK必须配置延迟上报功能。这确保了当SNK是流过程的INT时SRC SEP可以使用延迟报告。对于SRC设备，提供/配置延迟报告能力是可选的。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4KdO3jdf-1684252728319)(D:\BLUETOOTH\a2dp\企业微信截图_20210910173111.png)]

7 State Diagrams (状态转换逻辑)

7.1 State Definitions (状态定义)

State	State Name
I00	AVDTP_IDLE	状态机已初始化
I01	AVDTP_CONFIGURED	INT已成功配置ACP的流端点
I02	AVDTP_OPEN	INT和ACP已成功打开流端点
I03	AVDTP_STREAMING	INT和ACP已经成功地在流端点建立了流会话
I04	AVDTP_CLOSING	INT和ACP正在关闭流的端点
I05	AVDTP_ABORTING	INT或ACP请求中止流的建立

GAVDP

Generic Audio/Video Distribution Profile 通用的音/视频分发协议

1. 概述

1.1 GVADP Stack

1.2 角色 Role (INT/ACP)

Initiator (INT) – This is the device that initiates a signaling procedure.

Acceptor (ACP) – This is the device that shall respond to an incoming request from the INT

在下图中，便携式播放器是INT，耳机是ACP。INT发送信令消息signaling messages，例如请求建立连接或控制流。在第一个例子中，ACP应该响应来自INT的传入流建立请求。在第二种情况下，ACP应提供其支持的服务和运输能力等信息。

请再次注意：

1）角色可以互换:便携式播放器可以成为ACP，而耳机表现为INT。它取决于配置文件、应用程序和实现。

2）INT/ACP和SRC/SNK角色是相互正交和独立的，SNK和SRC可以是ACP或INT

1.3 应用场景

1、设置两个设备实现A/V数据流从一端流到另一端，然后用蓝牙事务连接这些设备。

2、控制已建立的 streaming （L2CAP 支持的 Streaming Modes）

2. AVDTP 互操作性需求 Interoperability Requirements

2.1 Signaling Procedures

本节介绍信令实体signaling entity 的互操作性要求。

在使用AVDTP时，GAVDP的用户会接触到以下三个状态:

1、IDLE：没有建立 streaming 连接的初始状态，用于 signaling 的L2CAP channel 已经 open。

2、OPEN：两台设备之间的 streaming 连接已经建立

3、STREAMING：两个设备都准备好 streaming

下图显示了这三个状态之间可能出现的转换：

2.1.1 Connection Establishment

2.1.2 Start Streaming

2.1.3 Connection Release

2.1.4 Suspend

2.1.5 Change Parameters

2.1.6 Signaling Control

2.1.7 Security Control

2.1.8 Delay Reporting

2.1.8.1 原理

1、SNK设备向SRC发送延迟报告（缓冲、解码、渲染等延迟），延迟上报命令由SNK设备通过AVDTP信令通道发送到SRC设备。

2、SRC设备收到延迟报告后，负责保持音频和视频同步，进行补偿延迟差异

1）首先启动延迟值较高的流来实现。

2）第二个流以与两个设备的延迟差相对应的延迟启动。例如，可以通过延迟差来改变发送视频帧的视频时间戳值来解决延迟值的变化问题。

2.1.8.2 Use Case 使用案列

第一个用例是解决了用户看视频时音画不同步的问题。用户体验到由于解码、缓冲或传输造成的延迟，音频和视频没有同步。延迟报告机制改善了本地视频回放和通过蓝牙链路的音频流之间的同步。

第二个用例是音频和视频都通过 Steam 传输出去，每个都传送到不同的设备。例如，在车内场景中，视频流到后排显示器，而音频流到耳机。

2.1.8.3 延迟的定义，延迟允许范围

从在SRC插入流帧到 SNK呈现帧的总延迟由三部分组成：SRC延迟、传输延迟、SNK延迟，如图3.12所示。

延迟的允许范围：正值表示音频领先于视频
音频和视频之间允许的最大显示延迟	+80/-150 ms
音频和视频之间推荐的显示延迟	+35/-95 ms
报告SNK延迟的最大允许偏差	+/- 30 ms
建议报告SNK延迟偏差	+/- 15 ms

A2DP

Advanced Audio Distribution profile 高质量音频分发协议

1. 概述

此 profile 定义了支持 A2DP 的蓝牙设备所需的要求。通过定义 Audio Distribution 应用模型中蓝牙设备之间互相操作时所需的功能和程序( features and procedures )，这些要求以终端用户服务services 的形式表示。

1.1 范围 Scope

A2DP 定义了在 ACL 通道上实现高质量 单声道mono 或 立体声stereo 音频内容分发的协议和程序。因此，术语 “advanced

audio高级音频” 应与 “Bluetooth audio蓝牙音频” 区分开来，后者表示在蓝牙基带规范第 12 章中定义的 SCO 信道上的窄带语音 (narrow band voice) 。

1.1.1 包括

典型的使用案例是将音乐内容从立体声音乐播放器流式传输到耳机或扬声器。 音频数据以适当的格式压缩以有效利用有限的带宽。

1.1.2 不包括

环绕声分发 Surround sound distribution 不包括在此配置文件的范围内。
A2DP 不包括远程控制功能。设备可以通过实现 AVRCP 来支持远程控制功能
A2DP 专注于音频流，而 视频分发配置文件 ( Video Distribution Profile VDP) 处理视频流。对这两种配置文件的支持使我们能够分发带有高质量音频的视频内容。 VDP 中描述了视频和音频流的使用案例。

2 和其他 profile 的依赖关系

如下图所示，A2DP 依赖于通用访问配置文件 (GAP) 以及通用音频/视频分发配置文件 (GAVDP) [3]，后者定义了设置音频/视频流所需的程序。 A2DP 定义了特定于音频流的参数和程序。除非另有明确说明，否则 GAP 和 GAVDP 中定义的术语、用户界面和程序适用于本配置文件。

2.1 A2DP Profile Stack

在 A2DP Profile 中用到的 protocols协议和实体entities：

2.2 角色 Role (Sourec/Sink)

为实现此配置文件定义了以下设备角色：
源 (Source SRC)：当设备充当传送到微微网 SNK 的数字音频流的源时，设备就是 SRC。

接收器（Sink SNK）：当设备充当从同一微微网上的 SRC 传送的数字音频流的接收器时，它就是 SNK。

下图描述了此配置文件角色的配置示例：

2.3 用户需求和场景

此配置文件涵盖以下场景：
• 设置/控制/操作从 SRC 到 SNK 的音频数据流。以下限制适用于此配置文件：

配置文件不支持同步点对多点分发。
SRC和SNK之间由于无线电信号处理、数据缓冲和流数据的编码/解码存在一定的延迟。应对此类延迟的影响取决于实施。

此配置文件中设置了以下要求：

音频数据速率应充分小于蓝牙链路上的可用比特率。这是为了允许重传方案减少数据包丢失的影响。
配置文件不排除任何内容保护方法。

3. 应用层 Application Layer

应用层的主要功能就是 audio streaming

3.1 Audio Streaming 对设备特性的要求

如果远程设备的 AVDTP 版本未知，则设备应执行 SDP 查询以获取远程设备上的 AVDTP 版本。这应在执行 GAVDP_ConnectionEstablishment 程序之前执行。这是必需的，因为音频流设置过程中的某些命令取决于 AVDTP 版本。

当设备希望开始 streaming 传输音频内容时，设备首先需要建立 streaming 连接。信令程序Signaling procedures 和典型的信令流程signaling flows 分别在 GAVDP [3] 的第 4.1 节和附录 A 中说明。在这样的设置过程中，设备选择最合适的音频流参数。配置了两种服务；一个是应用服务能力，一个是传输服务能力。

3.1.1 应用服务能力

提供给应用层的服务。例如：

(1)编解码器的协商和配置（音频编解码器互操作性的要求和编解码器参数的详细信息，例如模式、采样频率和比特率）、

(2)内容保护系统

(3)媒体同步支持

3.1.2 传输服务能力

更具体的传输层内与传输相关的“服务”，此能力由 AVDTP 提供。例如：这些包括成帧和分段、封装、交付性能报告、数据包丢失检测、数据包恢复、稳健的报头压缩以及将传输会话复用到传输通道，这些服务的适当配置增加了信道吞吐量。

3.2 Audio Streaming

一旦建立了 Streaming 连接并执行了 GAVDP 中的开始 Streaming Procedure，SRC 和 SNK 都处于 STREAMING 状态，其中 SRC (SNK) 准备发送（接收）音频流。SRC 使用 Send Audio Stream 程序将音频数据发送到 SNK，SNK 又使用 Receive Audio Stream 程序来接收音频数据。
这些过程的框图和创建的数据包格式如图 3.1 所示。在第 4 章中，还指定了 AVDTP 标头和媒体负载格式中的音频特定参数。
再次注意，设备应处于 STREAMING 状态以发送/接收音频流。如果 SRC/SNK 希望发送/接收音频流而状态仍处于 OPEN，则 SRC/SNK 应启动 GAVDP 中定义的开始流传输过程。

4. 音频编解码器互操作性要求 Audio Codec Interoperability Requirements

4.1 概述

1、Audio codec capabilities 定义了流设置中信令过程所需的能力域及其参数。GAVDP的相关程序是建立连接和更改参数程序

2、媒体包头要求在媒体包头中定义了编解码器的特定参数，这些参数必须添加到AVDTP实体中的媒体有效负载中。(见图3.1)

3、媒体有效载荷格式在AVDTP包中定义了编解码器特定的有效载荷格式，在3.2节的音频流过程中应使用。另见图3.1

4.2 支持的 Audio Codec

Codec Type	Support	Ref.
SBC
MPEG-1,2 Audio
MPEG-2,4 AAC
ATRAC family

4.2.1 强制支持的 (Mandatory) Codec - SBC

A2DP 要求低复杂度子带编解码器 (SBC) 来确保互操作性。当设备为 SRC 时，设备应实现 SBC 编码器，当设备为 SNK 时，应实现 SBC 解码器。

除了 SBC 其它的编解码格式都是非强制的。

4.2.2 Optional Codec

该设备还可以支持可选编解码器以最大限度地提高其可用性。当 SRC 和 SNK 都支持相同的 Optional 编解码器时，可以使用该编解码器代替 Mandatory 编解码器。此配置文件支持的可选编解码器在表 4.1 中列出，并在蓝牙分配编号 [8] 中另外定义。为保持互操作性，应应用第 4.2.4 节中的要求。
对于蓝牙分配编号 [8] 中列出但本规范未描述的所有可选编解码器，该列表包含有关如何获取有关编解码器特定信息元素、媒体包头要求和所有其他编解码器特定信息的信息的信息。

4.2.3 厂商专用 (Vendor Specific) A2DP Codecs

设备可能支持其他编解码器，如供应商专用A2DP编解码器。特定于供应商的A2DP编解码器的用户(以下简称供应商)将需要定义在A2DP中使用编解码器所需的参数和其他信息。配置文件没有为特定于供应商的A2DP编解码器指定任何东西，然而，强加了以下要求:

1、为保持互操作性，应应用第4.2.4节的要求

2、当满足4.2.2节中可选的编解码器要求以及以下要求时，厂商专用A2DP编解码器可以升级为可选

3、建议的编解码器应在正式的互操作性(IOP)测试会议中成功测试：

1）成功测试编解码器意味着至少有两个源和两个接收器实现必须向BARB提供所提议的编解码器已成功实现的证据

2）正式的IOP测试计划应在正式的IOP测试前提交给BARB，并由BARB批准

4、适用于拟议编解码器的任何许可应在公平合理的条款下提供，并以非歧视的方式获取。拟议编解码器的规格应向所有计划实施编解码器的公司提供，如有需要，应根据NDA

5、如果厂商专用A2DP编解码器升级为可选，它只会在蓝牙中列出分配的号码[8]，不在这个或未来的配置文件版本

4.2.4 Codec Interoperability Requirements 互操作性要求

当SRC希望发送SNK不支持编解码器格式的音频数据时，应将该数据转编码为SBC。因此，当SRC支持非强制编解码时，需要满足以下要求：

只有SNK不支持格式的SRC输入才需要转码到SBC，例如，当SRC接受非强制性编解码器格式的预编码音频数据时，SRC必须有一个非强制性编解码器以及一个用于转码的SBC编码器。

4.2.5 Audio Codec Type Field Values 类型字段值

有关音频编解码器类型，请参阅蓝牙分配号码[8]。音频编解码器功能的消息格式定义在AVDTP[4]的8.19.5节。

下一节定义蓝牙链路上音频流所需的音频编解码器参数和格式。

4.3 SBC

4.3.1 参考

在这个概要文件中，SBC是必须支持的。SBC规范是蓝牙规范的一部分。编解码规范附在本简介的12(附录B)中

4.3.2 编解码器特定信息元素

在AVDTP的 Get All Capabilities Response中，可以在每个字段中定义/设置一个或多个位。另一方面，在 AVDTP 的 Set Configuration Command 和 Reconfigure Command 中，每个字段只能定义/设置一个比特

4.3.2.1 采样率 (Sampling Frequency)

SNK中的解码器，必须支持44.1 kHz和48 kHz的采样频率

SRC中的编码器应至少支持44.1 kHz和48 kHz中的一种采样频率

表4.2给出了SBC的采样频率场值：(M must 必须、O optional 可选、C1 其中一个)

4.3.2.2 信道模式 (Channel Mode)

SNK中的解码器应支持所有功能 (Mono、Dual Channel、Stereo、Joint Stereo)

SRC中的编码器应至少支持单声道和双通道其中一种（DUAL CHANNEL、STEREO、JOINT STEREO）

表4.3显示了SBC的Channel Mode字段的值：(M must 必须、O optional 可选、C1 其中一个)

4.3.2.3 Block Length (块长度)

SRC和SNK应该支持所有的参数。

表4.4显示了SBC的Block Length字段的值：(M must 必须、O optional 可选、C1 其中一个)

4.3.2.4 Subbands (子频带)

SNK中的解码器应支持所有功能；

SRC中的编码器应支持至少8个子频带

表4.5显示了SBC的子带数量字段的值：

4.3.2.5 Allocation Method (分配方法)

SNK中的解码器应支持所有功能

SRC中的编码器应该至少支持LOUDNESS方法

表4.6显示了SBC的分配方法字段的值：

4.3.2.6 Minimum / Maximum Bitpool Value

4.4 MPEG-1,2 Audio

AVCTP

Audio/Video Control Transport Protocol Specification 音频/视频控制传输协议（以下简称 AVCTP）定义了在一对蓝牙设备之间发出的二进制事务，用于音频/视频 (A/V) 功能的发现和控制

1.缩写

CT	controller，AVCTP 中发送 Message 的一方
TG	target，AVCTP 中接收 Message 的一方
PID	Profile Identifier 配置文件标识符，在 AVCTP 支持多路协议复用时用来区分不同的 Profile。

2. 概述图

2.1 Operations between Devices

2.2 Operations between Layers

3. AVCTP Generic Transaction Model 通用事务模型

3.1 概念定义

3.1.1 AVCTP transtaction

命令消息和可能的响应消息在两个兼容设备之间交换的过程称之为 AVCTP的事务。

3.1.2 CT (controller)

通过发送命令消息来启动AVCTP事务的设备称为控制器(CT)

3.1.3 TG (target)

命令消息被传输到被称为此事务的目标(TG)的远程设备。目标根据目标的条件或发起的事务的类型，向控制器返回零个或多个响应

3.2 AVCTP的基本要求

1、AVCTP事务要求必须在交互的一对设备之间建立ACL链接。AVCTP事务是在设备之间建立的面向连接的通道上执行的，这些事务由在该通道上传输的双向消息组成。

**2、**AVCTP事务使用的L2CAP通道按照[1]的过程使用标准L2CAP服务进行设置、配置和释放。AVCTP提供完整的L2CAP通道服务封装，确保对等设备之间每个PSM (Protocol/ service Multiplexer)只有一个通道连接用于此目的。

3、两台设备之间可能存在多个AVCTP连接。每个AVCTP连接都有自己的L2CAP通道和唯一的PSM值。每个ACL每个PSM应该只有一个AVCTP连接；

4、在AV设备中，控制可能存在于连接的两边。由于这个原因，AVCTP应该能够在连接的两端同时支持控制器和目标功能

3.3 Transaction Procedure

CT 通过向 TG(作为事务目标的远程设备) 发送命令来启动事务。一个完整的AVCTP事务由 一条包含指向目标的命令的消息 和 零条或多条包含目标返回给控制器的响应的消息 组成。 AVCTP既不控制命令/响应消息序列，也不定义描述控制器和目标行为的规则; 这些规则由使用AVCTP传输服务的控制配置文件定义。

3.4 位和字节序的约定

在本规范(specification)中，图纸和表格中最左边的位置表示相应字节或字段的MSB；

当在一个字节中包含多个位域并在绘图中表示时，较有意义的(高阶)位向左显示，较无意义的(低阶)位向右显示；

当垂直绘制时，多字节字段表示为向上的更有意义的字节(高阶)和向下的较无意义的字节(低阶);当水平绘制时，较有意义的字节(高阶)向左表示，较无意义的字节(低阶)向右表示;

3.5 Message 服务的局限性

在此事务模型中，响应消息不是强制的。

目标是否返回一个或多个响应消息取决于应用程序，而不取决于传输的可靠性。消息服务是一种传输服务，仅确保传递的消息的完整性。在不可靠的ACL链接上，传输可能会失败，在这种情况下，由应用程序决定是否重新传输完整的消息。换句话说，当响应消息不被强制时，命令的实际确认不受协议本身的监督。

4. AVCTP Message Services 消息服务

4.1 概述 overview

每个AVCTP命令或响应消息在一个或多个AVCTP包中传输，AVCTP数据包由包头部分和可变长度消息信息部分组成。由于AVCTP包不包含长度信息，它们依赖于L2CAP包长度字段来分隔所传输的包：因此，每个AVCTP包必须在一个L2CAP包上传输。

**Message Header 报头部分：**包括一个事务标签 (transaction label)，唯一地标识在命令/响应流中具有有限范围的事务，以及提供消息碎片支持的包类型信息。

**Message Information 消息信息部分：**带有流方向指示符 ( flow direction indicator)、概要上下文信息的命令或响应数据(参见6.2节)。

4.2 事务标签 Transaction Labeling

每个AVCTP命令/响应消息都由一个事务标签字段标识，事务标签字段是一个4位字段。所有的标签值都是有效的，并且所有的值必须被所有的AVCTP实现接受。

在控制器和目标端，事务标签的处理依赖于应用程序，因此本规范中没有定义。 AVCTP使用目的实体中的交易标签来识别属于同一消息的AVCTP包:应用程序应提供标签值，以便区分不同消息的包。

事务标签绑定在L2CAP通道上，即不同L2CAP通道上的同一个事务标签属于不同的消息。

4.3 消息分片 Message Fragmentation

在AVCTP事务模型中，大多数命令或响应消息作为单个L2CAP包的有效负载进行传输。有时，为了在多个L2CAP包上传输大消息，AVCTP需要将其分片，所需的L2CAP包的数量取决于通道根据[1]中的过程协商的最大传输单元(MTU)。

4.3.1 传输的可靠性

L2CAP通道保证单个AVCTP包的完整性和以正确的顺序传递，而不是整个消息的完整性。由于信道可能不可靠，序列中的一些AVCTP包可能会丢失。由于起始包提供了重组完整报文所需的AVCTP包的数量，AVCTP接收实体应实现一致性检查，丢弃任何不完整的报文。

4.3.2 传输注意事项

由于AVCTP包可以在不可靠的ACL连接上传输，因此AVCTP发送端需要在第一个包消息信息的前面插入目的端预期的包数。分片报文必须在同一L2CAP通道上完全传输。不允许不同报文的分片交错。

4.3.3 分片传输时的三种分片包

Packet_Type字段(参见章节6.1.2)将每个L2CAP包设定为 first (Packet_Type=01)、continue (Packet_Type=10) 或 end packet (Packet_Type=11)

分片消息的接收方根据起始包长度和第一个包提供的包信息元素的数量分配用于消息重组的资源。因为这个原因:

**1、**起始包和继续包的L2CAP包的有效载荷长度应该相同；

**2、**结束包的L2CAP报文的有效载荷不能大于同一消息的开始包和继续包；

4.4 支持协议复用 Multiple Profiles Support

配置文件标识符 (Profile Identifier, PID) :

应用程序使用AVCTP在应用程序之间透明地传递控制消息。根据配置的复杂性，控制器和目标可能支持不同的配置文件和不同的使用规则，所以 AVCTP使用配置文件标识符 (Profile Identifier) 的概念来允许应用程序区分与不同配置文件相关的消息。

CT 选择 PID 值并插入到 Message 中，然后发送 Message：

当 CT 的应用程序想要根据一些配置文件规则发起一个事务时，它首先为这个配置文件选择合适的PID值，并将这个值传递给AVCTP，以便在要发送的 Command Message 前面插入(参见6.2节)。

TG 收到 Message 之后根据PID相关的 profile rule 去对 Message 进行解码：

如果接收到的PID值在系统支持的范围内，则 TG 会根据相关的配置文件规则对命令消息进行解码。在它的响应中，TG 的应用程序必须表明收到的匹配命令的PID值，以便控制器可以使用相同的规则解码响应消息。

4.5 AVCTP Message Type (Command/Respone)

Message Type分为 Command 和 Respone，因为设备可能在同一应用程序中支持 CT 和 TG 两种角色，所以 Message Type 用来在分配的设备角色相关的命令/响应流中提供区分。

4.6 AVCTP Message Size Information

由于L2CAP支持可变有效载荷长度，因此AVCTP包中不需要额外的长度信息。

5. AVCTP Channel Management Services 通道管理服务

5.1 Channel Establishment and Profile Registration (通道建立和协议注册)

在AVCTP配置中，支持控制器功能的设备还负责根据应用程序的请求初始化L2CAP通道连接。

由于连接的双方可能支持一个主动控制器或不同配置文件的控制器，所有AVCTP实现都应包括一个通道管理实体，以解决冲突的请求，并应确保每个PSM值只在对等实体之间连接一个通道。

5.2 Channel Release and Profile De-registration (通道释放和协议注销)

从本质上讲，AV设备之间的控制交易是零星的；因此，目标可以在远程端控制器应用程序仍在使用通道或在另一个控制配置文件仍在使用通道时请求释放通道。这可能会导致目标在下一次用户命令时一段时间内没有响应，因为需要首先由控制器端重新建立通道。

因此，每个AVCTP实体负责在每个概要文件的基础上在本地注册/注销通道连接使用。

6. AVCTP Message Format 消息格式

6.1 AVCTP Packet Headers 包头

AVCTP Message 是支持分片传输的，所以报头格式取决于是否分片传输 (Fragmentation)。

6.1.1 Non-Fragmented AVCTP Message (没有分片传输的消息)

1	Transaction label	值由应用程序提供
2	Packet_type	设置为 00，表示命令/响应消息以单个L2CAP包传输
3	C/R (Command 0/Respone 1)	值由应用程序提供，表示消息传递的是 Command (0) 还是 Respone (1)
4	IPID (Invalid Profile Identifier)	在响应消息中设置IPID位，表示在同一事务的命令消息中收到无效的配置文件标识符(PID)；否则这个位被设为零。在命令消息中，这个位被设为零
5	PID (Profile Identifier)	表示命令/响应帧是根据被标识的Profile定义的规则进行编码的。该值是在Bluetooth Assigned中为这个配置文件定义的服务类的16位UUID

6.1.2 Fragmented AVCTP Message (分片传输的消息)

1	Transaction label	值由应用程序提供
2	Packet_type	start packet (Packet_Type=01)、continue packet (Packet_Type=10) 、 end packet (Packet_Type=11)
3	C/R (Command 0/Respone 1)	值由应用程序提供，表示消息传递的是 Command (0) 还是 Respone (1)
4	IPID (Invalid Profile Identifier)	同上
5	RFA	保留字段，此字段代替继续或结束报文中的IPID字段。它为以后的添加保留，并应设置为零(0)
6	Number of AVCTP Packets	在每个起始包中，表示属于同一消息的AVCTP包的总数。由于起始报文也被计算，所以该值总是大于1