在本文檔的討論中，我們僅涉及SIP和BFCP的功能討論，不涉及其他協(xié)議對(duì)BFCP的功能支持。在我們討論雙流控制協(xié)議之前，我們首先需要介紹幾個(gè)常用的定義。在一般的基于SIP的網(wǎng)絡(luò)環(huán)境中，不外乎語(yǔ)音視頻或者加一個(gè)圖片傳輸?shù)耐ㄐ欧绞�。但是，目前大部分的企業(yè)通信要求不僅僅支持視頻，同時(shí)還要支持會(huì)議人員在進(jìn)行視頻會(huì)議的同時(shí)，可以分享或者對(duì)其他用戶發(fā)送其他文本文件或者演講的其他資料，例如PPT文件。視頻會(huì)議同時(shí)完成以上這兩種功能就需要所謂的雙流數(shù)據(jù)來(lái)實(shí)現(xiàn)。

　　首先，我們介紹一下什么是Floor Control（流控制）。Floor control 簡(jiǎn)單來(lái)說(shuō)就是一種處理機(jī)制，它支持應(yīng)用程序或者用戶安全獲得相互對(duì)端獨(dú)有資源，訪問(wèn)共享一些目標(biāo)文件或者資源，例如對(duì)端文本文件，PPT等客戶數(shù)據(jù)資源。這里需要讀者注意的是，這種機(jī)制必須以安全的方式，相互訪問(wèn)一些特定的目標(biāo)文件和資源。同時(shí)，F(xiàn)loor control 也可以實(shí)現(xiàn)會(huì)議和媒體的創(chuàng)建，會(huì)議策略管理，媒體控制等其他功能。當(dāng)然，這些功能需要第三方協(xié)議來(lái)協(xié)助完成。

　　其次，我們需要關(guān)于Binary Floor Control Protocol（BFCP）的定義。BFCP是一種協(xié)議，它可以在視頻會(huì)議中協(xié)調(diào)各種資源。比較典型的示例就是利用BFCP實(shí)現(xiàn)的視頻會(huì)議服務(wù)：

　　本圖片和以下所有圖片均來(lái)自于互聯(lián)網(wǎng)資源

　　在會(huì)議服務(wù)中涉及了幾個(gè)核心的要素：

　　RFC4582規(guī)范是Binary Floor Control Protocol （BFCP）的標(biāo)準(zhǔn)協(xié)議。在此協(xié)議中規(guī)定了BFCP中多個(gè)方面的內(nèi)容。其主要內(nèi)容包括：規(guī)范處理范圍， 操作流程，數(shù)據(jù)包格式，傳輸，較底層的安全處理，協(xié)議事務(wù)， 簽權(quán)和認(rèn)證，流會(huì)議成員操作，流會(huì)議主持人操作，一般會(huì)議人員操作，流控制服務(wù)器操作，和安全問(wèn)題。下面，我們按照RFC4582的規(guī)范說(shuō)明來(lái)進(jìn)一步介紹以上這幾個(gè)方面的內(nèi)容。

　　規(guī)范處理范圍（Scope），首先說(shuō)明，此規(guī)范重點(diǎn)討論的是關(guān)于BFCP協(xié)議本身的內(nèi)容，它所關(guān)心的是在會(huì)議狀態(tài)下如何通過(guò)BFCP來(lái)實(shí)現(xiàn)對(duì)資源的控制，它所遵守的要求是根據(jù)RFC4376來(lái)實(shí)現(xiàn)。另外，關(guān)于會(huì)議處理的介紹架構(gòu)是通過(guò)RFC4597定義。關(guān)于流會(huì)議人員和限定的內(nèi)容，讀者可以參考RFC4597做進(jìn)一步學(xué)習(xí)研究。以下示例是BFCP所能夠提供的功能。

　　流創(chuàng)建，關(guān)聯(lián)一個(gè)給定的流和相關(guān)的資源

　　獲得客戶端資源聯(lián)系流控制服務(wù)器，客戶端需要各種相關(guān)數(shù)據(jù)來(lái)創(chuàng)建和BFCP 流控制服務(wù)器的連接�？蛻舳怂�需要的消息數(shù)據(jù)包括服務(wù)器端的傳輸?shù)刂�，�?huì)議 ID和用戶ID。

