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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　BFCP公共頭格式

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　規范推薦會(huì )議用戶(hù)使用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完整中文用戶(hù)手冊詳解及免費slack支持：www.asterisk.org.cn

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

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

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