作者：Tsahi Levent-Levi（原文链接）
翻译：刘通
原标题：Why Developing With WebRTC is Different than VoIP Development?
#5 带着你自己的信令
VoIP因为是标准化的所以相对简单。你需要使用一个信令协议。其他人在一些标准化组织的会议室中已经制定好了这些协议。这是为了保证你的信息安全，支持互通性的概念和模型，允许哪些提供商不可知论者进行部署工作。
WebRTC避免了上面所说的所有内容，而是创造性地选择了不包括某个特定的信令协议。当然会有人对这感到不满（主要是VoIP从事者）。我在4年前写过一遍文章，是关于信令的衰败的。
而WebRTC，你可以选择想用什么信令协议。你也可以选择使用像基于WebSocket的SIP，BOSH或者WebSocket的XMPP这种解决方案的标准；也可以使用只针对你服务中特殊场景的新做出来的信令协议；甚至可以使用已经在你app中有的任何东西来进行信令工作。
正如WebRTC的其他特点一样，没有规定信令协议也引发了一些问题：
1. 你是应该使用一个基于信令协议的标准还是一个个人标准呢？
2. 你是应该自己做呢，还是使用第三方框架？
3. 你是应该自己经营管理它，还是使用别人的现成服务？
所有这些问题现在都应该有了答案。
#6 加密和私密是强制的
在VoIP中，加密永远只是个选项，大家想用就用不想用就不用。
我想起来之前做互通性测试，几乎那些使用了安全性保障的设备都没有成功通过。为什么？因为没有人与其他人之间是很相似的。
虽然随着一年年过去事情也在发生转变，但是使用加密的概念并没变。VoIP产品寄给消费者并且部署的时候还是没有加密功能。加密是一个很多人都会选择跳过的可选配置。因为加密会让使用Wireshark进行网络分析变的困难，也会消耗CPU，还会让一些事情变得很复杂。
WebRTC又是完全不同的一种情况，强制进行一种加密配置。不可能用明文RTP，即便你非常非常的想用明文传输。就算你跟WebRTC标准组发誓说我的所有浏览器以及他们之间的所有连接都是在一个安全的网络中运行，也是不可能不加密的。没戏，不可能把安全保障从WebRTC中剔除出去。
#7 如果有什么新事物出现，WebRTC就会用它
当WebRTC刚刚面世的时候，它就使用的是最新的RFC。
可以将RTP和RTCP捆绑在同一个流上面吗？当然。
可以将音频和视频复用在同一个流上面吗？当然。
可以在RTCP上发送FIR指令而不使用信令吗？当然。
可以在DTLS-SRTP而不是SDES上协商密钥吗？当然。
还有很多其他的例子。
在很多示例中，WebRTC禁止其他更常见，更老的机制来做事情。
VoIP会经常提供选项。你在标准里面会有至少10种不同的方法来搞定一件事，而且都是可以接受的。
WebRTC只接受有意义的，然后抛弃掉其他所有的，最后使得标准变的很简洁。
VoIP和SIP对WebRTC来说永远都不会很重要。接受这个事实吧。
#8 身份管理和认证比较难应付
WebRTC中没有身份管理功能。
也没听说过有明确的认证模型。
下面是一个简单的例子：
SIP，你处理用户的方法是给他们用户名和密码。用户点击进入客户端，然后习惯登录到服务中。
普通应用中，将用户名/密码设置成为TURN凭证也很简单。但是要是想在一个浏览器中的WebRTC这么做的话就很头疼了，因为需要将这些信息都要附在TURN服务器上，花费你的经费。
所以替代方法是在TURN和WebRTC中使用临时密码。这篇文章中解释了应该如何做。
在很多其他情况中你只是单纯的不在乎这件事。如果用户已经登录进了网业，并且已经声明并认证了他自己的身份，那么为什么还要设一道额外的检查呢？你可以简单的附上一个像Facebook通讯录，Twitter，领英，或者Google账号来进一步的对他进行身份认证。
#9 做路由，不要把所有的东西都混在一起
如果你是从VoIP转来的，那么你就应该知道如果在一则通话中有多于两个参与方的话，你就要把媒体混起来。你通常会对音频这么做，但是对视频来说也是这样。这就是如何工作的。
但是对于WebRTC来说，你需要将媒体路由通过一个SFU。
从多个角度来说都是十分合理的：
1. 对于很多用例来说，这是唯一一个可以满足你商业模型的办法。它平衡了使用性和开销。
2. 这使很多开发者和研究人员都进入到了这个领域，改进媒体路由以及SFU相关技术，随着时间推移会越来越好。
3. 在WebRTC中，客户是属于服务器的—服务器发送给客户HTML/JS代码。除了增加获取多媒体流的灵活性以外，还给UI的外观带来了灵活性。
还是由抵触使用路由模型的。当这些人有VoIP经验的话，他们就会更倾向使用MCU的混合模型。部署MCU会比部署SFU多花10倍或者更多的时间。
如果你打算使用WebRTC的话，一定要确保你知道并了解SFU。
#10 SBC是没用的
或者至少不再是强制的了。
每个SBC供应商都在添加WebRTC。
我知道，如果你正在搭建一个SBC（会话边缘控制器Sesson Border Controller），那么你应该也确保它可以支持WebRTC，好让那些想要通过浏览器访问的人都可以得到它。
SBC是加在VoIP中一个非常讨厌的东西。它的功能是确保你的内部网络不会受到恶意VoIP接入的破坏。是VoIP流量的一个防火墙。
之后人们将处理互通性的功能也捆绑在SBC上，因为不同的提供商产品与其他供应商的产品永远不会完美互通。然后转码功能就加进来了，随后还有一些其他功能。
但是WebRTC不需要SBC。
VoIP需要SBC来处理WebRTC。但是如果你计划做一个基于WebRTC的应用并且不会涉及多少VoIP，你就可以跳过SBC这步了。
#11 生态系统是由API建成的而不是规范
这是一个需要额外提到的区别。
VoIP中的生态系统是围绕这网络协议组建的。
你要让人们明白网络协议的标准规范，然后才能做产品。
在WebRTC中，核心并不是网络协议（是的，协议是非常重要的）而是WebRTC API。你在浏览器中实现API，它会让你可以在上层搭建客户端。理论上来说对所有的浏览器来说应该都是可以运行的。
这是两者之间巨大的差别。
很多WebRTC开发者对于网络都一无所知，这是比较羞耻的。另一方面，很多VoIP开发者认为他们了解网络，但是也不清楚网络在VoIP和WebRTC中工作的细微差别。
