Hands Free Profile

免提应用框架(HFP)

• 版本：v.18

• 发布日期：2020-04-14

• 小组编制人：音频、电话和汽车工作组

摘要：免提应用框架(HFP)规范定义了一组功能，使得移动电话可以与免提设备结合使用（比如安装在车内或者以耳机为代表的可穿戴设备），通过Bluetooth链路，为免提设备远程控制移动电话以及移动电话和免提设备之间的语音连接提供无线方式。

遵守本规范可以确保支持Bluetooth的免提设备与支持此应用框架、配备Bluetooth的移动电话之间得到互操作性。

版本历史

版本	变更
v1.0到v1.5	新功能： • 相应并保持 • 用户号码信息 • 增强型呼叫状态 • 增强型呼叫控制合并勘误表13、261、317、549、550、575、586、635、706、731、746、819、820、821、822和823。
v1.5到v1.6	新功能： • 宽带语音编解码器 • 编解码器协商 • 单个指示符激活合并勘误表913、1859、1868、1872、1878、1934、1958、1989、2037、2043、2144、2146、2209、2211、2259、2276、2286、2459、2484、2713、2716、2742、2855、3090、3152、3688、3816和3910。
v1.6到v1.7	新功能：免提指示符合并勘误表4718、4893、5213、5336、5806和8739。
v1.7.0到v1.7.1	合并勘误表E6105。
v1.7.1到v1.7.2	合并勘误表E6544、E6628、E6835、E8620、E9009、E9034、E9089、E9119、E9122、E9123、E9127、E9158、E9168、E9169、E9170、E9174、E9203、E9204和E10424。
v1.7.2到v1.8	新功能：增强型语音识别激活合并勘误表E11729。

4.10 呼叫、呼叫建立和呼叫保持状态的传输 21

4.13.1 从HF接听来电——In-band Ringing 32

4.13.2 从HF接听来电——No In-band Ringing 33

4.13.3 从AG接听来电 33

4.13.4 改变In-band ringtone设置 34

4.18 使用HF提供的电话号码拨打电话 40

4.22.1 三方通话——呼叫等待通知 44

4.22.2 三方通话——从HF拨打三方电话 45

4.23 主叫线路识别(CLI)通知 46

4.24 HF请求关闭AG的EC和NR 47

4.25 语音识别激活/增强型语音识别激活 48

4.25.1 语音识别激活——HF发起 49

4.25.2 语音识别激活——AG发起 50

4.25.3 语音识别停用 50

4.25.4 增强型语音识别激活会话 51

4.26 具有文本表示的增强型语音识别激活会话 52

4.30.2 从HF将来电置为保持状态 56

4.30.3 从AG将来电置为保持状态 57

4.30.8 呼叫者终止保持状态的来电 61

4.31 用户信息 61

4.32 增强型呼叫状态机制 62

4.32.1 获取AG中当前呼叫列表 62

4.34.2 来自GSM07.07和3GPP27.007的重用AT功能 66

4.35 指示符的激活和停用 73

4.35.1 Bluetooth定义的AT功能 74

5.3.1 与免提模式0.96实现的交互 90

5.3.2 与HFP 0.96、1.0和HFP 1.5实现的交互 91

5.4 链路管理器（LM）互操作性要求 92

5.5 链路控制（LC）互操作性要求 92

5.5.1 Class of Device 92

9.3.1 Frame_header 105

11.1.1 基于模式匹配的波形替换 107

11.1.2 重叠相加 107

11.1.3 幅度匹配 108

11.2 PLC与mSBC的集成 108

11.2.1 第一个替换帧中合并——避免延迟 108

11.2.2 mSBC在丢包后第一个正确包的重聚合 108

11.3.5 SBC解码器zero-input响应 109

11.3.6 错误帧调用示例 109

11.4 源码(ANSI C) 109

11.4.1 sbcplc.h源码文件 109

11.4.2 sbcplc.c源码文件 110

第12章附录D: 质量指标 111

12.1 音频水平 111

12.2 Bluetooth灵敏度频率响应 112

12.2.1 Bluetooth发送灵敏度频率响应 112

12.2.2 Bluetooth接收灵敏度频率响应 112

介绍

范围

本文档规定了在设备实现免提应用框架时所必须使用到的协议和程序。这类设备最常见的例子就是与手机或者可穿戴无线耳机相连接的车载免提装置。

该框架定义了支持该免提框架的两个设备如何在点对点的基础上相互作用。

免提模式框架的使用通常使耳机或者前途是免提单元能够无限连接到蜂窝电话，以用作蜂窝电话的音频输入输出机制，并且允许在不操作实际的电话情况下执行典型的电话功能。

应用框架依赖关系

图1.1中描述了Bluetooth应用框架结构和依赖关系。如果一个框架通过显示引用重复使用该框架的部分内容，则该框架要依赖于另一个框架。依赖关系如1.1图所示。

图1.1:Bluetooth应用框架

如图1.1所示，免提应用框架依赖于串口框架和通用访问框架(GAP)。具体描述在第五节(SPP)中和第六节(GAP)中。

符号和约定

需求状态符号

此文档中，下面的符号被使用：

• “M”表示强制支持

• “O”表示可选则支持

• “X”表示排除(用于设备可能支持的特性，但免提模式不得使用这些功能)

• “C”表示有条件支持

• “N/A”表示不适用(在给定的上下文中未定义此功能)

根据Bluetooth相关规范强制要求的某些功能或者特性(标识为“X”)不包含在本框架中，因为它们可能在特定的用例中低阶化设备的操作。在因此标记为“X”的用例操作中时，同样标记的特性或者功能不得被激活。

命名约定

在本文档中，使用了以下的命名约定:

其中“核心规范”是指Bluetooth SIG采用的Bluetooth核心规范v2.0+EDR或者更高版本。

其中所说的“LMP 链路”它是指链路管理器(LM)级链路，该链路上仅传输链路管理器(LMP)协议命令。

其中说所的“RFCOMM 连接”，则表示在[6]中规定的虚拟串行端口。

• 所说的“服务级连接”，意味着涉及协议栈的一部分的同步高级协议连接。在特定情况下，它指存在RFCOMM连接，并假设HF(免提装置)已使用指定的级别连接初始化过程将自身同步到AG(音频网关)的状态。

• 所说的“服务级连接初始化”，意味着执行框架指定的AT命令和响应，以使HF的状态与AG状态同步。

• 所说的“服务级连接的建立”，指建立RFCOMM连接的组合过程，以及使用服务级连接初始化进行必要的设备同步。

• 这里所说的“同步连接”，指的是用于支持全双工音频连接的SCO或者eSCO逻辑链路。

• 所说的“音频连接”，表示同步连接，包括在两个设备之间提供完整的音频路径的方法，同时在应用框架中扮演角色。

• 所说的“编解码器连接”，指的是在编解码器和相关配置的框架级别协商之后建立的同步连接。

• 所说的“宽带语音连接”，是指编码器连接，其中正在传说的媒体由从以16Khz采用的语音(或者其他音频)导出的编码帧组成。在建立编码器连接期间，应协商通过同步连接传输的媒体格式。

• 所说的“mSBC”或“改进型SBC”，表示A2DP SBC编解码器的修改版本，用作宽带语音连接的强制性编解码器。第5.7.4节包含组成mSBC的修改的完整定义。

• 所说的“来电”，表示在“电话网络=>AG”方向上的呼叫连接。它由AG所连接的网络发起。

• 所说的“去电”，表示在“AG=>电话网络”方向上的呼叫连接，它是由AG向其连接的网络发起。

• 所说的“传统设备”，指的是与本规范的早前版本v0.96、v1.0或者v1.5兼容的设备，见第5.3.2节。

信令图约定

本规范中的信令图仅供参考，以下约定用于描述过程:

图1.2:信令图使用的约定

语言

语言约定

Bluetooth SIG在规范制定的过程中建立了以下使用的单词，shall、must、will、should、may、can、is和note:

shall	需要——用于定义需求
must	通常用于表达: 先前规定的强制性要求的自然结果或无可辩驳的事实陈述(不论什么环境下总是正确的)
will	这是真的——仅用于事实陈述
should	建议——用于表示多种可能性中的一种建议特别适用，但不是必需的
may	允许——用于允许选项
can	能够——用于以因果关系的方式关联语句
is	定义为——用于进一步解释以前需要或允许的元素
note	用于指示包含的文本仅供参考，不需要用于实施规范。每个注释都明确指定为“注释”，并在单独的段落中列出。

关于这些术语的定义，请参考核心规范第1卷E部分第1节

保留以备将来使用

如果数据包、协议数据单元(PDU)或者其他数据结构中的字段被描述为“保留供将来使用”(无论是大写还是小写)，则创建该结构的设备应该将其值设置为零，除非另有规定。接受或解析该结构的任何设备应忽略该字段，特别是，它不应该因为该字段的值而拒绝该结构。

一个字段、参数、或者其他变量对象可以取一定范围的值，并且有些值被描述为“保留以备将来使用”(不管是大写还是小写)，发送对象的设备不应该设置该对象为这些值。接收到包含一个这些值的对象的设备应该拒绝该对象以及包含该值的任何数据结构，并被认为是错误的；但如果该对象被描述为被忽略或被指定为忽略无法识别的值时，这并不适用。

当字段值是位字段时，未指定为可以标记为保留备用，并设置为“0”。如果接收到一个保留供将来使用的位被设置成1，应该实现处理它仍然是0时的情况。除非另有规定。

禁止

单字段是枚举类时，未分配的值可以标记为“禁止”，这些值不应被实现使用，任何收到的包含禁止值的消息都应该被忽略，不应该被处理，也不应该被响应。

一个字段、参数、或者其他变量对象是可以取一定范围的值，并且有些值被描述为“禁止”，设备不应该将对象设置为这些禁止值中的任何一个。接收到具有该值的对象的设备应拒绝接收该对象以及包含该值的任何数据结构，任务该对象是错的。

应用框架概述

协议栈

图2.1显示了该应用框架中使用的协议和实体

图2.1 协议栈

基带、LMP和L2CAP是OSI的第一层和第二层Bluetooth协议。RFCOMM是Bluetooth串口仿真实体。SDP是Bluetooth服务发现协议。有关这些主题的更多细节，请参考[1]。

必须兼容v1.1或者更高版本的核心规范。

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

尽管没有在上面的模型中显示出来，但该框架假定免提控制可以访问一些低层级的过程(比如，同步连接建立)。

图2.1中所示的音频端口模拟层是在音频网关上模拟音频端口，而音频驱动是免提设备上的驱动软件。

对于图2.1中阴影的协议/实体，串口应用框架被用作基础标准。

对于这些协议，所有在串口应用框架中规定的强制性要求都适用，除了在某些本规范明确声明的偏差情况。

配置及角色

图2.2显示了免提应用框架适用设备的典型配置:

图2.2

这个应用框架定义了以下角色:

音频网关(AG)——此设备是音频的网关，用于输入输出。典型的作为音频网关适用的设备就是手机了。

免提设备(HF)——此设备是作为音频网关的远程音频输入输出机制的。它同样也提供一些远程控制手段。

此文档其余部分将使用上述的这些术语来指定这些角色。

用户需求及应用场景

以下规则适用于此应用框架:

当“免提应用框架”在音频网关和免提设备中激活时，框架的强制和可选特性才起作用。
框架规定使用CVSD用于传输音频(Bluetooth链路之上)。这就导致了音频是单声道，并且正常情况下它的质量不会有感知到的音频退化。
在免提设备和音频网关之间，一个服务级连接每次只支持一个音频连接。
音频网关和免提设备都可以初始化音频连接建立和释放。在建立音频连接之后，有效的音频数据应存在双向同步连接之上。
只有存在“音频连接”，相应的“服务级连接”也应该存在。
“服务级连接”的存在并不意味着存在“音频连接”。释放“服务级连接”也应释放相应的“音频连接”

框架基础

如果在免提设备和音频网关之间没有建立起LMP，在其他任何过程执行之前，必须先建立起LMP链路。

框架中没有固定的主从角色。

音频网关和免提设备提供串口仿真。对于串口仿真，RFCOMM(见[1])被使用。串口仿真用于传输从免提设备(HF)发送给音频网关(AG)的用户数据，包括modem控制信号和AT命令。AT命令是通过音频网关(AG)进行解析的，响应通过Bluetooth串口连接发送给免提设备

一致性

如果与此应用框架的一致性被声明，所有指示为此规范的强制性能力都需要被支持(过程-强制性)。这也适用于所有表示支持的可选和有条件的功能。

应用层

本节描述了符合HFP的设备的特性需求。

表3.1展示了此框架的这些特性需求

	Feature	Support in HF	Support in AG
1	连接管理	M	M
2	手机状态信息	M(note1)	M
3	音频连接处理	M	M
4	接听来电	M	M
5	拒绝来电	M	O
6	挂断电话	M	M
7	通话中的音频连接转换	M	M
8	用HF提供的号码拨打电话	O	M
9	记忆拨号	O	M
10	拨打最后一个拨打过的号码	O	M
11	呼叫等待通知	O	M
12	三方通话	O(note2)	O(note3)
13	主叫线路识别	O	M
14	回音消除和降噪	O	O
15	语音识别激活	O	O
16	语音标签附加一个电话号码	O	O
17	传输DTMF编码的能力	O	M
18	远程音频音量控制	O	O
19	回应和保持	O	O
20	用户号码信息	O	M
21a	增强呼叫状态	O	M
21b	增强呼叫控制	O	O
22	独立指示符激活	O	M
23	宽带语音通话	O	O
24	编解码器协商	O(note4)	O(note4)
25	HF指示符	O	O

表3.1应用层程序

注1:HF应支持至少两个指示符“服务”和“呼叫”。

注2:如果HF支持三方通话，它应该支持AT+CHLD值1和2。HF可额外支持AT+CHLD值0，3和4。

注3:如果AG支持三方通话，它应该支持AT+CHLD值1和2。AG可额外支持AT+CHLD值0，3和4。

注4:如果支持宽带通话，也应该支持编解码器协商。

表格3.2映射每一个特性到该特性使用的过程。如果支持特性，那么该特性映射的过程都需要支持。

	Feature	Procedure	Ref.
1	连接管理	服务连接的建立服务连接的断开	4.2 4.3
2	手机状态信息	注册状态的传输型号强度的传输漫游状态的传输电池电量的传输运营商的选择查询扩展音频网关错误码呼叫、呼叫建立和呼叫保持状态传输	4.4 4.5 4.6 4.7 4.8 4.9 4.10
3	音频连接处理	音频连接的建立音频连接的断开编解码器连接的建立	4.11 4.12
4	接听来电	接听来电	4.13
5	拒绝来电	拒绝来电	4.14
6	挂断电话	挂断电话	4.15
7	通话中的音频连接转换	音频连接转到HF 音频连接转到AG	4.16 4.17
8	用HF提供的号码拨打电话	用HF提供号码拨打电话	4.18
9	记忆拨号	记忆号码拨打电话	4.19
10	拨打最后一个拨打过的号码	上次拨打号码拨号	4.20
11	呼叫等待通知	呼叫等待通知激活	4.21
12	三方通话	三方通话处理	4.22
13	主叫线路识别	主叫线路识别通知	4.23
14	回音消除和降噪	HF请求关掉AG的回音消除和降噪	4.24
15	语音识别激活	语音识别激活	4.25
16	语音标签附加一个电话号码	附加一个语音片段到一个号码上	4.27
17	传输DTMF编码的能力	传输DTMF编码	4.28
18	远程音频音量控制	远程音频音量控制音量同步	4.29
19	回应和保持	查询响应和保持状态从HF设置一个来电为保持状态从AG设置一个来电为保持状态从HF接受一个保持状态的来电从AG接受一个保持状态的来电从HF拒绝一个保持状态的来电从AG拒绝一个保持状态的来电打电话者终止保持状态的来电	4.30
20	用户号码信息	用户号码信息	4.31
21a	增强呼叫状态	查询呼叫列表	4.32
21b	增强呼叫控制	释放指定的呼叫私人咨询模式	4.33
22	独立指示符激活	指示符激活和停止	4.35
23	宽带语音通话	宽带语音通话	9 10 11
24	编解码器协商	编解码器协商	4.11
25	HF指示符	HF指示符

表3.2 应用层特性映射到过程

表3.3 展示了此应用框架需要的编解码器

	Codec	Support in HF	Support in AG
1	CVSD	M	M
2	mSBC	C.1	C.1
C.1:如果支持宽带语音通话，则该项为强制条件，其他方式则不强制。

