网络会议三十年 · 第三章 · 协议的战争

真正的赢家，往往不是那张写得最厚的标准书，而是那个在标准书还没写完时，就用它做出产品的人。

一

1990 年代初的日内瓦，每隔几个月就会有一群穿着深色西装的工程师，从世界各地飞到莱蒙湖畔的一栋灰色大楼里。

那是国际电信联盟（International Telecommunication Union，ITU）的总部。它创立于 1865 年，比电话的发明还早十一年——最初是为了让欧洲各国的电报线能彼此互通而设。在 ITU 的玻璃门后面，挂着一面由各国国旗组成的墙。每一份标准草案，都要在成员、运营商、设备商和专家之间来回打磨，直到足够多的人愿意接受它。

那些标准是这样诞生的：

某一个国家的代表团（通常背后是 AT&T、NTT、德国电信这样的国有运营商）提出一份提案； 另一国的代表团（通常背后是另一家国有运营商）提出反对； 经过几个月的讨论，提案被修订成第二版； 第二版再争论几个月，进入第三版； 第三版被分发给一个叫 "Study Group" 的工作组，再争论一年； 最终，几年之后，一份带着编号的薄薄文件被印出来，盖上 ITU 的红色印章——

那是一份标准。

它的名字一般以一个字母加一个数字开头，比如：H.261、H.320、T.120。

字母代表领域：H 大致属于"视听与多媒体系统"，T 大致属于"远程信息处理终端和协议"。

数字代表序号。

整个 1990 年代，关于视频会议的许多商业战争、技术战争、地缘战争、专利战争——背后都绕不开这几个字母和数字。

二

第一份重要的视频会议标准是 H.261。

它最早在 1988 年形成，1990 年补齐互通所需的关键部分，后来又在 1993 年修订。它是第一批真正实用的数字视频压缩标准之一。它想解决的，其实是一个很朴素的问题：¹

当年的网络带宽窄得可怜，怎么才能把一段活动的画面，塞进那条细细的电话线里传出去？

一段没有压缩的视频，数据量大得吓人，根本进不了当年的网络。H.261 的办法，说穿了是两招：一是"只记变化的部分"——如果画面里大半没动，就没必要一帧一帧地重复传；二是"抓大放小"——人眼看不太出来的细节，就狠心扔掉。这两招，是一群工程师在多年争论之后，围绕当时的窄带网络、低延迟和互通需求妥协出来的产物。

它的影响巨大，因为后来的许多视频压缩标准——H.263、H.264、H.265，一直到今天手机和视频网站里用的编码——都在不同程度上沿用了它的这套基本思路。你今天在手机上看到的每一段流畅视频，血脉里都还流着 H.261 的血。

H.261 是这场战争的第一块砖。

三

光有 H.261 还不够。

H.261 只解决了"视频流怎么压缩"这一件事。但一场视频会议需要解决十几件事：

• 怎么发起呼叫？
• 怎么协商双方的能力？（你支持 CIF，我只支持 QCIF）
• 怎么传音频？
• 怎么传数据（比如共享文档）？
• 怎么处理三方以上的会议？
• 怎么挂断？

ITU 的答案是一整套标准簇，统称 H.32x 系列。

每一个 H.32x，对应一种网络环境：

这是一张精心设计的"分网络环境"地图。在 ITU 那栋大楼里的工程师们眼中，不同网络条件下的实时通信，需要不同的系统建议。²

但后来的趋势很快变得清楚：这张地图上的许多网络会逐渐退到边缘，只有一种网络会不断扩张。

那就是 H.323 那一行——IP 网。

四

H.323 在 1996 年发布时，是 ITU 给分组网络的一套完整多媒体通信方案。第一版标题强调的是"无服务质量保证的局域网"，后来很快被产业界拿去跑在更广泛的 IP 网络上。³

它本意是说："好，分组网络你们也搞起来了，那我们给你们一个能在这种网络上跑音视频会议的标准。"

H.323 的设计非常全面——全面到笨重。它像在搭一整套电话交换局：除了打电话的双方，还专门设了一个"总机"负责登记和调度，一个"调音台"负责把多方的声音画面拼在一起，还有一个"转接柜台"专门跟老式电话网打交道。

graph TB
    A[终端 A<br/>打电话的人] --- GK
    B[终端 B<br/>打电话的人] --- GK
    GK[总机 Gatekeeper<br/>登记 · 计费 · 调度] --- MCU
    MCU[调音台 MCU<br/>三人以上会议的混音混流]
    GW[转接柜台 Gateway<br/>连接老式电话网]
    GK --- GW

    classDef box fill:#f5f5f5,stroke:#888,stroke-width:1px;
    class A,B,GK,MCU,GW box;