　　獲得流資源的關(guān)聯(lián)綁定，流綁定相關(guān)資源。流會(huì)議用戶和流會(huì)議主持人需要獲得相關(guān)的系統(tǒng)資源綁定信息，以及如何獲得這些綁定消息的機(jī)制等。例如，BFCP可以通過(guò)SDP =m行使用offer/answer的交互模式獲得的消息。當(dāng)然，也可能通過(guò)其他的方式獲得資源信息。

　　獲得流資源的優(yōu)先權(quán)限，流會(huì)議人員被允許訪問(wèn)某些特定的資源，決定何種流會(huì)議人員有權(quán)限訪問(wèn)資源。

　　介紹完關(guān)于BFCP的一個(gè)規(guī)范使用范圍以后（Overview of Operation），我們?cè)倮^續(xù)了解關(guān)于BFCP的整個(gè)操作核心流程。在BFCP整體操作流程中，其實(shí)它就存在兩種流程的操作。一種是流會(huì)議成員和流控制服務(wù)器的接口操作，另外一種是流會(huì)議主持人和流控制服務(wù)器接口之間的操作。在BFCP的消息體的構(gòu)造中，BFCP消息使用的是TLV （Type-Length-Value） binary編碼方式，其消息由公共的頭值和一系列的屬性設(shè)置構(gòu)成。公共頭值包括一個(gè)32-bit的會(huì)議標(biāo)識(shí)符（identifier），流會(huì)議成員方，媒體參與方，和一個(gè)會(huì)議主持人（一個(gè)16-bit 用戶標(biāo)識(shí)符）。BFCP同時(shí)支持內(nèi)嵌屬性（屬性中包含其他的屬性），這些內(nèi)嵌屬性可以構(gòu)成一個(gè)組屬性。在BFCP中支持兩種事務(wù)處理（client-initiated transactions 和 server-initiated transactions.）。我們從它們各自的含義都可以了解到，客戶端初始的事務(wù)包含一個(gè)從客戶端到服務(wù)器端的消息，和從服務(wù)器端到客戶端的響應(yīng)消息。因?yàn)檫@兩種消息都在普通頭值的同一事務(wù)ID傳遞，因此，它們具有相關(guān)性。服務(wù)器端初始的事務(wù)由一個(gè)單個(gè)消息構(gòu)成，事務(wù)ID是0，從流控制服務(wù)器發(fā)送到客戶端。下面，我們分別討論一下流成員到流控制服務(wù)器接口的流程和流主持人到控制服務(wù)器接口的流程。

　　現(xiàn)在，我們討論一下流成員到流控制服務(wù)器接口流程。根據(jù)前面的圖例，流成員如果需要請(qǐng)求一個(gè)流的話，它需要對(duì)流控制服務(wù)器發(fā)送一個(gè)FloorRequest消息到流控制服務(wù)器。這里需要注意，BFCP也支持第三方的流請(qǐng)求。這種情況下，發(fā)送流請(qǐng)求的成員不需要和媒體一起配置發(fā)送，流請(qǐng)求同意以后，媒體可以直接獲得流。FloorRequest消息傳輸在公共頭值的用戶 ID傳遞請(qǐng)求者的身份標(biāo)識(shí)，并且在BENEFICIARY-ID屬性中流受益者身份標(biāo)識(shí)（在第三方流請(qǐng)求中）。FloorRequest消息確認(rèn)流或者在FLOOR-ID屬性中傳輸?shù)钠渌�的流（通過(guò)16-bit 流身份標(biāo)識(shí)符）。如果FloorRequest消息傳輸了一個(gè)以上的floor identifier 標(biāo)識(shí)符，流控制服務(wù)器將把所有的流標(biāo)識(shí)符看作一個(gè)atomic數(shù)據(jù)包。這也就是說(shuō)，流控制服務(wù)器允許或者拒絕所有流成員的請(qǐng)求。流控制服務(wù)器接收到請(qǐng)求以后，它會(huì)返回一個(gè)FloorRequestStatus 消息，此消息中包含流請(qǐng)求的狀態(tài)。另外，F(xiàn)LOOR-REQUEST-INFORMATION屬性是一個(gè)非常重要的屬性，它涉及了流請(qǐng)求的狀態(tài)和流成員的一些綁定關(guān)系（包括Floor Request ID和事務(wù)ID等），讀者可以通過(guò)RFC4582做更多了解。