表3.3 支持的编解码器需求

表3.4 此应用框架的链路特性与编解码器需求映射

	Feature	Support in HF	Support in AG
1	D0-SCO链路(HV1)上的CVSD	M	M
2	D1-SCO链路(HV3)上的CVSD	M	M
3	S1-eSCO链路(EV3)上的CVSD	M	M
4	S2-EDR eSCO链路(2-EV3)上的CVSD	M	M
5	S3-EDR eSCO链路(2-EV3)上的CVSD	M	M
6	S4-EDR eSCO链路(2-EV3)上的CVSD	M	M
7	T1-eSCO链路上的mSBC	C1	C1
8	T2-EDR eSCO链路上的mSBC	C1	C1
C1:如果支持宽带语音通话，则该项为强制条件，其他方式则不强制。

表3.3 编解码器到链路特性映射

免提控制互操作要求

介绍

本章节完整包含了免提控制实体的互操作性要求。第4.2节到第4.29节明确规定了这些与应用层直接相关过程的要求。

章节所列出来的这些过程主要是基于使用最少的一组AT命令作为控制协议。第4.34节规定了这些AT命令及其结果代码。

第4.2节规定了一般如何处理服务级连接，并且具体说明了如何使用免提控制实体以下层级来建立和释放服务级连接。

服务级连接的建立

在用户操作或者内部事件发生时，HF或者AG均可以初始化一个服务级连接建立程序。

服务级连接的建立需要一个已经存在的RFCOMM连接，即HF和AG之间的RFCOMM数据链路通道。

RFCOMM连接的建立应该按照GAP[5]的第7.3节和SPP[6]的第3章的描述来进行。

服务级连接的初始化

当一个RFCOMM连接已经建立好了，服务级连接初始化程序才可以被执行。

支持的功能交换

首先，在初始化程序中，HF发送AT+BRSF=<HF 支持的功能>命令到AG，以此通知AG此HF所支持的功能，并且在+BRSF结果代码¹取回AG所支持的功能。

编解码器协商

其次，在初始化过程中，如果HF支持编码器协商功能，则应检查来自AG对AT+BSRF命令的响应是否表明AG是支持编解码器协商功能的。如果HF和AG都支持编解码器协商功能，HF应该发送AT+BAC=<HF available>命令给AG，以便将HF²本身所支持的编解码器通知AG。

¹支持0.96版本的免提应用框架的音频网关(AG)会返回ERROR作为对AT+BRSF的响应。

²传统设备不会表示支持编解码器协商功能。

AG指示符

检索完成AG中所支持的功能之后，HF应确定AG支持哪些指示符，以及支持的指示符的顺序。这是因为，根据3GPP 27.007规范[2] AG可能支持免提应用框架未提供的附加指示符。并且指示符的顺序是特定于实现的。HF使用AT+CIND=?测试命令检索有关AG所支持的指示符以及其顺序的信息。

一旦HF具有了必要的所支持的指示符和顺序信息，它将使用AT+CIND？读取命令去检索AG中当前指示符的状态。

检索完AG中的指示符的状态之后，HF应通过发出AT+CMER命令来启用AG中的“指示符状态更新”功能，AG应响应OK。从此，每当服务、呼叫或呼叫建立状态出现改变时，AG就会主动地发出+CIEV结果代码和相应的指示符值。当需要同时更新呼叫和呼叫建立指示符时，AG应首先主动发送+CIEV呼叫指示符的结果代码，然后主动发送+CIEV呼叫建立指示符的结果代码。HF应使用+CIEV码所提供的信息去更新其内部和/或外部指示符。

启用“指示符状态更新”功能之后，AG应保持该功能使能直到AT+CMER命令发出将其停用，或者AG和HF之间的当前服务级连接因为任何原因中断。

HF启用AG中的“指示符状态更新”功能之后，如果HF和AG的支持的功能位图中的“呼叫等待”和“三方通话”位都被设置了，HF应发送AT+CHLD？测试命令来检索AG中支持的呼叫保持和多方通话功能信息。HF和AG有一方不支持“三方通话”功能的话，HF就不能发送AT+CHLD=？测试命令。

HF指示符

如果HF支持HF Indicator功能，则应检查+BRSF响应，看AG是否也支持HF指示符功能。

如果HF和AG都支持HF指示符功能，则HF应发送 AT+BIND=<HF supported HF indicators>命令，将HF支持的指示符已分配好的编号通知给AG。AG应响应OK。

向AG提供了其支持的HF指示符之后，HF应发送AT+BIND=？，用以请求AG所支持的HF指示符。AG应回复+BIND响应，列出所有的HF指示符，然后是OK。

HF从AG接收到其支持的HF指示符列表之后，HF应发送AT+BIND？命令以确定哪个HF指示符已被使能了。AG应响应一个或者多个+BIND响应。AG应以OK终止列表。

此刻开始，当一个是能过的HF指示符的值发生变化时，HF可以发送AT+BIEV命令和相应的HF指示符的值。

在任何时间点AG都可通过使用+BIND主动相应，以此来使能和停用任何HF指示符(详见4.36.1.4节)。

服务级连接初始化完成

HF应开了服务级连接完全初始化，从而在以下任一情况下建立:

• HF通过使用AT+BIND？命令成功检索到AG当前使能的“HF indicators”信息之后，当且仅当通过+BRSF命令交换的HF支持的功能位图和AG支持的功能位图中设置了“HF指示符”位时。

• HF使用AT+CHLD命令成功检索有关AG中如何支持呼叫保持和多方服务的信息之后，当且仅当HF和AG的SDP记录的SupportedFeature属性中设置了“呼叫等待和三方通话”位时。这种也适用于当HF或者AG通过+BRSF命令交换的支持功能位图中的“HF indicators”位未被设置时的情况。

• HF使用AT+CMER命令成功使能“Indicators status update”之后。适用当HF或者AG的SDP记录的SupportedFeature属性中的“呼叫等待和三方通话”位没有被置位时，并且当HF或者AG通过+BRSF命令交换，支持功能位图中的“HF indicators”位未被设置时这种情况。

如果HF从AG接收到一个呼叫当前处于激活状态的指示，HF可以通过查询AG的Response and Hold 状态，确定当前是否有未接听来电处于保持状态(详见4.30.1)。

AG应该考虑服务级连接被完全初始化，从而在下列任一情况下建立:

• AG成功的响应，使用+BIND命令提供了关于哪些HF indicators被使能的信息，同时也回应了OK，之后，当且仅当HF和AG的支持功能位图中的“HF indicators”位被置位时，支持功能位图是通过+BRSF命令交换。

• AG成功的响应，使用+CHLD命令，附带AG对呼叫保持和三方服务怎样支持的信息，同时也响应了OK，之后，当且仅当HF和AG的SDP属性中SupportedFeatures的“呼叫保持和三方通话”位都被置位时。此种适用于HF或AG通过+BRSF命令交换的支持功能位图中的“HF Indicators”位未被置位的情况。

• AG成功响应，通过OK和AT+CMER命令(使能“Indicators status update”功能)。此种也适用于当HF或者AG的支持功能位图中的“呼叫等待和三方通话”位没有被置位，也适用于当HF或者AG通过+BRSF名交换的支持功能位图中的“HF indicators”位未被置位情况。

详见4.34节，AT+CIND，AT+CMER，AT+CHLD，AT+BAC和AT+BRSF命令，+CIEV主动发送结果代码命令。

服务级连接图

图4.1 服务级连接建立

链路丢失恢复

本节介绍HF的链路丢失恢复。无论Bluetooth链路何时丢失，HF都可以重新连接AG。

当服务级连接由于一端外部直接终止而断开(服务级连接释放章节中的“服务连接释放”)，两个设备(AG和HF)在尝试重新建立服务级连接之前都应等待外部用户的行为。

如果HF确定了服务级连接是由于链路监控超时而断开，HF可以执行4.2节中描述的“服务级连接建立”程序去和AG建立一个新的服务级连接。由于链路监控超时导致的链路丢失后，HF不应假定上一个服务级连接状态有效(例如呼叫状态、服务状态)。

服务级连接的释放

本节描述释放一个服务级连接的过程。

服务级连接的断开会导致HF和AG之间RFCOMM数据链路通道相应的媒介的去除。存在的音频连接也会由于服务级连接的去除而被移除。L2CAP和链路层和连接的去除是可选的。

建立好的“服务级连接”应使用“服务级连接去除”程序来释放。

• HF或者AG应该在外部用户的请求下去初始化“服务级连接释放”程序。

• “服务级连接释放”程序会在HF或者AG端的Bluetooth功能被停用时初始化。

• “服务级连接释放”程序可能在如4.17节所描述“音频连接转换到AG”的时候初始化，表现为AG中有正在进行的来电。此种情况下服务级连接被去除，AG应在电话挂断之后尝试去重新建立此服务级连接。

作为此过程的先决条件，AG和HF之间应存在一个正在进行中的服务级连接。

图4.2 服务级连接去除

注册状态的传输

AT+CMER命令，如4.34节的描述，使能AG中的“注册状态更新”功能。

AT+BIA命令，如4.35.1节的描述，允许HF激活/停用单独的指示符。

当CMER功能被使能，并且AT+BIA命令还没有停用注册状态指示符时，一旦AG的注册状态有改变，AG就应主动发送+CIEV结果代码一并相应的服务指示符和值。HF应能够解析+CIEV结果代码提供的信息，以此确定4.34.2节中所列的服务的可用性。

如果CMER功能被禁用或者通过AT+BIA命令停用了该指示符，那么AG就不应主动发送结果代码。

图4.3 典型注册状态更新

信号强度的传输

AT+CMER命令，如4.34节的描述，使能AG中的“信号强度指示”功能。

AT+BIA命令，如4.35.1节的描述，允许HF激活/停用单独的指示符。

当CMER功能被使能，并且AT+BIA命令还没有停用该指示符时，一旦AG的信号强度有改变，AG就应主动发送+CIEV结果代码和相应的信号强度指示符和值。HF应能够解析+CIEV结果代码提供的信息，以此确定4.34.2节中所列的信号强度。

如果CMER功能被禁用或者通过AT+BIA命令停用了该指示符，那么AG就不应主动发送结果代码。

图4.4 信号强度的传输

此后，不论何时信号一旦发生变化，AG就应主动发送+CIEV结果代码和对应的信号强度值。

漫游状态的传输

AT+CMER命令，如4.34节的描述，使能AG中的“漫游状态指示”功能。

AT+BIA命令，如4.35.1节的描述，允许HF激活/停用单独的指示符。

当CMER功能被使能，并且AT+BIA命令还未停用该指示符时，一旦AG的漫游状态有改变，AG就应主动发送+CIEV结果代码和相应的漫游状态指示符和值。HF应能够解析+CIEV结果代码提供的信息，以此确定4.34.2节中所列的漫游状态。

如果CMER功能被禁用或者通过AT+BIA命令停用了该指示符，那么AG就不应主动发送结果代码。

图4.5 漫游状态指示的传输

电池电量的传输

AT+CMER命令，如4.34节的描述，使能AG中的“电池电量指示”功能。

AT+BIA命令，如4.35.1节的描述，允许HF激活/停用单独的指示符。

当CMER功能被使能，并且AT+BIA命令还未停用该指示符时，一旦AG的电池电量有改变，AG就应主动发送+CIEV结果代码和相应的电量指示符和值。HF应能够解析+CIEV结果代码提供的信息，以此确定4.34.2节中所列的电量。

如果CMER功能被禁用或者通过AT+BIA命令停用了该指示符，那么AG就不应主动发送结果代码。

图4.6 电池电量指示的传输

电池电量的传输

HF应执行下面的程序，以此找到当前AG选择的网络运营商的名字。

下面的前提条件适用于该程序:

• AG和HF之间应存在持续性连接。如果该连接不存在，AG应按照4.2节描述的“服务级连接设置”程序来建立一个连接。

图4.7 查询当前网络运营商

• HF应发送AT+COPS=3,0命令，以此将格式是设置成长字母数字型。长字母数字型被定义成最大16个字符。作为第一个参数的值3表示此命令仅影响format参数（第二个参数）。第二个参数0是将格式设置为“长字母数字”所需的值。

• 发生内部事件或者用户发起的行为时，HF应发送AT+COP？(读取)命令，以此查询到当前AG选择的网络运营商。

• AG使用+COPS响应，显示当前选择的运营商。如果没有运营商，<format>和<operator>将被忽略。

报告音频网关错误结果代码

HF应执行下面程序去使能/停用AG中的音频网关错误结果代码。

下面的前提条件适用于该程序:

• AG和HF之间应存在持续性连接。如果该连接不存在，AG应按照4.2节描述的“服务级连接设置”程序来建立一个连接。

图4.8 使能/停用AG错误结果代码

• HF应发送AT+CMEE命令，以此使能/停用AG中的“扩展音频网关错误结果代码”。参数<n>控制着“扩展错误结果代码”通知的激活/停用。

• 当AT命令导致AG功能出错时，AG应向HF发送+CEM ERROR:<err>响应。

呼叫、呼叫建立和呼叫保持状态的传输

AT+CMER命令，如4.34节的描述，使能AG中的“呼叫状态指示符更新”功能。

如第4.35.1节所述，AT+BIA命令允许HF停用/重新激活单个指示符。该命令不应该影响到呼叫、呼叫建立或者呼叫保持指示符。AT+BIA命令不能停用这些指示符。

当CMER功能启用时，只要AG当前的呼叫状态发生变化，AG应主动发送一个+CIEV结果代码以及相应的呼叫指示符和值。同样的，如果AG当前的呼叫建立发生变化时，AG应主动发送一个+CIEV结果代码以及相应的呼叫建立指示符和值。

如果CMER功能被禁用时，AG不应主动发送结果代码。

HF应能够解析+CIEV结果代码提供的信息，以此确定4.34.2节中所列的呼叫状态。

此外HF还可以解析4.34.2节中所列的+CIEV结果代码提供的可选呼叫建立状态信息。

HF应能够接受+CIEV结果代码提供的未知指示符。HF可能忽略上述未知指示符。

注意:尽管HF需要去解析+CIEV结果代码，但是不需要提供+CIEV结果代码的用户接口指示符。

呼叫状态的传输

AG中有任何呼叫状态发生变化时，AG隐之心下面程序，以此通知HF当前呼叫状态的改变。呼叫指示符的值有:

0=No calls(保持或激活)

1=Call is present(激活或保持)

下面的前提条件适用于此程序:

• HF应已经使能了AG中的“指示符状态更新”

• AG和HF设备之间应存在一个服务级连接

图4.9 呼叫状态: 来电接听

图4.10 呼叫状态: 拨打电话

因此，任何让AG处于“AG无呼叫状态”的呼叫释放，不管是AG、网络事件、或者是有HF发起的，AG都应主动发送+CIEV结果代码和指示符，其值为“0”。

图4.11 呼叫状态: HF释放呼叫

图4.12: 呼叫状态: AG释放呼叫

图4.13: 呼叫状态:网络呼叫释放

呼叫建立状态的传输

一旦AG的呼叫建立状态发生变化，AG应执行以下程序，以此通知HF当前呼叫建立状态的变化。呼叫建立指示符的值如下:

0=No call setup in progress

1=incoming call setup in progress

2=outgoing call setup in dialing state

3=outgoing call setup in alerting state

以下先决条件适用于此程序:

• HF应已经使能了AG中的“指示符状态更新”

• AG和HF设备之间应存在一个服务级连接

图4.14 呼叫状态: 呼出

图4.14 呼叫状态: 呼入

一旦任何适用的网络功能通知AG，呼叫已经达到端对端连接状态，呼叫建立指示符应被重新设置，以表明无呼叫建立程序正在进行中。

呼叫保持状态的指示

一旦AG的任何处于保持状态的呼叫的状态发生变化，AG应执行以下程序，以此通知HF当前保持状态呼叫的变化。呼叫保持指示符的值如下:

0=No call held

1=Call is placed on hold or active/held call swapped

(AG有一个进行中的呼叫和一个保持状态的呼叫)

2=Call on hold，no active call

以下先决条件适用于此程序:

• HF应已经使能了AG中的“指示符状态更新”

• AG和HF设备之间应存在一个服务级连接

当一个进行中的电话被设置成呼叫保持，这样AG就有了一个进行中的电话和一个呼叫保持中的电话，或者通过HF的请求或者AG的行为将进行中/保持状态的呼叫做了交换，AG就应主动发送+CIEV结果代码并且callheld indicator的值为“1”。

