蓝牙协议--HFP协议--转

　

hfp

HFP协议

目前HFP的使用场景有车载蓝牙，耳机和PDA，定义了AG和HFP两种角色。 

    AG（Audio Gate）音频网关—音频设备输入输出网关 

HF（Hands Free）免提—该设备作为音频网关的远程音频输入/输出机制，并可提供若干遥控功能。

在车载蓝牙中，手机侧是AG，车载蓝牙侧是HF，在Android源代码中，将AG侧称为HFP/AG，将HF侧称为HFPClient/HF。

LMP link:Link Manager (LM)level link over which only Link Manager Protocol (LMP) commands are conveyed

RFCOMM connection:虚拟串口通道存在

Service Level Connection：同步的部分协议栈高层协议，HFP协议层指的是RFCOMM connection，和AG同步。

Service Level Connectioninitialization:AT命令集执行 responses specified by the profile necessary to synchronize thestate of the HF with that of the AG.

Service Level Connectionestablishment:the combined process of establishing the RFCOMM connection, aswell as the necessary device synchronization using Service Level Connectioninitialization.

Synchronous Connection：为全双工音频链接的SCO或者eSCO逻辑link。

Audio Connection：包括音频通路的同步链接

incoming call：表示由Phone Network到AG的通话。

outgoing call：表示由AG到Phone Network的通话。

HF control通信流程  Service Level Connection

AG和HF均可以通过内部或者用户事件发起Service Level连接建立。Service Level Connection建立的前提是RFCOMM已经建立。同样RFCOMM的建立发起者可以是AG或者HF。 

The RFCOMM connection establishment shall be performed as described in Section7.3 of  Generic Access Profile [5] and Section 3 of Serial Port Profile [6].

·        支持能力交换 

首先HF发送AT+BRSF=<HF supported features >给AG，目的是首先通知AG其具有的能力，其次接收AG返回的其自身的BRSF能力。

·        Codec协商 

如果HF支持Codec Negotiation特征，其会查看AG返回的BRSF中是否也支持该特性，如果都支持该特性，则HF将发送AT+BAC=<HF available codecs >命令给AG以告知其可用的codec。

·        AG Indicator 

HF从AG接收到的BRSF，可以知道AG支持的Indicator，并按顺序拍好，这是因为根据3GPP 27.007规范，AG可以支持Hands-Free不支持的profile。HF使用AT+CIND=?测试命令接收AG支持的indicator以及它们的次序。 

当HF获得必须的Indicator和它们的次序，它将通过AT+CIND?命令取得AG端正在使用indicator的状态。 

当HF取得AG的indicator后，HF会使用AT+CMER使能AG的indicator状态跟新功能，AG会返回OK作为应答。当service，call或者call建立状态发生时，AG将发送和indicator相关的+CIEV结果码给HF。HF根据收到的+CIEV码来跟新其自身内部的indicator。 

AG侧会一直保持indicator状态跟新功能使能直到收到AT+CMER指示其关闭或者HF和AG端的Service Level Connection连接断开。 

当HF使能AG的indicator状态跟新，如果AG和HF都支持呼叫等待（Call waiting）和3方通信（3-waycalling）。HF将发送AT+CHLD=?测试命令取得AG是如何支持这种功能的。如果HF或者AG其中之一不支持三方通信，AT+CHLD=?命令不会被发送。

·        HF Indicator 

如果HF支持HF indicator，其会查看AG是否支持HF indicator。 

如果HF和AG支持HF indicator特性，HF将发送AT+BIND=< HF supported HF indicators >通知HF侧支持的indicator，AG以OK应答。 

当AG接收到HF告知的HF indicator特性，HF将发送AT+BIND=?请求AG侧支持的HF indicator。AG将会以+BIND和以OK结尾的应答。 

当HF接收到AG支持的HF indicator，HF将会发送AT+BIND?命令确定HF目前使能的HF indicator。AG将会一次或多次以+BIND应答和以OK结尾的应答。 

至此HF可能发送AT+BIEV命令告知AG其使能的HF indicator发生变化。 

AG可以使用+BIND使能或者禁止任何HF indicator。\

·        End of Service LevelConnection 

HF需要知道Service Level Connection被完全建立，这可以通过以下几个方式：

·        当且仅当AG通过+BRSF命令告知HF其支持的HFindicator，在HF收到AG通过AT+BIND？命令发来的其支持的HF indicator可认为完全建立。

·        当且仅当SDP服务发现AH和AG双方均支持“Callwaiting and 3-way calling”，在HFAG通过AT+CHLD命令发来的其对呼叫等待和多方电话的支持，对这种情况，HFindicator不要设置该比特位，AG也不要在+BRSF命令中设置该比特位。

