在關於BFCP雙流控制協議概論的第一部分，我們重點介紹了BFCP（RFC4582的規範細節）。在第二部分中，我們將重點介紹通過SDP拓展實現的BFCP數據交互信息的方式和BFCP其他技術架構的討論，應用場景（例如物聯網IOT）和其他部署問題的討論。
使用SDP描述實現BFCP數據交換（RFC4583）
在BFCP中，流客戶端需要獲得一系列的數據和流控制服務器端創建一個連接來獲得這些相關的數據，這些數據包括服務器傳輸地址，會議ID和用戶ID等信息。那麼，如何獲得這些消息數據？對於流客戶端來說，一種方法是使用SDP的offer/answer交互模式來獲得數據。RFC4583規範具體規定了如何對SDP交互信息進行解碼來獲得這些必要的數據。下面，筆者將重點介紹RFC4583中關於SDP交互的幾個主要的概念和處理流程，例如SDP中的m行解碼處理說明，流控制服務器的角色處理，會議ID和用戶ID的屬性說明，介於媒體流和流資源的關聯，TCP連接管理，籤權處理，示例和安全考慮。
首先我們來介紹一下SDP中的m行使用。一般情況下，SDP的客戶端使用SDP answer/offer模式對流媒體類型進行創建支持。同樣的道理，BFCP如果使用answer/offer模式交互數據時，BFCP也是作為一種流媒體支持的類型進行，它使用了支持媒體格式的m行和其他多種在a行解碼的屬性來實現。關於SDP中媒體格式支持和m行處理，讀者可以參考歷史文檔來進一步學習，這裡不再做過多詳解，或者參考RFC4566規範說明。現在，我們討論一下如何生成一個對BFCP媒體流的m行支持。根據RFC4566的規範規定，m行的語法構成是這樣的：
m= ...
此媒體域必須有一個“application”值，當然，在SDP中包括對值可能是語音，視頻，文本或應用。其中，端口設置需要根據RFC4145規範來處理。另外，取決於TCP 連接時流程中“setup”的取值，端口域所包含這個特定的端口，此端口是遠端客戶端發起的TCP連接，或者其他不相關連接（例如，客戶端將對遠端客戶端發起的連接），這種端口設置為9，因為BFCP連接僅使用TCP連接，這種是應該丟棄的端口。關於此細節說明，讀者可以參考RFC4245-4.1。
the endpoint using the value 'active' SHOULD specify a port number of 9 (the discard port) on its 'm' line.
在標準的SDP規範中，如果端口域的值為0的話，它具有一定的含義（例如，拒絕了媒體流）。在RFC4583中定義了兩種關於BFCP的端口設置，一種是TCP/BFCP，另外一種是支持TLS的TCP/TLS/BFCP。前面一種在TCP中直接運行，後面的定義方式當TCP支持TLS時，BFCP也需要在TLS下運行。在BFCP中，fmt格式是一個被忽略的值，BFCP的ftm列表應該包含一個單"*"字符。因此，一個標準的BFCP語法構成是這樣的：
<code> floor-control-attribute = "a=floorctrl:" role *(SP role) role = "c-only" / "s-only" / "c-s"/<code>
或者客戶端返回的示例：
<code> m=application 9 TCP/TLS/BFCP * // port 9將被丟棄。/<code>
以上就是關於BFCP中m行當語法說明。接下來，我們繼續討論關於流控制服務器的角色決定（Floor Control Server Determination）機制。
如果兩個終端創建了BFCP連接媒體流的話，它們需要決定誰是流控制服務器方。流控制服務器中的角色決定機制決定了哪一方作為流控制服務器方。流控制服務器的角色決定相對比較直接，一方是客戶端的話，其他的只能是流控制服務器方。大部分的使用場景中，如果一個客戶端創建了和會議服務器的流媒體連接的話，那麼，此客戶端通常為流控制服務器端。但是，在BFCP的應用場景中也存在比較特別的示例，例如兩個終端可能都想作為流控制服務器端。例如，在一個兩方的會話中，這個兩方會話涉及了語音和白板分享功能的使用的話，這兩個終端就需要決定哪一方是流控制方。在實際示例中，可能一個終端作為語音的流控制服務器，另外一個終端則為白板共享的流控制服務器。在RFC4583中，通過SDP屬性中的“floorctrl”來設定執行流控制服務器的角色設置，具體的用法如下：
<code>a=floorctrl:c-only s-only c-s/<code>
role的具體定義包括：“c-only”-表示offerer方願意成為流控制服務器的客戶端, “s-only”-表示offerer方願意成為流控制服務器的服務器端和“cs”-表示offerer方願意成為流控制服務器的客戶端和服務器端。如果在offer中的m行包含floorctrl，此answerer必須在其相應的answer中包含m行。answerer必須包含它的屬性來聲明answerer方將要扮演的角色。這也就是說，answerer選擇其中一個角色，此角色是offerer願意執行的，並且為answerer生成相應的answer。answerer方的角色決定依賴於offerer方的願意扮演的角色。兩者的角色取決於offerer方的角色。
此圖片及以下圖片均來自於互聯網資源
在answerer中的角色有各自的含義。“c-only”-表示answerer方願意成為流控制服務器的客戶端,接下來，offerer方為流控制服務器端。“s-only”-表示answerer方願意成為流控制服務器的服務器端，接下來，offerer方則為流控制客戶端。“cs”-表示answerer方願意成為流控制服務器的客戶端和服務器端，接下來，offerer也是流控制服務器的客戶端和服務器端。如果使用offer/answer交互模式的終端來創建BFCP連接的話，其終端必須支持floorctrl屬性。另外要注意，如果沒有在offer/answer交互模式中使用floorctrl屬性的話，在默認設置中，offerer方則為流控制服務器端，而answerer方則為流控制服務器端。以下示例是一個floorctrl在offer中的示例。當此屬性出現在answer中時，此屬性僅能傳遞其中一個角色，而不是傳遞所有角色：
<code>floor-id-attribute = "a=floorid:" token [" mstrm:" token *(SP token)]/<code>
在SDP屬性中，最為重要的兩個屬性是媒體級的SDP屬性 'confid'和 'userid'屬性。流控制服務器使用這兩個屬性為客戶端提供相應的會議ID和用戶ID。其具體語法如下：
<code>confid-attribute = "a=confid:" conference-id conference-id = token userid-attribute = "a=userid:" user-id user-id = token/<code>
以上這兩種屬性都是以整數為單位表示。使用offer/answer交互模式來創建BFCP連接的終端
必須支持confid 和userid 屬性。如果流控制服務器充當offerer或者answerer方的話，流控制服務器應該在會話描述中包含這兩種屬性。接下來，我們介紹一下如何關聯媒體流和流資源。RFC4583在SDP媒體級屬性中定義了一個floorid，語法如下：
<code>floor-id-attribute = "a=floorid:" token [" mstrm:" token *(SP token)]/<code>
floorid使用在BFCP的SDP m行中。它定義了流的標識符可以用來關聯一個或者多個媒體流。這裡的令牌token表示一個floor ID，它是一個整數值表示在BFCP中的Floor ID。表示媒體流的token指向了媒體流，這個媒體流通過SDP label attribute來定義。具體的用法參考RFC4574-5。使用offer/answer交互模式來創建BFCP連接的終端必須支持floorid和label屬性。如果流控制服務器充當offerer或者answerer方的話，流控制服務器應該在會話描述中包含這兩種屬性。
在BFCP連接的處理過程中，我們還要關注一下關於BFCP中TCP的管理。傳輸BFCP是通過“setup” 和“connection”屬性來執行。這個傳輸機制（SDP中基於TCP的媒體傳輸）需要按照RFC4245規範來執行。“setup”屬性表示哪一方（流客戶端還是流控制服務器端）終端發起的TCP連接。“connection”屬性用來處理TCP重連創建。在BFCP規範中描述了多種場景，在這些場景中，介於流客戶端和流控制服務器的TCP連接需要重新創建。具體這些場景的詳解，請讀者參考上一篇文章的介紹。但是，這些場景沒有說明具體的重新連接流程，因為，這些流程取決於創建TCP連接的第一個觸發點本身。BFCP實體按照answer/offer交互模式處理時，這些實體需要以下規則。當現存的TCP連接重新設置時，流客戶端應該對其流控制服務器端生成一個offer消息來進行重新連接。如果TCP連接不能傳輸BFCP消息或者傳輸超時（實體檢測到了TCP超時），發送BFCP消息的實體應該生成一個offer來重新創建TCP連接。使用answer/offer交互模式創建BFCP連接的終端必須支持“setup” 和“connection”屬性。
RFC4583中關於SDP拓展使用同樣也需要進行籤權機制的處理。當BFCP連接通過answer/offer交互模式創建以後，這是假設offerer方和answerer方通過某些籤權機制來對對方進行認證處理。一旦相互之間的籤權機制發生以後，所有的offerer方和answerer方需要確保它們接收BFCP消息的實體和前面它們生成offer或answer的相同。當使用SIP來進行offer/answer交互時，最初的相互的認證是發生在SIP協議級。另外，SIP使用S/MIME為offer/answer交互模式提供了一個完整保護通道，這個保護通道使用其他安全手段對其進行支持。BFCP利用這個完整保護方式下的offer/answer交互模式執行籤權機制處理。在此offer/answer交互模式下，offerer和answerer交互自簽證書的指紋信息。這些自簽證書用來創建TLS連接，這個TLS連接來傳輸offerer方和answerer方之間的BFCP數據流量。進一步說明，涉及到證書選擇和使用的話，BFCP客戶端和流控制服務器需要按照RFC4572的規範來執行。此規範聲明瞭TLS在SDP中的使用。此規定的表示除非會話描述中包含指紋（fingerprint）屬性，TLS級的證書必須是自簽證書或者合法第三方證書。使用offer/answer交互模式創建的BFCP連接必須支持指紋（fingerprint）屬性，並且應該在會話描述中包括指紋（fingerprint）屬性。當使用了TLS連接以後，一旦TCP連接創建後，無論其角色是何角色（在TCP創建流程中其角色是被動或主動角色），answerer方則為TLS服務器端。
以下示例說明關於SDP中關於m行使用的情況，會議服務器端發送到客戶端的offer消息：
<code>m=application 50000 TCP/TLS/BFCP * a=setup:passive a=connection:new a=fingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB a=floorctrl:s-only a=confid:4321 a=userid:1234 a=floorid:1 m-stream:10 a=floorid:2 m-stream:11 m=audio 50002 RTP/AVP 0 a=label:10 m=video 50004 RTP/AVP 31 a=label:11/<code>
以下是客戶端返回的answer消息：
<code>m=application 9 TCP/TLS/BFCP * a=setup:active a=connection:new a=fingerprint:SHA-1 \ 3D:B4:7B:E3:CC:FC:0D:1B:5D:31:33:9E:48:9B:67:FE:68:40:E8:21 a=floorctrl:c-only m=audio 55000 RTP/AVP 0 m=video 55002 RTP/AVP 31/<code>
關於RFC4583的安全討論。規範RFC4583中涉及了BFCP（RFC4582），SDP（RFC4566）和offer/answer交互模式（RFC3264）.這些規範都已經定義了其相應的安全機制。在筆者的歷史文檔都已經分別做了非常詳細說明，讀者可以參考歷史文檔來了解這些規範的具體詳解。另外，RFC4145也討論了基於TCP媒體傳輸的安全機制，在RFC4572中也討論了SDP中TLS的支持規範。這些規範都涵蓋了關於安全機制的討論。除此之外，BFCP假設客戶端和流控制服務器端使用了自簽證書來實現對安全完整性的通道保護。並且，對於在SIP中傳輸的會話描述，S/MIME是一個自然的選擇來提供這樣的通道。
BFCP應用場景示例（視頻會議/IOT）
前面章節介紹了關於SDP m行在BFCP中的應用，以及RFC4538規範的細節。這裡，我們介紹一下關於BFCP的幾個應用場景。首先，BFCP雙流控制協議應用在視頻會議的場景中。研究人員Aila H.Koponen在較早時間發佈了關於流控制服務在分佈式會議的研究成果，此研究人員對流控制服務器的功能和在視頻會議中的作用做了比較完整的介紹和功能實現方式的操作說明。因為，IMS網絡的逐漸普及，更多的視頻會議的部署模式開始出現，其技術架構也不斷升級。基本的視頻會議的功能模塊包括：
其中，會議實體中包括了更多關於會議實體屬性的一些功能。
在BFCP處理過程中使用了RFC4582規範，不同的實體通過相應的請求和響應來處理其消息。關於RFC4582的詳解規範，請讀者參考part 1的內容。基於SIP或者其他協議進行會議請求的處理方式基本細節如下：
具體的流會議成員邀請和會議釋放流程如下：
具體的流會議成員請求和釋放消息細節如下：
目前的視頻會議形式出現了更多的支持模式，包括基於WebRTC的視頻會議等模式。這些比較新的會議解決方案大部分在技術架構和以前說的有一些不同，這些新的模式更多依賴於雲平臺的模式，而不是依賴於IMS網絡的其他資源（例如MRFC）。
除了BFCP在視頻會議中的應用場景以外，BFCP也正在應用在基於物聯網IOT的場景中。Oscar Novo提出了一個基於BFCP在IOT物聯網的應用技術架構。在其技術架構中，充分利用BFCP實現對物聯網終端實現資源訪問控制，例如支持各種傳感器和探測器實現告警和資源調用功能。其核心模塊仍然包括流成員，流主持人方和流控制服務器方，通過流控制服務器狀態機，流管理模塊和HTTP服務器端實現多方之間的通信。
BFCP在IMS網絡/雲分佈式部署等環境討論
前面的討論中，筆者已經說明了在IMS網絡環境中BFCP的應用。這裡，筆者說明架構比較細節的關於BFCP的部署使用方式。首先，IMS網絡中通過MRFC實現了BFCP流控制服務器的功能。以下是Ericsson提出的BFCP在IMS網絡中的應用方式，這是一個比較早期的技術架構，很多後期的技術實現方式基本上都是從這裡衍生出來的。
IMS網絡中BFCP的支持方式
圖例來自於互聯網資源
具體實現方式
目前比較熱門的WebRTC和視頻會議實現也實現了無縫集成。在WebRTC和語音通信研究比較權威的Meetecho提出了輕量級的技術架構：
圖片來自於互聯網資源
其中，在此架構中通過RTCWeb Offer/Answer Protocol (ROAP)實現了對BFCP協議的支持。
總結
在關於BFCP雙流控制協議的概論中，筆者在第一部分討論了RFC4582（BFCP協議規範），還有第二部分中的如何通過SDP實現BFCP的創建。另外，筆者簡單討論了BFCP在視頻會議和物聯網IOT的應用可能，最後分享了BFCP協議在IMS網絡和基於WebRTC集成中的實現可能。
說明，因為，基於互聯網的技術在不斷髮展，研究人員的技術成果也同樣在不斷髮展，很多技術細節仍然在不停更新，我們僅能按照比較新的技術文獻參考來做參考。更多的關於WebRTC視頻會議（例如開源視頻會議jitsi等部署）或者視頻會議處理模式，基於雲平臺的視頻會議管理和應用等話題不在筆者討論的範圍。
參考資料：
https://www.rfc-editor.org/rfc/rfc4574
https://www.rfc-editor.org/rfc/rfc4583.html
www.asterisk.org.cn
www.freepbx.cn
Aila H.Koponen，A Floor Control Server in a Distributed Conference Service
Oscar Novo，A Framework for Access Coordination in IoT
A Novel Architecture for Floor Control in the IP
Multimedia Subsystem of 3G Networks
