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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　BFCP公共頭格式

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　FloorRelease 消息接收處理，流控制服務(wù)器收到釋放請求消息以后，它會生成一個FloorRequestStatus。它會它經(jīng)過同樣的處理流程，流控制服務(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)其流請求的身份，通過添加FLOOR-REQUEST-ID來實現(xiàn)。最后，流控制服務(wù)器必須在FLOOR-REQUEST-INFORMATION組屬性中增加一個OVERALL-REQUEST-STATUS屬性。

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

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

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

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

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

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

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

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

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

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

　　參考資料：

　　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完整中文用戶手冊詳解及免費slack支持：www.asterisk.org.cn

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

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

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