Android Bluetooth HFP

本篇blog结合日志来分析HFP，以手机连接上耳机后，打电话为例，来分析HFP的过程。

1. HFP

基于Hands-Free Profile 1.8 – Bluetooth® Technology Website文档。

本文档定义了实现免提配置文件的设备应使用的协议和程序。此类设备最常见的示例是与蜂窝电话或可穿戴无线耳机一起使用的车载免提装置。该配置文件定义了支持免提配置文件的两个设备应如何在点对点的基础上相互交互。

免提配置文件（HFP）的实现通常使耳机或嵌入式免提单元能够无线连接到蜂窝电话，以充当蜂窝电话的音频输入和输出机制，并允许典型的电话功能在没有访问实际电话的情况下执行。

1.1 Profile Introduction

 如图 1.1 所示，免提配置文件依赖于串行端口配置文件（SPP）和通用访问配置文件（GAP）。

图 2.1 显示了此配置文件中使用的协议和实体。

免提控制是负责免提单元特定控制信令的实体；这个信号是基于 AT 命令的。

尽管在上面的模型中没有显示，但此配置文件假定免提控制可以访问一些较低层的过程（例如，同步连接SCO建立）。

图 2.1 所示的音频端口仿真层是在 Audio Gateway 上仿真音频端口的实体，音频驱动程序是免提单元中的驱动软件。

对于图 2.1 中的阴影协议/实体，SPP用作基本标准。对于这些协议，SPP中规定的所有强制性要求都适用，除非在本规范明确说明偏差的情况下。

图 2.2 显示了适用免提配置文件的典型设备配置。

• 音频网关 (AG) – 这是作为音频网关的设备，用于输入和输出。充当音频网关的典型设备是蜂窝电话。
• 免提单元 (HF) – 这是充当音频网关的远程音频输入和输出机制的设备。它还提供了一些远程控制手段。

1.2 Service Level Connection Establishment

根据用户动作或内部事件，HF 或 AG 都可以启动服务级别连接建立过程。服务级别连接的建立需要存在 RFCOMM 连接，即 HF 和 AG 之间的 RFCOMM 数据链路通道。

HF 和 AG 都可以发起 RFCOMM 连接建立。如果 AG 和 HF 之间没有 RFCOMM 会话，则发起设备应首先初始化 RFCOMM。

RFCOMM 连接建立应按照 GAP 的第 7.3 节和 SPP 的第 3 节中的描述执行。

如下为服务级别连接建立的过程，涉及到很多的AT Command，这部分内容可以参考HFP的4.34和4.35节。

2. RFCOMM

基于https://www.bluetooth.com/specifications/specs/rfcomm-1-2/文档。

RFCOMM 协议通过 L2CAP 协议提供串行端口的仿真。该协议基于 ETSI 标准 GSM 07.10。

RFCOMM 是一种简单的传输协议，具有模拟 RS-232 (ITU-T V.24) 串行端口的九个电路的附加条款。 RFCOMM 协议支持两个蓝牙设备之间最多 60 个同时连接。蓝牙设备中可以同时使用的连接数是特定于实现的。

RFCOMM 旨在涵盖使用其所在设备的串行端口的应用程序。在简单配置中，通信段是从一个设备到另一个设备的蓝牙链路（直接连接），见图 1.2。

2.1 Terms and Abbreviations

2.2 RFCOMM Service Overview

2.2.1 RS-232 Control Signals

RFCOMM 模拟 RS-232 接口的九个电路。

2.2.2 Null Modem Emulation

RFCOMM 基于 GSM 07.10。当涉及到非数据电路的状态传输时，GSM 07.10 不区分 DTE 和 DCE 设备。

 当两个同类设备连接在一起时，GSM 07.10 传输 RS-232 控制信号的方式会创建一个隐式零调制解调器。图 2.1 显示了当两个 DTE 通过 RFCOMM 连接时创建的空调制解调器。没有单一的零调制解调器电缆布线方案适用于所有情况；但是，RFCOMM 中提供的空调制解调器方案在大多数情况下应该可以工作。

2.2.3 Multiple Emulated Serial Ports

