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