在關(guān)于BFCP雙流控制協(xié)議概論的第一部分，我們重點(diǎn)介紹了BFCP（RFC4582的規(guī)范細(xì)節(jié)）。在第二部分中，我們將重點(diǎn)介紹通過SDP拓展實(shí)現(xiàn)的BFCP數(shù)據(jù)交互信息的方式和BFCP其他技術(shù)架構(gòu)的討論，應(yīng)用場景（例如物聯(lián)網(wǎng)IOT）和其他部署問題的討論。

　　在BFCP中，流客戶端需要獲得一系列的數(shù)據(jù)和流控制服務(wù)器端創(chuàng)建一個(gè)連接來獲得這些相關(guān)的數(shù)據(jù)，這些數(shù)據(jù)包括服務(wù)器傳輸?shù)刂�，�?huì)議ID和用戶ID等信息。那么，如何獲得這些消息數(shù)據(jù)？對于流客戶端來說，一種方法是使用SDP的offer/answer交互模式來獲得數(shù)據(jù)。RFC4583規(guī)范具體規(guī)定了如何對SDP交互信息進(jìn)行解碼來獲得這些必要的數(shù)據(jù)。下面，筆者將重點(diǎn)介紹RFC4583中關(guān)于SDP交互的幾個(gè)主要的概念和處理流程，例如SDP中的m行解碼處理說明，流控制服務(wù)器的角色處理，會(huì)議ID和用戶ID的屬性說明，介于媒體流和流資源的關(guān)聯(lián)，TCP連接管理，簽權(quán)處理，示例和安全考慮。

　　首先我們來介紹一下SDP中的m行使用。一般情況下，SDP的客戶端使用SDP answer/offer模式對流媒體類型進(jìn)行創(chuàng)建支持。同樣的道理，BFCP如果使用answer/offer模式交互數(shù)據(jù)時(shí)，BFCP也是作為一種流媒體支持的類型進(jìn)行，它使用了支持媒體格式的m行和其他多種在a行解碼的屬性來實(shí)現(xiàn)。關(guān)于SDP中媒體格式支持和m行處理，讀者可以參考?xì)v史文檔來進(jìn)一步學(xué)習(xí)，這里不再做過多詳解，或者參考RFC4566規(guī)范說明�，F(xiàn)在，我們討論一下如何生成一個(gè)對BFCP媒體流的m行支持。根據(jù)RFC4566的規(guī)范規(guī)定，m行的語法構(gòu)成是這樣的：

　　m=<media> <port> <transport> <fmt> …

　　https://www.rfc-editor.org/rfc/rfc4566