　　接下來(lái)，我們討論關(guān)于流主持人和流控制服務(wù)器接口的處理流程。此接口流程相對(duì)比較簡(jiǎn)單。但是這里需要說(shuō)明的是，盡管流主持人可以對(duì)流控制服務(wù)器發(fā)送ChairAction消息獲取流控制服務(wù)器權(quán)限資源，但是，流控制服務(wù)器沒(méi)有必要允許流主持人的所有請(qǐng)求，流控制服務(wù)器根據(jù)ChairAction和流控制服務(wù)器的內(nèi)部狀態(tài)來(lái)進(jìn)行處理。例如，如果此流請(qǐng)求涉及到了atomic流請(qǐng)求的話，即使流主持人對(duì)某個(gè)流請(qǐng)求了獲得允許，流控制服務(wù)器仍然不會(huì)允許其他的流請(qǐng)求通過(guò)，直到流主持人獲得所有流請(qǐng)求通過(guò)，流控制服務(wù)器才允許所有的流請(qǐng)求通過(guò)。因此，流控制服務(wù)器最終根據(jù)其相關(guān)的流主持人命令的流狀態(tài)來(lái)決定其最終處理狀態(tài)。

　　流主持人命令流控制服務(wù)器示意圖

　　接下來(lái)，我們繼續(xù)討論關(guān)于BCFP的數(shù)據(jù)包格式（Packet Format）。BFCP的數(shù)據(jù)包格式一個(gè)12-octet的公共頭（COMMON-HEADER）和其屬性構(gòu)成。公共頭的格式如下：

　　BFCP公共頭格式

　　我們經(jīng)常需要注意的或者比較重要的是Primitive（消息目的和方向），Conference ID（會(huì)議ID），Transaction ID和User ID。

　　BFCP的數(shù)據(jù)包格式除了公共頭的格式以外，還有一個(gè)屬性的格式。

　　其中，Type 包括了各種類(lèi)型定義，內(nèi)容和格式。

　　這里，讀者需要注意經(jīng)常見(jiàn)到的一下錯(cuò)誤代碼-ERROR-CODE，和其他的錯(cuò)誤引申含義。因?yàn)槠�幅關(guān)于，筆者不再介紹BFCP的其他格式內(nèi)容，讀者可以參考RFC4582來(lái)進(jìn)一步研究。

　　BFCP實(shí)體之間的的傳輸方式（Transport）是通過(guò)TCP連接實(shí)現(xiàn)。大家都知道，TCP可以提供可靠按序傳輸方式，保證其資源訪問(wèn)的穩(wěn)定性。在會(huì)議中，流會(huì)議客戶端只能使用一個(gè)TCP連接來(lái)連接流控制服務(wù)器，不能使用多于一個(gè)以上的連接。但是，如果同樣的物理終端支持了不同的流會(huì)議終端的話（例如，流會(huì)議成員和會(huì)議主持人），它們本身具有各自的用戶ID的話，可以支持不同的TCP連接來(lái)連接流控制服務(wù)器，不同終端對(duì)流控制服務(wù)器的獨(dú)立的連接方式是允許的。

　　如果BFCP實(shí)體（流客戶端或流控制服務(wù)器端）從TCP收到數(shù)據(jù)，此數(shù)據(jù)不能被實(shí)體正確解析的話，此實(shí)體就會(huì)關(guān)閉TCP連接，需要重新創(chuàng)建一個(gè)新的連接。同樣的，如果TCP連接不能傳遞BFCP消息或者出現(xiàn)超時(shí)的話，TCP連接也需要重新創(chuàng)建。重新創(chuàng)建TCP連接方式的規(guī)則取決于流客戶端從流控制服務(wù)器獲得的消息來(lái)決定，例如，使用SDP offer/answer交互模式實(shí)現(xiàn)。關(guān)于SDP 的offer/answer 交互模式，讀者可以參考作者歷史文檔來(lái)進(jìn)一步學(xué)習(xí)，這里不再做更多討論。

　　WebRTC-ICE/RFC5245中文詳解發(fā)布關(guān)于SDP answer/offer介紹。