光是把这套"电话局"搭起来还不够。两个人要接通一通电话，背后还要走一长串繁琐的"报到—对暗号—再接通"的流程：先向总机登记报到，再互相通报"我支持什么画质、你能听什么音质"，反复确认之后，才终于开始传声音和画面，通话结束时还要再走一遍正式的挂断手续。

在 1990 年代那种网络条件下，光是这一连串握手，就可能让用户在按下拨号键之后，明显感觉"慢了半拍"。

H.323 不是不能用，它只是重。

它的设计者们来自电信背景。在电信世界里，一次呼叫从来都是要慢慢握手的——电话拨号要响铃 3 声，传真要"叮——咚——刺啦"地协商一分钟。重，是电信的美学。

但互联网不吃这一套。

五

1990 年代中后期，正当 ITU 把 H.323 端上桌的时候，另一边——互联网社区——一群工程师在写一份截然不同的草案。

他们的"组织"叫 IETF（Internet Engineering Task Force，互联网工程任务组）。

IETF 不是 ITU。它没有玻璃大楼，也没有红色印章。它的成员资格是任何人都能加入——只要你订阅了邮件列表，你就是 IETF 的一员。它的会议每三个月一次，地点是世界各地不同的会议酒店，参会者穿牛仔裤、T 恤、凉鞋，开会时一边敲键盘一边吃披萨。

它的口号是一句广为流传的话：

"We reject kings, presidents, and voting. We believe in rough consensus and running code."

我们拒绝国王、总统和投票。我们相信粗略共识和能跑的代码。

—— David Clark，1992 年

在这种文化下，IETF 的 MMUSIC 工作组开始推动一项工作，目标是给互联网设计一个简单的、文本的、轻量的会话控制协议。

它的名字叫 SIP——Session Initiation Protocol，会话发起协议。

SIP 的第一份 RFC（RFC 2543）发布于 1999 年，作者包括 Mark Handley、Henning Schulzrinne、Eve Schooler 和 Jonathan Rosenberg。⁴ 这份文档相比 H.323 那一整套标准簇，薄得像一本小说。

SIP 最大的特点是：它长得像网页。

熟悉网页的人都知道，浏览器向网站要一个页面，用的是一句大白话式的指令，比如 GET 表示"给我看看这个页面"。SIP 借用了同样的思路，只不过把动词换成了打电话的动作：一句 INVITE（邀请）就是"我想跟你通话"，BYE（再见）就是"我要挂了"。

它的一条呼叫消息，翻成人话大致是这么几行：

邀请 bob@example.com 通话 发起人：Alice 接收人：Bob 我这边能收发的音频格式：（附在后面）……

任何一个和网页打过交道的工程师，都能在五分钟之内看懂它。它有像网页请求那样的"动词"，有像网页那样的"回执码"——比如对方正在响铃、对方接通了、对方占线——还随消息附带一小段纯文本的"自我介绍"，告诉对方"我想传什么、我能收什么、走哪个地址"。

更关键的是，SIP 不需要 H.323 那套沉重的"电话局"班底。它的呼叫流程简单到可以画在一张餐巾纸上：

sequenceDiagram
    participant A as Alice
    participant B as Bob
    A->>B: 我想跟你通话（附上音视频格式）
    B-->>A: 正在响铃……
    B-->>A: 接通！（也报上自己的格式）
    A->>B: 好，开始
    Note over A,B: 声音和画面双向流动
    A->>B: 我挂了
    B-->>A: 好，再见

几个来回，通话就接通了。

六

H.323 和 SIP 的战争，本质上是两种文化的战争。

H.323 是工程师写给工程师看的； SIP 是工程师写给"任何看得懂大白话的人"看的。

最终结果你已经知道了：

• 2000 年代初，企业 PBX 和软交换厂商开始大规模支持 SIP；
• 2000 年代中后期，SIP 逐渐成为互联网电话和企业通信里的主流信令协议之一；
• 2010 年之后，H.323 更多留在会议室设备互联、网关和存量系统里；
• 今天让浏览器直接能打视频电话的 WebRTC，虽然不等于 SIP，但仍沿用了它那套"先互相通报格式、再商量着接通"的思路。

H.323 没有死。它今天还活在 Polycom、Lifesize、Cisco TelePresence 等会议室视频系统里。它在某些场景下甚至比 SIP 还稳定。

但它输掉了"心智份额"。