　　此媒體域必須有一個(gè)“application”值，當(dāng)然，在SDP中包括對值可能是語音，視頻，文本或應(yīng)用。其中，端口設(shè)置需要根據(jù)RFC4145規(guī)范來處理。另外，取決于TCP 連接時(shí)流程中“setup”的取值，端口域所包含這個(gè)特定的端口，此端口是遠(yuǎn)端客戶端發(fā)起的TCP連接，或者其他不相關(guān)連接（例如，客戶端將對遠(yuǎn)端客戶端發(fā)起的連接），這種端口設(shè)置為9，因?yàn)锽FCP連接僅使用TCP連接，這種是應(yīng)該丟棄的端口。關(guān)于此細(xì)節(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

　　在標(biāo)準(zhǔn)的SDP規(guī)范中，如果端口域的值為0的話，它具有一定的含義（例如，拒絕了媒體流）。在RFC4583中定義了兩種關(guān)于BFCP的端口設(shè)置，一種是TCP/BFCP，另外一種是支持TLS的TCP/TLS/BFCP。前面一種在TCP中直接運(yùn)行，后面的定義方式當(dāng)TCP支持TLS時(shí)，BFCP也需要在TLS下運(yùn)行。在BFCP中，fmt格式是一個(gè)被忽略的值，BFCP的ftm列表應(yīng)該包含一個(gè)單"*"字符。因此，一個(gè)標(biāo)準(zhǔn)的BFCP語法構(gòu)成是這樣的：

　　m=application 50000 TCP/TLS/BFCP * // 支持了TLS

　　或者客戶端返回的示例：

　　m=application 9 TCP/TLS/BFCP * // port 9將被丟棄。

　　以上就是關(guān)于BFCP中m行當(dāng)語法說明。接下來，我們繼續(xù)討論關(guān)于流控制服務(wù)器的角色決定（Floor Control Server Determination）機(jī)制。

　　如果兩個(gè)終端創(chuàng)建了BFCP連接媒體流的話，它們需要決定誰是流控制服務(wù)器方。流控制服務(wù)器中的角色決定機(jī)制決定了哪一方作為流控制服務(wù)器方。流控制服務(wù)器的角色決定相對比較直接，一方是客戶端的話，其他的只能是流控制服務(wù)器方。大部分的使用場景中，如果一個(gè)客戶端創(chuàng)建了和會(huì)議服務(wù)器的流媒體連接的話，那么，此客戶端通常為流控制服務(wù)器端。但是，在BFCP的應(yīng)用場景中也存在比較特別的示例，例如兩個(gè)終端可能都想作為流控制服務(wù)器端。例如，在一個(gè)兩方的會(huì)話中，這個(gè)兩方會(huì)話涉及了語音和白板分享功能的使用的話，這兩個(gè)終端就需要決定哪一方是流控制方。在實(shí)際示例中，可能一個(gè)終端作為語音的流控制服務(wù)器，另外一個(gè)終端則為白板共享的流控制服務(wù)器。在RFC4583中，通過SDP屬性中的“floorctrl”來設(shè)定執(zhí)行流控制服務(wù)器的角色設(shè)置，具體的用法如下：

　　floor-control-attribute  = "a=floorctrl:" role *（SP role）

　　role                     = "c-only" / "s-only" / "c-s"

　　role的具體定義包括：“c-only”-表示offerer方愿意成為流控制服務(wù)器的客戶端， “s-only”-表示offerer方愿意成為流控制服務(wù)器的服務(wù)器端和“cs”-表示offerer方愿意成為流控制服務(wù)器的客戶端和服務(wù)器端。如果在offer中的m行包含floorctrl，此answerer必須在其相應(yīng)的answer中包含m行。answerer必須包含它的屬性來聲明answerer方將要扮演的角色。這也就是說，answerer選擇其中一個(gè)角色，此角色是offerer愿意執(zhí)行的，并且為answerer生成相應(yīng)的answer。answerer方的角色決定依賴于offerer方的愿意扮演的角色。兩者的角色取決于offerer方的角色。

　　在answerer中的角色有各自的含義。“c-only”-表示answerer方愿意成為流控制服務(wù)器的客戶端，接下來，offerer方為流控制服務(wù)器端。“s-only”-表示answerer方愿意成為流控制服務(wù)器的服務(wù)器端，接下來，offerer方則為流控制客戶端。“cs”-表示answerer方愿意成為流控制服務(wù)器的客戶端和服務(wù)器端，接下來，offerer也是流控制服務(wù)器的客戶端和服務(wù)器端。如果使用offer/answer交互模式的終端來創(chuàng)建BFCP連接的話，其終端必須支持floorctrl屬性。另外要注意，如果沒有在offer/answer交互模式中使用floorctrl屬性的話，在默認(rèn)設(shè)置中，offerer方則為流控制服務(wù)器端，而answerer方則為流控制服務(wù)器端。以下示例是一個(gè)floorctrl在offer中的示例。當(dāng)此屬性出現(xiàn)在answer中時(shí)，此屬性僅能傳遞其中一個(gè)角色，而不是傳遞所有角色：

　　a=floorctrl:c-only s-only c-s

　　在SDP屬性中，最為重要的兩個(gè)屬性是媒體級的SDP屬性 'confid'和 'userid'屬性。流控制服務(wù)器使用這兩個(gè)屬性為客戶端提供相應(yīng)的會(huì)議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 屬性。如果流控制服務(wù)器充當(dāng)offerer或者answerer方的話，流控制服務(wù)器應(yīng)該在會(huì)話描述中包含這兩種屬性。

　　接下來，我們介紹一下如何關(guān)聯(lián)媒體流和流資源。RFC4583在SDP媒體級屬性中定義了一個(gè)floorid，語法如下：

　　floor-id-attribute = "a=floorid:" token [" mstrm:" token *（SP token）]

　　floorid使用在BFCP的SDP m行中。它定義了流的標(biāo)識(shí)符可以用來關(guān)聯(lián)一個(gè)或者多個(gè)媒體流。這里的令牌token表示一個(gè)floor ID，它是一個(gè)整數(shù)值表示在BFCP中的Floor ID。表示媒體流的token指向了媒體流，這個(gè)媒體流通過SDP label attribute來定義。具體的用法參考RFC4574-5。使用offer/answer交互模式來創(chuàng)建BFCP連接的終端必須支持floorid和label屬性。如果流控制服務(wù)器充當(dāng)offerer或者answerer方的話，流控制服務(wù)器應(yīng)該在會(huì)話描述中包含這兩種屬性。

　　在BFCP連接的處理過程中，我們還要關(guān)注一下關(guān)于BFCP中TCP的管理。傳輸BFCP是通過“setup” 和“connection”屬性來執(zhí)行。這個(gè)傳輸機(jī)制（SDP中基于TCP的媒體傳輸）需要按照RFC4245規(guī)范來執(zhí)行。“setup”屬性表示哪一方（流客戶端還是流控制服務(wù)器端）終端發(fā)起的TCP連接。“connection”屬性用來處理TCP重連創(chuàng)建。在BFCP規(guī)范中描述了多種場景，在這些場景中，介于流客戶端和流控制服務(wù)器的TCP連接需要重新創(chuàng)建。具體這些場景的詳解，請讀者參考上一篇文章的介紹。但是，這些場景沒有說明具體的重新連接流程，因?yàn)�，這些流程取決于創(chuàng)建TCP連接的第一個(gè)觸發(fā)點(diǎn)本身。BFCP實(shí)體按照answer/offer交互模式處理時(shí)，這些實(shí)體需要以下規(guī)則。當(dāng)現(xiàn)存的TCP連接重新設(shè)置時(shí)，流客戶端應(yīng)該對其流控制服務(wù)器端生成一個(gè)offer消息來進(jìn)行重新連接。如果TCP連接不能傳輸BFCP消息或者傳輸超時(shí)（實(shí)體檢測到了TCP超時(shí)），發(fā)送BFCP消息的實(shí)體應(yīng)該生成一個(gè)offer來重新創(chuàng)建TCP連接。使用answer/offer交互模式創(chuàng)建BFCP連接的終端必須支持“setup” 和“connection”屬性。