数据链路连接标识符 (Data Link Connection Identifier，DLCI) GSM 07.10 标识客户端和服务器应用程序之间正在进行的连接。 DLCI 由 6 位表示，但其可用值范围为 2…61；在GSM 07.10中，DLCI 0是专用控制信道，DLCI 1由于Server Channels的概念不可用，DLCI 62-63被保留。 DLCI 在两个设备之间的一个 RFCOMM 会话中是唯一的。 

如果蓝牙设备支持多个模拟串行端口并且允许连接在不同的蓝牙设备中，那么 RFCOMM 实体必须能够运行多个 GSM 07.10 多路复用器会话，见图 2.3。请注意，每个多路复用器会话都使用自己的 L2CAP 通道 ID (CID)。运行 GSM 07.10 多路复用器的多个会话的能力对于 RFCOMM 是可选的。

考虑到客户端和服务器应用程序都可能驻留在 RFCOMM 会话的两侧，并且任一侧的客户端彼此独立地建立连接，DLCI 值空间使用 RFCOMM 服务器的概念在两个通信设备之间划分通道和方向位。 RFCOMM 服务器通道号是 GSM 07.10 帧中地址字段的 DLCI 部分比特的子集。

C/R（命令/响应）位将帧标识为命令或响应。根据 HDLC 规则，命令帧包含它被发送到的数据链路连接实体的地址，而响应帧包含发送该帧的数据链路连接实体的地址。对于给定的 DLC，地址字段的 DLCI 值保持不变，但 C/R 位发生变化。

根据 ISO/IEC 13239:1997 的规则，地址字段的范围可以通过使用 EA 位来扩展。当 EA 位在一个八位字节中设置为 1 时，表示该八位字节是地址字段的最后一个八位字节。当 EA 位被设置为 0 时，它表示地址字段的另一个八位字节跟随。在本文档中只有一个地址八位字节，因此 EA 位始终设置为 1。请注意，本文档（GSM 07.10）的未来修订可能会扩展地址字段并使用 EA 位。

向 RFCOMM 服务接口注册的服务器应用程序被分配一个范围为 1…30 （5位二进制，去除全0和全1的剩余）的服务器通道号。 [0 和 31 不应使用，因为相应的 DLCI 在 GSM 07.10 中保留]。

对于 RFCOMM 会话，启动设备被赋予方向位 D=1（反之，在其他设备中 D=0）。请注意，这里的D标志位处于低位，Server Channel处于高位。

在现有 RFCOMM 会话上建立新的数据链路连接时，方向位与服务器通道一起使用，以确定用于连接到特定应用程序的 DLCI。此后，此 DLCI 用于端点之间双向的所有数据包。

实际上，这对 DLCI 值空间进行了分区，以便在 DLCI 2、4、6、…、60 （1~30左移一位）上可以访问非启动设备上的服务器应用程序；在 DLCI 3、5、7、…、61 （上述基础上，最低位置1）上可以访问启动设备上的服务器应用程序。 （请注意，对于支持与两个或更多设备同时进行多个 RFCOMM 会话的设备，方向位可能在所有会话上都不相同）。

RFCOMM 实体在现有会话上创建新的 DLC，通过组合另一个设备上的应用程序的服务器通道和会话的自身方向位的反转来形成 DLCI。

DLCI 1 和 62-63 被保留，在 RFCOMM 中从未使用过。

2.3 Service Definition Model

2.4 GSM 07.10 Subset Supported by RFCOMM

2.4.1 Frame Types

表 4.1 显示了 RFCOMM 支持的 GSM 07.10 帧类型：

SABM 命令应用于将寻址站置于异步平衡模式（ABM），其中所有控制字段的长度应为一个八位字节。报告站应在第一次机会时通过发送 UA 响应来确认接受 SABM 命令。接受此命令后，DLC 发送和接收状态变量应设置为零。

UA 响应应由工作站用于确认接收和接受 SABM 和 DISC 命令。

DM 响应应用于报告站与数据链路逻辑断开的状态。当处于断开模式时，不接受任何命令，直到断开模式因收到 SABM 命令而终止。如果在断开模式下收到 DISC 命令，则应发送 DM 响应。