　　一旦重新TCP連接創(chuàng)建以后，流客戶端可以重新對(duì)流控制服務(wù)器端發(fā)送上次沒(méi)有從流控制服務(wù)器端收到響應(yīng)的消息。如果流控制服務(wù)器端檢測(cè)到其中一個(gè)流客戶端的TCP連接斷開(kāi)的話，流控制服務(wù)器將會(huì)使用本地策略，流控制服務(wù)器根據(jù)自己的策略對(duì)待處理請(qǐng)求進(jìn)行進(jìn)一步處理。RFC4582建議，無(wú)論在何種場(chǎng)景中，重新TCP建立連接時(shí)，流控制服務(wù)器都要保持流請(qǐng)求，不能被取消。如果流客戶端希望斷開(kāi)對(duì)BFCP流控制服務(wù)器的連接時(shí)，它可以使用相對(duì)比較合理的方式斷開(kāi)流控制服務(wù)器TCP連接。如果流控制服務(wù)器希望斷開(kāi)流客戶端BFCP連接，流控制服務(wù)器需要使用比較合理的處理方式斷開(kāi)BFCP流客戶端連接。

　　BFCP使用了較低層（Lower-Layer Security）的安全機(jī)制來(lái)實(shí)現(xiàn)回放和完整的安全保護(hù)。BFCP 服務(wù)器端和客戶端都必須支持TLS。任何BFCP實(shí)體可以支持其他的安全機(jī)制。BFCP必須至少支持TLSTLS_RSA_WITH_AES_128_CBC_SHA ciphersuite算法。當(dāng)然，目前發(fā)布了很多比較新的安全算法，很多終端特別是SIP業(yè)務(wù)方面的的安全算法也有很多更新。關(guān)于安全機(jī)制的算法，讀者可以查閱RFC3268， RFC4366和TLS拓展RFC6066。關(guān)于TLS設(shè)置一定要注意。在TLS設(shè)置支持時(shí)，TSL服務(wù)器端的設(shè)置取決于流客戶端和流控制服務(wù)器的TCP連接方式處理流程。不一定是流控制服務(wù)器端就是TLS服務(wù)器端。如果TCP連接協(xié)商機(jī)制使用的是SDP offer/answer交互模式時(shí)，answerer方（無(wú)論是流客戶端或流控制服務(wù)器端）總是TLS服務(wù)器端。

　　在BFCP協(xié)議中支持兩種事務(wù)類(lèi)型（Protocol Transactions）。一種是基于客戶端初始化的事務(wù)，另外一種是服務(wù)器端初始的事務(wù)（notifications，流控制服務(wù)器對(duì)流會(huì)議終端發(fā)送的提示消息）�；�于客戶端發(fā)起的事務(wù)由客戶端到服務(wù)器端的一個(gè)請(qǐng)求和一個(gè)由服務(wù)器端發(fā)送到客戶端的響應(yīng)消息構(gòu)成。請(qǐng)求中會(huì)在公共頭中傳遞一個(gè)Transaction ID，流控制服務(wù)器端會(huì)拷貝這個(gè)ID到響應(yīng)消息中。流客戶端會(huì)使用這個(gè)ID來(lái)匹配響應(yīng)消息，流客戶端檢查是否和前一次發(fā)送的請(qǐng)求匹配�；�于服務(wù)器發(fā)起的事務(wù)由一個(gè)單個(gè)從流控制服務(wù)器端發(fā)送到流客戶端的消息構(gòu)成�；�于服務(wù)器發(fā)起的事務(wù)因?yàn)闆](méi)有觸發(fā)任何響應(yīng)消息，因此，它的Transaction ID為0。下面，我們分別討論關(guān)于客戶端處理流程和服務(wù)器端處理流程。如果一個(gè)流客戶端發(fā)起了客戶端事務(wù)的話，這個(gè)客戶端必須把消息的公共頭中Conference ID設(shè)置為會(huì)議的ID，這個(gè)會(huì)議ID是客戶端前面獲得的ID。另外，客戶端必須把公共頭中的Transaction ID設(shè)置為一個(gè)數(shù)值，這個(gè)數(shù)值是從0開(kāi)始的不同的數(shù)值，并且，這個(gè)數(shù)值一定不能在客戶端消息中重新使用，直到流客戶端從流控制服務(wù)器收到一個(gè)針對(duì)此事務(wù)的響應(yīng)以后，此數(shù)值才能變化。流客戶端使用Transaction ID來(lái)匹配從流控制服務(wù)器返回的響應(yīng)消息。流控制服務(wù)器端的處理有兩種情況。流控制服務(wù)器在基于客戶端發(fā)起的事務(wù)中發(fā)送響應(yīng)，流控制服務(wù)器端必須從請(qǐng)求中拷貝Conference ID，Transaction ID和User ID到響應(yīng)中。如果是基于服務(wù)器端發(fā)起的事務(wù)，則必須包含一個(gè)Transaction ID，這個(gè)ID為0。