　　RFC4583中關(guān)于SDP拓展使用同樣也需要進(jìn)行簽權(quán)機(jī)制的處理。當(dāng)BFCP連接通過answer/offer交互模式創(chuàng)建以后，這是假設(shè)offerer方和answerer方通過某些簽權(quán)機(jī)制來對對方進(jìn)行認(rèn)證處理。一旦相互之間的簽權(quán)機(jī)制發(fā)生以后，所有的offerer方和answerer方需要確保它們接收BFCP消息的實(shí)體和前面它們生成offer或answer的相同。當(dāng)使用SIP來進(jìn)行offer/answer交互時(shí)，最初的相互的認(rèn)證是發(fā)生在SIP協(xié)議級。另外，SIP使用S/MIME為offer/answer交互模式提供了一個(gè)完整保護(hù)通道，這個(gè)保護(hù)通道使用其他安全手段對其進(jìn)行支持。BFCP利用這個(gè)完整保護(hù)方式下的offer/answer交互模式執(zhí)行簽權(quán)機(jī)制處理。在此offer/answer交互模式下，offerer和answerer交互自簽證書的指紋信息。這些自簽證書用來創(chuàng)建TLS連接，這個(gè)TLS連接來傳輸offerer方和answerer方之間的BFCP數(shù)據(jù)流量。進(jìn)一步說明，涉及到證書選擇和使用的話，BFCP客戶端和流控制服務(wù)器需要按照RFC4572的規(guī)范來執(zhí)行。此規(guī)范聲明了TLS在SDP中的使用。此規(guī)定的表示除非會(huì)話描述中包含指紋（fingerprint）屬性，TLS級的證書必須是自簽證書或者合法第三方證書。使用offer/answer交互模式創(chuàng)建的BFCP連接必須支持指紋（fingerprint）屬性，并且應(yīng)該在會(huì)話描述中包括指紋（fingerprint）屬性。當(dāng)使用了TLS連接以后，一旦TCP連接創(chuàng)建后，無論其角色是何角色（在TCP創(chuàng)建流程中其角色是被動(dòng)或主動(dòng)角色），answerer方則為TLS服務(wù)器端。