它输掉了——新生代工程师第一次接触实时通信时的心智入口。

七

故事还有第三个主角。

它不是协议，而是一份用来"配合"协议的标准。它的编号是 T.120——T 字头，代表"数据"领域。

T.120 是 ITU 在 1990 年代中期发布的一组多点数据协同标准。它定义了：⁵

• 怎么让多个客户端共享应用或协同操作？
• 怎么共享一块"白板"？
• 怎么传文件？
• 怎么投票？
• 怎么聊天？

T.120 的设计目标，是给视频会议加上"协作"的翅膀——让会议不只是看见彼此，还能一起做事。

这里要停一下。

真正的在线会议，从来不是单纯的"视频通话"。它有三根柱子：

H.261、H.320、H.323 这一支，讲的是视频与呼叫控制。 SIP、RTP 这一支，后来把音频、视频的实时传输变成互联网工程。 而 T.120 这一支，讲的是共享。

如果说音频让远方的人"进来"，视频让远方的人"出现"，那么共享让远方的人坐到同一张桌子前。

它其实是一整套子标准，各管一摊，加起来就是一间"虚拟会议室"里该有的协作能力：

T.120 最有名的早期实现之一，是 1996 年微软发布的一款免费软件——NetMeeting。⁶

NetMeeting 最早随 Internet Explorer 3 公开发布，后来又随多版 Windows 分发；它把上面这些协作能力和音视频通话结合在了一起。它能让两个 Windows 用户做这些事：

• 视频通话
• 共享屏幕上的应用
• 一起在白板上涂画
• 互传文件
• 远程帮对方操作电脑
• 文字聊天

——所有这些，在 1990 年代中后期，陆续出现在普通 PC 用户面前。

NetMeeting 一度是最重要的桌面协同工具之一。它启发了无数后来者。微软自己却没有把它做成一个长期独立的会议平台；后来，它逐渐让位于 Messenger、Office Live Meeting、Lync/Skype/Teams 这一条线。

但 T.120 的思想留了下来。

后来的 WebEx、Lotus Sametime、Citrix GoToMeeting，在不同程度上都继承了 T.120 那个核心问题：人不在同一个房间里，怎样一起看、一起指、一起改、一起讨论？

这也是为什么，早期 WebEx 的灵魂并不是高清视频。它最先打动企业客户的，是网络会议（web conferencing）：把演示文稿、屏幕、应用和远方的人放到同一个会议空间里。

WebEx 最看重的，是共享优先——先让大家能一起看同一个东西、一起改一起讨论。 Zoom 后来最看重的，则是视频优先——先让大家像坐在一起、面对面。

这两者不是谁高谁低，而是两个时代的产品答案：前者解决"远程一起工作"，后者解决"远程像在一起"。

T.120 是 WebEx 的一位远房长辈。

讲到这里，我们终于可以提到那个名字了——

朱敏。

八

T.120 草案在 ITU 内部讨论的那几年（1993~1996），朱敏正在硅谷。

那时他刚从 Future Labs 走出来。Future Labs 是他在 1991 年创办的公司，主打多点文档协同——和 T.120 关心的是同一个问题：不在同一个房间里的人，怎样一起协作。Future Labs 一度做得不错，但协作软件很快卷入了一个更大的问题：当微软把类似能力免费推给 IE 和 Windows 用户时，独立协作软件该靠什么生存？⁷

NetMeeting 免费，跟着 IE 和 Windows 进入越来越多的 PC。Future Labs 这类产品收费，独立发行。

Future Labs 在 1996 年被 Quarterdeck 收购。公开报道给出的交易估值约为一千万美元量级。⁷

那一年他 48 岁。

行业里的所有人都觉得他该退休了。

但朱敏的脑子里有另一个想法——一个被桌面软件路线反向激发出来的想法：

"如果协作软件不应该装在每个人的 Windows 里，那它应该装在哪儿？"

答案后来由他自己给出。

那个答案，将在三十六个月之后，定义一个全新的产品形态。

这个答案后来有个名字，叫 "软件即服务"（Software as a Service）。

而 WebEx，会成为这个方向最早、也最有代表性的商业实现之一。⁸

九

回到协议的战争。

战争的胜负，今天看是显然的：

• H.261 / H.263 / H.264 / H.265——视频压缩家族赢了，成为现代视频编码的主线。
• SIP——呼叫协议赢了，成为互联网电话和企业通信的重要基础。
• T.120——它很早淡出主流，但它提出的"协作"问题没有退场。
• H.323——在会议室、网关和存量系统里还有余温，但不再是多数新生代工程师的第一入口。