　　BFCP實(shí)體之間的資源訪問(wèn)需要認(rèn)證和簽權(quán)的處理機(jī)制（Authentication 和 Authorization）。BFCP客戶端應(yīng)該在對(duì)流控制服務(wù)器發(fā)送消息或者接收消息前，它首先對(duì)流控制服務(wù)器進(jìn)行驗(yàn)證處理。同樣的，流控制服務(wù)器端對(duì)流客戶端發(fā)送或者接收消息前也要進(jìn)行認(rèn)證處理。在RFC4582中規(guī)定，BFCP的流客戶端和控制服務(wù)器支持基于TLS的相互認(rèn)證的機(jī)制。這是BFCP推薦的認(rèn)證機(jī)制，當(dāng)然，BFCP也應(yīng)該支持TLS未來(lái)拓展的認(rèn)證機(jī)制。更多關(guān)于BFCP TLS安全機(jī)制處理，讀者可以參考RFC4582-9.1章節(jié)。除了認(rèn)證以外，BFCP的流控制服務(wù)器也需要對(duì)消息進(jìn)行簽權(quán)處理。流控制服務(wù)器在收到認(rèn)證消息以后，它需要對(duì)消息進(jìn)行簽權(quán)處理，它會(huì)檢查流客戶端發(fā)送的消息是否是通過(guò)簽權(quán)處理。如果流客戶端沒(méi)有被允許進(jìn)行某些操作的話，流控制服務(wù)器將會(huì)對(duì)流客戶端生成一個(gè)錯(cuò)誤響應(yīng)，錯(cuò)誤代碼為5（Unauthorized Operation）。沒(méi)有被流控制服務(wù)器允許的消息不會(huì)被進(jìn)行進(jìn)一步的處理。

　　以上介紹了關(guān)于BFCP中的一些基本操作和處理流程。接下來(lái)，我們具體介紹BFCP實(shí)體操作的流程細(xì)節(jié)。

　　首先，我們介紹流會(huì)議成員的操作流程（Floor Participant Operations）。流客戶端首先需要對(duì)流控制服務(wù)器發(fā)送一個(gè)FloorRequest消息。它發(fā)送的消息中包括一個(gè)公共頭和屬性值，其中包括一些必要選項(xiàng)和一些可選選項(xiàng)。FloorRequest需要在公共頭中設(shè)置Transaction ID和Conference ID，同時(shí)流成員需要把在公共頭中的User ID設(shè)置為流成員標(biāo)識(shí)符。此用戶ID將被流控制服務(wù)器作為認(rèn)證和簽權(quán)的主要憑證。注意，如果FloorRequest發(fā)送方不是會(huì)議成員（它將獲得流資源），例如第三方發(fā)送的流請(qǐng)求，請(qǐng)求發(fā)送方應(yīng)該在消息中增加一個(gè)BENEFICIARY-ID屬性，表示其是流資源的第三方收益方。

　　流會(huì)議成員必須在FloorRequest消息中插入一個(gè)FLOOR-ID屬性值。如果流會(huì)議成員在其floor請(qǐng)求中插入一個(gè)以上的FLOOR-ID，流控制服務(wù)器會(huì)認(rèn)為這個(gè)流請(qǐng)求是一個(gè)atomic package，流控制服務(wù)器就會(huì)允許或者拒絕FloorRequest消息中所有的流。當(dāng)然，流會(huì)議成員也可以使用PARTICIPANT-PROVIDED-INFO屬性來(lái)說(shuō)明流或者其他流是流成員要求的請(qǐng)求，可以在PARTICIPANT-PROVIDED-INFO屬性中增加文本說(shuō)明來(lái)聲明其原因。流控制服務(wù)器端收到FloorRequest消息以后，對(duì)其請(qǐng)求進(jìn)行處理，然后流控制服務(wù)器生成一個(gè)或多個(gè)FloorRequestStatus消息。流會(huì)議成員從返回的FloorRequestStatus消息中獲得必要的屬性參數(shù)，例如FLOOR-REQUEST-INFORMATION，OVERALL-REQUEST-STATUS，STATUS-INFO，F(xiàn)LOOR-REQUEST-STATUS，BENEFICIARY-INFORMATION和PRIORITY屬性。當(dāng)然，返回的信息也可能是錯(cuò)誤響應(yīng)。具體以上這些屬性的具體內(nèi)容，讀者可以查閱RFC4582-10.1.2，這里不再做過(guò)多解釋。

