在關于BFCP雙流控制協(xié)議概論的第一部分，我們重點介紹了BFCP（RFC4582的規(guī)范細節(jié)）。在第二部分中，我們將重點介紹通過SDP拓展實現(xiàn)的BFCP數(shù)據(jù)交互信息的方式和BFCP其他技術架構的討論，應用場景（例如物聯(lián)網IOT）和其他部署問題的討論。
1、使用SDP描述實現(xiàn)BFCP數(shù)據(jù)交換（RFC4583）
在BFCP中，流客戶端需要獲得一系列的數(shù)據(jù)和流控制服務器端創(chuàng)建一個連接來獲得這些相關的數(shù)據(jù)，這些數(shù)據(jù)包括服務器傳輸?shù)刂罚瑫hID和用戶ID等信息。那么，如何獲得這些消息數(shù)據(jù)？對于流客戶端來說，一種方法是使用SDP的offer/answer交互模式來獲得數(shù)據(jù)。RFC4583規(guī)范具體規(guī)定了如何對SDP交互信息進行解碼來獲得這些必要的數(shù)據(jù)。下面，筆者將重點介紹RFC4583中關于SDP交互的幾個主要的概念和處理流程，例如SDP中的m行解碼處理說明，流控制服務器的角色處理，會議ID和用戶ID的屬性說明，介于媒體流和流資源的關聯(lián)，TCP連接管理，簽權處理，示例和安全考慮。
首先我們來介紹一下SDP中的m行使用。一般情況下，SDP的客戶端使用SDP answer/offer模式對流媒體類型進行創(chuàng)建支持。同樣的道理，BFCP如果使用answer/offer模式交互數(shù)據(jù)時，BFCP也是作為一種流媒體支持的類型進行，它使用了支持媒體格式的m行和其他多種在a行解碼的屬性來實現(xiàn)。關于SDP中媒體格式支持和m行處理，讀者可以參考歷史文檔來進一步學習，這里不再做過多詳解，或者參考RFC4566規(guī)范說明。現(xiàn)在，我們討論一下如何生成一個對BFCP媒體流的m行支持。根據(jù)RFC4566的規(guī)范規(guī)定，m行的語法構成是這樣的：
m=<media> <port> <transport> <fmt> …
https://www.rfc-editor.org/rfc/rfc4566
此媒體域必須有一個“application”值，當然，在SDP中包括對值可能是語音，視頻，文本或應用。其中，端口設置需要根據(jù)RFC4145規(guī)范來處理。另外，取決于TCP 連接時流程中“setup”的取值，端口域所包含這個特定的端口，此端口是遠端客戶端發(fā)起的TCP連接，或者其他不相關連接（例如，客戶端將對遠端客戶端發(fā)起的連接），這種端口設置為9，因為BFCP連接僅使用TCP連接，這種是應該丟棄的端口。關于此細節(jié)說明，讀者可以參考RFC4245-4.1。
the endpoint using the value 'active' SHOULD specify a port number of 9 （the discard port） on its 'm' line.
https://www.rfc-editor.org/rfc/rfc4145
在標準的SDP規(guī)范中，如果端口域的值為0的話，它具有一定的含義（例如，拒絕了媒體流）。在RFC4583中定義了兩種關于BFCP的端口設置，一種是TCP/BFCP，另外一種是支持TLS的TCP/TLS/BFCP。前面一種在TCP中直接運行，后面的定義方式當TCP支持TLS時，BFCP也需要在TLS下運行。在BFCP中，fmt格式是一個被忽略的值，BFCP的ftm列表應該包含一個單"*"字符。因此，一個標準的BFCP語法構成是這樣的：
m=application 50000 TCP/TLS/BFCP * // 支持了TLS
或者客戶端返回的示例：
m=application 9 TCP/TLS/BFCP * // port 9將被丟棄。
以上就是關于BFCP中m行當語法說明。接下來，我們繼續(xù)討論關于流控制服務器的角色決定（Floor Control Server Determination）機制。
如果兩個終端創(chuàng)建了BFCP連接媒體流的話，它們需要決定誰是流控制服務器方。流控制服務器中的角色決定機制決定了哪一方作為流控制服務器方。流控制服務器的角色決定相對比較直接，一方是客戶端的話，其他的只能是流控制服務器方。大部分的使用場景中，如果一個客戶端創(chuàng)建了和會議服務器的流媒體連接的話，那么，此客戶端通常為流控制服務器端。但是，在BFCP的應用場景中也存在比較特別的示例，例如兩個終端可能都想作為流控制服務器端。例如，在一個兩方的會話中，這個兩方會話涉及了語音和白板分享功能的使用的話，這兩個終端就需要決定哪一方是流控制方。在實際示例中，可能一個終端作為語音的流控制服務器，另外一個終端則為白板共享的流控制服務器。在RFC4583中，通過SDP屬性中的“floorctrl”來設定執(zhí)行流控制服務器的角色設置，具體的用法如下：
floor-control-attribute = "a=floorctrl:" role *（SP role）
role = "c-only" / "s-only" / "c-s"
role的具體定義包括：“c-only”-表示offerer方愿意成為流控制服務器的客戶端， “s-only”-表示offerer方愿意成為流控制服務器的服務器端和“cs”-表示offerer方愿意成為流控制服務器的客戶端和服務器端。如果在offer中的m行包含floorctrl，此answerer必須在其相應的answer中包含m行。answerer必須包含它的屬性來聲明answerer方將要扮演的角色。這也就是說，answerer選擇其中一個角色，此角色是offerer愿意執(zhí)行的，并且為answerer生成相應的answer。answerer方的角色決定依賴于offerer方的愿意扮演的角色。兩者的角色取決于offerer方的角色。
在answerer中的角色有各自的含義。“c-only”-表示answerer方愿意成為流控制服務器的客戶端，接下來，offerer方為流控制服務器端。“s-only”-表示answerer方愿意成為流控制服務器的服務器端，接下來，offerer方則為流控制客戶端。“cs”-表示answerer方愿意成為流控制服務器的客戶端和服務器端，接下來，offerer也是流控制服務器的客戶端和服務器端。如果使用offer/answer交互模式的終端來創(chuàng)建BFCP連接的話，其終端必須支持floorctrl屬性。另外要注意，如果沒有在offer/answer交互模式中使用floorctrl屬性的話，在默認設置中，offerer方則為流控制服務器端，而answerer方則為流控制服務器端。以下示例是一個floorctrl在offer中的示例。當此屬性出現(xiàn)在answer中時，此屬性僅能傳遞其中一個角色，而不是傳遞所有角色：
a=floorctrl:c-only s-only c-s
在SDP屬性中，最為重要的兩個屬性是媒體級的SDP屬性 'confid'和 'userid'屬性。流控制服務器使用這兩個屬性為客戶端提供相應的會議ID和用戶ID。其具體語法如下：
confid-attribute = "a=confid:" conference-id
conference-id = token
userid-attribute = "a=userid:" user-id
user-id = token
以上這兩種屬性都是以整數(shù)為單位表示。使用offer/answer交互模式來創(chuàng)建BFCP連接的終端必須支持confid 和userid 屬性。如果流控制服務器充當offerer或者answerer方的話，流控制服務器應該在會話描述中包含這兩種屬性。
接下來，我們介紹一下如何關聯(lián)媒體流和流資源。RFC4583在SDP媒體級屬性中定義了一個floorid，語法如下：
floor-id-attribute = "a=floorid:" token [" mstrm:" token *（SP token）]
floorid使用在BFCP的SDP m行中。它定義了流的標識符可以用來關聯(lián)一個或者多個媒體流。這里的令牌token表示一個floor ID，它是一個整數(shù)值表示在BFCP中的Floor ID。表示媒體流的token指向了媒體流，這個媒體流通過SDP label attribute來定義。具體的用法參考RFC4574-5。使用offer/answer交互模式來創(chuàng)建BFCP連接的終端必須支持floorid和label屬性。如果流控制服務器充當offerer或者answerer方的話，流控制服務器應該在會話描述中包含這兩種屬性。
在BFCP連接的處理過程中，我們還要關注一下關于BFCP中TCP的管理。傳輸BFCP是通過“setup” 和“connection”屬性來執(zhí)行。這個傳輸機制（SDP中基于TCP的媒體傳輸）需要按照RFC4245規(guī)范來執(zhí)行。“setup”屬性表示哪一方（流客戶端還是流控制服務器端）終端發(fā)起的TCP連接。“connection”屬性用來處理TCP重連創(chuàng)建。在BFCP規(guī)范中描述了多種場景，在這些場景中，介于流客戶端和流控制服務器的TCP連接需要重新創(chuàng)建。具體這些場景的詳解，請讀者參考上一篇文章的介紹。但是，這些場景沒有說明具體的重新連接流程，因為，這些流程取決于創(chuàng)建TCP連接的第一個觸發(fā)點本身。BFCP實體按照answer/offer交互模式處理時，這些實體需要以下規(guī)則。當現(xiàn)存的TCP連接重新設置時，流客戶端應該對其流控制服務器端生成一個offer消息來進行重新連接。如果TCP連接不能傳輸BFCP消息或者傳輸超時（實體檢測到了TCP超時），發(fā)送BFCP消息的實體應該生成一個offer來重新創(chuàng)建TCP連接。使用answer/offer交互模式創(chuàng)建BFCP連接的終端必須支持“setup” 和“connection”屬性。
RFC4583中關于SDP拓展使用同樣也需要進行簽權機制的處理。當BFCP連接通過answer/offer交互模式創(chuàng)建以后，這是假設offerer方和answerer方通過某些簽權機制來對對方進行認證處理。一旦相互之間的簽權機制發(fā)生以后，所有的offerer方和answerer方需要確保它們接收BFCP消息的實體和前面它們生成offer或answer的相同。當使用SIP來進行offer/answer交互時，最初的相互的認證是發(fā)生在SIP協(xié)議級。另外，SIP使用S/MIME為offer/answer交互模式提供了一個完整保護通道，這個保護通道使用其他安全手段對其進行支持。BFCP利用這個完整保護方式下的offer/answer交互模式執(zhí)行簽權機制處理。在此offer/answer交互模式下，offerer和answerer交互自簽證書的指紋信息。這些自簽證書用來創(chuàng)建TLS連接，這個TLS連接來傳輸offerer方和answerer方之間的BFCP數(shù)據(jù)流量。進一步說明，涉及到證書選擇和使用的話，BFCP客戶端和流控制服務器需要按照RFC4572的規(guī)范來執(zhí)行。此規(guī)范聲明了TLS在SDP中的使用。此規(guī)定的表示除非會話描述中包含指紋（fingerprint）屬性，TLS級的證書必須是自簽證書或者合法第三方證書。使用offer/answer交互模式創(chuàng)建的BFCP連接必須支持指紋（fingerprint）屬性，并且應該在會話描述中包括指紋（fingerprint）屬性。當使用了TLS連接以后，一旦TCP連接創(chuàng)建后，無論其角色是何角色（在TCP創(chuàng)建流程中其角色是被動或主動角色），answerer方則為TLS服務器端。
以下示例說明關于SDP中關于m行使用的情況，會議服務器端發(fā)送到客戶端的offer消息：
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
以下是客戶端返回的answer消息：
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
關于RFC4583的安全討論。規(guī)范RFC4583中涉及了BFCP（RFC4582），SDP（RFC4566）和offer/answer交互模式（RFC3264）。這些規(guī)范都已經定義了其相應的安全機制。在筆者的歷史文檔都已經分別做了非常詳細說明，讀者可以參考歷史文檔來了解這些規(guī)范的具體詳解。另外，RFC4145也討論了基于TCP媒體傳輸?shù)陌踩珯C制，在RFC4572中也討論了SDP中TLS的支持規(guī)范。這些規(guī)范都涵蓋了關于安全機制的討論。除此之外，BFCP假設客戶端和流控制服務器端使用了自簽證書來實現(xiàn)對安全完整性的通道保護。并且，對于在SIP中傳輸?shù)臅捗枋觯琒/MIME是一個自然的選擇來提供這樣的通道。
2、BFCP應用場景示例（視頻會議/IOT）
前面章節(jié)介紹了關于SDP m行在BFCP中的應用，以及RFC4538規(guī)范的細節(jié)。這里，我們介紹一下關于BFCP的幾個應用場景。首先，BFCP雙流控制協(xié)議應用在視頻會議的場景中。研究人員Aila H.Koponen在較早時間發(fā)布了關于流控制服務在分布式會議的研究成果，此研究人員對流控制服務器的功能和在視頻會議中的作用做了比較完整的介紹和功能實現(xiàn)方式的操作說明。因為，IMS網絡的逐漸普及，更多的視頻會議的部署模式開始出現(xiàn)，其技術架構也不斷升級。基本的視頻會議的功能模塊包括：
其中，會議實體中包括了更多關于會議實體屬性的一些功能。
在BFCP處理過程中使用了RFC4582規(guī)范，不同的實體通過相應的請求和響應來處理其消息。關于RFC4582的詳解規(guī)范，請讀者參考part 1的內容。基于SIP或者其他協(xié)議進行會議請求的處理方式基本細節(jié)如下：
具體的流會議成員邀請和會議釋放流程如下：
具體的流會議成員請求和釋放消息細節(jié)如下：
目前的視頻會議形式出現(xiàn)了更多的支持模式，包括基于WebRTC的視頻會議等模式。這些比較新的會議解決方案大部分在技術架構和以前說的有一些不同，這些新的模式更多依賴于云平臺的模式，而不是依賴于IMS網絡的其他資源（例如MRFC）。
除了BFCP在視頻會議中的應用場景以外，BFCP也正在應用在基于物聯(lián)網IOT的場景中。Oscar Novo提出了一個基于BFCP在IOT物聯(lián)網的應用技術架構。在其技術架構中，充分利用BFCP實現(xiàn)對物聯(lián)網終端實現(xiàn)資源訪問控制，例如支持各種傳感器和探測器實現(xiàn)告警和資源調用功能。其核心模塊仍然包括流成員，流主持人方和流控制服務器方，通過流控制服務器狀態(tài)機，流管理模塊和HTTP服務器端實現(xiàn)多方之間的通信。
3、BFCP在IMS網絡/云分布式部署等環(huán)境討論
前面的討論中，筆者已經說明了在IMS網絡環(huán)境中BFCP的應用。這里，筆者說明架構比較細節(jié)的關于BFCP的部署使用方式。首先，IMS網絡中通過MRFC實現(xiàn)了BFCP流控制服務器的功能。以下是Ericsson提出的BFCP在IMS網絡中的應用方式，這是一個比較早期的技術架構，很多后期的技術實現(xiàn)方式基本上都是從這里衍生出來的。
IMS網絡中BFCP的支持方式
具體實現(xiàn)方式
目前比較熱門的WebRTC和視頻會議實現(xiàn)也實現(xiàn)了無縫集成。在WebRTC和語音通信研究比較權威的Meetecho提出了輕量級的技術架構：
其中，在此架構中通過RTCWeb Offer/Answer Protocol （ROAP）實現(xiàn)了對BFCP協(xié)議的支持。
4、總結
在關于BFCP雙流控制協(xié)議的概論中，筆者在第一部分討論了RFC4582（BFCP協(xié)議規(guī)范），還有第二部分中的如何通過SDP實現(xiàn)BFCP的創(chuàng)建。另外，筆者簡單討論了BFCP在視頻會議和物聯(lián)網IOT的應用可能，最后分享了BFCP協(xié)議在IMS網絡和基于WebRTC集成中的實現(xiàn)可能。
說明，因為，基于互聯(lián)網的技術在不斷發(fā)展，研究人員的技術成果也同樣在不斷發(fā)展，很多技術細節(jié)仍然在不停更新，我們僅能按照比較新的技術文獻參考來做參考。更多的關于WebRTC視頻會議（例如開源視頻會議jitsi等部署）或者視頻會議處理模式，基于云平臺的視頻會議管理和應用等話題不在筆者討論的范圍。
參考資料：
https://www.rfc-editor.org/rfc/rfc4574
https://www.rfc-editor.org/rfc/rfc4583.html
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