图4.16 呼叫保持或激活/保持转换

因此，任何对保持状态的呼叫的释放，由HF，AG或者网络事件发起，或者HF或AG找回保持状态的呼叫产生，AG都应主动发送+CIEV结果代码并且callheld indicator的值为“0”

图4.17 呼叫保持的释放

如果当一个正在进行通话已经结束仍然由一个呼叫处于保持状态，或者唯一的一个呼叫被设置成呼叫保持状态，AG应主动发送一个+CIEV结果代码并且callheld indicator的值是“2”。

图4.18 通话终止/仍有呼叫处于保持状态

音频连接的建立

在用户操作或者内部事件发生时，HF或者AG均可以根据需要初始化一个音频连接连接建立过程。HF或者AG可能需要更进一步的内部操作来内部路由、修改音频路径的采样率、帧和/或样本对齐。更加正式的说，音频连接设置的要求是:

• HF应能够在没有呼叫过程中启动音频连接

• HF可以在没有呼叫情况下启动音频连接

• AG应能够在呼叫过程中启动音频连接

• AG可以在没有呼叫情况下启动音频连接

来电音频处理将在4.12节中进一步讲解。

拨号通话音频处理将在4.17，4.18和4.19节中进一步讲解。

音频连接设置过程始终意味着同步连接的建立，并且始终与现有服务级连接相关联。

原则上，使用本节描述的过程去建立一个音频连接不一定与任何呼叫过程相关。

作为此过程的前提条件，AG和HF之间应存在持续的服务级连接。如果该连接不存在，该过程的发起者应使用4.2节中描述的适当过程自动建立服务级连接。

AG建立的音频连接

当AG打算建立起一个音频连接，如果服务级协商表明两边都支持编解码器连接，它应发起编解码器连接建立程序。

图4.19 AG发起的音频连接建立过程

HF建立的音频连接

对应双方都支持编码器协商功能的所有HF发起的音频连接，HF应触发AG去建立编解码器连接。这是必须的，因为只要AG知道该网络的编解码器选择和设置。

图4-20 HF发起的音频连接建立过程

当HF触发编解码器链接的建立，HF应给AG发送AT+BCC命令。

如果AG会开启编解码器连接过程，就应响应OK，如果AG不能开启连接过程则响应ERROR。

AG响应OK之后，应发起编解码器连接建立过程。

此过程中建立的同步连接类型和它使用的设置由通过此连接要传输的媒体类格式来决定，可以在4.2.1和5.7.2节中找到。

编解码器连接的建立

在用户操作或者内部事件发生时，HF或者AG均可以根据需要初始化一个编解码器连接建立过程。HF或者AG可能需要更进一步的内部操作来内部路由、修改音频路径的采样率、帧和/或样本对齐。

尽管音频连接可以由AG或者HF触发，编码器连接和同步连接总是由AG来建立(除非设备中的一个是传统设备)。

在当前服务级连接上HF已经发送了至少一个AT+BAC命令，并且表明支持编解码器协商功能，只有在此基础上，AG才应发起编解码器协商。AG应使用最近HF发过来的AT+BAC命令中提供编解码器信息去选择该使用哪一个编解码器。

建立同步连接之前，AG应将会使用的编解码器ID通知给HF。如果编解码器已经在当前服务级连接上成功选择过，AG就不需要通知HF要使用哪一个编解码器，除非下一次的同步连接需要更改编解码器。如果HF已经在完成服务级连接过程中发送了一个附加的AT+BAC命令，可能就需要重新选择编解码器了。

图4.21 编解码连接建立过程

AG应主动发送+BCS=<Codec ID>给HF。然后HF应响应刚才的AG发出的主动响应，使用AT+BCS=<Codec ID>命令。只有是支持的ID，该命令中的ID就应该与AG发出的命令中的ID相同。如果接收到的ID不支持，HF就应该使用AT+BAC响应本身可用的编解码器。

如果AG接收到的AT+BCS中的ID和本身发送的一样，那么就应响应OK，如果不一样则发送ERROR。如果在发送+BCS之后，没有收到AT+BCS，而是收到了AT+BAC，此过程就应终止，但可以由AG在刚才收到的AT+BAC提供信息基础上重新选择编解码器ID，之后，重新开启过程。

发送完OK响应之后，AG应使用刚才ID决定的设置来开启同步连接。HF一旦发送完AT+BCS=<Codec ID>命令之后就应准备好接受同步连接建立。

同步连接建立之后，将建立编解码器连接。使用+BCS命令对编解码器的选择在后续的编解码器连接中也起作用。

如果在同步连接建立之前，编解码器连接建立过程失败，那么在任何同步连接建立之前首先应重新开启新的编解码器连接过程。

如果无法根据所选的编解码器所需的参数建立(e)SCO链路(比如，尽管已选择宽带编解码器，但对于具有重传的链路，基带协商失败)，AG应该重新启动编解码器连接过程，以此选择可用使用的编解码器。AG放弃尝试建立编解码器连接之前，应使用强制性窄带编解码器(CVSD)。

本过程中建立的同步连接的类型设置取决于通过音频连接传输的媒体格式，可在第5.7.2节中找到。

可用编解码器更新

在双方都支持编解码器协商功能的已建立的服务级别连接上，任何时候，HF都可以发送AT+BAC来通知AG关于可用编解码器集合中的动态变化。它只提供消息，不要求关闭任何现存音频连接。如果AG已启动编解码器连接设置程序，当所选编解码器不可以用时，HF应发送AT+BAC，以响应AG发出的+BCS非请求响应。

如果最后选择的编解码器变得不可以用，HF应向AG发送AT+BAC，以确保AG在下一个编解码器连接设置之前重新选择编解码器，并且AG应在开始建立同步连接之前发送+BCS非请求响应。

强制性窄带编解码器应始终在AT+BAC命令中公布。因此，AT+BAC永远不会是空列表，这确保了，始终可以使用回退选项来设置音频连接。

强制宽带编解码器也应始终在AT+BAC命令中公布，除非对宽带语音的支持暂时不可以用。如果HF先前在其AT+BAC命令中表示其支持宽带语音，则AG应将其解释为暂时暂停宽带语音支持，直到HF发送下一个AT+BAC命令。如果AT+BAC命令中未包含强制性宽带语音编解码器，则不应包含其他可选宽带语音编解码器。

图4.22 可用编解码器列表更新过程

编解码器重协商

但AG要建立音频连接时，它将根据最近的一次AT+BAC命令交换的可用编解码器列表来决定使用什么编解码器。无论AG或HF侧的连接发生任何变化，所选择的Bluetooth编解码器应该在整个正在进行过程中的同步连接中使用。AG可用通过发起一个编解码器连接来改变已选择的Bluetooth编解码器。作为编解码器重协商的结果，新选择的编解码器应在接下来的音频连接中使用。

音频连接的释放

在用户操作或者内部事件发生时，HF或者AG均可以释放一个存在的音频连接。更正式的说，音频连接释放要求如下:

• HF应能够在呼叫过程中释放音频连接。

• 如果HF能够在无呼叫过程中建立音频连接，则HF应能够在无呼叫过程中释放音频连接。

• AG应能够在呼叫过程中释放音频连接。

• 如果HF能够在无呼叫过程中建立音频连接，则AG应能够在无呼叫过程中释放音频连接。

作为本程序的先决条件，AG和HF之间应存在持续的音频连接。

一个音频连接的释放，总是意味着它相应的同步连接的断开。

当音频连接释放，音频路径应转移到AG³。

³原则上使用本章描述的过程去移除一个音频连接，不一定与任何回家过程相关。

图4.23 音频连接的释放

接听来电

接的来电之后，AG应向HF发送一系列未经请求的RING警报。只有呼叫接受一直处于挂起状态，或在来电因任何原因中断之前，RING警报就会一直重复。

在响应RING时，HF应产生一个本地警报。

如果AG的SDP记录(或BRSF消息)表明支持“In-band ring tone”，则AG应发送带内铃声，除非随后在使用4.13.4节中的过程去更改。

AG可在必要时中止来电。然后停止向HF发送RING报警。

从HF接听来电——In-band Ringing

AG可选择性的提供In-band ring tone。

这种情况在下图4.24中进行了描述，并按时AG和HF之间存在持续性的服务级连接作为先决条件。如果不存在此连接，AG应使用4.2节中描述的过程去自主地去创建服务级连接。

如下图所示，如果In-band ring tone在使用，AG应通过建立好的音频连接去发送ring-tone给HF。

图4.24 从HF接听来电——in-band ring tone

用户使用HF提供的合适的方法接听来电。HF向AG发送ATA命令(详见4.34)。然后AG应开始接听来电过程。

如果正常的接听来电过程被任何原因打断，AG应发送+CIEV结果代码，加上指示符的值(callsetup=0)，以此将此情况通知HF。

从HF接听来电——No In-band Ringing

AG和HF之间存在持续性的服务级连接作为先决条件。如果不存在此连接，AG应使用4.2节中描述的适合的过程，自主地去创建服务级连接。

如下图所示，如果没有ringtone被使用并且音频连接不存在，一旦HF去接听来电，AG就应该建立音频连接并且将音频路径转移到HF。

图4.25 从HF接听来电——no in-band ringtone

用户使用HF提供的合适的方法接听来电。HF向AG发送ATA命令(详见4.34)。然后AG应开始接听来电过程，如果没有音频连接存在，则需要建立音频连接(参考4.10.1节)。

如果正常的接听来电过程被任何原因打断，AG应发送+CIEV结果代码，加上指示符的值(callsetup=0)，以此将此情况通知HF。

从AG接听来电

下面的先决条件适用于该过程:

• 作为先决条件，在AG和HF之间应存在持续的服务级连接。

• AG应使用4.13.1和4.13.2节中的某一个描述的过程来警告HF。

• HF应提醒用户。

图4.26 从AG接听来电

用户通过AG提供的合适的方法接听来电。

如果正常的接听来电过程被任何原因打断，AG应发送+CIEV结果代码，加上指示符的值(callsetup=0)，以此将此情况通知HF(详见14.14.2节)。

改变In-band ringtone设置

SDP记录条目“SupportedFeature”记录的“In-band ringtone”(见表5.4)使HF明确了AG是否能够发送in-band ringtone。如果AG能够发送in-band ringtone，它应该默认发送in-band ringtone。AG接下来可以改变该设置。

如果AG想要在持续的服务级连接上改变in-band ringtone设置，它应该通过非请求结果代码+BSIR(Bluetooth Set In-band Ring tone)来通知HF该变更。详情参考图4.27。

更多信息请参考4.34节+BSIR非请求结果代码。

一个服务级连接期间in-band ringtone可以改变多次。

AG和HF之间存在持续性的服务级连接作为先决条件。如果不存在此连接，AG应使用4.2节中描述的适合的过程，自主地去创建服务级连接。

图4.27 AG发起的in-band ringtone设置变更

如果HF不想使用AG的in-band ringtone，它可以在收到+CIEV:(callsetup=1)之后去关闭该音频连接。HF应在收到+CIEV:(callsetup=0)时开启该音频连接。

拒接来电

有来电的时候，AG应按照4.13.1和4.13.2节中描述的其中一个的过程来通知HF。

用户可以通过HF或者AG上的用户操作来拒绝来电过程，而不是去接听来电。两个步骤将在下面的章节中描述。

从HF拒接来电

作为此过程的前提条件，AG应通过4.13.1和4.13.2节中描述的过程之一来通知HF。

用户通过使用HF设备中的用户接口拒接来电。然后HF应发送AT+CHUP(见4.34节)命令给AG。此操作可以在4.13.1和4.13.2节描述的过程中的任意时刻发生。

然后AG应停止通知HF有来电，并且发送OK，接着发送+CIEV结果代码，指示符的值为(callsetup=0)。

图4.28 从HF拒接来电

从AG拒接/中断来电

作为此过程的前提条件，AG应通过4.13.1和4.13.2节中描述的过程之一来通知HF。

用户通过使用AG设备中的用户接口拒接来电。或者AG中的来电过程可以被AG中的任意其他原因中断。

结果，AG应发送+CIEV结果代码，附带指示符的值(callsetup=0)。然后HF停止提醒用户。

图4.29 从AG拒接/中断来电

终止呼叫过程

进行中的呼叫过程可以被HF或者AG通过用户行为或者任何另外的事件终止。

从HF终止呼叫过程

• AG和HF之间存在持续性的服务级连接作为先决条件。如果不存在此连接，HF应使用4.2节中描述的适合的过程，自主地去创建服务级连接。

• Call-related过程正在AG中进行。

尽管终止呼叫不需要音频连接，当AG和HF之间通常存在音频连接。

图4.30 HF发起的终止正在进行中的呼叫

用户可以使用HF设备提供的不管什么方法来取消正在进行的呼叫过程。

HF应发送AT+CHUP命令(见4.34节)给AG，然后AG开启终止或者打断当前呼叫过程的程序。之后AG应发送OK指示，随后发送+CIEV结果代码，附带指示符(call=0)。

执行相似程序，上述AT+CHUP命令也可以用于中断正常的呼叫建立过程。

从AG终止呼叫过程

• AG和HF之间存在持续性的服务级连接作为先决条件。如果不存在此连接，AG应使用4.2节中描述的适合的过程，自主地的去创建服务级连接。

• Call-related过程正在AG中进行。

图4.31 AG发起的终止正在进行中的呼叫

此过程完全适用于因AG中的任何原因而终止一个正在进行中的呼叫过程。

这种情况，AG应发送+CIEV结果代码，附带指示值(call=0)。

音频连接转换到HF

进行中的呼叫的音频路径可以从AG转换到HF。此过程是4.10.1节中描述的“音频连接建立”的一种特殊情况。

呼叫连接从AG到HF的转换是由用户在HF或者AG端发起的。这将导致HF或者AG，分别地，启动“音频连接设置”程序，将当前的音频路径转移到HF。

此过程只适用于在HF和AG之间当前没有建立起音频连接。事实上，如果音频连接已经存在，则无线进行此步骤，因为AG的音频路径假定已经转移到HF了。

• AG和HF之间应存在持续性的服务级连接。如果此连接不存在，“音频连接转移到HF”的发起者就应使用4.2节中描述的适合的过程自主地去建立服务级连接。

• AG中存在进行中的呼叫，音频路径转移到了AG。

图4.32 音频连接转换到HF

音频连接转换到AG

进行中的呼叫的音频路径可以从HF转换到AG。此过程是4.12节中描述的“音频连接建立”的一种特殊情况。

呼叫连接从HF转换到AG是由用户在HF端的行为或者由于内部事件或用户在AG端的行为发起的。这将导致HF或者AG，分别启动“音频连接释放”程序，保持当前呼叫并将音频路径转移到AG。

作为HF发起的“音频连接转换到AG”过程的结果，现存的服务级连接将由AG自主的移除，在当前呼叫结束之后，AG应尝试重新建立起服务卡连接。

作为前提条件，进行中的呼叫过程应存在AG中。此呼叫的音频路径应通过AG和HF之间的音频连接建立变的可用。

图4.33 音频连接转换到AG

使用HF提供的电话号码拨打电话

HF可以向AG提供电话号码然后发起一个向外拨号。HF应发起服务级连接(如果需要)并且发送ATDdd…dd;命令给AG去开启呼叫建立。AG应使用从HF接收到的电话号码开启呼叫建立过程，并且使用+CIEV结果代码，附带指示(callsetup=2)，去通知HF呼叫建立已经成功初始化。

更多ATDdd…dd;命令信息请参考4.34节。

AG和HF之间存在持续性的服务级连接作为先决条件。如果不存在此连接，HF应使用4.2节中描述的适合的过程，自主地的去创建服务级连接。

如果音频连接未建立，AG应建立适合的音频连接，并且在进行中的呼叫建立程序开始之后立即将呼出电话的音频路径转移到HF。

一旦AG被远程方告知警报已经开始，AG就应发出+CIEV结果代码，附带指示(callsetup=3)。如果无线网络没有向AG通知远程放警报开始，AG就不能发送该指示给HF。

一旦呼叫连接，AG应发送+CIEV结果代码，附带指示(call=1)。

如果正常的呼出电话建立过程被任何原因中断，AG就应发送+CIEV结果代码，附带指示(callsetup=0)，去通知HF此情况(见4.15.2节)。

