WebRTC Data Channel在它的“苦苦寻觅”之下，终于在context中找到了它的用武之地。
自从WebRTC被推出以来，很多技术人员就一直在紧密观察data channel，期待着看到开发者最终会与它擦出什么火花。虽然从这其中发生了很多有趣的使用案例，但从大体来讲，决定WebRTC何去何从还为时尚早。在过去的几个星期里，尽管我们已经看到了越来越多的证据表明：WebRTC Data Channel被调用还尚有“用武之地”，比想象得要多得多。这个“用武之地”是针对于音频或者视频呼叫来添加context。
那这些怀疑由何而生？
请看以下图表，通过调用WebRTC来描绘一个简易的联络中心：
当我们有一个客户和一个代理商（agent）进行互动时，差不多总是有两台服务器牵涉其中：
1.Web服务器，能使两个浏览器构成连接。它对于我们来说充当着信令服务器的角色，在它的传输中使用HTTP 或者 Websockets；
2.媒体服务器，可以作为一个会话边界控制器（SBC），连接双方或者仅仅是一个媒体服务器，可以处理呼叫等待队列、录制呼叫等等任务。
这里的逻辑是：与web服务器的连接足以提供context，（那么为什么根本就没有必要在这里开发一个data channel呢？尽管由于各种原因，我仍旧看到很多证据表明，比如在这样一些场景中，调用data channel以通过context），（事实是）在服务器端终止了它（data channel），在浏览器之间并不直接走它（data channel）的通道。
这是为什么呢？为什么不投入到另一个连接中去呢？
第一个原因：延迟性
如果你真的需要从一个浏览器连到另一个浏览器，那么为什么要弄出“多余的一条腿”来通过信令服务器呢？
直接的方式可以减少延迟性，然而这对于某个特定问题来讲不算什么，在有应用案例的情况下，这将会变得重要。当我们正经过的Context类型与协作性相关时，（诸如共享鼠标移动或者白板之类的动作）我们就想要尽快使它共享。
第二个原因：防火墙
对于data类型来讲，我们可能不想通过信令服务器，我们希冀以context的形式分享。假设我们把它当做一个案例来看，那么，因为context的原因，将另一个独立服务器处理Websocket连接的能力打破可能会有些繁琐。将WebRTC data channel 作为点对点连接对象（the peer connection object）的一部分，在同一时间创建和拆除将会变得易于管理。
在NAT（网络地址转换）和防火墙转换机制中它也被在合适位置构建了。因此如果呼叫正经过时，然后就是context的事了，无需为这个呼叫部署、配置和测试另一个系统。
第三个原因：不对等性，非对称性
有时，并不是都要使用WebRTC。代理商也可以在一通PSTN电话上，在他的监视器上看着客户关系管理（CRM）的屏幕，或者无论从哪里接到呼叫了，都可以将会话的网关植入一个SIP网络中。
在这种情况下，媒体服务器将是一个网关（gateway）——它是一个将信令和媒体从一端传输转换到另一端的转换设备，它将桥接两个世界，它将两个世界连接起来。如果我们把其分隔，并将我们的context置入一个独立WebSocket，那么我们将会有不止一个服务器和不止一个协议来处理网关（gateway）和传输转换（translate）的事宜。在网关中全盘照搬如上事宜时，网关（gateway）已经处理好了媒体流的传输转换（translate），这对于很多应用案例来讲，意义匪浅。
第四个原因：加载管理，负荷管理
Web服务器是处理信令吗？你需要通过Web服务器以管理系统中的所有会话。它可能将处理所有文本类聊天、主动呼叫、在IVR队列中等待的来电等等。
假设我们不得不经过的context只是一些登录信息和一个URL网址，那么这构不成问题。但是，如果我们需要做一些传输之类的事情，例如屏幕截图、传输图像或文件之类的东西，该怎么办呢？这些吃了带宽堵塞服务器需要处理其他的事情。尝试性的缩放和负载平衡服务器与工作负载不统一是相较于缩放统一工作负载更难。
第五个原因：因为我们可以
让我们来面对这一事实吧——WebRTC是一个“崭新的玩具”。在WebRTC中的data channel是我们手中“闪亮亮的把玩之物”。为什么不好好利用它呢？开发者们都喜欢“闪亮亮的新玩具”……
“谦逊的”WebRTC Data Channel
data channel问世时间和WebRTC一样长，但它却没有得到同等的青睐和关注。现如今对于它的应用非常之少。通过context会话区，Data Channel所找到的新归属将会是非常有趣的开发实例。