DISC 命令应用于终止先前由命令设置的操作或初始化模式。它应用于通知一个站，另一个站正在暂停操作，并且该站应采取逻辑断开模式。在执行命令之前，接收站应通过发送 UA 响应来确认接受 DISC 命令。另外，在 DLCI 0 发送的 DISC 命令与多路复用器关闭命令具有相同的含义。

UIH 命令/响应应用于发送信息而不影响任一站的 V(S) 或 V(R) 变量。 UIH 用于传输信息的完整性不如将其传送到正确的 DLCI 的情况。对于 UIH 帧，FCS 应仅在地址、控制和长度字段上计算。 UIH 命令/响应的接收不是数据链路程序验证的序列号；因此，如果在命令的受保护部分传输期间发生数据链路异常，则 UIH 帧可能会丢失，或者如果在对命令的任何回复期间发生异常情况，则 UIH 帧可能会重复。没有对 UIH 命令/响应的指定响应。

2.4.2 Commands

 GSM 07.10 定义了一个具有专用控制信道 DLCI 0 的复用器。控制信道用于在两个复用器之间传送信息。 RFCOMM 支持 GSM 07.10 中的以下命令：

3. 日志分析

以一台手机A给另一台手机B打电话为例，手机B连接蓝牙耳机，日志文件由手机B提供。

基于日志文件：https://download.csdn.net/download/hihan_5/86814431分析（本日志价值2毛的电话费）。

首先明确AG和HF在本次例子中的角色。AG-手机B，HF-手机B连接的蓝牙耳机。

3.1 Open Channel & Send Modem Status Command

打开两个设备之间的第一个仿真串口连接的设备（即发起者）负责建立多路复用器控制通道。它应

• 使用 L2CAP 服务原语建立到对等 RFCOMM 实体的 L2CAP 通道；
• 通过在 DLCI 0 上发送 SABM 命令启动 RFCOMM 多路复用器，并等待对等实体的 UA 响应；

在这些步骤之后，可以建立用户数据流量的 DLC。

Frame#1087，由启动设备发出SABM command，L2CAP分配CID0x2040给到RFCOMM。

Address Field从高位到低位的顺序，Server Channel为0b00000，D为0b0，C/R为0b1，EA为0b1，最后合起来就是0x03。

Frame Type为set SABM Command，P/F为0b1，组合起来就是0b00111111，即0x3f。

Frame#1091为Slave回复的UA，P/F为0b1，组合起来就是0b01110011，即0x73。

Frame#1092 1096是Master和Slave之间通过UIH Command/Response进行的参数协商（Parameter Negotiation，PN）。

PN 命令在 GSM 07.10 中被指定为可选，但它必须用于符合蓝牙规范版本 1.2 及更高版本的 RFCOMM 实现。该命令应至少在 RFCOMM 会话上创建第一个 DLC 之前使用，并且发起者必须尝试启用基于信用的流量控制的使用。

Modem Status Command设计用于将虚拟 V.24 控制信号传送到数据流，这是通过发送 MSC 命令来完成的。 MSC 命令具有一个强制控制信号字节和一个可选中断信号字节。此命令仅在选择基本选项时相关。

 Frame#1102是Master发出的Modem Status Command。（注意，这些command/response怎么看呢，可以选择相同的server channel，然后按照Frame的先后顺序看）

3.2 AT Command

参数协商后，Master又发起了新的DLC建立，创建了用于HFP的RFCOMM Channel。

后续就是 Service Level Connection建立的过程了。

（1）AT BRSF

• AT+BRSF (Bluetooth Retrieve Supported Features)

Syntax: AT+BRSF=<HF supported features bitmap>
通知 AG HF 中可用的支持功能，并请求有关 AG 中支持的功能的信息。方向：HF --> AG。

•  +BRSF (Bluetooth Retrieve Supported Features)

Syntax: +BRSF: <AG supported features bitmap>

AG响应AT+BRSF命令发送的结果码，用于通知HF AG支持哪些功能。方向：AG --> HF。

 Frame#1109 1110 1111为AT BRSF一轮过程。

 （2）AT BAC

• AT+BAC (Bluetooth Available Codecs)

