本文章主要講下電話免提協(xié)議HFP（Hands-Free Profile）Connection management。包括connection establishment? ? ?跟connection realease，那connection establishment又會(huì)涉及到HFP SLC的建立過程。
本節(jié)講解的內(nèi)容就是一下HFP feature中的NO.1
本專欄文章我們會(huì)以連載的方式持續(xù)更新，本專欄計(jì)劃更新內(nèi)容如下：
第一篇:藍(lán)牙綜合介紹 ，主要介紹藍(lán)牙的一些概念，產(chǎn)生背景，發(fā)展軌跡，市面藍(lán)牙介紹，以及藍(lán)牙開發(fā)板介紹。
第二篇:Transport層介紹,主要介紹藍(lán)牙協(xié)議棧跟藍(lán)牙芯片之前的硬件傳輸協(xié)議,比如基于UART的H4,H5,BCSP，基于USB的H2等
第三篇:傳統(tǒng)藍(lán)牙controller介紹，主要介紹傳統(tǒng)藍(lán)牙芯片的介紹，包括射頻層（RF），基帶層（baseband），鏈路管理層（LMP）等
第四篇:傳統(tǒng)藍(lán)牙host介紹，主要介紹傳統(tǒng)藍(lán)牙的協(xié)議棧，比如HCI,L2CAP,SDP,RFCOMM,HFP,SPP,HID,AVDTP,AVCTP,A2DP,AVRCP,OBEX,PBAP,MAP等等一系列的協(xié)議吧。
第五篇：低功耗藍(lán)牙controller介紹，主要介紹低功耗藍(lán)牙芯片，包括物理層（PHY），鏈路層（LL）
第六篇：低功耗藍(lán)牙host介紹，低功耗藍(lán)牙協(xié)議棧的介紹，包括HCI,L2CAP,ATT,GATT,SM等
第七篇：藍(lán)牙芯片介紹，主要介紹一些藍(lán)牙芯片的初始化流程，基于HCI vendor command的擴(kuò)展
第八篇：附錄，主要介紹以上常用名詞的介紹以及一些特殊流程的介紹等。
另外，開發(fā)板如下所示，對于想學(xué)習(xí)藍(lán)牙協(xié)議棧的最好人手一套。以便更好的學(xué)習(xí)藍(lán)牙協(xié)議棧，相信我，學(xué)完這一套視頻你將擁有修改任何協(xié)議棧的能力（比如Linux下的bluez，Android下的bluedroid）。
-------------------------------------------------------------------------------------------------------------------------
CSDN學(xué)院鏈接（進(jìn)入選擇你想要學(xué)習(xí)的課程）：
藍(lán)牙交流扣扣群：970324688
Github代碼：
入手開發(fā)板：
藍(lán)牙學(xué)習(xí)目錄：
--------------------------------------------------------------------------------------------------------------------------
HFP connection Management分為兩個(gè)小節(jié)：1）connection establishment? ? ?2）connection realease
下面我們就來分別介紹下兩個(gè)小節(jié)
Upon a user action or an internal event, either the HF or the AG may initiate a Service Level Connection establishment procedure.
A Service Level Connection establishment requires the existence of a RFCOMM connection, that is, a RFCOMM data link channel between the HF and the AG.
Both the HF and the AG may initiate the RFCOMM connection establishment. If there is no RFCOMM session between the AG and the HF, the initiating device shall first initialize RFCOMM.
When an RFCOMM connection has been established, the Service Level Connection Initialization procedure shall be executed.
其中以上的意思大概就是：在建立HFP SLC之必須要有一個(gè)RFCOMM通道，也就是HFP的Server channel必須存在
你可能會(huì)問HFP的SLC是什么，拿SLC（Service Level Connection）就是一堆HFP HF角色跟AG角色的一些AT command的交互，這些AT command交互完畢才叫HFP SLC建立，SLC建立的流程如下：
下面我們就來分別介紹下小步驟（注意哈，虛線部分是可選步驟，在SLC建立的時(shí)候可以不做）：
First, in the initialization procedure, the HF shall send the AT BRSF=<HF supported features> command to the AG to both notify the AG of the supported features in the HF, as well as to retrieve the supported features in the AG using the BRSF result code.
這個(gè)過程很簡單充當(dāng)HF角色首先要發(fā)送AT BRSF=<HF supported features>，AG會(huì)回復(fù) BRSF=<AG?supported features>
BRSF?(Bluetooth Retrieve Supported Features)，此命令就是用于HF和AG互相告知對方支持的特性，HF&AG的support feature都是一個(gè)32bit的數(shù)，HF的support feature的bit map為
其中bit7為V1.6才添加，bit 7,8,9是V1.7才添加，AG的support feature的bit map為：
其中bit9為V1.6才添加，bit10,11是V1.7才添加
Secondly, in the initialization procedure, if the HF supports the Codec Negotiation feature, it shall check if the AT BRSF command response from the AG has indicated that it supports the Codec Negotiation feature. If both the HF and AG do support the Codec Negotiation feature then the HF shall send the AT BAC=<HF available codecs> command to the AG to notify the AG of the available codecs in the HF.
如果HF和AG都支持BRSF中的Codec negotiation，那么HF發(fā)送：
AT BAC=<HF available codecs>
BAC(Bluetooth Available Codecs)
Description:
This command informs the remote device (AG) about what codecs (see Table 3.3) the HF
supports.The Codec ID for the mandatory narrow band codec (CVSD) shall always be included. If wide band speech is supported, then the mandatory codec (mSBC) shall be included unless it is temporarily unavailable.
Any other optional wide band speech codecs may also be included in this list as long as the
mandatory codec is included first.
這個(gè)命令是HF告知AG，自己支持的codec,CVSD就是NBS（窄帶通話，8KHz）的編解碼方式，mSBC就是WBS(寬帶電話，16KHz)的編解碼方式,ID如下表所示
After having retrieved the supported features in the AG, the HF shall determine which indicators are supported by the AG, as well as the ordering of the supported indicators. This is because, according to?the 3GPP 27.007 specification [2], the AG may support additional indicators not provided for by the Hands-Free Profile, and because the ordering of the indicators is implementation specific. The HF uses the AT CIND=? Test command to retrieve information about the supported indicators and their ordering. Once the HF has the necessary supported indicator and ordering information, it shall retrieve the current status of the indicators in the AG using the AT CIND? Read command. After having retrieved the status of the indicators in the AG, the HF shall then enable the "Indicators status update" function in the AG by issuing the AT CMER command, to which the AG shall respond with
OK. As a result, the AG shall send the CIEV unsolicited result code with the corresponding indicator value whenever a change in service, call, or call setup status occurs. When an update is required for both the call and call setup indicators, the AG shall send the CIEV unsolicited result code for the call indicator before sending the CIEV unsolicited result code for the call setup indicator. The HF shall use the information provided by the CIEV code to update its own internal and/or external indications.
Once the "Indicators status update" function has been enabled, the AG shall keep the function enabled until either the AT CMER command is issued to disable it, or the current Service Level Connection between the AG and the HF is dropped for any reason.
After the HF has enabled the “Indicators status update” function in the AG, and if the “Call waiting and 3-way calling” bit was set in the supported features bitmap by both the HF and the AG, the HF shall issue the AT CHLD=? test command to retrieve the information about how the call hold and multiparty services are supported in the AG. The HF shall not issue the AT CHLD=? test command in case either the HF or the AG does not support the "Three-way calling" feature.
這部分有幾個(gè)重點(diǎn)：
① 發(fā)送AT CIND=?問詢支持的indicators(包括service/call/callsetup/callheld/signal/?roam/?battchg)的index
AT CIND=?是問詢AG有多少indicators，并且自己解析每個(gè)indicators的index
如圖所示：service的index是1，call的index是2，callsetup的index是3，battchg的index是4，signal的index是5，roam的index是6，callheld的index是7，后續(xù)AG更新過來 CIEV是通過這個(gè)index來決定他是跟的什么值
② 發(fā)送AT CIND?問詢各個(gè)indicators的status，此命令就是統(tǒng)一問下各個(gè)indicator的值，接著上圖問詢AT CIND?
如圖，service的值為1，call的值為0，callsetup的值為0, battchg的值為2, signal的值為3, roam的值為0, callheld的值為0，那么你一定會(huì)好奇各個(gè)value的值代表什么意思，下面我們就一一貼出
發(fā)送AT CMER enable各個(gè)indicators,發(fā)送這個(gè)后，如果某一個(gè)indicator有變化，那么AG就可以發(fā)送 CIEV來告知
AT CMER 是Standard event reporting activation/deactivation AT command.說白了就是使能/失能 indicator，一共有兩種格式
AT CMER=3,0,0,1 activates “indicator events reporting”.
AT CMER=3,0,0,0 deactivates “indicator events reporting”.
使能之后，AG可以發(fā)送 CIEV命令來匯報(bào)各個(gè)indicator的變化
先來看下 CIEV AT command
CIEV:Standard “indicator events reporting” unsolicited result code.
格式為： CIEV: <ind>,<value>，舉例來說（此部分要根據(jù)CIND的index來角色，每個(gè)AG可能index不同，所以代碼重要有解析index的動(dòng)作，我這個(gè)index是根據(jù)2.1.3小節(jié)的index來講解）
如果后續(xù)AG發(fā)送過來 CIEV:1,x那么就是service有變化，值為x,
如果AG發(fā)送過來 CIEV:5,x那么就是signal有變化,值為x
再來個(gè)具體的例子，如圖
這個(gè)就說明signal的值有變化，變成了4
以上三個(gè)發(fā)送完畢后，如果HF&AG都支持三方通話，那么發(fā)送AT CHLD=?
此部分是問詢手機(jī)三方通話的支持的特性都有哪些，一共有以下幾個(gè)特性
比如如圖就是支持0,1,1x,2,2x,3,下面我們就來說下每個(gè)值得功能，這個(gè)功能是以后三方功能HF主動(dòng)給AG下AT command用的
0 = Releases all held calls or sets User Determined User Busy (UDUB) for a waiting call.
->相當(dāng)于此時(shí)正在通話中，又有一通電話來，拒接來電
1 = Releases all active calls (if any exist) and accepts the other (held or waiting) call.
->掛斷所有在通話中的電話，接聽來電
1<idx> = Releases specified active call only (<idx>).
->掛斷idx的通話中的電話
2 =Places all active calls (if any exist) on hold and accepts the other (held or waiting) call.
->把所有通話中的電話設(shè)置為hold狀態(tài)，然后接聽電話
2<idx> = Request private consultation mode with specified call (<idx>). (Place all calls on hold EXCEPT the call indicated by <idx>.)
->請求接受<idx>標(biāo)識(shí)電話，讓其它電話保持。
3 = Adds a held call to the conversation.
->增加一個(gè)保持電話到對話中
4 = Connects the two calls and disconnects the subscriber from both calls (Explicit Call Transfer). Support for this value and its associated functionality is optional for the HF.
->連接兩個(gè)電話并且斷開兩個(gè)電話的訂閱。HF側(cè)可選。
注意此部分，雖然手機(jī)都顯示支持，但是部分cmd手機(jī)還是會(huì)返回error，尤其帶有idx的cmd
If the HF supports the HF indicator feature, it shall check the BRSF response to see if the AG also supports the HF Indicator feature. If both the HF and AG support the HF Indicator feature, then the HF shall send the AT BIND=<HF supported HF indicators> command to the AG to notify the AG of the supported indicators’ assigned numbers in the HF. The AG shall respond with OK. After having provided the AG with the HF indicators it supports, the HF shall send the AT BIND=? to request HF indicators supported by the AG. The AG shall reply with the BIND response listing all HF indicators that it supports followed by an OK.
Once the HF receives the supported HF indicators list from the AG, the HF shall send the AT BIND? command to determine which HF indicators are enabled. The AG shall respond with one or more BIND responses. The AG shall terminate the list with OK. From this point onwards, the HF may send the AT BIEV command with the corresponding HF indicator value whenever a change in value occurs of an enabled HF indicator. The AG may enable or disable the notification of any HF indicator at any time by using the BIND
unsolicited response.
這部分有幾個(gè)重點(diǎn)：
① 如果HF & AG都支持HF Indicators的feature,那么HF發(fā)送AT BIND=<HF supported HF indicators>來告知AG支持那些indicator
② 發(fā)送AT BIND=?問詢AG支持哪些indicator
③ 發(fā)送AT BIND?問詢AG哪些indicator是enable的
④ 發(fā)送AT BIEV來使能某一個(gè)indicator
HFP的indicator一共有兩個(gè)：
下面我們來看下我們抓取的btsnoop（在資料中STM32_UBUNTU_BLUETOOTH\2-藍(lán)牙資料\藍(lán)牙協(xié)議分析\hfp_slc連接.log）
整個(gè)流程如下：
我們生成一個(gè)流程圖
這些圖放在這里當(dāng)作你們的參考
斷開連接比較簡單，就是斷開RFCOMM link就OK了
好了，本節(jié)內(nèi)容到此結(jié)束