如果AG支持“三方通话”功能并且一个电话已经在进行中，执行此过程将会使一个新的通话置于第三方，而当前正在进行的通话就会被置于保持状态。关于处理多方通话怎样处理细节，参考4.22.2节。

图4.34 用HF中输入的数字打电话

HF记忆拨号

HF可以使用AG的记忆拨号功能发起拨号。为了开启呼叫建立，HF应发起服务级连接(需要的话)并且发送ATD>Nan…;命令给AG。然后，AG应使用存储在由Na…;提供的位置的电话号码开启呼叫建立过程，并且发送+CIEV结果代码，附带指示(callsetup=2)，以此通知HF呼叫建立已经成功发起。

更多ATD>Nan…命令信息请参考4.34节。

AG和HF之间存在持续性的服务级连接作为先决条件。如果不存在此连接，HF应使用4.2节中描述的适合的过程，自主地的去创建服务级连接。

如果音频连接未建立，AG应建立适合的音频连接，并且在进行中的呼叫建立程序开始之后立即将呼出电话的音频路径转移到HF。

一旦远程方警报开始，AG就应发出+CIEV结果代码，附带指示(callsetup=3)。

一旦呼叫连接，AG应发送+CIEV结果代码，附带指示(call=1)。

如果正常的呼出电话建立过程被任何原因中断，AG就应发送+CIEV结果代码，附带指示(callsetup=0)，去通知HF此情况(见4.15.2节)。

如果HF提供的存储位置没有电话号码，则AG应响应ERROR。

图4.35 使用记忆拨号拨打电话

从HF重拨最后一个号码

HF可以通过重拨AG上次的拨号发起电话呼叫。HF应发起服务级连接(如有必要)并且发送AT+BLDN命令给AG以此开启呼叫建立。然后，AG应使用最后一次拨打的电话号码开启呼叫建立过程，并且发送+CIEV结果代码，附带指示(callsetup=2)，以此通知HF呼叫建立已经成功发起。

更多关于AT+BLDN命令的信息，请参考4.34节。

AG和HF之间存在持续性的服务级连接作为先决条件。如果不存在此连接，HF应使用4.2节中描述的适合的过程，自主地的去创建服务级连接。

如果音频连接未建立，AG应建立适合的音频连接，并且在进行中的呼叫建立程序开始之后立即将呼出电话的音频路径转移到HF。

一旦远程方警报开始，AG就应发出+CIEV结果代码，附带指示(callsetup=3)。

一旦呼叫连接，AG应发送+CIEV结果代码，附带指示(call=1)。

如果正常的呼出电话建立过程被任何原因中断，AG就应发送+CIEV结果代码，附带指示(callsetup=0)，去通知HF此情况(见4.15.2节)。

图4.36 使用最后号码拨号

呼叫等待通知激活

HF可以发送AT+CCWA命令去使能AG中的“呼叫等待通知”功能。

一旦“呼叫等待通知”被使能，AG就应在一个通话正在进行，一个来电正在等待时主动向HF发送相应的+CCWA结果代码。“呼叫等待”服务在网络中总是假设开启着。

一旦HF发送了AT+CCWA，AG应响应OK。然后AG应保存“呼叫等待通知”使能直到另一个AT+CCWA命令来停用它或者当前AG和HF之间的服务级连接应一些原因断开了。

更多关于AT+CCWA命令的信息，参考4.34节。

AG和HF之间存在持续性的服务级连接作为先决条件。如果不存在此连接，HF应使用4.2节中描述的适合的过程，自主地的去创建服务级连接。

图4.37 呼叫等待通知的激活

三方通话的处理

应通过执行[2]中描述的过程实现多个同时通话的适合的管理，当本规范中说明了一些限制。有关更多详细信息，请参考4.34节。

设备不能总是假定“呼叫保持和/或多方”服务在网络中可用的。如果AG认定某HF设备发起的请求由于网络不支持该功能或者缺少用户订阅而不能被执行，AG应返回+CME error。

有两个+CME ERROR码，用于向HF表明网络相关失败原因。

• 30——无网络服务。表示AT+CHLD命令由于网络限制不能被实现。

• 31——网络超时。表示AT+CHLD命令由于网络问题不能被实现。

通常来说，当用户处理多个同时的通话时，HF应根据用户的行为发送相应的AT+CHLD命令。该命令允许对同时发生的通话的控制，以及提供保持通话、结束通话、两组通话之间的切换和在增加一组通话进多方会议中的方法。

当HF和AG支持该功能时，只需要实现“基础的三方通话”命令AT+CHLD=1和2。

本节包括两种用法。第一种，AG收到第三方通话，并且向HF通过“Call waiting notification”发送通知。第二种，三方通话由HF发起。

更多AT+CHLD命令信息见4.34节。

以下的前提条件适用于这些过程。

• AG和HF之间存在持续性的服务级连接作为先决条件。如果不存在此连接，此程序的发起者应使用4.2节中描述的适合的过程，自主地的去创建服务级连接。

• AG中存在正在进行中的通话。

三方通话——呼叫等待通知

除了前面提到的两个前提条件，向HF发送呼叫等待通知应在AG中已经被使能了(这就是说，4.21节描述的过程已经被执行过)。

图4.38 HF可能的响应紧跟呼叫等待通知

如果AG收到了三方通话，它应向HF发送呼叫等待通知+CCWA和+CIEV结果代码，附带指示(callsetup=1)

如果用户在HF上拒绝来电，HF应AG发送AT+CHLD命令附带参数0。然后AG应拒绝呼叫并且响应OK，并且发送+CIEV结果代码附带指示(callsetup=0)。

如果用户在HF上接受呼叫，HF应向AG发送AT+CHLD附带参数1或者2。

HF不能通过带有的AT+CHLD命令将一个来电添加为会议电话，但如果需要，HF可以通过先发送AT+CHLD=2命令，然后发送AT+CHLD=3命令来实现。然后AG应接收等待的呼叫并响应OK，并且发送+CIEV结果代码附带指示(callsetup=0)。如果HF选择发送AT+CHLD=2(将原来的电话置于等待状态)，然后AG应发送+CIEV结果代码附带保持呼叫指示(callheld=1)。

可选的，HF随后可以使用AT+CHLD命令来改变保持呼叫和激活呼叫的状态。

如果正常的来电过程被任何原因中断，AG应发送+CIEV结果代码，附带指示(callsetup=0)，来通知HF此状况(见4.14.2节)。

三方通话——从HF拨打三方电话

图4.39 三方通话处理——当HF拨打三方通话时

HF通过使用ATD命令发起第三方通话，然后AG应向HF发送OK指示和两个+CIEV结果代码，一个附带指示(callsetup=2)，另一个附带指示(callheld=2)。允许AG按照任意顺序发送+CIEV结果代码，因为AG中的事件时间在实现和网络类型之间可能不同。如果联系到远程方并且发出警报，AG应发送+CIEV结果代码附带指示(callsetup=3)。如果无线网络没有向AG提供远程发警报，AG可以不发送该指示。

如果远程方接听了电话，AG应发送+CIEV结果代码附带指示(callsetup=0)和(callheld=1)。与之前一样，设两个+CIEV结果代码没有强制要求顺序。

可选的，HF随后可以使用AT+CHLD命令来改变保持呼叫和激活呼叫状态。如果AT+CHLD命令导致呼叫保持状态发送变化，则AG应使用+CIEV结果代码附带指示值提供当前呼叫保持状态(callheld=<0，1，2>)。

如果正常的呼出电话建立过程被任何原因中断，AG就应发送+CIEV结果代码，附带指示(callsetup=0)，去通知HF此情况(见4.15.2节)。AG随后应根据以下两种情况之一更新callheld状态，以指示原始(held)呼叫状态的变化。

• AG可选择保留原始通话。此种情况下，AG应发送+CIEV结果代码附带指示(callheld=2)

• 或者，AG可以自动检索保持呼叫，从而改变状态，并应发送+CIEV指示符(callheld=0)。

无论哪种情况，+CIEV响应(call=1)应保持不变。

主叫线路识别(CLI)通知

HF可以使用AT+CLIP命令去使能AG中的“主叫线路识别通知”功能。

如果主叫用户号码信息可以从网络获得，当HF在来电中被提醒，AG将在每一个RING指示后立即发出+CLIP主动结果代码。有关更详细信息，参阅4.13节。

一旦HF发出AT+CLIP命令，AG将响应OK。然后，AG将保持“主叫线路识别通知”启用，直到HF发出AT+CLIP命运以禁用它，或者AG和HF之间的当前服务级连接因为任何原因断开。

更多关于AT+CLIP命令的信息，请参考4.34节。

AG和HF之间存在持续性的服务级连接作为先决条件。如果不存在此连接，HF应使用4.2节中描述的适合的过程，自主地的去创建服务级连接。

图4.40 CLI通知的启用

HF请求关闭AG的EC和NR

HF可以通过AT+NREC命令禁用驻留在AG中的回声消除和降噪功能。

如果HF支持嵌入式EC和/或NR功能，则它应支持本节程序中描述的AT+NREC命令。此外如果HF启用了这些功能，则它应在HF和AG之间建立任何音频连接之前执行此过程。

默认情况下，如果AG支持自己的嵌入式回音消除和/或降噪功能，则应将它们激活，直到收到AT+NREC命令。从那时起，直到AG和HF之间的当前服务级连接因为任何原因中断，每次HF和AG之间的音频连接用于音频路由时，AG都应该禁止这些功能。

如果AG不支持任何回音消除和降噪功能，它应该在收到AT+NREC命令时以ERROR指示符来进行响应。

更多AT+NREC命令的信息，请参考4.34节。

AG和HF之间存在持续性的服务级连接作为先决条件。如果不存在此连接，HF应使用4.2节中描述的适合的过程，自主地的去创建服务级连接。

图4.41 AG中可用的NR和EC功能

HF发送AT+NREC命令，AG使用OK或者ERROR指示确认。

语音识别激活/增强型语音识别激活

HF可用通过AT+BVRA命令或者AG自主地，激活和停用在AG里的语音识别功能。增强型语音识别状态和语音识别文本功能增强了AT+BVRA命令的使用。将在4.35.1节中详细描述。除了音频路由和语音识别功能之外，其余的语音识别功能取决于实现。

AG支持语音识别功能时，应支持本节流程中描述的AT+BVRA命令。

如果HF发送AT+BVRA命令，如果AG支持语音识别的话就响应OK结果代码，然后向HF发起音频连接(如果跟音频连接不存在的话)，并且开始语音输入序列。

如果AG不支持语音识别的话，就响应ERROR指示符。

如果语音识别功能由AG激活时，它应主动通过+BVRA:1结果代码通知HF并且向HF发起音频连接(如果音频连接不存在的话)，然后开始语音输入序列。

一旦激活，根据语音识别实现，AG应保持语音识别功能使能：

• 对于实现支持的持续时间(“瞬间开启”语音识别实现)。这种情况下，AG应主动发送+BVRA:0结果代码来通知HF。

• 或者直到HF发出AT+BVRA命令来禁止语音识别。

• 或者直到AG和HF之间的服务级连接因为任何原因而中断。

更多关于AT+BVRA名和+BVRA结果代码的信息请参考4.34节。

如果增强型语音识别状态和语音识别文本功能收到支持的话，AT+BVRA命令的扩展值为2。该值只能在AG和HF都支持增强型语音识别状态功能时使用。它表明当语音连接第一次建立起时，HF就准备好接收语音了。

HF可以在正在进行的VR(语音识别)会话期间发送该值以此终止来自AG(如果有)的音频输出并让AG为新的音频输入做准备。

+BVRA的语法使用<vrecstate>和<textualRepresentation>进行了扩展。

比如，<vrecstate>为5(b101)意味着AG正在监听音频输入同时正在处理过程中。

相互建立以文本表示的示例:

+BVRA:1,1,12AA,1,1,“Message 1 for Janina”AG发送到HF的一个新的文本。AG现在有了文本:

12AA: Message 1 from Janina

+BVRA:1,1,12AB,1,1,“Message 2 from Mellisa”:从AG发送到HF的一个新的文本附带新的<textID>。AG现在有了文本:

12AA: Message 1 from Janina

12AB: Message 2 from Melissa

+BVRA:1,1,12AB,1,2, “Message 3 from Mellisa”:从AG发送了一个新的文本使用了和示例2一样的<textID> 。textID与示例2中一样并且此操作为替换，示例2被新的文本替代。所以AG现在有了如下文本:

12AA: Message 1 from Janina

12AB: Message 3 from Mellisa

+BVAR: 1,1,12AB,1,3, “with new stuff”: 从AG发送一个新的文本到HF并且附加到了旧的文本上。textID和示例3中一样并且此操作为附加，新的文本附加到了示例3中的文本。AG现在有的文本是:

12AA: Message 1 from Janina

12AB: Message 3 from Mellisa with new stuff

更多的信息请参考4.35.1节

AG和HF之间存在持续性的服务级连接作为先决条件。如果不存在此连接，此过程的发起者应使用4.2节中描述的适合的过程，自主地的去创建服务级连接。

语音识别激活——HF发起

图4.42 语音识别激活——HF发起

语音识别激活——AG发起

图4.43 语音识别激活——AG发起

语音识别停用

图4.44 语音识别停用——“瞬间”方法

图4.45 语音识别停用——HF发起

增强型语音识别激活会话

图4.46 增强型语音识别激活会话示例序列图

具有文本表示的增强型语音识别激活会话

图4.47 具有文本表示的序列图

将电话号码附加到语音标签

此过程适用于支持内部语音识别功能的HF设备。它提供了一种从AG读取数字的方法，以创建唯一的语音标签并将该数字及其链接的语音标签存储在HF内存中。然后，但是用4.18节中描述的“使用HF提供的电话号码拨打电话”过程识别语音标签时，HF可以使用其内部语音识别来拨打链接的电话号码。

出现内部事件或者用户行为时，HF可以通过发送AT+BINP命令从AG中请求电话号码。依据当前状况，它可以接收或者拒绝该请求。

如果AG接收该请求，它应获得电话号码并通过发送+BINP响应将电话号码发送回去。

如果AG拒绝来自HF的该请求，它将发送ERROR结果代码，以此向HF表示这种情况。

当此程序被多次执行时(检索多个要链接到语音标签的AG电话号码)，每次执行该程序时，AG要负责提供下一个要传递给HF的电话号码。

更多关于AT+BINP命令和+BINP响应的信息，请参考4.34节。

AG和HF之间存在持续性的服务级连接作为先决条件。如果不存在此连接，HF应使用4.2节中描述的适合的过程，自主地的去创建服务级连接。

图4.48 向AG发送电话号码请求

传输DTMF编码

通话过程中，HF发送AT+VTS命令以指示AG向其网络链接发送特定的DTMF编码。

更多关于AT+VTS命令请参考4.34节。

下面的前提条件适用于本过程:

• AG和HF之间存在持续性的服务级连接。如果不存在此连接，HF应使用4.2节中描述的适合的过程，自主地的去创建服务级连接。

• AG中有持续的通话

图4.489 DTMF编码传输

远程音量控制

音量控制

此过程使用户可以从AG修改HF的扬声器音量和麦克风增益。

AG可以通过分别主动发送结果代码+VGM和+VGS来控制HF和麦克风和扬声器的增益。结果代码的顺序和数量没有限制。

如果HF设备支持远程音频音量控制功能，它将至少支持远程扩音器音量控制。

AG和HF之间存在持续性的服务级连接作为先决条件。如果不存在此连接，AG应使用4.2节中描述的适合的过程，自主地的去创建服务级连接。

音频连接不是此功能的必要前提。

图4.50 音量控制典型示例

扬声器和麦克风增益都表示为+VGS和+VGM的参数，范围从0到15。这些值都是绝对值。并于有HF控制的特定(取决于实现)音量水平相关。

更多的关于这些命令和非请求结果代码的信息请参考4.34节。

音量同步

此过程允许HF将与HF扬声器音量和麦克风增益相对应的当前增益设置通知AG。

在服务级连接建立时，HF应通过使用AT命令AT+VGS和AT+VGM将自己当前的设置通知AG。

如果在HF上实施了本地手段来控制增益设置，HF还应使用AT命令AT+VGS和AT+VGM来永久更新AG中这些增益设置变化。

在所有情况下，增益设置都应在当前服务级连接期间保存在双方。此外

如果服务级连接由于HF启动的“音频连接转移到AG”而被释放，如4.17节所述，HF还应保持增益设置，并在服务级连接重新建立时重新存储。

当HF支持远程扩音器增益控制时，它应支持扩音器同步。