　　以下示例說明關(guān)于SDP中關(guān)于m行使用的情況，會(huì)議服務(wù)器端發(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

　　關(guān)于RFC4583的安全討論。規(guī)范RFC4583中涉及了BFCP（RFC4582），SDP（RFC4566）和offer/answer交互模式（RFC3264）。這些規(guī)范都已經(jīng)定義了其相應(yīng)的安全機(jī)制。在筆者的歷史文檔都已經(jīng)分別做了非常詳細(xì)說明，讀者可以參考?xì)v史文檔來了解這些規(guī)范的具體詳解。另外，RFC4145也討論了基于TCP媒體傳輸?shù)陌踩珯C(jī)制，在RFC4572中也討論了SDP中TLS的支持規(guī)范。這些規(guī)范都涵蓋了關(guān)于安全機(jī)制的討論。除此之外，BFCP假設(shè)客戶端和流控制服務(wù)器端使用了自簽證書來實(shí)現(xiàn)對安全完整性的通道保護(hù)。并且，對于在SIP中傳輸?shù)臅?huì)話描述，S/MIME是一個(gè)自然的選擇來提供這樣的通道。

　　前面章節(jié)介紹了關(guān)于SDP m行在BFCP中的應(yīng)用，以及RFC4538規(guī)范的細(xì)節(jié)。這里，我們介紹一下關(guān)于BFCP的幾個(gè)應(yīng)用場景。首先，BFCP雙流控制協(xié)議應(yīng)用在視頻會(huì)議的場景中。研究人員Aila H.Koponen在較早時(shí)間發(fā)布了關(guān)于流控制服務(wù)在分布式會(huì)議的研究成果，此研究人員對流控制服務(wù)器的功能和在視頻會(huì)議中的作用做了比較完整的介紹和功能實(shí)現(xiàn)方式的操作說明。因?yàn)�，IMS網(wǎng)絡(luò)的逐漸普及，更多的視頻會(huì)議的部署模式開始出現(xiàn)，其技術(shù)架構(gòu)也不斷升級�；�本的視頻會(huì)議的功能模塊包括：

　　其中，會(huì)議實(shí)體中包括了更多關(guān)于會(huì)議實(shí)體屬性的一些功能。

　　在BFCP處理過程中使用了RFC4582規(guī)范，不同的實(shí)體通過相應(yīng)的請求和響應(yīng)來處理其消息。關(guān)于RFC4582的詳解規(guī)范，請讀者參考part 1的內(nèi)容�；�于SIP或者其他協(xié)議進(jìn)行會(huì)議請求的處理方式基本細(xì)節(jié)如下：