　　如果流會(huì)議成員希望取消正在發(fā)送的請(qǐng)求的話，它可以對(duì)流控制服務(wù)器發(fā)送一個(gè)FloorRelease消息。另外注意，流會(huì)議成員也可以通過(guò)FloorRelease消息來(lái)實(shí)現(xiàn)流等待請(qǐng)求，然后釋放流資源。FloorRelease發(fā)送和接收需要流會(huì)議成員和流控制服務(wù)器雙方協(xié)商處理，通過(guò)公共頭中的Conference ID和Transaction ID實(shí)現(xiàn)釋放匹配處理。另外，流控制服務(wù)器需要處理錯(cuò)誤響應(yīng)等流程。

　　除了上面介紹的流成員方的操作以外，另外一個(gè)實(shí)體是流主持人（Chair Operations）。這里，我們?cè)倮^續(xù)介紹關(guān)于流會(huì)議主持人的操作流程。流會(huì)議主持人的作用就是對(duì)流控制服務(wù)器發(fā)出指令，使用前面章節(jié)中的協(xié)議通過(guò)流控制服務(wù)器獲得或者取消流資源。流會(huì)議主持人通過(guò)對(duì)流控制服務(wù)器發(fā)送ChairAction消息來(lái)實(shí)現(xiàn)對(duì)流控制服務(wù)器的指令。當(dāng)然，按照正常的響應(yīng)處理流程，流會(huì)議主持人通過(guò)發(fā)送ChairAction和接收ChairAction的響應(yīng)消息實(shí)現(xiàn)對(duì)流控制服務(wù)器的指令操作。首先，流會(huì)議主持人對(duì)流控制服務(wù)器端發(fā)送ChairAction消息，在公共頭中設(shè)置Conference ID，Transaction ID和user ID。User ID將被流控制服務(wù)器用來(lái)對(duì)流會(huì)議主持人進(jìn)行認(rèn)證和簽權(quán)處理。在ChairAction請(qǐng)求消息中包含對(duì)流控制服務(wù)器的指令，在一個(gè)特定的流請(qǐng)求中，這些指令可以應(yīng)用在一個(gè)流或多個(gè)流的場(chǎng)景中。流會(huì)議主持人可以使用FLOOR-REQUEST-STATUS提供一個(gè)新的流請(qǐng)求狀態(tài)，這個(gè)狀態(tài)可以關(guān)聯(lián)到一個(gè)特定的流資源（其狀態(tài)可以支持隊(duì)列位置，允許或者拒絕權(quán)限訪問(wèn)）。流會(huì)議主持人也可以在ChairAction消息中添加一個(gè)OVERALL-REQUEST-STATUS，對(duì)其流請(qǐng)求提供一個(gè)整體狀態(tài)的說(shuō)明。流會(huì)議主持人也可以通過(guò)STATUS-INFO屬性說(shuō)明流被接受，解決或者取消的原因，此描述是文本格式。流會(huì)議主持人可以收到從流控制服務(wù)器返回的ChairActionAck消息，此消息確認(rèn)流控制服務(wù)器收到了ChairAction請(qǐng)求消息。如果流會(huì)議主持人收到一個(gè)錯(cuò)誤消息的話，它說(shuō)明流控制服務(wù)器因?yàn)槟承┰�因，它不能處理ChairAction消息，原因需要查看錯(cuò)誤消息。

　　以上我們討論了針對(duì)流會(huì)議成員和流會(huì)議主持人的操作流程。除了這兩個(gè)實(shí)體的特定操作以外，BFCP仍然有一些不針對(duì)特定一方的非�；�本的操作流程（General Client Operation）。這些操作流程不僅針對(duì)流會(huì)議成員或者流會(huì)議主持人，也可能同時(shí)支持兩種角色的操作。這些操作包括：