当HF支持远程麦克风增益控制时，它应支持麦克风增益同步。

AG和HF之间存在持续性的服务级连接作为先决条件。如果不存在此连接，HF应使用4.2节中描述的适合的过程，自主地的去创建服务级连接。

图4.51 音量同步典型示例

更多关于这些命令和非请求结果代码的信息，请参考4.34节。

响应和保持

此过程允许用户保持来电，然后接受或者拒绝来自HF或者AG的呼叫。此功能特定于PDC和CDMA网络支持此功能的有限市场。

查询响应和保持状态

HF应执行此程序，以此查询AG的“响应和保持”状态的状态。

图4.52 查询AG的响应和保持状态

• HF应使用AT+BTRH？命令去查询当前AG的“响应和保持”状态。

• 如果AG当前处于响应和保持状态中的任何一个，则AG将发送参数设置为0的+BTRH:响应。如果AG没有处于响应和保持状态，就不需要发送响应。

• AG发送完AT+BTRH？命令的响应后应发送OK。

从HF将来电置为保持状态

• 作为该过程的前提，AG不应该有接通电话和来电保持。

• AG应该向HF主动发送一系列的RING提醒。RING提醒应不断重复，直到HF接听来电或者直到因为任何原因来电被中断。

• 如果HF已经使能了主叫显示(CLI)，AG应向HF发送+CLIP响应。

• 用户可以通过使用HF提供的合适的方法将来电置为保持状态。然后HF应发送AT+BTRH命令附带参数<n>为0。然后AG应开始将来电置为保持状态过程。

• 一旦来电被置为保持状态，AG应立即发送+BTRH响应，附带参数设置为0。

• 当电话通过AT+BTRH=0消息被置为保持状态时，+CIEV:(callheld=2)消息不应被发送。（）

• AG应发送+CIEV响应附带call 状态设置为1。

• AG应发送+CIEV响应附带callsetup状态设置为0。

图4.53 从HF将来电置为保持状态

从AG将来电置为保持状态

• 作为该过程的前提，AG不应该有接通电话和来电保持。

• AG应该向HF主动发送一系列的RING提醒。RING提醒应不断重复，直到HF接听来电或者直到因为任何原因来电被中断。

• 如果HF已经使能了主叫显示(CLI)，AG应向HF发送+CLIP响应。

• 用户可以通过使用AG提供的合适的方法将来电置为保持状态。然后AG应发送+BTRH命令附带参数<n>为0。以此表明来电处于保持状态。

• 当AG通过响应和保持方法保持呼叫时，+CIEV:(callheld=2)消息不应被发送。

• 根据是否启用或者停用带内振铃，HF和AG之间可能会或者不会建立同步连接。当来电被保持时，同步连接状态(启用或者禁止)。

• AG应发送+CIEV响应附带call 状态设置为1。

• AG应发送+CIEV响应附带callsetup状态设置为0。

图4.54 从AG将来电置为保持状态

从HF接受保持来电

下列附加前提条件适用于此过程:

• 有来电已被置为保持状态

• 用户可以通过使用HF提供的合适的方法接受保持状态的来电。然后HF应发送AT+BTRH命令附带参数<n>为1。然后AG应开始接受保持状态的来电过程。

• AG应发送+BTRH响应，附带参数<n>设置为1以此通知HF，保持状态的来电已经被接受。

• AG应开始建立音频连接程序，并且只有在音频连接没有建立时才将音频路径路由到HF。

图4.55 从HF接受保持状态的来电

从AG接受保持来电

以下附加前提适用于此过程:

• 有来电已被置为保持状态

• 用户可以通过使用AG提供的合适的方法接受保持状态的来电。然后AG应发送 +BTRH命令附带参数<n>为1。以此通知HF，保持状态的来电已被接受。

图4.56 从AG接受保持状态的来电

从HF拒绝保持来电

以下附加前提适用于此过程:

• 有来电已被置为保持状态。

• 用户可以通过使用HF提供的合适的方法拒绝保持状态的来电。

HF和AG应当允许如下两个序列中的一个:

HF应发送AT+BTRH命令附带参数<n>为2。然后AG应开始决绝保持状态的来电过程。然后AG应发送+BTRH响应附带参数<n>设置为2，以此通知HF，保持状态的来电已经被拒绝。
HF可以发送AT+CHUP命令来拒绝保持状态的来电，AG应拒绝保持来电并且向HF发送OK指示。

• AG应发送+CIEV响应附带call状态设置为0。

图4.57 从HF拒绝保持状态的来电

从AG拒绝保持来电

以下附加前提适用于此过程:

• 有来电已被置为保持状态。

用户可以通过使用AG提供的合适的方法拒绝保持状态的来电。

然后AG应发送+BTRH响应附带参数<n>设置为2以此通知HF保持状态的来电已被拒绝。

• AG也应发送+CIEV响应附带参数call状态设置为0，以此表示AG当前没有来电。

图4.58 从AG拒绝保持状态的来电

呼叫者终止保持状态的来电

以下附加前提适用于此过程:

• 有来电已被置为保持状态。

• 呼叫者可以终止保持状态的来电。然后AG应发送+BTRH响应附带参数<n>设置为2，以此来通知HF保持状态的来电已经终止。

• AG应发送+CIEV响应，附带参数call状态设置为0，以此表明AG当前无来电。

图4.59 呼叫者终止保持状态的来电

用户信息

此过程允许HF获取AG里的用户信息。

以下附加前提适用于此过程:

• AG和HF之间存在持续性的服务级连接作为先决条件。如果不存在此连接，HF应使用4.2节中描述的适合的过程，自主地的去创建服务级连接。

• HF应发送AT+CNUM命令，以此获取AG的用户电话号码信息。

• 如果用户电话号码可用，AG应以+CNUM响应。如果多个电话号码可用，AG应将每个可用号码单独通过+CNUM响应。

• AG应使用OK响应，以表示完成了都AT+CNUM命令的响应。OK响应会紧随0个或多个+CNUM响应(见图4.57和图4.58)。

图4.60 获取AG的用户电话号码信息

图4.61 AG的用户电话号码为空

增强型呼叫状态机制

获取AG中当前呼叫列表

HF应执行下面过程，以此获取AG中的当前呼叫列表。

下列前提适用于此过程:

• AG和HF之间存在服务级连接，如果不存在，HF应发起一个服务级连接。

• HF应通过向AG发送AT+CLCC命令来找出当前呼叫列表。

• 如果命令成功了，并且在AG里存在呼出(手机拨打的)或者呼入(打给手机的)的电话，AG应向HF发送+CLCC响应附带填充合适参数。

• 如果没有可用的呼叫，就没有发送给HF 的+CLCC响应。

• AG应该总是发送OK响应给HF。

图4.62 获取当前呼叫列表

增强型呼叫控制机制

如同之前所述，增强型呼叫控制机制就是一个目前的AT+CHLD命令的简单的扩展。这些扩展定义为AT+CHLD命令的附加参数。该命令新的参数包括一个+CLCC响应中指明的索引值。

释放指定呼叫的索引

HF应执行此过程，以此释放一个AG中指定的呼叫。

下列前提适用于此过程:

• AG和HF之间存在服务级连接，如果不存在，HF应发起一个服务级连接。

• HF应发送AT+CHLD=1<idx>命令，以此释放一个指定的进行中的呼叫。

• AG应释放该指定的呼叫。

如果呼叫状态发生改变，AG应通过呼叫(call)状态向HF报告。如果保持状态发生改变，AG应通过呼叫保持(callheld)状态向HF报告。

如果索引(<idx>)为非法时，AG应通过错误码报告HF。

图4.63 释放指明的呼叫

私人咨询模式

HF应通过执行此过程，以此将所有参与多方通话的各方置为保持状态，除了指明的呼叫方。

下列前提适用于此过程:

• AG和HF之间存在服务级连接，如果不存在，HF应发起一个服务级连接。

• AG中存在多方通话。

图4.64 请求私人咨询模式

• HF应发送AT+CHLD=2<idx>命令，以此请求私人咨询模式。

• AG应将其他的参与通话各方置为保持状态。

• AG应向HF报告保持状态的各方的状态。

• 如果索引(<idx>)为非法时，AG应通过错误码报告HF。

AT命令和结果代码

概述

对于命令和非请求结果代码，应参考3GPP 27.007[2]的格式、语法和程序。以下规则特别适用于HFP规范:

• 每个命令行只需要执行一个命令(或非请求结果代码)。

• 默认情况下，AG不应该回显示命令字符。

• AG应始终使用详细格式传输结果代码。

• 以下字符应用于AT命令和结果代码格式。

<cr> 对应于[7]中所述的回车(0/13)。

<lf> 对应于[7]中所述的换行符(0/10)。

• 由HF发给AG的命令格式应该为:

• 由AG发给HF的OK码格式应该为:

• 由AG发给HF的ERROR码格式应该为:

<cr><lf>ERROR<cr><lf>

• 由AG发给HF的非请求结果代码格式应该为:

免提应用框架使用了现有标准中的AT命令和结果代码的子集;它们在4.34.2节中有列出来。4.35节列出了新的Bluetooth协议定义的、没有复用现有标准的AT命令和结果代码。

一般而言，AG应使用4.34.2节中所述的OK码确认命令的正确执行，并且使用正确的错误指示以响应从HF收到的位置的命令。

AG必须正确地响应任何错误条件，HF必须正确处理从AG收到的响应错误指示码。ERROR码，如4.34.2节中所述，应用作此目的的错误指示。

对于本规范中定义的AT命令，HF应始终忽略从AG收到的任何位置的或者预料之外的指示码。本规范未定义的AT命令的处理在实现中完成。唯一例外是AG使用+CME ERROR: result code (见[2]) 发送一个“Modile Equipment Error”指示。这种情况下，HF应以与通用错误码相同的处理方式解释该结果代码。

作为一般规则，当实施本规范的AT命令或结果代码时，除非在每种特定情况下另有明确规定，否则应认为必须支持本规范中“涵盖”的相关参数及其所有相应的可能值。

来自GSM07.07和3GPP27.007的重用AT功能

用于实现本规范所述功能的复用的AT命令和非请求码，如下:

作为惯例，如果AT命令或结果代码的参数未在本规范中“涵盖”，则其不应该出现在相应的AT命令中，且HF应在收到存在它的结果代码时，忽略该参数。

• ATA

标准呼叫应答命令。见[2]中附录G

• ATDdd…dd;

用于拨打电话号码的标准AT命令。本规范只涵盖语音通话。参见[2]中6.2节。

• ATD>nnn…;

标准ATD命令的扩展，用于内存拨号。本规范只涵盖语音通话。参见[2]中6.3节。

• ERROR

标准错误指示码。应在检测到任何语法、格式或程序错误情况下发送。“Mobile Equipment Error”报告码“+CME ERROR”如下所述。见[2]中附录B。

• OK

对命令执行的标准确认。见[2]中附录B。

• NO CARRIER，BUZY，NO ANSWER，DELAYED BLACKLISTED

AT命令的扩展相应指示码。这些指示码是从AG向HF发送，作为对HF向AG发出的命令的响应，或从AG发出，作为非请求结果代码。是对+CME ERROR: responses的补充。

• RING

标准的来电指示。见[2]中附录B。

• AT+CCWA

标准“Call Waiting Notification”AT命令。在AT+CCWA=[<n>[,<mode>[,<class>]]]命令中，本规范仅涉及使用<n>参数，启用/停用“呼叫等待通知”非请求结果代码+CCWA。参见[2]中7.12节。

• +CCWA

标准“Call Waiting notification”非请求结果代码。

在+CCWA结果代码中，本规范只涵盖<number>和<type参数>。另外的参数在本规范中不相关，HF应忽略。

• <number>参数应为文本字符串，且应始终包含在双引号内。

• <type >字段指定多提供的电话号码的格式，可以是以下的取值之一:

值128-143:电话号码格式可以是国家或国际格式，并且可以包含前缀和/或转义数字。无需更改数字显示。

值144-159:电话号码格式为国际号码，包括国家代码前缀。如果加号（“+”）未包含在数字中，则AG应根据需要添加加号。

值160-175:国家号码。不包括前缀或转义数字。

见[2]中7.12节。

• AT+CHLD

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

0=释放所有保持通话或对来电设置用户忙(UDUB)。
1=释放所有进行中的通话(如果存在的话)并且接受另外的(保持的或者等待的)呼叫。
1<idx>=释放特定索引<idx>的呼叫。
2=将所有的进行中的通话(如果存在的话)置为保持状态，并接受另外的(保持或等待)呼叫。
2<idx>=请求与特定的呼叫<idx>进行私人咨询模式。(将除了用<idx>指明的之外的所有呼叫置为保持状态)。
3=添加一个保持通话到会议中。
4=连接两个呼叫并断开用户与两个呼叫的连接(显示呼叫转移)。对该值及其相关功能的支持对于HF是可选的。
如果同时存在呼叫保持和等待呼叫，则上述程序应适用于冲突情况下的等待呼叫(即，不适用于保持呼叫)。

测试命令AT+CHLD=？可用用于检索AG中可用的呼叫保持和多方通话服务信息(见4.2.1节)。

详见[2]中7.13节和4.5.5.1节。

• AT+CHUP

标准的挂断电话命令。执行此命令将使AG中断当前正在进行中的通话。该命令不得影响保持呼叫的状态，除非使用4.30.6节定义的“响应和保持”功能中的决绝保持状态的呼叫。见[2]中6.5节。

AT+CHUP也被用作在应答之前拒绝任何来电命令。

• 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)相关的命令发送之前，AT+CIND=？命令至少要被发送一次。

免提应用框架规范限制了AG返回的指示符的最大数量为20个。

本规范涵盖以下的指示符:

service: 服务可用指示符，

<value>=0暗示没有服务。没有Home/Roam网络可用。

<value>=1暗示有服务。Home/Roam网络可用。

call: 标准呼叫指示符，

<value>=0表示没有进行中的呼叫。

<value>=1表示有至少一个呼叫正在进行中。

callsetup: Bluetooth专用呼叫建立指示符⁴。HF对此指示符的支持是可选的。如果支持，该指示符应与标准呼叫指示符一同使用，并作为呼叫指示符的扩展。可能的值如下:

<value>=0表示当前没有建立起的呼叫。

<value>=1表示有来电正在进行中。

<value>=2表示有呼出电话正在进行中。

<value>=3表示呼出的远程方正在响铃中。

见[2]中8.9节。

callheld: Bluetooth专用呼叫保持状态指示符^{4(没有在GSM07.07规范中定义)}。AG对此指示符的支持是强制的，HF是可选的。可能的值如下:

0=表示当前处于保持的呼叫。

1=表示呼叫被保持，或激活/保持呼叫转换(AG同时有一个激活的和一个保持的呼叫)。

2=表示呼叫被保持，没有激活的呼叫。

signal: 信号强度指示符，

<value>=0~5范围。

roam: 漫游状态指示符，

<value>=0表示漫游状态未激活。

<value>=1表示漫游状态已激活。

battchg:AG电池充电指示符，

<value>=0~5范围。

• +CIND

标准的当前电话状态指示符。见[2]中8.9节。

• AT+CLCC

标准的当前呼叫列表命令。见[2]中7.18节。

• +CLCC

标准当前呼叫列表结果代码。见[2]中7.18节。

支持参数如下:

idx=由被服务用户看到的建立或接收呼叫(激活、保持或等待)的顺序给出的呼叫编号(从1开始)。电话号码一直保留到被释放。新呼叫使用最小编号。
dir=0(呼出) ，1(呼入)，
status=

0=Active

1=Held

2=Dialing(仅用作呼出)

3=Alerting(仅用作呼出)

4=Incoming(仅用作来电)

5=Waiting(仅用作来电)

6=Call held by response and hold

mode=0(voice)，1(数据)，2(传真)
mpty=

0-此呼叫不是多方会议的成员

1-此呼叫是多方会议的成员

number(可选的)
类型(可选的)

• AT+COPS

在发送AT+COPS之前，HF应向AG发送AT+COPS=3,0？命令AT+COPS=3,0将网络运营商字符串的格式设置为长格式字母数字。

AT+COPS？命令用于读取网络运营商。此应用框架仅支持“读取”网络运营商的名称。AG对此命令的响应应该返回+COPS:<mode>，<format>，<operator>，其中：

<mode>包含当前模式，不提供有关运营商的信息。

<format>指定<operator>参数字符串的格式，对于本规范，该格式应始终为0。

