作者:Tsahi Levent-Levi(原文链接)
翻译:刘通
原标题:Why Developing With WebRTC is Different than VoIP Development?
让我从此处开始说起:
WebRTC是VoIP
但是在最重要的几个方面上WebRTC与VoIP有着区别:
1. 企业用它来实现点子的方式上
2. 开发者用它来做应用的方式上
为什么呢?
因为WebRTC适合在两个非常不同的领域中应用,而且都是在互联网上运行:网页和VoIP。
而且这两个领域的相交部分并不大。除了他们都是在IP上运行的,但是他们并没有很多的相似之处。
如果你之前在VoIP方面进行过任何开发,那么你就会知道通话是如何连接的。你的工作主要是响铃以及那些组成第五类软交换机的那些特性。事实上,这些知识在你进行WebRTC开发的时候经常会成为你的绊脚石。
下面是WebRTC开发和VoIP开发之间的10个主要区别:
#1 你不再有控制权
VoIP开发中,事情都很简单。所有解决方案都是你的。服务器,客户都是。当有什么东西不工作的时候,你只要过去,分析,修复相关的软件就可以了。
但是WebRTC不一样。你有的只有一个费心的东西,叫做“浏览器”。它们有4种。
并且它们会经常更新,经常发生改变。
下图展示了去年Chrome和Firefox的版本更新时间。
每个版本会持续6到8周。
这些版本更迭它们都有可能会改变那些会牵扯到WebRTC表现的东西。这些改变很有可能会导致你的服务出现一些不法预料的错误。
这些改变意味着:
1. 你对运行你服务的软件不具备完全的控制权
2. 你无法控制你的一部分部署进行更新(浏览器更不更新可不会听你的)
VoIP可不是这样。你进行开发,整合,部署,然后由你自己决定是什么时候更新或者进行改变。在开发WebRTC的时候就不行了。
你必须针对未来的浏览器版本不断的进行测试。你需要能够方便快捷的更新你的产品服务,而且要做好经常进行这套工作的准备。
#2 JavaScript是王道
我之前是一个VoIP开发人员。我之前进行过开发,项目管理,产品管理,然后还做了CTO,我们做的产品是在多种通信产品中使用的VoIP软件SDK。
说真的,我是一个很棒的开发人员。至少是在C语言编程上。VoIP就是用C/C++和Java进行开发的。
JavaScript呢,我只是了解,但是根本达不到一般开发者的地步。我猜很多VoIP工程师的背景都和我差不多。
WebRTC完全是JavaScript的天下。
是的。WebRTC有一个JavaScript API。但这并不是全部。很多为了使用WebRTC所写的后端系统到最后都会使用Node.js,而它用的是JavaScript。
WebRTC并不止仅限于JavaScript。有很多系统是用C,Java,Python,C#,Erlang,Dart,甚至PHP所写。也有.Net的系统。在移动端,原生软件在其客户端WebRTC SDK实现中使用的是Objective-C,Swift或者Java。
但是最主要的是JavaScript。
我认为用JavaScript的原因主要有三:
1. 潮流。Node.js十分新潮。WebRTC也是个新兴的技术,所以它们很般配。
2. 异步。WebRTC中的信令需要是交互式的。它需要有一个后端,以可以很好的适用于它的异步交互模型。Node.js提供了这个功能,而且可以同时在前端和后端进行信令更简化一点。这也带来了第三个,有可能是最重要的一个原因—
3. JavaScript。你在前端和后端都要使用JavaScript。对于开发人员来说,在两端都能使用同样一种语言会方便很多。如果需要的话,想要把代码的一部分从一端移到另一端也会变的更简单。
#3 一个大岛
VoIP主要是关于互联互通性。如果你从一个供应商那里买了一个手机,那么你就“应该”可以给通过另一个供应商的PBX给第三个供应商的手机打电话。确实可以做到,至少是有时可以做到。而且需要在互通性下很大的功夫来进行测试和调试。一个很大的工程。
VoIP以及互通性对于岛的概念深恶痛绝。不同的通信服务之间无法进行连接。
WebRTC则不同。你不再需要为了与其他供应商的VoIP设备进行通信而搭建一个VoIP产品或者设备。你要搭建整个事情。
WebRTC也是一个岛,只不过非常大而已。在这个“岛”上,你可以通过所有浏览器,操作系统,以及移动设备来提供权限。
你不再需要考虑与其他提供商的互通性—只需要考虑你的设备与你所依赖的浏览器之间的互通性。在某种方面简化了事情。
#4 云
看起来VoIP总是要在本地部署上运行。虽然有全球部署的例子,但是不是很多。通常需要考虑地理问题。
这可能是与VoIP的本质捆绑在一起的—因为VoIP就是你之前所用的电话网的替代品/电子版。这与现在世界比过去“更大”了也有关系—云这个概念在过去并不存在。
WebRTC有更大的挑战以及更多的要求。
对于绝大部分,以及大多数WebRTC部署,有三件事情是显而易见的:
1. 部署是全球性的。你永远都不知道用户会从哪里加入会话。
2. 网络是不可管理的。与上面一点很相似。你对于网络没有任何控制能力,但是你的用户还是会对通话质量产生抱怨。
3. 我们在AWS上部署他们、所有时间运行、在虚拟机上、在Docker容器中、一层层的抽取。对于实时服务来说,看起来是可行的。