　　關(guān)于流的信息，包括操作流程是發(fā)送FloorQuery消息和接收響應(yīng)消息。

　　關(guān)于流請(qǐng)求的信息，包括的操作流程是FloorRequestQuery消息和接收其相應(yīng)的響應(yīng)消息。

　　關(guān)于對(duì)用戶的請(qǐng)求消息操作，包括發(fā)送UserQuery消息，接收其響應(yīng)消息。

　　關(guān)于獲得流控制服務(wù)器的支持能力的操作，包括發(fā)送Hello 消息，接收其響應(yīng)能力支持消息。

　　以上章節(jié)介紹流流會(huì)議成員操作，流會(huì)議主持人操作和它們的一些一般操作流程。接下來(lái)，我們將介紹最后的一個(gè)操作，那就是流控制服務(wù)器端的操作流程（Floor Control Server Operations）。流控制服務(wù)器端的流程涉及了八個(gè)不同的消息處理流程，這八個(gè)處理流程分別針對(duì)的是流會(huì)議成員，流會(huì)議主持人。

　　FloorRequest消息接收，流控制服務(wù)器收到FloorRequest消息以后，檢查其認(rèn)證和簽權(quán)狀態(tài)。（注意，以下其他消息也必須經(jīng)過(guò)同樣的認(rèn)證和簽權(quán)流程和消息解析）在處理其請(qǐng)求過(guò)程中，如果不理解消息內(nèi)容，服務(wù)器端生成一個(gè)錯(cuò)誤響應(yīng)。如果流控制服務(wù)器成功解析其請(qǐng)求消息，則返回一個(gè)或多個(gè)FloorRequestStatus 消息，說(shuō)明其是否接受或者拒絕流請(qǐng)求。當(dāng)然，流請(qǐng)求也可能繼續(xù)進(jìn)行，流控制服務(wù)器也可以獲得其它狀態(tài)消息。

　　FloorRequestQuery消息接收，流控制服務(wù)器收到請(qǐng)求查詢消息以后，流控制服務(wù)器需要處理幾個(gè)必要的屬性參數(shù)，例如，Conference ID, Transaction ID 和 User ID，添加FLOOR-REQUEST-STATUS，提供REQUESTED-BY-INFORMATION，增加PARTICIPANT-PROVIDED-INFO說(shuō)明添加的理由，添加PRIORITY來(lái)表示流請(qǐng)求組控制的優(yōu)先級(jí)。

　　UserQuery 消息接收，流控制服務(wù)器收到用戶查詢消息后，它會(huì)快速生成

　　一個(gè)UserStatus消息。它經(jīng)過(guò)同樣的處理流程，流控制服務(wù)器需要把

　　Conference ID, Transaction ID 和 User ID拷貝到UserStatus消息中。

　　流控制服務(wù)器在響應(yīng)消息中添加BENEFICIARY-ID（受益人ID）。

　　FloorRelease 消息接收處理，流控制服務(wù)器收到釋放請(qǐng)求消息以后，它會(huì)生成一個(gè)FloorRequestStatus。它會(huì)它經(jīng)過(guò)同樣的處理流程，流控制服務(wù)器需要把Conference ID, Transaction ID和用戶ID拷貝到FloorRequestStatus消息中。流控制服務(wù)器必須在狀態(tài)消息中添加FLOOR-REQUEST-INFORMATION組屬性。流控制服務(wù)器必須從釋放消息中拷貝FLOOR-REQUEST-ID到FLOOR-REQUEST-INFORMATION屬性中的Floor Request ID。流控制服務(wù)器也必須確認(rèn)其流請(qǐng)求的身份，通過(guò)添加FLOOR-REQUEST-ID來(lái)實(shí)現(xiàn)。最后，流控制服務(wù)器必須在FLOOR-REQUEST-INFORMATION組屬性中增加一個(gè)OVERALL-REQUEST-STATUS屬性。