<operator>以字母数字格式指定一个带引号的字符串，表示网络运营商的名称。该字符串不得超过16个字符。参见[2]中的第7.3节。

• AT+CMEE

标准的AT命令，用于启用结果代码+CME ERROR：<err>作为与AG功能相关的错误指示。

本规范涵盖AT+CMEE=1设置命令。

• +CME ERROR

扩展音频网关错误结果代码响应。响应的格式:+CME ERROR:<err>。本规范中的<err>格式应为数字格式。本规范中涵盖的<err>的可能值如下所述。可以提供这些错误代码而不是标准ERROR响应代码，以此向HF提供附加信息。使用扩展音频网关错误结果代码时，仍然允许使用错误响应代码。

+CME ERROR: 0 – AG failure

+CME ERROR: 1 – no connection to phone

+CME ERROR: 3 – operation not allowed

+CME ERROR: 4 – operation not supported

+CME ERROR: 5 – PH-SIM PIN required

+CME ERROR: 10 – SIM not inserted

+CME ERROR: 11 – SIM PIN required

+CME ERROR: 12 – SIM PUK required

+CME ERROR: 13 – SIM failure

+CME ERROR: 14 – SIM busy

+CME ERROR: 16 – incorrect password

+CME ERROR: 17 – SIM PIN2 required

+CME ERROR: 18 – SIM PUK2 required

+CME ERROR: 20 – memory full

+CME ERROR: 21 – invalid index

+CME ERROR: 23 – memory failure

+CME ERROR: 24 – text string too long

+CME ERROR: 25 – invalid characters in text string

+CME ERROR: 26 – dial string too long

+CME ERROR: 27 – invalid characters in dial string

+CME ERROR: 30 – no network service

+CME ERROR: 31 – network Timeout.

+CME ERROR: 32 – network not allowed – Emergency calls only

• AT+CLIP

标准的“主叫线路识别通知”非请求结果代码。

在+CLIP: <number>, type> [,<subaddr>,<satype> [,[<alpha>] [,<CLI validity>]]]结果代码中。本规范仅涵盖<number>和<type>参数。其他参数与本规范不相关，HF应忽略。

<type>字段指定所提供电话号码的格式，可以是以下之一：

值128-143:电话号码格式可以是国家或国际格式，并且可以包含前缀和/或转义数字。无需更改数字显示。
值144-159: 电话号码格式为国际号码，包括国家代码前缀。如果加号(“+”)未包含在数字中，则AG应根据需要添加加号。
值160-175: 国家号码。不包括前缀或转义数字。
参见[2]中的第7.11节。

• AT+CMER

标准事件报告激活/停用AT命令。

AT+CMER=[<mode>[,<keyp>[,<disp>[,<ind> [,<bfr>]]]]]命令中，只有<mode>和<ind>参数与本规范相关。本规范仅涵盖其值<mode>=(3)和<ind>=(0,1)。参见[2]中的第7.11节。

以下示例显示了AT+CMER命令如何用于激活或停用“指示符事件报告”结果代码：

AT+CMER=3,0,0,1 激活 “indicator events reporting”。

AT+CMER=3,0,0,0 停用 “indicator events reporting”。

• +CIEV

标准的非请求“指示符事件报告”结果代码。

在+CIEV: <ind>,<value> result code中，只有上述AT+CIND命令中规定的指示符与本规范相关，其中：

<ind>: 从AG检索到的列表中指示符的顺序索引，AT+CIND=？命令列表的第一个元素应具有<ind>=1。
<value>: 当前该指示符的值。

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

参见[2]中的第8.10节。

• AT+VTS

标准的DTMF生成AT命令。本规范仅涉及AT+VTS=<DTMF>命令格式。

参见[2]中的附录C.2.11。

• AT+CNUM

语法:

AT+CNUM (检索用户号码信息)

AT+CNUM=? (测试用户号码信息——未实现)

描述:

HF针对AG中的“用户号码信息”功能发出的命令。

仅使用+CNUM格式的操作命令。

• +CNUM

语法:

+CNUM: [<alpha>],<number>, <type>,[<speed> ,<service>] (AT+CNUM命令响应)

描述:

用于从AG发送“用户号码信息”到HF的标准响应。

AG应向HF发送+CNUM:响应作为AT+CNUM的响应。

值:

<alpha>:此可选字段不受支持，应保留为空。
<number>:包含电话号码的带引号的字符串，格式由<type>指定。
<type>字段指定所提供电话号码的格式，可以是以下格式之一:

值128-143:电话号码格式可以是国家或国际格式，并且可以包含前缀和/或转义数字。无需更改数字显示。

值144-159: 电话号码格式为国际号码，包括国家代码前缀。如果加号(“+”)未包含在数字中，则AG应根据需要添加加号。

值160-175: 国家号码。不包括前缀或转义数字。

<speed>此可选字段不受支持，应保留为空。
<service>指示该电话号码与哪个service有关。应为4(语音)或5(传真）。

示例:

+CNUM: ,"5551212",129,,4

参见[2]中的7.1节。

指示符的激活和停用

HF应执行此过程，以此改变AG发送的指示符的子集。

如下前提条件适用于此过程:

• AG和HF之间应存在持续性的服务级连接。如果不存在此连接，HF应使用4.2节中描述的适合的过程，自主地的去创建服务级连接。

图4.65 指示符的激活和停用示例

图4.65并不意味着CIND字段的强制顺序，也不意味着CIND指示符字段的强制设置。

如果需要更改AG中指示符的激活/停用状态，HF应发出AT+BIA命令。

AG应在处理格式正确的命令后将OK结果代码发送至HF。

如果命令格式不正确，AG应向HF发送ERROR码。

成功处理AT+BIA命令后，AG不得发送停用的指示符。

只有事件报告使能时，AG才应发送已激活的指示符响应。

AT+BIA命令的影响仅在当前服务级连接期间持续有用，当服务级连接断开并且新的服务级连接建立，所有的指示符，默认的都处于激活状态。

在禁用事件报告时，发送AT+BIA命令是有效的。如果在服务级别连接终止之前启用了事件报告，AG应仅发送最近处理的AT+BIA命令激活的指示符。

如果事件报告(CMER)被禁用，然后又启用了，AG应仅发送最近处理的AT+BIA命令激活的指示符，或者在HF没有发送过AT+BIA命令时，发送所有的指示符。

AT+BIA命令对“AT+CIND”命令的响应是没有影响的(见[1]中4.33.2)。

AT+BIA命令限制适用于呼叫、呼叫状态和保持呼叫指示符。AG应该总是认为这些指示符已是被激活状态，即使HF请求停用它们。

AG被强制要求支持AT+BIA命令。

HF对AT+BIA命令的支持是可选的。

HF对使用AT+BIA命令是可选的。

更多关于AT+CMER(事件报告)命令的信息参见[1]中4.33节。

Bluetooth定义的AT功能

这些命令将参考GSM07.07的格式和语法规则。

下面列出了新的Bluetooth特定的AT功能:

• AT+BIA(Bluetooth指示符激活)

语法:AT+BIA=[[<indrep 1>][,[<indrep 2>][,…[,[<indrep n>]]]]]]

描述:

单独激活或者停用指示符。指示符映射由“AT+CIND”测试命令给出(见[1]中4.33.2节)。

<indrep x>:报告指示符x的状态。1表示激活，0表示停用。

如果逗号之间省略了指示符状态，则该指示符报告的当前状态不应改变。比如，如果HF发送命令“AT+BIA=,1,,0”，只有第二个和第四个指示符会受影响。第一个和第三个指示符报告的状态保持不变。

如果AG支持的指示符多余HF提供的报告过状态的指示符，AG应保持这些指示符报告的当前状态。比如，如果AG支持5个指示符，HF发送“AT+BIA=1,0,1”命令，那只有前三个AG指示符会收到此命令的影响。

Call、Call setup和Heldcall指示符已被定义为强制指示符。这意味着，不管HF报告什么状态，AG应该总是保持这些指示符为激活状态。

AG应优雅地忽略结尾处的任何多余参数。

AG应默默忽略停用强制指示符的命令请求。

前三点允许HF使用固定字符串激活或停用除了强制之外的指示符。

比如，如果最大的指示符的数量是20:

所有的指示符可以通过固定字串来设置激活:

AT+BIA=1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1

并且可以使用(除了总是激活状态的)以下字串去停用:

AT+BIA=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

实际所允许的指示符的数量由AT+CIND命令定义。

• AT+BINP(Bluetooth输入)

语法:AT+BINP=<datarequest>

期待响应: +BINP:<dataresp₁>…<dataresp_n>

描述:

命令用于从AG⁵请求一些特定的数据输入。收到该命令后，AG应执行适当的操作，以便使用+BINP响应将请求的信息返回给HF。

HF在AG返回的<dataresp>参数中预期的数据类型取决于每种情况下请求的信息。

只有对执行命令的支持是强制性的。读取和测试命令都不是强制性的。

⁵^{AT+BINP的创建考虑到了未来的可扩展性。而免提模式仅指定<datarequest>值1（即电话号码），未来的应用框架可能会选择为<datarequest>添加值，以支持从AG检索其他数据。}

值:

<datarequest>:1,

1=HF中记录的最后一个语音标签对应的电话号码。

<dataresp1..n>:AG返回的数据参数。它们的内容由<datarequest>参数的值决定，如下:

<datarequest> value

<dataresp> parameters

<Phone number>:

电话号码字符串(最大32个数字)。电话号码的格式(地址的类型)应符合[7]中所述规则，10.5.4.7款，对于地址八位字节类型为145的值(整数格式)，如果拨号字符串包含国际访问码字符“+”，则为129。

• AT+BLDN(Bluetooth上次拨打号码)

语法:AT+BLDN

描述:

命令用于呼叫上次拨打的电话号码。一旦收到此命令，AG应呼叫上次拨打的号码，建立语音呼叫。

只有对执行命令的支持是强制性的。读取和测试命令都不是强制性的。

• AT+BVRA(Bluetooth语音识别激活)

语法:AT+BVRA=<vrec>

描述:

使能/禁用AG中的语音识别功能。如果支持增强型语音识别功能，此命令用于向AG表明，HF已经准备好呈现语音输出。

只有对执行命令的支持是强制性的。读取和测试命令都不是强制性的。如果支持增强型语音识别功能，如果AG之前从HF接收到AT+BVRA=2且已建立eSCO链路，则AG应仅向HF发送音频。

仅当AG和HF都支持增强语音识别状态功能时，才应使用值2。

值:

<vrec>:0，1或2，整型输入

• 禁用AG中的语音识别。

• 如果支持增强型语音识别功能，该值将终止当前语音识别会话。

• 如果支持增强型语音识别功能，该值还可用于拒绝来自AG的+BVRA=1请求以启动新的VR会话。

1=使能AG中的语音识别。

2=当AG和HF都支持增强型语音识别功能时，该值才能使用。该值表示HF在第一次建立时就已经准备好接收音频了。HF只有在eSCO链路建立好时才应该发送该值。

HF可以在有VR会话的时候发送该值，以此终止来自AG的音频输出并且使AG准备接收新的音频输入。

• +BVRA(Bluetooth语音识别激活)

语法:+BVRA=<vrec> [,<vrecstate>][,<textualRepresentation>]

描述:

非请求码，用于AG自主地激活/停用AG自身的语音识别功能时通知HF。如果支持增强型语音识别功能，该值也用于AG的语言识别功能引擎状态的改变。

如果相应的语音识别激活已经由HF发起，非请求码+BVRA:1结果代码不能由AG发送给HF。此外，如果相应的语音识别停用已经由HF发起，非请求码+BVRA:0结果代码不能由AG发送给HF，无论哪一方发起的语音识别激活。

如果支持增强型语音识别功能，如果AG先前已经从HF收到了AT+BVRA=2并且eSCO链路已经建立好，则AG应该只传输音频给HF。

值:

<vrect>: 0,整型输入值

0=AG中的语音识别被禁用。

1=AG中的语音识别被启用。

<vrecstate>:

反映AG上语音识别引擎当前状态的Bitmask。当没有激活的语音识别会话时，0位应该被置为0。0位被置为0时，其他位都应被置为0。

如果AG和HF都支持增强语音识别状态功能，则应出现<vrecstate>；否则，它将不存在。

Bit	描述
0	如果该位为1，AG已经准备好接收音频输入
1	如果该位为1，AG正在向HF发送音频
2	如果该位为1，AG正在处理音频输入

<textualRepresentation>:

<textID>,<textType>,<textOperation>,<string>如果AG和HF都支持增强语音识别文本功能，textualRepresentation则应出现。

<textID>:

十六进制字符串的当前文本的唯一ID（有效长度最多为4个字符，但小于4个字符）。如果textType改变，TextID也应该改变。VR会话的每一个textID都应该时唯一的。跨越VR会话的TextID values 时无效的。

<textType>:

以下列表中文本类型的ID：

ID	描述
0	AG根据HF提供的音频输入识别的文本
1	AG的音频输出文本
2	AG中包含问题的音频输出文本
3	来自AG的音频输出文本，包含错误描述
4~31	留作将来使用

<textOperation>:

文本操作的ID

ID	描述
0	留作将来使用
1	新文本：表示新文本已启动。应在textID更改时使用
2	替换：使用相同的文本ID和文本类型替换任何现有文本
3	附加：将新文本附加到现有文本，并保持相同的文本ID和文本类型
4~31	留作将来使用

<string>:

<string>参数应为UTF-8文本字符串，且应始终包含在双引号内。字符串的长度取决于实现。

下面的+BVRA命令示例包含句子“Message to Melissa”的文本表示。在本例中，语音识别引擎的状态接受进一步的音频输入，文本ID为12AB，文本类型为“从音频输入识别的文本”，操作为“新文本”：+BVRA: 1,1,12AB,0,1,“Message to Melissa”

• AT+BRSF (Bluetooth检索支持功能)

语法: AT+BRSF=<HF supported features bitmap>

描述:

将HF支持的功能通知给AG，并请求有关AG中支持的功能的信息。支持的功能应以十进制值表示。

值:

<HF supported features bitmap>:

十进制数字字符串，表示32位无符号整数的值。32位无符号整数表示HF中受支持功能的位图，如下所示：

ID	功能
0	EC and/or NR function
1	Three-way calling
2	CLI presentation capability
3	Voice recognition activation
4	Remote volume control
5	Enhanced call status
6	Enhanced call control
7	Codec negotiation
8	HF Indicators
9	eSCO S4 Settings Supported
10	Enhanced Voice Recognition Status
11	Voice Recognition Text
12~31	留作将来使用

保留bit位(12~31)应初始化为0。

• +BRSF (Bluetooth检索支持功能)

语法: +BRSF=<AG supported features bitmap>

描述:

AG响应AT+BRSF命令发送的结果代码，用于通知HF AG支持哪些功能。支持的特征应以十进制值表示。

值:

<AG supported features bitmap>:

十进制数字字符串，表示32位无符号整数的值。32位无符号整数表示AG中受支持功能的位图，如下所示

Bit	功能
0	Three-way calling
1	EC and/or NR function
2	Voice recognition function
3	In-band ring tone capability
4	Attach a number to a voice tag
5	Ability to reject a call
6	Enhanced call status
7	Enhanced call control
8	Extended Error Result Codes
9	Codec negotiation
10	HF Indicators
11	eSCO S4 Settings Supported
12	Enhanced Voice Recognition Status
13	Voice Recognition Text
14~31	留作将来使用

保留bit位(14~31)应初始化为0。

• AT+NREC (噪声降低和回音消除)

语法: AT+NREC=<nrec>

描述:

发送该命令用于禁止嵌入AG中的回音消除和降噪功能。

对支持命令的执行是强制的。读取和测试命令都不是强制的。

值:

<nrec>: 0,整型输入

0=禁用AG中的EC/NR。

• AT+VGM (麦克风增益)

语法: AT+VGS=<gain>

描述:

HF发出的向AG报告其当前麦克风增益水平设置的命令。

<gain>是一个十进制数值常量，与HF控制的特定（取决于实现）音量有关。此命令不会改变AG的麦克风增益；它只是指示HF中话筒增益的当前值。

对支持命令的执行是强制的。读取和测试命令都不是强制的。

值:

<gain>: 0 -15，整型输入

0=最小增益

15=最大增益

• AT+VGS (扩音器增益)

语法: AT+VGS=<gain>

描述:

HF发出的向AG报告其当前扩音器增益水平设置的命令。

