Alan Johnston, John Yoakum, Kundan Singh, Avaya公司
会话边缘控制器及防火墙穿透
SBC本质上是一个应用层的防火墙，其中建立有信令及媒体应用层网关（ALG）。SBC经常作为一个企业网络元素被连入企业的非警戒区（DMZ）。它会阻挡一切未授权的信令及媒体流，并且提供策略执行，如图1所示。当今的SBC支持SIP和RTP，包括安全RTP（SRTP）。
图1 SBC在5060端口截取SIP/SDP信令，提供策略，并且打开防火墙的孔洞来为企业通信建立一个RTP媒体通道，但是WebRTC传输使用了HTTP保护（HTTPS），其不是截取的，并且会加强被阻挡的媒体通道。
SIP是一种为VoIP和视频通信建立RTP（或者SRTP）媒体传输的信令协议。通过分解SIP信息，SBC传输可以寻找出用于媒体通信的传输地址（5-元组）。如果SIP传输已经被建立且被授权，SBC或者打开一个孔洞（允许RTP传输的过滤规则），或者激活一个RTP时延。在这两种情况中，产生的RTP媒体传输都可以穿透防火墙。
另外，对于防火墙穿透，SBC也可以提供很多其他服务，包括信令归一化、媒体转码、以及针对恶意数据包和支付链接的保护。这些功能并不与本文所讨论防火墙的穿透问题所直接相关，但是对企业来说极为有利。
既然企业已经在通信防火墙穿透领域广泛应用了SBC，在WebRTC中也使用这项技术看机来就很符合逻辑。但是，这项进程当中有着很多的困难和问题。第一，它以来与使用信令通道来验证媒体通道。而在WebRTC中还没有标准的信令通道。第二，SBC需要将其自己嵌入到控制通道当媒体流开始和结束的时候来学习。而在WebRTC中，控制通道是在浏览器和网络服务器之间的HTTP或者WebSocket通道，而且就像图1所示的那样，其会在TLS上运行，并且因此会被加密，所以并不会被观察到。最后，SBC利用从信令通道所定义的身份信息来验证媒体通道。但是在WebRTC中，并没有一个标准的方法来验证身份信息。很少在标准体里被讨论的身份验证机制与媒体通道的身份有关，并且这些身份信息与SBC所习惯处理的信息有着本质上的区别。
并且，WebRTC中没有时间段的概念；而是被流（stream）的概念所替代。流具有媒体源和结束点，可以产生和结束媒体流。它们通过使用JavaScript来产生和操作，产生于建立的对等通信。流可以为媒体在端到端、或者在浏览器和媒体服务器或者混合器之间传输而产生。在对等通信以及多方通信之间并没有直接交互。一旦对等通信已经在浏览器和媒体选择器之间被建立，额外的参与方可以在任意时间被加入。举个例子，来自于多方的媒体可以被混入或者提供给媒体混合器或选择器。
图2. 将WebRTC媒体流转换成SIP/SRTP以允许SBC的策略执行，对于简单的通话或者会议来说是可能的，但是其不会在在WebRTC媒体流和SIP通信之间的一对一传输的多网络的情况下工作。
一有个可能的方式会为企业尝试转换每个通过企业边界进入通信段的WebRTC通信。这可以将WebRTC会话转换成SIP会话、提供政策及验证、以及再次转换回原样以提供给其他服务器（图2）。这种“人为中心”的方式并不实际，尤其是WebRTC的功能可以被嵌入至多种网络应用及站点之内，而且它们遵循着不同的实时通信规范。尤其是，从WebRTC流到SIP会话的一对一转换不能脱离破坏已存在的SIP实现传输。而且，所有的WebRTC内的控制和媒体是被加密的。
这些问题不意味着WebRTC永远不会穿透企业防火墙，而更重要的是说明需要应用全新的方法。其中的一些方法可能是创新的，并且通过实践产生并应用于WebRTC的。但是有一些指示也许可以应用到当今的标准和方法中。本文其余部分将展示一些想法来回答下面这三个问题：企业防火墙如何适配与WebRTC？企业如何发现并且应用策略到WebRTC数据流中？还有如何将新兴的WebRTC应用整合嵌入到已存在的企业通信设备中去。