　　具體的流會(huì)議成員邀請和會(huì)議釋放流程如下：

 

　　具體的流會(huì)議成員請求和釋放消息細(xì)節(jié)如下：

　　目前的視頻會(huì)議形式出現(xiàn)了更多的支持模式，包括基于WebRTC的視頻會(huì)議等模式。這些比較新的會(huì)議解決方案大部分在技術(shù)架構(gòu)和以前說的有一些不同，這些新的模式更多依賴于云平臺(tái)的模式，而不是依賴于IMS網(wǎng)絡(luò)的其他資源（例如MRFC）。

　　除了BFCP在視頻會(huì)議中的應(yīng)用場景以外，BFCP也正在應(yīng)用在基于物聯(lián)網(wǎng)IOT的場景中。Oscar Novo提出了一個(gè)基于BFCP在IOT物聯(lián)網(wǎng)的應(yīng)用技術(shù)架構(gòu)。在其技術(shù)架構(gòu)中，充分利用BFCP實(shí)現(xiàn)對物聯(lián)網(wǎng)終端實(shí)現(xiàn)資源訪問控制，例如支持各種傳感器和探測器實(shí)現(xiàn)告警和資源調(diào)用功能。其核心模塊仍然包括流成員，流主持人方和流控制服務(wù)器方，通過流控制服務(wù)器狀態(tài)機(jī)，流管理模塊和HTTP服務(wù)器端實(shí)現(xiàn)多方之間的通信。

　　前面的討論中，筆者已經(jīng)說明了在IMS網(wǎng)絡(luò)環(huán)境中BFCP的應(yīng)用。這里，筆者說明架構(gòu)比較細(xì)節(jié)的關(guān)于BFCP的部署使用方式。首先，IMS網(wǎng)絡(luò)中通過MRFC實(shí)現(xiàn)了BFCP流控制服務(wù)器的功能。以下是Ericsson提出的BFCP在IMS網(wǎng)絡(luò)中的應(yīng)用方式，這是一個(gè)比較早期的技術(shù)架構(gòu)，很多后期的技術(shù)實(shí)現(xiàn)方式基本上都是從這里衍生出來的。

　　IMS網(wǎng)絡(luò)中BFCP的支持方式

　　具體實(shí)現(xiàn)方式

　　目前比較熱門的WebRTC和視頻會(huì)議實(shí)現(xiàn)也實(shí)現(xiàn)了無縫集成。在WebRTC和語音通信研究比較權(quán)威的Meetecho提出了輕量級的技術(shù)架構(gòu)：

　　其中，在此架構(gòu)中通過RTCWeb Offer/Answer Protocol （ROAP）實(shí)現(xiàn)了對BFCP協(xié)議的支持。

　　在關(guān)于BFCP雙流控制協(xié)議的概論中，筆者在第一部分討論了RFC4582（BFCP協(xié)議規(guī)范），還有第二部分中的如何通過SDP實(shí)現(xiàn)BFCP的創(chuàng)建。另外，筆者簡單討論了BFCP在視頻會(huì)議和物聯(lián)網(wǎng)IOT的應(yīng)用可能，最后分享了BFCP協(xié)議在IMS網(wǎng)絡(luò)和基于WebRTC集成中的實(shí)現(xiàn)可能。

　　說明，因?yàn)椋�基于互�?lián)網(wǎng)的技術(shù)在不斷發(fā)展，研究人員的技術(shù)成果也同樣在不斷發(fā)展，很多技術(shù)細(xì)節(jié)仍然在不停更新，我們僅能按照比較新的技術(shù)文獻(xiàn)參考來做參考。更多的關(guān)于WebRTC視頻會(huì)議（例如開源視頻會(huì)議jitsi等部署）或者視頻會(huì)議處理模式，基于云平臺(tái)的視頻會(huì)議管理和應(yīng)用等話題不在筆者討論的范圍。

　　參考資料：

　　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