·        在HF使用AT+CMER命令成功使能了“Indicator status update”功能，对这种情况SDP服务不应该设置“Call waiting and 3-way calling”比特位。 

如果HF收到AG通过indicator指示当前有电话时，HF查询AG的接听和保持状态来判断是否是未接听电话。 

同样AG侧Service Level Connection完全建立也有几种情况：

·        当且仅当HF indicator在HF被设置且AG侧支持的indicator已经通过+BRSF命令应答，则AG以+BIND加OK结尾的命令应答其使能的HF indicator时可认为Service Level Connection完全建立。

·        当且仅当“Call waiting and 3-waycalling”比特在HF和AG的SDP服务中被置位，在AG通过+CHLD加OK结尾命令成功响应其对呼叫保持和多方电话支持时SLC会被完全建立。对这种情况，+BRSF不应该设置该HF indicator比特位。

·        在AG成功响应AT+CMER命令。

连接丢失恢复

在蓝牙连接丢失时，HF侧会主动重连AG。但当Service Level Connect被用命令主动断开连接时，AG和HF将会在接收到重连命令后等待一个确定时间再重连。

电话建立保持的传输

AT+CMER命令使能了AG侧的“Call Status indicator update”功能。

音频连接建立

HF和AG可以根据用户动作或者内部事件建立音频连接，AH和AG也许需要内部动作来路由，更改采样率，帧/或者音频通路采样对齐。正式点的说法是音频连接建立：

HF在接听电话中能够初始化音频连接建立

HF在无电话时能初始化音频连接建立

HG在接听电话中能够初始化音频连接建立

HG在无电话时能初始化音频连接建立 

音频连接建立过程总是意味着同步连接（Synchronous Connection）建立，并且同步连接和已经建立的SLC是相关的。 

该过程的一个先决条件是，AG和HF之间需要存在SLC，如果不存在则将会先建立这个连接。 

发起者和接收者都将通知新音频连接已经存在。

由AG发起的音频连接建立

当AG侧发起音频连接时，它将初始化编解码器连接建立过程。

HF侧发起音频连接

对于两边都支持编解码器协商特性的场景，由HF发起的建立音频连接将会触发AG确立编解码器连接。这是必须的，因为只有AG知道编解码格式。

当HF发起音频编解码连接建立时，其将发送AT命令AT+BCC给AG。AG在启动编解码建立过程时会发送OK应答，如果不启动编解码时会发送ERROR应答。

编解码连接建立

尽管AG和HF都可以发起建立音频连接，但是编解码和同步连接建立只能有AG侧建立（除非其中一个设备是legacy设备）。 

仅当HF通知AG其支持Codec Negotiation时，AG才会通过当前的SLC发送AT+BAC命令发起CodecConnection。AG会根据HF对AT+BAC的应答来选择合适的Codec connection。

AG将会通知HF在建立Synchronous Connection前使用哪个codec ID。 

AG将会发送未经请求的命令+BCS=<Codec ID>给HF。HF将以AT+BCS=< CodecID>命令响应，只要该ID是支持的，ID将会和AG发来的未经请求的命令是一样的。但是如果ID不支持，HF将以AT+BAC和其可用的codec作为应答。 

如果AG收到的AT+BCS命令的ID和之前其发送的一样，则会发送OK应答，否则发送ERROR。如果AG发送命令+BCS后没有收到AT+BCS而是AT+BAC，这一过程将会结束但是AG在重新选择codec ID后会重新这一过程。 

在发送OK响应后，AG将会根据ID打开相应设置的同步连接，而HF在发送AT+BCS=<Codec ID>命令后也能够接收同步连接建立请求。 

在同步连接建立完成后，codec 连接建立也完成。+BCS命令是对这次和后续连接codec选择。 

如果(e)SCOlink无法建立，AG将会重启启动CodecConnection建立过程。在Codec connection建立连接之前，CVSD编码将被启用。

可选的codec跟新

对AG和HF都支持CodecNegotiaton特性的SLC场景。HF可以发送AT+BAC通知AG可选codec的动态变化。如果AG已经发起Codec Connection建立过程，HF将会发起AT+BAC命令以响应AG的未经请求的+BCS命令的codec不可用的情况。

原文: https://mp.weixin.qq.com/s/4FWo97i275KvfrKs1cTb4A

相关阅读

HFP

我。。。。 HFP是啥东西，是啥东西。。我也不知道 咋不能只是说这个东西是啥，应该说一下应用场景 好比小明有一个手机（HFP上叫做AG）