<gain>是一个十进制数值常量，与HF控制的特定（取决于实现）音量有关。此命令不会改变AG的扩音器增益；它只是指示HF中扩音器增益的当前值。

对支持命令的执行是强制的。读取和测试命令都不是强制的。

值:

<gain>: 0 -15，整型输入

0=最小增益

15=最大增益

• +VGM (麦克风增益)

语法: +VGM:<gain>

描述:

AG发送的非请求结果代码，用于设置HF的麦克风增益。<gain>是

一个十进制数值常量，与HF控制的特定(取决于实现)音量有

关。

由于GSM标准([2])与当前耳机规范([3])之间存在微小的不一

致，HF也应该接受“=”符号，替换“：”，作为该非请求码合法

的分隔符。

值:

<gain>: 0 -15，整型输入

0=最小增益

15=最大增益

• +VGS (扩音器增益)

语法: +VGS:<gain>

描述:

AG发送的非请求结果代码，用于设置HF的扩音器增益。<gain>是

一个十进制数值常量，与HF控制的特定(取决于实现)音量有

关。

由于GSM标准([2])与当前耳机规范([3])之间存在微小的不一

致，HF也应该接受“=”符号，替换“：”，作为该非请求码合法

的分隔符。

值:

<gain>: 0 -15，整型输入

0=最小增益

15=最大增益

• +BSIR (Bluetooth带内ringtone设定)

语法: +BSIR:<bsir>

描述:

AG发送给HF的非请求结果代码，用来表明带内ringtone设定已经在本地更改过。HF可通过改变其自身的振铃方式做出相应反应。

值:

<bsir>:

0=AG提供无带内ringtone

1=AG提供带内ringtone

• AT+BTRH (Bluetooth响应和保持功能)

语法:

AT+BTRH=<n>(设置命令)

AT+BTRH？(读取命令)

描述:

HF针对AG中的“响应并保持”功能发出的命令。

本规范定义了设置和读取命令。HF应使用“AT+BTRH？”命令去获取AG中的“响应和保持”当前状态。

值:

<n>:0,1,2 整型输入

0=将来电置为保持状态

1=接受保持状态的来电

2=拒绝保持状态的来电

• +BTRH (Bluetooth响应和保持功能)

语法:

+BTRH=<n>(AT+BTRH的响应)

描述:

结果代码，当来电被置为保持或者接受或者拒绝状态时，用于通知HF。AG也应该用此结果代码响应来自HF的AT+BTRH？命令。

值:

<n>:0,1,2 整型输入

0=来电被置为保持状态

1=保持状态的来电已被接受

2=保持状态的来电已被拒绝

• AT+BCC (Bluetooth编解码器连接)

语法:

AT+BCC

描述:

此命令被HF用来向AG请求开始编解码器连接过程。

• AT+BCS (Bluetooth编解码器选择)

语法:

AT+BCS= (u是编解码器ID)

描述:

此命令用于向AG确认编解码器，并且隐式地确认同步连接该使用哪一种同步协议。

如果没有值包含在里面，此命令为非法。

值:

:

所有可能的编解码器ID，参见AT+BAC定义。

• +BCS (Bluetooth编解码器选择)

语法:

+BCS: (u是编解码器ID)

描述:

AG用此命令将所选编解码器通知给HF，并且隐式地确认同步连接该使用哪一种同步协议。

值:

:

所有可能的编解码器ID，参见AT+BAC定义。

• AT+BAC (Bluetooth可用编解码器)

语法:

AT+BAC= [<u1>[,<u2>[,...[,<un>]]]] (u1,u2, ..., un 编解码器ID)

描述:

用此命令将HF支持的编解码器(见表3.3)通知给AG。

强制的窄带编解码器(CVSD)ID应该始终包括在里面。

如果支持宽带通话，则强制的编解码器(mSBC)应该被包括在里面，除非它暂时为不可使用。

任何其他可选的宽带语音编解码器也可以包括在此列表中，只要首先包括强制性编解码器。

值:

:

所有可能的编解码器ID。编解码器ID应以十进制数字的字符串表示形式传输。编解码器ID的格式为第10节(附录B：编解码器ID)中定义的8位别名。对于ID=12的单个编解码器和必需的默认编解码器（1和2），命令：

AT+BAC=1,2,12 被发送。

• AT+BIND (BluetoothHF指示符的功能)

语法:

AT+BIND= <a>,,<c>,...,<n> (HF支持的指示符列表)

AT+BIND=? (读取AG支持的指示符)

AT+BIND? (读取AG 使能/禁用指示符的状态)

描述:

此命令使HF能够通知AG支持哪些HF到AG的指示符。指示符可以启用或禁用。

当AG和HF BRSF的“HF Indicators”功能位都被设置为1时，AT+BIND命令才能使用。

值:

<a> ... <n>:

0-65535, 输入为无前导零的十进制无符号整数值，参考HF 指示符已分配的编号。值在Bluetooth SIG Assigned Number[10]网页上定义。请求中指示符已分配编号的最大数量应为20。

• +BIND (BluetoothHF指示符的功能)

语法:

AT+BIND:<a>,,<c>,...,<n> (AT+BIND=?的响应)

AT+BIND: <a>, <state>(作为非请求码，或者 AT+BIND?的响应)

描述:

此命令使AG能够通知HF，哪些HF支持的指示符和它们的状态，指示符可以启用或禁用。

当AG和HF BRSF的“HF Indicators”功能位都被设置为1时，+BIND响应才能使用。

当响应AT+BIND? Command命令时，AG应发送一个或多个+BIND响应，然后发送OK以终止列表。

值:

<a> ... <n>:

0-65535, 无前导零的十进制无符号整数值，参考HF 指示符已分配的编号。值在Bluetooth SIG Assigned Number[10]网页上定义。请求中指示符已分配编号的最大数量应为20。

<state>: 0-1, 整型输入

0=指示符已禁用，变化的值不应该向该指示符发送

1=指示符已使能，变化的值可用发送给该指示符

• AT+BIEV (BluetoothHF指示符的功能)

语法:

AT+BIEV= <assigned number>, <value> (指示符更新值)

描述:

此命令使HF向AG发送已启用HF指示符的更新值。

当AG和HF BRSF的“HF Indicators”功能位都被设置为1时，AT+BIEV命令才能使用。

值:

<assigned number>:

0-65535, 无前导零的十进制无符号整数值，参考HF 指示符已分配的编号。值在Bluetooth SIG Assigned Number[10]网页上定义。

<value>:

0 到4,294,967,295, 无前导零的十进制无符号整数值，该值的含义取决于<assigned number>，并在Bluetooth SIG assigned number[10]网页上定义。

HF指示符

功能描述

HF Indicator功能用于允许免提设备将某些HF指示符的数值通知给音频网关。HF可以通过使用此功能，分享一些如电池电量或增强的驾驶员安全开关等信息。

如第4.2.1节所述，设备应通过验证远程BRSF位来确定是否支持HF指示器功能

HF支持的HF Indicators的传输

在服务级连接建立过程中(见第4.2.1节)，HF应向AG发送支持的HF指示符列表。应使用分配编号[10]网页中分配的相应16位已分配编号来表示https://www.bluetooth.com/specifications/assigned-numbers/. HF不得发送任何未经过Bluetooth SIG定义的指定号码。

图4.66: HF发送支持的HF指示符

AG支持的HF Indicators的传输

HF发送其支持的HF指示器列表后，应确定AG支持的指示符。HF 应发送 AT+BIND=? 命令到 AG。 AG 应以 +BIND 响应，指示 AG 支持哪些 HF 指示符。

图4.67: AG支持的HF指示符

从AG到HF使能的HF Indicators的传输

一旦 HF 如第 4.36.1.2 节所述确定了 AG 支持哪些 HF 指示符，HF 将通过发送 AT+BIND ？命令来确定 AG 能够接收哪些 HF 指示符。然后，AG 将发送一个或多个 +BIND:anum,state 响应，其中包含每个支持的 HF 指示符的分配编号和状态（0=禁用/1=启用），然后是 OK。

图4.68: AG列出每个HF指示符的使能/禁用状态

AG支持的HF Indicators的激活和停用

AG 可以更改 HF 支持的任何 HF 指示器的启用/禁用状态。为了改变状态，AG 发送一个非请求码 +BIND:anum,state。每当 HF 收到来自 AG 的非请求 +BIND 指示，该指示用于将特定 HF 指示符的状态从禁用变为启用时，HF 应使用 +BIEV 命令将该指示器的当前状态发送到 AG(见第 4.36.1.5 节)。这将确保 HF 指示符的状态在设备之间同步。

图4.69: 设置HF指示符使能/禁用状态

HF Indicators的值的传输

当 HF 内的情况发生变化时，它将使用 AT+BIEV=anum, value 命令通知 AG 值的变化。然后，AG 应以 OK 确认收到值更新。如果 AG 不支持 HF 上报的指示符或如果它被禁用，AG 将返回一个 ERROR 响应代码。

分配编号及其相关值由Bluetooth SIG 在分配编号 [10] 网页中定义。

图4.70: HF指示符的值更新

HF 应该只为那些已设置为由 AG 启用的 HF 指示器值更新。如果 AG 接收到禁用或未知 HF 指示符或超出范围的值的更新，则 AG 应以 ERROR 响应代码进行响应。

串行端口应用框架

此应用框架符合Serial Port Profile [6]。除了Serial Port Profile中定义的要求外，以下文本和相关子条款还定义了与此应用框架文件相关的要求。

对于免提应用框架，AG和HF都可以发起连接的建立。因此，为了理解Serial Port Profile [5]，AG和HF都可以假设为角色中的设备A或者设备B。

RFCOMM互操作需求

对于RFCOMM层，Serial Port Profile [6]中的第4节规定的要求不适用。

L2CAP互操作性要求

对于L2CAP层，Serial Port Profile [6]中的第5节规定的要求不适用。

SDP互操作性要求

以下服务记录是为免提应用框架定义的。有一个服务记录适用于免提装置，另一个适用于音频网关。

“SupportedFeatures”属性描述了每一个设备支持的功能。该属性未编码为数据元素序列；它只是一个16位无符号整数。在此属性中，每种情况下支持的功能集，以是/否为基础，逐位定义的。HF的该属性中的功能和相应的bit位之间的映射已在表5.2列出，AG的已在表5.4列出。如果一个设备表示支持某一功能，应以本框架规定的方式支持该功能。

Value列中，给助记符分配的编码，与给属性id(如果没有明确在AttrID中指出的话)分配的编码一样，已经在Bluetooth Assigned Numbers [10]网页中列出。

表5.2中给出的“SupportedFeatures”位映射值，应该与AT-command AT+BRSF(见4.35节)中的Bit0~4相同。

Item				Definition	Type	Value	Status	Default
ServiceClassIDList							M
	ServiceClass0				UUID	Hands-Freee	M
	ServiceClass1				UUID	Generic Audio	M
ProtocolDescriptorList							M
	Protocol0				UUID	L2CAP	M
	Protocol1				UUID	RFCOMM	M
			ProtocolSpecificParameter0	ServerChannel	Uint8	N=server channel#	M
BluetoothProfileDescriptorList							M
	Profile0			SupportedProfile	UUID	Hands-Free	M	Hands-Free
		Param0		ProfileVersion	Uint16	0x0108(6)	M
ServiceName				Display-able Textname	String	Service-provider	O	“Hands-Free unit”
SupportedFeatures				Features supported	Uint16	Device development	M	0x0000

表5.1 HF服务记录

Bit position(0=LSB)	Feature	Default in HF
0	EC and/or NR function (yes/no, 1 = yes, 0 = no)	0
1	Call waiting or three-way calling (yes/no, 1 = yes, 0 = no)	0
2	CLI presentation capability (yes/no, 1 = yes, 0 = no)	0
3	Voice recognition activation (yes/no, 1= yes, 0 = no)	0
4	Remote volume control (yes/no, 1 = yes, 0 = no)	0
5	Wide band speech (yes/no, 1 = yes, 0 = no)	0
6	Enhanced Voice Recognition Status (yes/no, 1 = yes, 0 = no)	0
7	Voice Recognition Text (yes/no, 1 = yes, 0 = no)	0

表5.2 HF “SupportedFeatures”属性bit映射

“Network”属性说明 AG 是否有能力拒绝传入呼叫⁷。该属性未编码为数据元素序列；它只是一个8位无符号整数。“Network”属性中给出的信息应与非请求结果代码+BRSF第5位中给出的信息相同(见第4.35节)。将0x00的属性值转换为0的位值；属性值0x01转换为位值1。

表5.4中给出的“SupportedFeatures”位图的值应与非请求结果代码+BRSF的位0至4的值相同（见第4.35节）。

^{6 指示版本HFP 1.8[E7428]}

^{7 在以前版本的面条应用框架中，属性值称为“类似GSM”和“其他”}

表5.2 AG Service Record

表5.4: “SupportedFeatures” attribute bit mapping for the AG

与免提模式0.96实现的交互

HF实现，根据免提应用框架修订版0.96，将不发送AT+BRSF命令。同样，根据免提应用框架修订版 0.96 的 AG 实现将无法使用 +BRSF 未经请求的结果代码响应 AT+BRSF。相反，它们会以 ERROR 响应。

为了从不发送 AT+BRSF 的 HF 检索“SupportedFeatures”信息，AG 实施应使用服务发现。当 HF 服务记录中不存在“SupportedFeatures”属性时，或者如果 AG 不执行服务发现过程，则应假定表 5.2 中所述的默认值。

为了从不发送 +BRSF 的 AG 检索“SupportedFeatures”和“Network”信息，HF 实施应使用服务发现。每当 AG 服务记录中不存在“SupportedFeatures”属性时，或者如果 HF 不执行服务发现过程，则应假定表 5.4 中所述的默认值。

与HFP 0.96、1.0和HFP 1.5实现的交互

符合免提应用框架修订版 0.96、1.0 或 1.5 的 HF 实现不应指示对编解码器协商功能的支持，并且AG不应发送 AT+BAC 命令或 AT+BCC 命令来触发音频连接建立。

符合免提应用框架修订版 0.96、1.0 或 1.5 的 AG 实现不应指示对编解码器协商功能的支持，也不应向 HF 发送 +BCS非请求响应。

为了向后兼容，HFP 修订版“x.y”实现应能够根据免提应用框架修订版 1.0 或 1.5 处理同步连接的建立。

• HF 应能够接受来自 HFP 1.0 或 1.5 AG 的同步连接的建立。

• AG 应能够启动与 HFP 1.0 或 1.5 HF 的同步连接的建立。

图5.1 从AG建立音频连接过程

HF 应能够启动与 HFP 1.0 或 1.5 AG 的同步连接的建立。

AG 应能够接受来自 HFP 1.0 或 1.5 HF 的同步连接的建立。

图5.1 从HF建立音频连接过程

链路管理器（LM）互操作性要求

该应用框架采用了“串行端口应用框架”[6] 中所述的对链路管理器的要求。

此外，该框架要求 AG 和 HF 设备均应支持同步逻辑传输，但须符合第 5.6 节中的要求。

链路控制（LC）互操作性要求

表 5.5 显示了串行端口框架 [6] 中链路控制器的要求变化。

表5.5 链路控制器要求

Class of Device

实现HFP 中的HF角色的设备应在服务等级字段中设置“音频”位。或者，如果HF打算被发现为“免提”，它可以在设备类别字段中使用以下值：

将“音频”指示为主要设备类别。
将“免提”指示为次要设备类别。

查询 AG 可以使用此信息来过滤查询响应。

基带互操作性要求

如果支持宽带语音，则应支持 eSCO 链路和空中模式“透明数据”，否则为可选。

只有在支持核心版本 2.1 或更高版本的情况下，才能将错误数据传送用于宽带语音。

C1: 如果支持宽带语音，则为必填项，否则为可选

C2: 如果支持核心版本 2.1 或更高版本，则可选，否则排除

表5.6 基带要求

编解码器互操作性要求

表5.7显示了应用框架支持的强制和可选编解码器。

C1: 如果支持宽带语音则为强制选项，否则为排除项.

表5.7 支持的编解码器

同步连接互操作性要求

图5.3 同步连接建立流程图

同步传输的选择

发起同步连接请求的设备称为发起方，接收请求的设备称为响应方。响应者可以接受或拒绝逻辑传输请求。

要选择要使用的同步传输类型(eSCO 或 SCO)，设备应遵循以下逻辑：

• 如果响应方支持 eSCO，则应首先在 eSCO 逻辑传输上尝试同步连接。见第 5.7.1.2 节。