　　FloorQuery消息接收處理，流控制服務(wù)器收到流查詢消息以后，它會(huì)通過(guò)FloorStatus 消息不斷通知流客戶端。單個(gè)的FloorStatus傳遞單個(gè)的流狀態(tài)消息。如果流客戶端需要多個(gè)流狀態(tài)消息的話，流控制服務(wù)器端需要分開(kāi)獨(dú)立發(fā)送其狀態(tài)消息。取決于用戶對(duì)不同狀態(tài)的請(qǐng)求不同，F(xiàn)loorQuery也可以查詢待處理請(qǐng)求的狀態(tài)等消息。

　　ChairAction消息接收處理，流控制服務(wù)器收到主持人的請(qǐng)求以后，它會(huì)生成一個(gè)ChairActionAck響應(yīng)消息。它會(huì)它經(jīng)過(guò)同樣的處理流程，流控制服務(wù)器需要把Conference ID, Transaction ID和用戶ID拷貝到ChairActionAck消息中。當(dāng)然，流控制服務(wù)器會(huì)根據(jù)本地策略，對(duì)流會(huì)議主持人返回拒絕或者接受請(qǐng)求等消息。

　　Hello消息接收處理，流控制服務(wù)器收到Hello消息以后，它會(huì)生成一個(gè)HelloAck消息。它會(huì)它經(jīng)過(guò)同樣的處理流程，流控制服務(wù)器需要把Conference ID, Transaction ID和用戶ID拷貝到HelloAck消息中。最后，流控制服務(wù)器必須在HelloAck增加一個(gè)SUPPORTED-PRIMITIVES屬性，表示流控制服務(wù)器支持的BFCP消息。流控制服務(wù)器在HelloAck中必須增加一個(gè)SUPPORTED-ATTRIBUTES，在屬性列表中列出流控制服務(wù)器所支持的屬性能力。

　　Error 消息生成處理，錯(cuò)誤消息是一個(gè)響應(yīng)消息，它是由客戶端發(fā)出的，它是基于客戶端事務(wù)的一個(gè)部分。它會(huì)它經(jīng)過(guò)同樣的處理流程，流控制服務(wù)器需要把Conference ID, Transaction ID和用戶ID拷貝到錯(cuò)誤消息中。在錯(cuò)誤消息中必須增加一個(gè)ERROR-CODE，此屬性錯(cuò)誤碼包含一個(gè)錯(cuò)誤代碼。另外，流控制服務(wù)器也可以增加一個(gè)ERROR-INFO屬性來(lái)說(shuō)明具體的錯(cuò)誤原因。

　　以上討論基本上涵蓋了RFC4582關(guān)于BFCP的基本處理流程。最后一個(gè)需要討論的是BFCP的安全問(wèn)題。

　　BFCP本身默認(rèn)支持了TLS的安全機(jī)制，只要支持的參數(shù)類(lèi)似，BFCP同時(shí)它也可以增加其他的安全機(jī)制。

　　在BFCP安全討論中，主要的幾個(gè)攻擊威脅是冒充流會(huì)議成員或者流會(huì)議主持人獲得流資源權(quán)限。

　　另外，可以冒充一個(gè)流控制服務(wù)器端，讓流會(huì)議成員和主持人訪問(wèn)來(lái)獲得終端用戶信息。

　　攻擊者修改相關(guān)的交互信息來(lái)獲得認(rèn)證權(quán)限。攻擊者也可能盜取相關(guān)的安全交互信息，然后訪問(wèn)其流資源服務(wù)器內(nèi)容。

　　規(guī)范推薦會(huì)議用戶使用TLS加密方式來(lái)進(jìn)行流會(huì)議實(shí)體之間的交互，這樣可以避免攻擊者非法盜取相關(guān)的會(huì)議信息。

　　參考資料：

　　https://www.rfc-editor.org/rfc/rfc4582.html

　　https://www.hjp.at/doc/rfc/rfc5018.html

　　https://www.hjp.at/doc/rfc/rfc5567.html

　　https://sci-hub.st/https://ieeexplore.ieee.org/abstract/document/8599589/

　　融合通信/IPPBX/FreePBX商業(yè)解決方案：www.hiastar.com

　　最新Asterisk完整中文用戶手冊(cè)詳解及免費(fèi)slack支持：www.asterisk.org.cn

　　Freepbx/FreeSBC技術(shù)文檔： www.freepbx.org.cn

　　如何使用FreeSBC，qq技術(shù)分享群：334023047

　　關(guān)注微信公眾號(hào)：asterisk-cn，獲得有價(jià)值的通信行業(yè)技術(shù)分享