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