完整双流控制协议（BFCP），SDP拓展和应用概论-part 2

　　在关于BFCP双流控制协议概论的第一部分，我们重点介绍了BFCP（RFC4582的规范细节）。在第二部分中，我们将重点介绍通过SDP拓展实现的BFCP数据交互信息的方式和BFCP其他技术架构的讨论，应用场景（例如物联网IOT）和其他部署问题的讨论。

　　1、使用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=<media> <port> <transport> <fmt> …

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

　　此媒体域必须有一个“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.

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

　　在标准的SDP规范中，如果端口域的值为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行当语法说明。接下来，我们继续讨论关于流控制服务器的角色决定（Floor Control Server Determination）机制。

　　如果两个终端创建了BFCP连接媒体流的话，它们需要决定谁是流控制服务器方。流控制服务器中的角色决定机制决定了哪一方作为流控制服务器方。流控制服务器的角色决定相对比较直接，一方是客户端的话，其他的只能是流控制服务器方。大部分的使用场景中，如果一个客户端创建了和会议服务器的流媒体连接的话，那么，此客户端通常为流控制服务器端。但是，在BFCP的应用场景中也存在比较特别的示例，例如两个终端可能都想作为流控制服务器端。例如，在一个两方的会话中，这个两方会话涉及了语音和白板分享功能的使用的话，这两个终端就需要决定哪一方是流控制方。在实际示例中，可能一个终端作为语音的流控制服务器，另外一个终端则为白板共享的流控制服务器。在RFC4583中，通过SDP属性中的“floorctrl”来设定执行流控制服务器的角色设置，具体的用法如下：

　　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愿意执行的，并且为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中时，此属性仅能传递其中一个角色，而不是传递所有角色：

　　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

　　以上这两种属性都是以整数为单位表示。使用offer/answer交互模式来创建BFCP连接的终端必须支持confid 和userid 属性。如果流控制服务器充当offerer或者answerer方的话，流控制服务器应该在会话描述中包含这两种属性。

　　接下来，我们介绍一下如何关联媒体流和流资源。RFC4583在SDP媒体级属性中定义了一个floorid，语法如下：

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

　　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消息：

　　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的安全讨论。规范RFC4583中涉及了BFCP（RFC4582），SDP（RFC4566）和offer/answer交互模式（RFC3264）。这些规范都已经定义了其相应的安全机制。在笔者的历史文档都已经分别做了非常详细说明，读者可以参考历史文档来了解这些规范的具体详解。另外，RFC4145也讨论了基于TCP媒体传输的安全机制，在RFC4572中也讨论了SDP中TLS的支持规范。这些规范都涵盖了关于安全机制的讨论。除此之外，BFCP假设客户端和流控制服务器端使用了自签证书来实现对安全完整性的通道保护。并且，对于在SIP中传输的会话描述，S/MIME是一个自然的选择来提供这样的通道。

　　2、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服务器端实现多方之间的通信。

　　3、BFCP在IMS网络/云分布式部署等环境讨论

　　前面的讨论中，笔者已经说明了在IMS网络环境中BFCP的应用。这里，笔者说明架构比较细节的关于BFCP的部署使用方式。首先，IMS网络中通过MRFC实现了BFCP流控制服务器的功能。以下是Ericsson提出的BFCP在IMS网络中的应用方式，这是一个比较早期的技术架构，很多后期的技术实现方式基本上都是从这里衍生出来的。