• 如果 eSCO 不可用(例如，Responder 不支持或链路建立失败)，并且由于正在使用 BR/EDR 安全连接而当前未禁止 SCO，则发起方应打开 SCO 逻辑连接。见第 5.7.1.3 节。

eSCO配置参数的协商

本节以 HCI 级别参数作为参考。在不包含 HCI 的系统上，应使用 LMP 级 eSCO 连接参数 T_eSCO 、W_eSCO 和对应于这些 HCI 参数的数据包长度的等效值。以下要求适用于 eSCO 逻辑传输的支持和使用，并基于参数集 S1-S4 和 T1-T2：

• 发起方对 eSCO 传输的请求可能涉及与语音编解码器的双向吞吐量要求相匹配的任何配置参数（见第 5.5 节）。如果此设备支持 HCI，则建立同步连接的请求可能包括在同一请求中屏蔽的单个或多个数据包类型。

• 响应者可以选择接受或拒绝发起者的请求。它可能会拒绝 eSCO 传输的请求，或者可能会接受与请求参数不匹配的参数。在这种情况下，发起方可以使用不同的配置参数重试同步连接设置。

• 建议在使用 BR/EDR 安全连接、使用复杂拓扑或设备想要提高与其他无线技术的共存时使用 S4 或 T2 设置。

• 如果对 S4、S3 或 T2 的请求失败并且发起方需要采用基于时分的解决方案来实现 MWS 共存，发起方应尽最大努力重新配置其 MWS 无线电，以便不再需要采用时分- 基于划分的 MWS 共存解决方案。例如，AG 可能有机会更改其正在使用的蜂窝频段，以允许在同步连接期间关闭 MWS 共存功能。

• 当远程设备请求时，设备应接受使用 S4 或 T2 设置。仅支持此框架 1.7.1 或更早版本的设备可能会拒绝 S4 设置，在这种情况下，发起设备应请求 S3 设置。

• 如果对 eSCO 逻辑传输的初始或任何后续请求失败，则发起方不得在未使用下表中指定的“安全设置”请求 eSCO 的情况下放弃 eSCO 传输的设置：

表5.7 强制安全设置

• 仅适用于基于 HCI 的设备：如果响应方不拒绝 eSCO 传输请求，则响应始终包含与表 5.8 中指定的“安全设置”对应的参数，当接受请求时。如果发起方未能使用 S1 设置建立 eSCO 传输，发起方应请求建立 SCO 传输，如果当前没有被禁止，因为正在使用 BR/EDR 安全连接。

• 如果支持宽带语音，并且发起方无法使用 T1 设置建立 eSCO 传输，发起方应尝试使用窄带 CVSD 编解码器通过 eSCO(或 SCO 传输，如果由于 BR /EDR 安全连接正在使用）。

SCO配置参数的协商

在允许使用 SCO 逻辑传输的条件下，与使用 SCO 链路相关的要求包含在参数集 D0-D1 中。

透明数据的同步头

定义了两个同步头；第一个只包含一个序列号。第二个具有同步字和序列号。

H1：带有序列号的头

图 5.4 显示了仅包含序列号的标题 H1 的布局。一个八位字节报头应包含一个 4 位序列号（SN0，…，SN3）。序列号由一个简单的重复代码保护(所有位都是重复的)。因此，序列号中的每个连续位对应始终为 00 或 11。

图5.4 一字节帧同步 H1 头

当使用错误数据传递特性时，H1 头中的序列号应始终不为 0。原因是错误数据传递特性将对应于丢失 (e)SCO 数据包的有效载荷数据八位字节设置为 0。

H2：带有同步字和序列号的报头

图 5.5 显示了包含同步字和序列号的头 H2 的布局。两个八位字节头应包含一个 12 位同步字和一个 2 位序列号(SN0，SN1)。后者由一个简单的重复代码保护(两个位都是重复的)。因此，序列号中的每一对位应始终为 00 或 11。

图5.5 两字节帧同步 H2 头

应该注意的是，当使用透明数据传输时，编码音频流帧（编解码器帧和同步字）与 eSCO 数据包边界的任何对齐都取决于实现。同步报头的使用使得接收方能够恢复未对齐的编解码器音频帧。

CVSD编码

表 5.9 定义了用于 CVSD 编码的 SCO 配置参数集 D0 和 D1。

表5.9 SCO 同步连接(HCI 参考参数)

表 5.10 定义了用于 CVSD 编码的 eSCO 配置参数集 S1、S2、S3 和 S4。

表5.10 eSCO 同步连接(HCI 参考参数)

mSBC编码

如果此应用框架支持宽带语音，则必须支持 SBC 编解码器的修改版本（以下称为 mSBC）。原始 SBC 编解码器在 A2DP [9] 中指定。构成 mSBC 的 SBC 修改在本概要的附录 A 中指定。

此编解码器的各种强制性和可选设置在下表中指定。

如果支持宽带语音，则必须支持以下 mSBC 配置。

表5.11 mSBC强制参数集

一个 mSBC 帧，应该在每个帧之前有一个同步头 H2。 H2 标头将确保接收器知道是否丢弃了一个或多个无线电链路数据包。

使用 mSBC 编解码器时，宽带语音应仅使用 eSCO 传输。应支持以下 eSCO T1 设置。如果一个或多个 eSCO 设置请求失败，则需要在放弃通过 eSCO 传输的宽带语音之前使用 T1 设置。

表5.12 使用mSBC编解码器的宽带语音连接eSCO参数

编解码器与链路参数协商

此应用框架中定义的编解码器协商过程确定在建立音频连接时使用哪个编解码器。此过程不用于协商与所选编解码器一起使用的链路参数。链路参数由链路管理器通过使用链路管理器的协议去协商。

推荐的链接参数是：

• 对于 CVSD：S4 优于 S3，S3 优于 S2，S2 优于 S1，S1 优于 D1，D1 优于 D0。使用 S4 的决定也可能基于实现特定的共存用例。

• 对于 mSBC：T2 优于 T1。

可选编解码器

设备可能支持可选编解码器，以最大限度地提高其可用性。当发起设备和响应设备都支持相同的可选编解码器时，可以使用此编解码器代替强制编解码器。目前没有可选的编解码器被列为本规范的一部分。

本规范文档的未来版本可以通过向附录 B 和可选的编解码器规范添加新的可选编解码器 ID 来包含可选编解码器。

如果指定了可选编解码器，则它应支持 T2 eSCO 逻辑传输设置。

语音质量建议

在HFP框架中引入宽带语音将提高终端客户对感知语音质量的期望。如果遵循，以下章节中的建议将有助于确保高水平的客户满意度。

包丢失隐藏（PLC）

强烈建议在宽带语音连接的接收端，采用某种形式的PLC，以在所有信道条件下提供令人满意的语音质量。

可使用附录C中提供的示例PLC算法。该示例PLC在典型丢包条件下的语音质量令人满意。如果实施选择修改或实施备用PLC方案，任何此类备用PLC的性能应达到或超过附录C中提供的示例PLC的性能。

信号等级

在本应用框架中，编解码器的16位线性PCM接口的全摆幅定义为3 dBm0。此定义适用于支持窄带和宽带语音的设备。

通用访问应用框架(GAP)

本节定义了对核心规范的“通用访问框架”中定义的功能的支持要求。

模式

表 6.1 显示了此框架中 GAP 模式的支持状态。

表6.1 模式

安全方面

免提装置和音频网关的基带认证和加密都是可选的。如果两个设备都支持身份验证和加密，则任一个设备上的应用程序可能需要使用它。但是，如果两个设备都支持安全连接，则Bluetooth核心 4.1 规范(或更高版本)强制要求使用它。

免提装置可以在不创建安全连接的情况下使用音频网关的服务。免提单元是否为用户提供或支持安全实施是特定于实现的。

每当使用基带验证或加密时，两个设备应使用通用访问框架 [5] 的第 5.1 节中描述的 GAP 验证程序创建安全连接。此过程可能包括输入Bluetooth PIN 码或密码以及创建正确的链接密钥。如果未使用简单安全配对且免提装置的 UI 受到限制，则在 GAP 身份验证过程中可能会使用固定的Bluetooth PIN 码。

如果使用 Secure Connections，Authenticated Payload Timeout 应小于或等于 10s。超时后的断开连接行为是特定于实现的。

Idle模式程序

表 6.2 显示了此框架文件中空闲模式程序的支持状态。

表6.2 Idle模式程序

参考文献

[1] Bluetooth Core Specification, v1.1 or later

[2] 3GPP 27.007 v6.8.0 now supersedes and replaces ETS 300 916, “Digital cellular

telecommunications system (Phase 2+); AT command set for GSM Mobile Equipment (ME) (GSM

07.07 version 7.5.0)”

[3] 3GPP Specification: http://www.3gpp.org/ftp/Specs/html-info/27007.htm

[4] Headset Profile (HSP), v1.1 or later

[5] Bluetooth Core Specification, v1.1 or later. [Vol 3] Part C, Generic Access Profile

[6] Serial Port Profile v1.1 or later

[7] ITU-T50, Terminal Equipment and Protocols for telematic services: International Reference

Alphabet (IRA) (Formerly International Alphabet No. 5 IA5). Information technology – 7-Bit coded

character set for information interchange

[8] Digital cellular telecommunication system (Phase 2+); Mobile radio interface layer 3 specification,

(GSM 04.08 version 6.11.0)

[9] Advanced Audio Distribution Profile (A2DP), v1.0 or later

[10] Bluetooth Assigned Numbers

[11] D. Goodman, et al., “Waveform Substitution Techniques for Recovering Missing Speech Segments

in Packet Voice Communications”, IEEE Transaction on Acoustics, Speech and Signal Processing,

December 1986, pp. 1440 - 1448.

缩略词列表

附录A: mSBC技术规范

介绍

本附录描述了A2DP[9]标准中定义的SBC编解码器的变更，该标准包括修改后的SBC编解码器。A2DP SBC的更改仅仅限于帧头部的语法和语义。SBC定义的所有其他部分仍未修改。

助记符

以下助记符用于描述编码比特流中使用的不同数据类型。

表9.1 助记符

语法

表9.2 mSBC语音帧的语法

Note: mSBC语音帧的语法与A2DP[9]中的原始SBC定义相同。

表9.3 mSBC帧头部的语法

语义

Frame_header

syncword ——8 位字符串 %10101101 或 $AD。

同步字与 A2DP 规范中为 SBC 指定的同步字不同，因此实现可以将其用作编码流旨在包含宽带语音的附加指示。

Codec ID——下表表示与编解码器 ID 字段中指定的值对应的各种 mSBC 参数的值。

表9.4 编解码器 Id 到 mSBC 参数的映射

表 9.4 中规定的 mSBC 参数的解释与 A2DP [9] 中 SBC 定义中规定的解释相同。

Padding

全零 8 位字符串 %00000000 或 $00 应用于填充。

附录B: 编解码器ID

下表指定了编解码器到各自编解码器ID的映射。

表10.1 编解码器类型到ID的映射

附录C: PLC实现示例

本附录描述了基于 D. Goodman 等人[11]的论文的数据包丢失隐藏 (PLC) 方法，并适用于 mSBC。

基线丢包隐藏

讨论了基于 [1] 中介绍的技术的基线数据包丢失隐藏算法。这个基线 PLC 是一个通用的基于 PCM 的系统，不对 mSBC 做任何假设。将其集成到 mSBC 中以形成 mSBC 的参考 PLC，将在后面的部分中描述。

以下小节描述了基线 PLC 算法中使用的技术。

基于模式匹配的波形替换

[1] 的第四节“基于模式匹配的波形替换”中的技术用于构建丢失数据包中波形的估计。该算法搜索先前接收到的样本的历史缓冲区以找到样本的数据包价值来替换丢失的数据包。该选择基于构建紧接在丢失数据包之前的 M 个样本的模板，并扫描历史缓冲区中 N 个样本的搜索窗口以找到与模板最匹配的 M 个样本。然后它将遵循最佳匹配的 L 个样本用作替换数据包。所使用的模式匹配标准是与论文的等式(4)中的相似的互相关，除了分母包含一个平方根，如互相关的标准定义。实现遵循论文的建议，并使用 4ms (M=64)的模板和 16ms(N=256)的搜索窗口。使用 7.5ms(L=120)的帧大小，对应于默认 mSBC 配置的帧大小。

重叠相加

如论文第三部分所述，为了减少由正确数据包和替代数据包之间的边界处的不连续性引起的可听失真，通过重叠相加程序“合并”两个波形是很重要的。示例 PLC 遵循论文的建议，并使用升余弦加权，合并持续时间为 1 ms(16个样本)。论文添加了1ms的延迟，以便在最后一个正确数据包和替换数据包之间的边界处进行合并。然而，示例 PLC 通过使用包含在 mSBC 解码器存储器中的部分信号来避免这种增加的延迟。这将在第 11.2.1 节中更详细地描述。在丢包后的第一个正确包与替代包它们之间的边界处，论文将替代波形扩展1ms到正确的包中以进行合并。示例 PLC 遵循类似的方法，除了进一步扩展替代波形以允许 mSBC 解码器信号在数据包丢失后重新收敛。这也在后面描述。

幅度匹配

论文的 B 部分描述了调整替换包的幅度以匹配前一包的幅度的过程。示例 PLC 使用数据包幅度的均值绝对值测量来实现这种方法。

PLC与mSBC的集成

论文中描述的 PLC 是为 PCM 设计的，没有考虑与诸如 mSBC 之类的编解码器集成。就 PLC 的集成而言，mSBC 的主要问题是 mSBC 解码器中子带滤波器的响应。集成将在接下来的小节中描述。

第一个替换帧中合并——避免延迟

如前所述，本文通过引入1ms延迟在最后一个正确数据包和替换数据包之间执行合并。在示例PLC中，通过利用嵌入在mSBC解码子带滤波器存储器中的信号避免了该延迟。在第一替换帧中，向mSBC解码器馈送与全为零的输入信号相对应的比特流。然后，使用本文所述的1ms升余弦加权，使用解码器的输出与替换波形合并。此过程还具有将解码器内存设置为零的优点。

mSBC在丢包后第一个正确包的重聚合

mSBC解码器中的子带滤波器引起的延迟意味着，当分组丢失后的第一个正确分组被解码时，在输出重新收敛到所需的解码器输出之前将有一段时间。由于解码器存储器基本上通过第11.2.1节中描述的程序重置为零，解码器输出将在其重新收敛时从零开始上升。在分组丢失之后，替换波形被扩展到第一个正确分组中，扩展量等于该重新收敛时间，并用作输出。一旦解码器输出已充分重新收敛，则使用1ms升余弦加权将替换波形与解码器输出合并。使用的再聚集时间在实验上调整为36个样本（2.25ms）。

API描述

本节介绍mSBC示例PLC的API。

内存分布

初始化

正确帧的处理

错误帧的处理

SBC解码器zero-input响应

错误帧调用示例

源码(ANSI C)

sbcplc.h源码文件

sbcplc.c源码文件

附录D: 质量指标

音频水平

Bluetooth核心规范(第二卷，B部分，第9节，音频)用于Bluetooth空中接口的语音CVSD编解码器。核心协议同样也为窄带语音提供了通用音频建议。此附录为免提应用框架的宽带语音更新提供建议。

对于CVSD(窄带)和宽带语音编解码器来说，满标度正弦波PCM数据应满足之前为CVSD编解码器指定的+3dBm0网络水平。

AG制造商应调整从Bluetooth参考点（BTR）到蜂窝网络的增益，如核心规范所示。HF负责将语音信号调整到BTR，如核心规范所示，以此确保AG和HF之间的最佳互操作性，如ITU-T P.1100所述，在HF的嘴参考点处，在给定的-4.7 dBPa标称声压级下，能够使网络中的标称语音电平为-21dbm0。

dBm0：以dBm为单位的绝对功率电平指相对电平为零的点（0 dBr点）

可能的测试步骤如图12.1。

表12.1 音频水平测试示例

在确认AT+NREC=0命令后，应针对两种信号处理模式调整从BTR到网络的增益和从网络到BTR的增益：在电话(AG)或免提(HF)设备上。当确认AG上的信号处理被禁用时，可以使用正弦信号来验证BTR和网络之间的增益。在AG上执行回声消除和降噪的主动信号处理时，正弦信号可能导致错误结果，应使用类似语音的信号，如P.50(人工语音)。由于实际网络中增益和信号处理的未知状态，因此强烈建议在测试期间使用网络模拟器。