谁也没想到一场疫情让Zoom在短短两个月内市值翻了一倍，而更没想到仅仅在一周内，因为安全问题引发的舆情让CEO袁征频繁出面道歉，股价又从最高点重挫近30%。
前有Marc Benioff离开老东家Oracle Siebel创立了Salesforce，后有袁征离开Cisco Webex创立了正处于“冰与火”之中的Zoom。
回顾视频会议技术的发展史，不得不让人惊叹于历史的相似与轮回。
2003年同样是一场我们熟知的非典疫情，成就了一家现在已被大多数人忘却的远程会议方案公司——Polycom（宝利通）；
2020年这场可能连病源都与十七年前相似的灾难，再一次成就了以Zoom为代表的新一代视频会议技术公司。
再过十几年，我们还会看到Zoom吗？
想起巴菲特常说的一句话：
“我只想知道将来我会死在什么地方，这样我就不去那儿了”。
在下文里，我将用三条小学公式诠释视频会议技术的更迭；再通过三家代表性公司解析商业背后的成败。
只有借前车之鉴，才能解锁Zoom之未来。
视频会议的鼻祖：视频电话
关键词：一对一、编解码、协议标准
视频电话，更准确地说是“一对一”视频通话。
让我们回到上世纪30年代——1930年，一款叫做“Iconophone”的双向可视电话原型机诞生于著名的贝尔实验室，“双向连通”奠定了这种“图像式电话”走向商用的基础。
而视频电话真正得到普及是在上世纪90年代，为什么呢？我们先了解一下打一通视频电话需要的设备：
输入设备：摄像头、麦克风；
输出设备：从可视电话到后来的专用设备、PC等；
数据网络：电话拨号专用网、卫星线路、LAN（局域网）或广域网等；
计算设备：通信协议解析、数字信号编解码处理等。
整个过程如下图，记住里面的五组词你也可以在朋友圈装装极客了！
首先，传输过程中最关键的是数据传输的实时性，一般来说发生超过300毫秒以上的延迟，用户就会明显感到图像模糊或卡顿等现象。
其次，由于视频电话包含了声音和图像，在传输时两种信号必须同时打包处理，以保证两者的同步性。
而视频电话能真正传播开来是因为具备了以下三个条件：
数字图像及高效的编解码技术（俗称“打包工具”）：将压缩比提升到1:500以上；
终端通信协议终于达成国际统一标准：以前终端的编码器必须来自同一厂商，现在基于一套国际标准即可实现不同设备和系统间互通；
网络基础设施和集成电路的飞速发展：在这个诞生了雅虎、亚马逊、eBay的年代，不管是网络传输设备还是CPU处理能力都得到显著提升，带宽成本也快速下降。
从用户角度，当时对音视频的质量要求并不高，因为那时候通话设备本身清晰度就比较低。
也是在这个互联网的黄金时代，一系列视频会议技术公司相继成立。老规矩，先上时间轴。
前前后后二十年时间，见证了第一代技术和商业的更迭：
首先，牢记视频会议技术的“四大才子”——Polycom、Radvison、Tandberg和Webex；
Webex与前三家技术路线不同，早期产品经过几次调整，最终通过提供基于微软NetMeeting的企业级视频会议方案而成功上市；
最终，“四大才子”都以被并购或退市收场，只是收场时的姿态各异；
如今又过了快十年，Cisco、Avaya和微软等当年的巨头，现在似乎又遭遇了新一代技术公司的挑战。
我们走进90年代。
视频会议1.0：从电话到网络会议
关键词：多对多、MCU、Polycom、木桶效应
如果一通电话是“一对一”，一场会议则是“多对多”，而一套视频网络会议方案就是要管理N个并行的多对多视频会话。
刚开始用得起视频会议的都是不差钱的金主，如银行、运营商或政府机构，一般小企业打个电话就行了。在金主面前，各家公司比拼的都是使用体验和设备性能，例如：
是否支持高清图像，背后包含编解码、降噪处理等技术；
支持多少方同时加入并保证相同体验；
主持人邀请、点名等会议管理功能。
最后为了将体验做到极致，业界引入了一种新的设备叫MCU(Multipoint Control Unit，多点控制单元)。
我们可以把MCU理解成一台多媒体信息（后称“媒体流”）交换机，信息包括但不限于声音、图像和文本等数据。主要职责为：
媒体流的信号处理及编解码；
并行多对多的线路切换、路径管理；
还需具备数据加密、稳定传输等功能。
如上图这个例子，A、B、C参加视频会议，
首先，A、B和C必须将自己的媒体流全部传给MCU；
MCU把收到的音视频包根据相关格式协议进行分解；
然后根据各方请求，MCU将音视频分别合成并打包；
最后由MCU传送给终端，整个过程称之为“混音混屏”。
公式一：视频会议1.0= 视频终端 +MCU，其中MCU=CPU+ 固化算法。
图中是这次G20欧盟分会场，这位大佬除了能看到全体参会人员的集合画面，还增加了一个只显示自己的屏幕，也就是前面例子中C这个场景。MCU确保参会者和线上会议室的对应关系，也就是路径管理。
视频会议1.0时代就是建立在以MCU硬件为基础的中心化处理架构上。
但是，这里便出现一个问题：中心化处理的优点是保证了所有参会者体验的一致性。但这就要求所有终端的性能和网速都要保持在一个水准，否则就会极大影响体验，因为混合的过程受制于音画质最差的那个终端，也就是“木桶效应”。
所以，当时为了满足高清、超高清到网真级别（即1080P）的画质，终端设备都走上了定制和专业化，同时相应的编解码器也被集成到终端上，最终各公司都推出了价格昂贵的端到端专业视频会议方案（Dedicated video conferencing solution）。
公式二：专业视频会议方案 = 专业设备 +MCU+ 专用网络。
谈到这就不得不重点说说90年代的第一大才子，而后却被两次“贱卖”的Polycom。
Polycom成立于1990年，曾经也是加州车库初创公司的代表。最早从电话会议系统起步，1996年成功登陆纳斯达克，十年后2007年全年营收突破10亿美金，其中整个会议系统产品占当时全球市场份额达到惊人的60%。
而让Polycom彻底打开中国市场，就是因为2003年的那场疫情危机——SARS非典。
根据2015年哈佛商业评论对当时时任Polycom大中华区总裁李钢的采访：
“2003年‘非典’疫情席卷中国，给中国医疗系统带来前所未有的挑战。最急迫的问题是，许多医疗机构分散在全国的疫苗中心和研究所，人员无法出差，因为一旦出差就要被隔离。医疗机构的远程携作需求瞬间爆发，而远程携作正是Polycom视频通讯的核心业务，包括流调系统、专家系统和政府指挥系统在内的三大系统都使用了Polycom的视频通讯技术。
当时除了Polycom之外，还有几家国内外厂商包括华为、中兴、Tandberg以及Radvision也在竞争这个机会。”（是不是都是熟悉的名字？）
神州数码是当时Polycom中国区的总代，在2005年一次对神码企业系统事业部应用网络部总经理的采访中得知，“非典”期间一个季度的销售额就比往年全年的销售额还多。据悉Polycom当年在中国的销售额同比增长达70%。
同期受益的是整个远程会议市场，2003年也成为了中国视频会议市场的“元年”。
总之，Polycom在初期通过不断基础研发和大手笔并购，掌握了音视频编解码、回声抑制等方面的核心IP。在网络环境有保证的情况下，视频会议的效果达到业界顶尖。
然而在2016年，加拿大移动通信公司Mitel宣布以19.6亿现金和股票收购Polycom，Mitel当时的市值甚至略低于Polycom，此番“小鱼吞大鱼”的戏码让市场一片哗然。
同年在中国，身为当时全球副总裁兼中国区总经理的袁文辉，与中国研发技术中心的早期成员也离开老东家，创立了小鱼易连。他们号称“摒弃传统视频会议厂家的专线专网”，采用云视频技术，保证与专线相似的音视频体验。
两年后，耳机制造商Plantronics宣布以20亿美金再次收购Polycom，一大才子短短时间内竟被两次倒卖！
可见2016年的并购退市事件成为了Polycom由盛转衰的标志。
（来源：IDC）
在2018年IDC发表的“全球企业级视频会议供应商评估报告（《IDC MarketScape：Worldwide Enterprise Videoconferencing 2018 Vendor Assessment》）”里也能看到，Cisco和微软（通过收购Skype）牢牢占据了领先者象限，Polycom已退居二线。
同时在主流玩家（Major players）象限中，新一代技术公司早已出现，加速了Polycom的衰退，有一家我们必须记住——Vidyo。
了解Vidyo的兴，也就明白了Polycom的衰。
视频会议2.0：从中心化到分布式
关键词：路由器、SVC、Vidyo、分布式
专业视频会议方案固然性能好、效果佳，但部署一套方案的成本也居高不下，这不仅把许多中小企业挡在门外，还大大损害了客户采购终端设备的灵活性 。
这时一名以色列人看到了商机，他曾是上文提到的Radvision初创团队的骨干，2004年从Radvision辞职后，次年成立了Vidyo。
Vidyo采用了一个全新架构，去掉昂贵的MCU，摆脱之前方案对专业设备和专网的依赖，将视频会议技术带入2.0分布式时代：
公式三：视频会议2.0= 各类设备 + 路由器 + 公共网络（即互联网）。
这个架构带来了一个重要变革：将过去对媒体流的中心化处理变为分布式传输：
首先，终端上实现所有编解码：由于摩尔定律带来计算能力的提升，编解码已能通过软件形式安装在终端，由终端的通用CPU统一处理；
其次，路由器实现路径管理：普通路由器的功能就是读取数据包中的地址然后决定如何送到下个目的地，这里就变成读取媒体流中的基本信息如目的地IP地址后建立点对点连接。
例如A、B、C开会，路由器把B和C的地址告诉A，让A直接通过公网把媒体流打包好后送至B和C，不再需要经过昂贵的MCU了；
最后，SVC编码技术实现音画质自适应：前面讲过，由于中心化架构和“木桶效应，音画质效果在不稳定的网络环境下无法得到保障。这时候，Vidyo首次将一个全新的视频压缩标准应用到了网络传输上——SVC（Scalable Video Coding, 可伸缩视频编码）。
该技术将音视频信号分成“基本层和多个高解析层”进行分层编码：当带宽不足时，只对基本层的信号流进行传输和解码，这时解码后的视频质量尽管不高，但对简单终端如手机的屏幕来说已经适用；当带宽变大时，就可以解码高解析层来提高视频质量。
（来源：Vidyo、bloggeek.me）
回到A、B、C开会的例子，假设A的网络情况不好，B和C相对较好，会议依然正常启动。
首先，ABC都向路由器发送会议基本信息；
路由器收到消息后，分别通知A、B、C和自己开会的对象以及对方的IP地址；
然后ABC之间直接基于SVC建立连接，媒体流的速率则根据终端配置不同进行自适应；
最后，每个终端会收到三个媒体流，通过自带软件进行解码和还原。
结果就是，网络状况较好的B和C自行建连接，还原出较好的音画质，并不受到A端网络质量的影响。但B和C看A的画面，就会比较模糊。
回想一下，我们现在用钉钉的时候（为什么钉钉“躺枪”，留个伏笔），会经常出现对某个参与者说“你的画面不清晰，会卡顿，要不你重新连接一下”诸如此类的情况。
就这样，分布式路由与SVC技术的结合破解了“木桶效应”问题。名声大噪的Vidyo也自此走上融资的快车道。
（来源：公开信息整理）
Vidyo的产品形态主要有三类：
VidyoConnect/Vidyo Cloud：面向大型客户提供专业视频会议系统，如金融、医疗、政府等领域，对标Cisco。云视频服务商兴起后转向云端发展，对标Zoom；
VidyoEngage：面向呼叫中心提供低成本的嵌入式视频会议方案，对标Avaya的呼叫中心系统；
Vidyo.io：这是Vidyo最特别的产品，面向开发者提供技术支持如SDK开发包，以便第三方二次开发并部署到其他应用或终端上。
伏笔揭晓，2016年4月，求小学生手下留情的“钉钉”便宣布与Vidyo建立深度合作，成为钉钉嵌入式高清画质和点击入会的视频会议合作伙伴，即向钉钉开放SDK。小米手机也是Vidyo的客户。
（来源：Vidyo、bloggeek.me）
然而细心看前面的融资历史，你们可能已经发现了，在成立十四年后，Vidyo依然逃不过被收购的命运。并且按照被收购的对价和之前的融资金额，肯定又是一次跟Polycom相似的“贱卖”。
Polycom和Vidyo，同样拥有核心技术却最后黯淡退场的背后到底是什么原因？让我先把技术发展史讲完。
随着2006年SVC技术和分布式架构的出现，同年亚马逊推出了举世瞩目的AWS（亚马逊云服务），将路由器功能搬到云端并取代高成本的本地部署，就是自然而然的事情了。
Webex在刚开始推出的并不是完整的多方视频会议方案，而是“Webinar（网络讲座）”。主要形式为一个主持人主讲并可以共享屏幕，其他参与者之间几乎无互动，也就是基本没有媒体流的传输。
在2007年被Cisco收购后，Webex也推出了云视频会议方案。但由于产品线之间的竞争，而高端设备一直是Cisco的主要利润来源，因此多数时候Webex只能成为传统远程会议系统的“云补充”。
在服务了千家企业后，一位Webex的资深工程师发现“没有一家客户对Webex的产品满意”，而老东家也无心投入到一个新方案的开发上。于是在2011年，这位工程师带着四十五位来自原Webex团队的兄弟，成立了一家新公司，叫SaaSbee，用他的原话说，
“既然Cisco不肯做，这就是最好的时机由我来解决。”
一年后SaaSbee改名为Zoom，再之后的故事就被大家熟知了。
（视频会议技术更迭的四个时期）
前车之鉴，后事之师
关键词：木桶效应、PMF、利基市场
回顾历史的多次重演，让我首先对过去由兴转衰的公司展开了反思。
为什么Polycom会衰落？
我认为有两个层面：
技术层面，简单把MCU设备“软件化”或搬上云，本质上并没有改变“中心化”网络架构，因而无法解决“木桶效应”问题。
这不仅对于Polycom，还包括Cisco、华为在内的传统方案厂商来说，都是巨大的挑战。而Cisco之所以仍能保持竞争力，是由多方面因素支撑的。
首先，远程会议业务收入占Cisco整体营收不到10%，不构成重要影响；其次，在金融和政府等领域各业务线间能共享客户和渠道资源；最后，Webex在被收购后，尽管沦为“云补充”，但仍能凭借Cisco的品牌和服务在中小企业抢夺一定份额，对Zoom形成压制。
反过来看，在一些专业或特殊场合，如这次的G20会谈，同步性和音画质依然是用户的首选，而不是价格。这时候中心化网络架构就是基础，而在这些市场里Cisco和Polycom仍占据重要位置，只是后者已然失去了当年的风光。
（来源：Synergy Research）
商业层面，既然在技术上没有革命性改变，就无法从商业角度服务“长尾”客户，也就决定了产品的PMF（Product-market fit，产品/市场契合点）是失败的。
Polycom在后期尝试通过与微软等软件厂商合作，向中小企业售卖一套软硬组合方案。很显然，这跟Zoom等SaaS厂商相比，没有任何吸引力。
展开一下，当年投资者看到SaaS鼻祖Salesforce的价值，本质在于以年付费的订阅模式给企业创造了一笔省心省力的“递延收入（Deferred revenue）”，大大提高了当年收入的确定性。
而SaaS进入以Zoom和Slack为首的“自助（Self-serve）时代”，在更灵活的收费模式下，留存和增购成为了更核心的指标，根本原因来自个人软件的网络效应以及员工对企业IT采购的影响力提升。
因此，必须先确定你的客户和他们的痛点，再去定义产品。至于以什么形式来提供，是由时代背景和许多不同因素所决定的。
更关键的是，真正面对“危机”，传统企业有没有革自己命的决心？
为什么Vidyo会失败？
第一个教训：找到你的利基市场。利基市场指的是在较大的市场中具有相似需求的一小群客户及占有的市场空间，例如亚马逊刚开始选择的图书市场。Vidyo一开始不是没有聚焦，但选择的是与传统厂商相似的金融和医疗市场，主打对多种高清和普通终端设备的兼容性。
这是一个高风险的策略，因为对于大型客户而言，最终选择一个供应商背后的因素非常复杂，而价格绝对不是首选，安全、口碑和服务都排在前面，那么对于初创公司来说，顶级的技术或许能带你入门，却不一定能带你上道。
其次，以API、SDK等形式做技术支持而不提供端到端解决方案，对于技术型初创公司来说，需要非常慎重，很可能是一种讨巧却无法形成足够壁垒的战术失败。这里的确有例外，有机会我们再详细讨论。
最终，仓促上线的多产品线又导致在竞争上腹背受敌，只能靠不断融资续命。
第二个教训：选择最优的商业模式。“作嫁衣裳”的产品思路我向来认为需要十分谨慎。这件事情不是不能做，如果你是Google，当年开源实时通信项目WebRTC（我们常用的QQ、Skype等一对一通话都采用了这个技术），意在让更多开发者能够直接在浏览器中创建视频或语音聊天，免费的背后依旧带着强烈的商业目的。
尤其对于拥有创新技术的软件公司来说，真正的商业价值仍在于能否解决客户的一揽子问题。这让我想到了SaaS模式对于开源商业化的意义，重要的并不是第一个“S（Software，软件）”，而是第二个“S（Service，服务）”。
如果你还在犹豫甚至尝试同时发力多条产品线，那不妨先思考第一个问题：如何先“打透”利基市场。
总之，如果Polycom的衰落是在PMF出现了偏差，那么Vidyo则是太执着于Technology-product fit（技术与产品匹配），而完全忽略了商业的本质和战略。
Zoom的危机与野心
关键词：安全、端到端、远程会议、开源
要解析Zoom的未来，不妨先了解它所面对的危机。
在近期Citizen Lab和华盛顿邮报相继爆出产品存在重要安全漏洞后，Zoom官方承认了在应对近几周流量激增的时候，平台“错误地”让两个在中国的数据中心接受了在非中国区的“通话（Accept calls）”，作为网络拥堵时的备选。CEO袁征随后解释道：
“在正常情况下，Zoom的客户端会优先向附近的首级数据中心发送请求，如果因为网络拥挤导致多次请求失败，客户端会再连接两个二级数据中心。在任何情况下，Zoom的客户端都只会与本地区内合适的数据中心进行连接。”
然而事实并不是这样，Zoom确实犯了一个错误。
但是，当我们回看公式三（视频会议2.0= 各类设备 + 路由器 + 公共网络），便会发现这几件事：
向数据中心传输的只是会议基本信息，不包含用户的视频等敏感信息。“上云”只是将路径和参会者信息上传到云端服务器或IDC（数据中心）上进行处理，真正的媒体流仍在公网上进行点对点传输，再由终端设备进行编解码。
众所周知，公网环境和云服务器通常是不受Zoom管控的。当然这并不能说明Zoom没有责任提醒用户并做相关保护性措施；
Zoom所面对的安全性问题实际上是无可避免的，要做到外界期望的“端到端”加密是一次关于技术、投入回报和舆论的博弈。
根据Zoom在4月1号官方博客上的解释，目前做法是对每段传输的内容进行加密，而密钥管理在云端，因此引发了外界对相关风险敞口的推测。
而给出的解决方案是用户可以选择将密钥管理部署在本地，这确实是当下相对合理的办法，但多余的成本自然由用户买单。
所以说到底，这背后是经济账。就像袁征说的那样，Zoom从一开始就不是为个人通信设计的，而是用于团队远程会议与协同。个人通信应用WhatsApp就使用的是端到端加密，但只能最多支持四方视频聊天。
但是，Zoom却在网站和营销材料上宣称产品使用了“端到端加密”，所以第二个争议点就落在了诚信问题上。这个问题可大可小，放在中概股连续爆雷的当下，难免会挑动更多人的神经。
在我看来，真正的解决方案不是不断添加补丁，而是从产品线源头推出全新解决方案。其实在上市前后，Zoom就祭出了两大杀手锏：
面向大型企业和政府的Zoom Meeting：通过一个连接器（Connector）将Cisco、Polycom等传统设备整合进Zoom平台，与其他使用Zoom客户端的用户打通，因此连接器的功能包含了解析并整合不同通信协议、加密等功能；
面向传统交换机业务的Zoom Phone：将电话会议系统整合进统一通信（Unified communication）业务中，主要是为那些想要在无法视频的情况下用电话接入的用户设计。你可以从最近的财报电话会上听出袁征对统一通信业务的期望。
这宣告了Zoom全面进军整个企业级远程会议市场。
杀回老东家Cisco的大本营，不再局限于视频会议。毕竟在这个金融和政府客户收入贡献占近一半的市场，Zoom要持续仰攻并不容易。
再回看Vidyo，两家公司的技术路线和产品看似殊途同归，但结局却大相径庭，实在让人唏嘘。
最后，对Zoom来说接下来要解决的远不止安全问题。
仍然拿这次G20会议举例，在如此高规格的场合下，除了极高的安全和保密性外，音画质和稳定性依旧是关键。
技术上主要包括：能否适配不同类型的高清视频设备，以及能稳定地支撑多少方的网真级别会议，毕竟“川建国”的任何一个微表情都可能被其他国家元首所津津乐道。
其次，从商业角度，Polycom当年在中国的成功靠的是慷慨与代理商一起“分蛋糕”的销售体系。而Zoom的核心产品本身非常标准且价格透明，留给代理商的“肉”并不多。
这也是新一代自助模式下SaaS厂商的困境，我们会看到Zoom在财报中一直强调收入贡献超过10万美金客户的数量和比例。
因此，Meeting和Phone系列便试图通过对传统设备的向前兼容，留给集成商一块蛋糕。包括后来的“App Marketplace（应用商店）”也是寄希望让公司从会议管理平台升级为一个协同办公平台，然而生态建立的实际效果仍需要时间来验证。
在3月30号面对福布斯的专访，袁征说如果未来不能把Zoom打造成“全世界最安全的平台”，那么他愿意“把Zoom开源，与其他人一起尝试”。
我认为这绝不只是出于公关和安抚舆论的目的。在近三个月收获了1.9亿用户后，Zoom的确被迫进入了一个“完全不同的赛场（Different game）”，所幸Vidyo的前车之鉴及庞大的用户基础都可以成为袁征在做战略选择时的底气。
不过，企业级客户的需求总是复杂的，而安全性是相对的。有时候“开后门”反而是一种“安全”措施，你们细品。
不管怎么说，如果真的到了Zoom已经不再属于公司本身，而是“属于全世界”的那天，也许我们会习惯一种新的说法：
“Let’s Zoom！（让我们Zoom一下！）”。
参考资料：
视频会议系统百年发展史：https://www.sohu.com/a/322143513_100255873
Polycom:本土化要规则更要情谊：http://software.it168.com/a2015/1020/1769/000001769929.shtml
视频市场需要繁荣，但更需要“冷静”：http://money.163.com/economy2003/editor_2003/040920/040920_230850.html
Vidyo百度百科及Wiki：https://baike.baidu.com/item/vidyo/9835126?fr=aladdin
《揭秘中美传统视频会议发展“制造之路”，打开中国云视频创造“崛起之门”》国泰君安证券2019.05.05
Vidyo.io and Differentiating in the Brave New CPaaS World：https://bloggeek.me/vidyo-iodifferentiating-cpaas/?nsukey=dtGbRiB6cJydv5kai%2FE9lI5Yf8z6ibigeH5CSSycTDSMUMh%2BKjAiYxdshNUAiuPZldUMjfbO5D4kXxmhghdlPnpY%2FE7z4gMqkkLMh%2BujJoPIIo9yGEOWdXfdexZ69yb3f0H0EHYMEmQix2u%2FRi%2BgBPjY%2FcoqFvc6zvIiw4OV0bu3lKVpTKRARWOgukIC93f6yhPqHcmqElJRiMniiBMJgw%3D%3D
Maybe we shouldn’t use Zoom after all：https://techcrunch.com/2020/03/31/zoom-at-your-own-risk/
The Facts Around Zoom and Encryption for Meetings/Webinars：https://blog.zoom.us/wordpress/2020/04/01/facts-around-zoom-encryption-for-meetings-webinars/
