Alan Johnston, John Yoakum, and Kundan Singh, Avaya Inc
WebRTC防火墙穿透
从之前的讨论中，我们得知WebRTC防火墙穿透必须脱离标准化信令协议，脱离传统信令身份，并且脱离可控制会话的概念，才能工作。这看起来可能是一个艰巨的任务，但是这里会提供一些潜在的选项。
需要明确的一点是，会话边缘控制器这个专业名词不适用于帮助WebRTC穿透企业防火墙的设备。尽管边缘部分可能会很明确，但是会话部分不可应用，而且任何不通过信令通道来控制WebRTC的尝试都是不合实际的。在接下来的讨论中，我们倾向于将实现企业边界穿透的网络元素成为安全边界，所以我们就有了一个标签。下面有一些定义安全边界的方法。
检测ICE变换
有一类标准信令协议被定义为WebRTC的一部分可以用于建立媒体流。其被搭建于ICE协议中用于打洞。在所有媒体数据流之前，ICE在两个浏览器之间传播。安全边界可以探测到ICE变换开始穿过企业边界。这可以被用于定义WebRTC媒体流从随机数据流中穿过边界，允许策略执行。
另外，在ICE STUN中存在用户名/秘钥片段。通常来讲，这类信息是随机产生的。如果此信息是特定产生或者与企业验证系统有关联，安全边界会验证ICE变化并且因此产生媒体流。阐述如何进行这项工作的一个协议写在[10]中。在WebRTC中，ICE由浏览器执行。尽管JavaScript拥有用户名/秘钥片段的权限，目前在JavaScript中并没有一个标准的方式来设定这个媒体流的身份。可能将浏览器插入，被企业所使用并且设定其身份信息。
SRTP秘钥协商
另一个方法可以用SRTP秘钥伴随DTLS来验证媒体流。举个例子，如果DTLS-SRTP被用于秘钥管理，则安全边界则可以扮演中间人并且因此在指纹中生效公共秘钥。如果企业开发了PKI，则可以得到确认和生效。一种自签名确认也可以从浏览器上传，并且储存在企业秘钥服务器中。这将会允许安全边界验证企业内部浏览器以及提供相应的策略。但是，如果一些端到端的身份信息被应用于WebRTC当中，那么这个中间人方法看起来就会像一次攻击并会被侦测到而警告用户。
如果媒体被中间人所延迟，那么这也可以提供一个记录的场所。请注意，媒体流的环境将不可用。也就是说在媒体流远端的身份信息或者应用、网站，将不会被内部所认知。
图3 在DMZ中利用媒体中继的流来实现WebRTC中的媒体通道
媒体中继
另一种方法可以提供用于WebRTC媒体会话通过企业边界的媒体中继。对于媒体中继有一种标准协议，被称为TURN。ICE打洞起始于每个浏览器手机参与者地址：哪些可能在路由输入媒体包给浏览器有用的地址。典型的，这包含通过读取NIC或者用户设备所定义的私有IP地址，而公共IP地址呗STUN服务器的STUN响应数据包所定义。另外，一个TURN候选地址可以被用于当做最终地址。
企业防火墙可以用于阻挡非中继的WebRTC媒体流。企业可以在DMZ中开发一个TURN服务器，并且允许媒体流通过此服务器，就像图3所示。企业可以质疑用于TURN服务器的非个人信用。用户可以通过他们的TURN进入浏览器，可以使用它们获得TURN候选地址。在媒体流设定的期间，TURN服务器可以验证其用户，并且学习那些媒体流时基于所需带宽而设定的。这时有些策略则可以被应用于媒体流。
请注意，媒体流的确切环境还并不知道。这个方法也依赖于浏览器能够识别用户TURN的信任证书。在某些方面，这与识别网络代理很相像，被一些企业用来监管和控制网络浏览。
对于企业政策来说，TURN服务器同时也是一个用来记录的理想地点。同样的，没有了网页的合作，媒体流的环境不能被决定。既然媒体是被端到端加密的，浏览器或者网页应用需要共享加密秘钥来使媒体能够回放。