但战争的真正教训，不在胜负本身。

真正的教训是：

当 ITU 在玻璃大楼里讨论"理想的视频会议标准应该长什么样"时，IETF 在邮件列表里不断把"能跑的代码"推到前台。

当 PictureTel 还在卖昂贵的会议室系统时，VocalTec 已经把 Internet Phone 做成了几十美元的软件。

当 NetMeeting 在 Windows 里免费送时，朱敏在思考"如果协作不靠 Windows，靠什么"。

标准很重要。但比标准更重要的，是谁能尽早用标准做出能跑的东西。

工程师的世界里有一句话，常被引用：

"Standards are like toothbrushes—everyone agrees they're a good idea, but no one wants to use someone else's."

标准就像牙刷——每个人都同意它是好东西，但没人想用别人的那一支。

这句话的作者已经不可考。它在工程师社区里流传很广。

它讽刺的恰恰是：每个标准化组织都觉得自己的标准最好，每家厂商都想把自己的方案变成标准，最终大家妥协出一个谁都不太满意的东西，再用接下来的十年互相不兼容。

H.323 不兼容 SIP； SIP 早期版本之间彼此也不兼容； T.120 厂商之间的实现差异，让"跨厂商协作"形同空话； 直到 WebRTC 在 2011 年之后出现，浏览器才逐渐变成一个更统一的实时通信运行环境。

十

我后来在思科合肥研发中心做电话接入平台的那几年，每天都要在 SIP、H.323、ISDN PRI、SS7 这几种协议之间互相翻译。

我们写过无数的"网关"——SIP 到 H.323 的网关、H.323 到 ISDN 的网关、ISDN 到 PSTN 的网关。每写一个网关，背后就是一段历史的胶水。

有一天我从一份很久以前的旧代码里翻出一段注释，作者已经不知道是谁了。大意是这样：

// FIXME: 这里的转换逻辑看起来很奇怪，
// 但它是在替两个年代、两套协议、两种世界观做翻译。
// 如果你多年以后还在维护这段代码，
// 请向当年写网关的人致敬。

我笑了好一会儿。

然后把那段注释保留了下来。

那不是代码注释，那是一座墓志铭。

属于一场漫长、缓慢、最终被时间和互联网一起埋葬的战争。

十一

这一章结束的时候，我们需要在脑子里留下一张地图。

graph LR
    subgraph ITU["ITU 阵营 · 玻璃大楼与红色印章"]
        V["视频压缩<br/>H.261 → H.264 → 今天的编码<br/><i>成为现代视频编码主线</i>"]
        S1["呼叫信令<br/>H.320 → H.323<br/><i>新系统里让位给 SIP</i>"]
        D["数据协作<br/>T.120 → NetMeeting<br/><i>思路被后来的 SaaS 继承</i>"]
    end

    subgraph IETF["IETF 阵营 · 邮件列表与能跑的代码"]
        S2["呼叫信令<br/>SIP（1999）<br/><i>成为互联网电话主流之一</i>"]
        M["媒体传输<br/>RTP（1996）<br/><i>至今仍是音视频基础</i>"]
        W["浏览器实时通信<br/>WebRTC（2011 起）<br/><i>把实时通信带进浏览器</i>"]
    end

    subgraph BIZ["企业阵营 · 产品形态"]
        H["PictureTel / Polycom<br/>会议室硬件"]
        P["Cisco IP Phone<br/>桌面网络电话"]
        C["WebEx / Sametime<br/>网络协作服务"]
    end

    D -.接力.-> C

    classDef itu fill:#eef3fb,stroke:#5b7fb0;
    classDef ietf fill:#eefbf0,stroke:#5bb07f;
    classDef biz fill:#fbf6ee,stroke:#b0955b;
    class V,S1,D itu;
    class S2,M,W ietf;
    class H,P,C biz;

每一条支线，都是一支队伍漫长的征程。 每一支队伍背后，都有无数写代码的工程师、反复拉锯的会议、长期投入的资本和并购。

但所有这些复杂的支线，最终都会在 2011 年那个春天的硅谷小办公室里——汇成一条河。

那一年，袁征带着四十多名工程师离开思科。他们的目标是从零再造一艘船。

他们的船最后会跑进无数台 PC、手机、客厅、学校和真实生活现场里。

但在那之前，让我们先讲清楚一件事——

互联网的破晓。

那是下一章的故事。

协议是工程师的语言。 写标准的人，用语法定义未来。 但写产品的人，用产品定义现在。 未来是个孤儿。它必须借助现在来出生。