Syntax: AT+BAC= [<u1>[,<u2>[,...[,<un>]]]] (u1,u2, ..., un are a codec IDs)

此命令通知远程设备 (AG) HF 支持哪些编解码器（参见表 3.3）。必须始终包含强制窄带编解码器 (CVSD) 的编解码器 ID。如果支持宽带语音，则应包括强制编解码器 (mSBC)，除非它暂时不可用。只要首先包含强制性编解码器，任何其他可选的宽带语音编解码器也可以包含在此列表中。

 Frame#1114 1115是AT BAC的一组流程。

 （3）AT CIND

标准的指示器更新 AT 命令。只有读取指令 AT+CIND？和测试命令 AT+CIND=?要求在本规范中实现。

AT+CIND? 读取命令用于获取 AG 指示器的当前状态。AG 应返回 AT+CIND=? 命令中列出的所有指示器。

使用 AT+BIA 命令关闭任何指示器对 AG 响应 AT+CIND？读取命令没有影响。

AT+CIND=? 测试命令用于检索 AG 支持的每个指示器与其对应的区间和索引之间的映射关系。在使用与这些指示器相关的任何其他命令（AT+CIND? 或 AT+CMER）之前，应至少发出一次。HFP将 AG 返回的指示器数量限制为最多 20 个。

Frame#1118 1119 1120为一轮AT+CIND=?的一轮流程，是HF检索AG支持的指示器。

 Frame#1123 1124 1125为一轮AT+CIND?的一轮流程，是HF查询AG指示器的状态。

（4）AT+CMER

标准事件报告激活/停用 AT 命令。 AT+CMER=[<mode>[,<keyp>[,<disp>[,<ind> [,<bfr>]]]]]命令中，只有<mode> 和<ind>参数与这个规范相关。本规范仅涵盖它们的值 <mode>=(3) 和 <ind>=(0,1)。

以下示例显示了如何 使用 AT+CMER 命令激活或停用“指标事件报告”结果代码： AT+CMER=3,0,0,1 激活“指标事件报告”。 AT+CMER=3,0,0,0 停用“指标 事件报告

Frame#1128 1129为一轮AT+CMER流程，使能指示器状态上报。

  

（5）AT+CHLD

标准呼叫保持和多方处理 AT 命令。在 AT+CHLD=<n> 命令中，本规范仅涵盖 <n> 的值 0、1、1<idx>、2、2<idx>、3 和 4，其中

0 = 释放所有保持的呼叫或将用户确定用户忙 (User Determined User Busy，UDUB) 设置为等待呼叫。

1 = 释放所有活动呼叫（如果存在）并接受另一个（保持或等待）呼叫。

1<idx> = 释放指定索引的调用 (<idx>

2 = 保持所有活动呼叫（如果存在）并接受另一个（保持或等待）呼叫。

2<idx> = 使用指定呼叫（<idx>）请求私人咨询模式。 （将所有呼叫置于保持状态，<idx> 指示的呼叫除外。）

3 = 将保持的呼叫添加到对话中。

4 = 连接两个呼叫并断开用户与两个呼叫的连接（显式呼叫转移）。对于 HF，支持此值及其相关功能是可选的。

如果同时存在保持呼叫和等待呼叫，则上述程序适用于冲突情况下的等待呼叫（即，不适用于保持呼叫）

测试指令 AT+CHLD=?可用于检索有关 AG 中可用的呼叫保持和多方服务的信息。

Frame#1131 1132 1133为一轮AT+CHLD的流程，检索“三方呼叫”信息。

某个时刻起，有一个电话呼入。

（6）+CIEV

标准的“指示器事件报告”主动结果代码。

在+CIEV:<ind>,<value>结果码中，只有上述AT+CIND命令中说明的指示器与本规范相关，其中： - <ind>：指示器在从AG检索的列表中的指令索引用 AT+CIND=?命令。列表的第一个元素应具有 <ind>=1。

- <value>：指标的当前状态。

如果 HF 接收到任何未知的指示器或值，它将忽略它。

 紧接着一个RING提示。

 后续通过CLIP上报电话号码，以及重复的振铃，直到电话接听或者挂断。