Labs 导读
音视频通话是实时通信(Real Time Communication, RTC)业务的主要应用场景，也是人与人之间沟通交流的重要方式，伴随着运营商与互联网厂商近二十年的竞合博弈，人们得以便捷地享受到各类形式的语音或视频交互应用服务。语音通话作为运营商的重要业务，逐步被互联网OTT应用冲击，近些年来也出现了通话量负增长的现象;针对视频互动通话，互联网厂商推出的各类软件应用在低廉资费、功能丰富等方面更是处于领先地位。发展大势中互联网厂商不断将运营商管道化，特别在近两年来互动直播、视频会议等应用快速发展的背景下，互联网厂商也不断在建设自己的音视频网络，将业务打入了运营商的腹地，逐步“旁路化”运营商的用户流量。俗话说“要致富，先修路”，而在音视频信息高速公路建设这条赛道上，拥有一张稳定、高性能的底层音视频传输网络，是上层应用的构建基础，也是获得用户青睐的关键因素。
1、同样的业务形态，不同的底层实现
互联网许多应用都可以为用户提供了语音通话、视频互动等实时通信功能，但与运营商传统通话业务相比，两者基于不同的技术栈。例如，互联网厂商从开始就基于VoIP(Voice over Internet Protocol)开发产品，而运营商从最初的大哥大时代模拟通话到后来的数字通话、从电路交换再到分组交换，底层技术经历了巨大的改变和发展。从图1概括了经典语音业务两类服务者不同的技术实现。
例如，以语音业务的承载方式为例，早期运营商以时分复用技术承载语音业务，包括移动通信2/3G时代的电路域，以及固定电话接入的公共交换电话网(Public switched telephone network，PSTN)，资源按时隙独占的方式最大程度保证通话的质量;但随着通信和互联网技术的发展与融合，4G时代采纳了完全基于IP分组交换来承载数据传输的IMS方案，建立专门承载运营商语音业务的IMS网络，提高资源的利用率。运营商虽然目前也采纳IP承载语音业务，但与互联网厂商仍有本质区别：
- IMS建设独立于Internet互联网，通过标识区分语音和数据业务，虽然都基于IP接入，但转发至IMS网络的语音业务能够通过QoS保证通话质量，相比之下，互联网提供商的APP则需要走公共互联网，与其他互联网数据业务竞争网络传输资源;
- 运营商语音通话不需要额外的APP，通过手机终端的拨号功能直接发起通话，是最便捷的触点入口，而互联网厂商提供语音服务则必须研发不同的APP。
2、运营商RTC通信
运营商RTC通信主要是通过运营商建立的通信网基础设施承载语音和视频业务，包括个人座机和手机等终端形态。随着移动通信技术的发展，人们日常生活多以手机终端作为媒介联络他人。个人座机通过固网PSTN通信场景已经渐渐从个人日常生活中没落，更多存在于企业客户场景下，而移动通信技术的高速发展，除了保证基础电话业务外，互联网数据服务的发展，造就了近十年来互联网各类应用井喷式发展的盛世。
运营商RTC最初的业务形态主要针对电话场景，早期2/3G仍采用电路交换，即常说的CS(Circuit Switching)域;4G LTE和目前正在建设的5G SA独立组网架构，都会采用IP分组交换的方式通过IMS提供服务，实际上通过IP可以提供语音和视频两种业务形态，但受限于对手机终端硬件的型号要求和资费问题，运营商的视频通话业务一直没有广泛普及，目前基于运营商网络提供的RTC通信服务基本上都是语音业务。基于4G的语音解决方案称作VoLTE，5G则称为VoNR，但相同点都会采用IMS、图2展示了4G VoLTE中IMS系统和CS域回落主要的业务流程和网络体系，方便读者理解数据传输形式的演进。
LTE包含4G接入和核心网的关键网元;CS域则表示了早期使用电路交换的2G/3G通话，数据传输采用资源独占的形式，有别于基于IP尽力而为的分组交换网络;而IMS网络中包括了P/I/S-CSCF、HSS、PCRF、MGCF等核心网元，数据的传输采用IP分组交换。
在4G VoLTE业务全面部署开通之前，IP分组交换与CS域电路交换传输方式并存，IMS网络中MGCF(Media Gateway Control Function，媒体网关控制功能)用于IMS域与CS域的互通，负责完成控制面信令的互通，并通过媒体网关MGW(Media Gateway)连接4G核心网用户面数据网关PGW(PDN Gateway)，实现与CS域之间的转换，达到4G与2/3G语音互通的目的，也就是VoLTE回落至2/3G通话，称为电路域回退(CS Fallback, CSFB)。用户直观的体验就是打电话与手机上网玩游戏、发微信消息等不可兼得，在IMS建设之前，运营商视角里的语音通话和数据上网是走两条截然不同的道路。
但随着VoLTE(LTE+IMS)普及开来，以及5G VoNR紧锣密鼓地建设发展，电路域传输逐步被弱化，运营商在实时通信领域上的电路域回退(CSFB)、语音与流量上网不可兼得的情况早已成为过去。同时，2G/3G退网重耕优质频谱资源的呼声也越来越高，这都得益于采用IP分组交换的IMS，使得手机电话与互联网应用的数据在底层都基于IP传输，网关处只需要标识出业务类型，就可让通话业务走IMS对应的传输通路，流量数据通过网关传入外部互联网。以图2为例的IMS主要包括如下核心网元：
（1）HSS(Home Subscriber Server)，归属用户服务器，统一存储用户数据，处理IMS网络中呼叫控制网元对用户的数据访问，还通过开通接口接收并响应BOSS业务开通指令;
（2）CSCF ( Call Session Control Function ) ，会话控制和路由，也是整个IMS域的核心，用于处理IMS网络中主要的控制层数据，进一步又细分为P/I/S/E四种网元，其中：
- P-CSCF：Proxy CSCF，代理CSCF，是IMS拜访网络的统一入口点，功能上提供注册鉴权、信令保护、信令压缩、媒体授权、QoS控制、信令路由(如SIP协议)、紧急呼叫、漫游计费等功能，主要负责控制信令相关的传输，与I-CSCF/S-CSCF侧配合完成呼叫的接续处理;此外，在物理部署层面，P-CSCF 可以在统一的会话边界控制器(Session Border Controller，SBC)设备上实现，同时结合 IMS-ALG/IMS-AGW(IMS Application Level Gateway/IMS Access Gateway，又可简写为ATCF/ATGW)分别提供通话业务的控制/媒体流层面的数据交互;
- I-CSCF：Interrogating CSCF，提供S-CSCF指派、路由查询功能，在 IMS 注册时，询问 HSS 以确定哪个合适的 S-CSCF 路由注册请求，对于来自P-CSCF的移动终端呼叫，询问 HSS 以确定用户注册到哪个 S-CSCF;
- S-CSCF：Serving CSCF，提供会话建立、会话拆除、会话控制和路由功能,为在其控制下的所有会话生成用于计费的记录、充当SIP协议的注册服务器，并通过HSS 查询适用的订户配置文件，处理涉及这些端点后续的呼叫流程。
- E-CSCF：Emergency CSCF，从P-CSCF接受紧急会话建立请求，并完成用户接入位置信息查询和紧急呼叫路由等功能。
上述功能分类说明了CSCF网元的逻辑功能，在物理部署层面，P-CSCF与IMS-ALG/IMS-AGW可以合设为同一物理设备，P-CSCF处理IMS呼叫控制层面信令等数据， IMS-ALG/IMS-AGW完成用户层面媒体流数据的控制/转发等功能。此外，CSCF除了实现SIP协议完成会话的控制和通话媒体流建立功能之外，还使用Diameter协议完成与核心网和IMS其他网元(如MME、HSS、PCRF等)签约及鉴权、计费信息等数据信息的传递，如P-CSCF通过Diameter Rx接口连接，完成对用户数据报文的策略和计费控制。
（3）TAS：Telephony Application Server，是运营商核心网络中用于提供电话应用和附加多媒体功能等功能。
目前，4G VoLTE基本已经全面商用，另正在建设的5G VoNR中，仍将采用IMS实现对多媒体RTC通信服务的IP承载，特别是5G新通话等应用探索IMS数据通道传递新型业务数据，此处不再赘述。IMS的发展，让运营商RTC服务与数据接入互联网Internet可以共享同样的IP接入和承载网络，但在业务类型层面，IMS网络与用户上网连接Internet又是互相隔离。此外，IMS作为一张专网，全球移动运营商的IMS网络又是互联互通的，因此IMS也是一个全球范围的网络，但与互联网厂商通过Internet提供RTC通信服务相比，IMS网络的路由优化与可靠性的保证远优于Internet。
总之，运营商RTC使用IMS承载业务，一般采用SIP协议互通，网络架构需遵循3GPP等规范开发产品，同时，由于运营商的网络基本交由各家厂商建设，除考虑兼容性外，在个性化功能定制方面往往受限于各个厂家的支持，并不是只是运营商自己的一局游戏，需要各方都遵循规范、开放互通，研发和推广周期一般较长。
3、互联网RTC通信
相比运营商，互联网RTC通信建立在运营商建立的基础设施通路之上，一般在专注于应用产品，各个厂商都会研发自己的APP，头部互联网玩家为了保证用户体验，还会建设大量的IDC机房为用户提供就近接入等优质服务，或者形成云化产品/解决方案卖给小型企业。由于各大互联网厂商的应用都运行在公共互联网Internet之上，因此从一开始就是采用VoIP的方案，凭借各家企业对编码、网络传输、部署架构等方面的优化，也能够为用户提供高质量的互联网语音通话服务，目前用户更倾向于使用互联网产品进行视频通话、远程会议或视频互动等功能，如阿里云、声网、腾讯云、字节火山引擎等，相比之下，运营商RTC通信服务在诸如此类方面就要落后于互联网RTC通信服务商。两者整体区别如图3所示。
在4G VoLTE/5G VoNR方案下，用户直接用手机拨号接入的运营商RTC语音(多媒体)业务将由核心网直接转发至IMS相关网元/设备，而数据(流量)业务直接通过互联网传输给对应厂商，在此场景下运营商只是充当了用户的移动接入和数据传输的管道职能，具体业务由不同的互联网厂商进行处理。
互联网RTC产品的研发相较于运营商而言，可以针对应用场景自行设计私有通信协议或基于通用协议进行定制，在应用层设计产品架构提供PaaS或SaaS服务，开发周期相对较短，但入口只能从APP或H5发起。例如微信语音、视频等功能，租用好各大运营商的接入线路，只要运营商的Internet线路畅通，通话双方就可以建立通话连接。而运营商RTC通信经由不同运营商的IMS网络控制，在跨运营商发起通话时，跨网通信经常需解决兼容性等问题。因此，基于互联网厂商的RTC产品往往在产品功能丰富、交付时长短等方面具有天然优势，用户也习惯了使用互联网产品。
提供RTC服务的互联网厂商一般采用私有协议提供音视频能力，或采用近几年备受欢迎的WebRTC协议建设自己的音视频网络。互联网通信包括即时通讯(Instant Messaging, IM)和RTC两种类型，前者主要包括文字聊天、语音消息发送、文件传输、音视频播放等应用场景，强调消息的可靠性和送达率;后者场景包括语音、视频电话会议、网络电话等，强调低延时和接通率，也是本文讨论的重点内容。
早期互联网RTC产品，采用IP传输实现语音通话与多媒体会议的功能，即VoIP。从广义上讲，运营商VoLTE和VoNR也属于IP多媒体通信范畴，但数据不通过公共互联网。VoIP已经有二十多年的发展历程，早在1995年VocalTec公司推出了第一款VoIP电话软件，其基于Internet传输语音服务，是现在所有互联网RTC产品的雏形。1999年，GIPS的诞生为互联网通信提供了发动机，对整个VoIP产生了巨大的影响。2003年前后，GIPS向Skype、Webex以及QQ提供了GIPS引擎，并于2011年被谷歌收购，随后项目开源，即广为人知的WebRTC开源项目，现在被广泛应用于互联网RTC产品中。
国内腾讯是较早提供互联网RTC产品的公司之一，在音视频实时通信领域有着深厚的技术积累，QQ也是国内较早并广受欢迎提供VoIP服务的产品。QQ 音视频起初使用 GIPS 公司的产品，后来就转为自研路线，诞生出了TRAE 引擎(QQ)、OpenSDK引擎和XCAST引擎(腾讯会议)。与今日厂商广泛直接采用WebRTC技术栈实现音视频网络不同，腾讯在WebRTC项目开源之前就在音视频领域有着广泛的研究，基本采用腾讯自研的音视频引擎提供服务，如图5所示。
由于GIPS引擎对互联网VoIP产品有着深远影响，被谷歌收购开源为WebRTC项目后就被众多RTC厂商广泛采纳，腾讯也顺应潮流在微信小程序中支持了WebRTC技术(如图6所示)，通过转码服务器对接其他腾讯系XCAST产品，此外，XCAST对外还兼容其他厂商的WebRTC产品。
除腾讯部分产品外，阿里云、声网、字节跳动等音视频领域的互联网厂商在RTC场景下的产品研发，基本都采用WebRTC作为音视频网络的基础协议。下面简述WebRTC协议。
WebRTC协议简述
WebRTC，名称源自网页实时通信(Web Real-Time Communication)的缩写，是一项实时通讯技术，在不借助中间媒介的情况下，建立浏览器或手机应用之间点对点(Peer-to-Peer)的连接，实现视频流和(或)音频流或者其他任意数据的传输，支持实时语音对话或视频对话。它是谷歌收购的GIPS项目和libjingle项目融合而成，其中GIPS部分主要提供媒体的处理的功能，libjingle项目部分主要提供P2P传输部分的功能，并于2011年5月开放了工程的源代码，与相关机构 IETF 和 W3C 制定行业标准，组成了现有的 WebRTC 项目，在行业内得到了广泛的支持和应用。需要注意的是，WebRTC是RTC应用场景下的协议，不能与RTC直接划等号。图7展示了WebRTC的协议栈设计。
图7. WebRTC协议栈设计
图7右侧为基于TCP的可靠传输部分，可以建立WebSocket等连接实现信令(如SIP等)的可靠传输或使用HTTP协议传输业务数据，WebRTC 核心关于音视频相关的协议在图例左侧基于 UDP 基础上搭建起来的，提供的API主要包括音视频抓取、音视频流通道和数据通道等。其中：
- ICE、STUN、TURN 用于NAT穿透, 解决了获取与绑定外网映射地址，以及 keep alive 机制;DTLS 用于对传输内容进行加密，可以看做是 UDP 版的 TLS。
- SRTP 与 SRTCP 是对媒体数据的封装与传输控制协议。
- SCTP 流控制传输协议，提供类似 TCP 的特性，在 WebRTC 里基于 DTLS 和UDP协议之上。
- RTCPeerConnection 用来建立和维护端到端连接，并提供高效的音视频流传输;RTCDataChannel 用来支持端到端的任意二进制数据传输，例如文字聊天内容等。
总之，WebRTC可通过getUserMedia(获得用户设备的摄像头及话筒视频、音频的媒体流)、RTCPeerConnection、RTCDataChannel面向Web开发者提供应用开发接口，实现功能丰富的Web应用;向下针对音视频的编解码、传输等底层技术，厂商可以自行进行优化，如支持不同的编解码协议。各大主流浏览器内核目前基本都支持了WebRTC，安卓和iOS应用也可以集成使用WebRTC与其他移动设备或PC端Web应用建立音视频通信。
但是，在控制层面WebRTC没有指明特定的信令协议，旨在最大限度地提高与已有技术的兼容性，可以与已有的系统进行对接。目前已经有企业在探索SIP/PSTN与WebRTC互通的系统，如音视频会议对接SIP/PSTN音视频通话、企业内部APP移动工作台(智能办公电话)等场景，因此，WebRTC已不仅限于互联网音视频领域，还可以通过信令交互和代理的模式，打通应用App与传统移动电话网络的通路。
WebRTC作为一个天生的P2P通话协议，为什么各大互联网厂商都在建设基于WebRTC的音视频网络?其中比较重要的原因是RTC服务提供商为了能够为用户提供就近接入的服务，最大程度降低端端时延，并且提高统一通话线路(房间)内可同时互动的人数。
回顾WebRTC的协议栈，在媒体流数据转发层面，P2P是其一个典型的特征，终端之间形成两两互联的网状结构，即Mesh方案。但在实际中，Mesh方案往往只做理论对比，针对终端的性能和带宽要求都很高，并不会真正使用，因此，往往需要服务提供商建立音视频媒体流的传输分发网络作为中继，MCU(MultiPoint Control Unit)和SFU(Selective Forwarding Unit)是两种较为常见的中继方案，如图8所示。
MCU 不仅接收每个共享端的音视频流，还会经过解码并把解码后的音视频进行混流、重新编码，之后再将混好的音视频流发送给房间里的所有人，最终每个端侧只有一条上行通路和一条下行通路，因此，所有人看到的都是经过服务器混流后相同的一路画面，用户体验较好。但对服务器而言，性能要求较高，不仅需要进行数据转发，还要进行媒体流的编解码处理，对 CPU等硬件资源的消耗很大，图9展示了MCU服务器涉及的工作流。
相比之下，SFU的功能更像一个“媒体流路由器”，基本功能包括媒体流的转发和选路等功能。图8只示意了SFU基本原理，各端除了一条上行通路外，还需要多路下行通道同步来自其他端侧的媒体流信息。实际上，SFU服务器可以通过两两级联的方式灵活组网，形成跨区域的媒体流传输分发网络，可以为用户提供就近接入的服务，然后通过最优路径的选取进行媒体流转发，最大程度降低端端时延。由于SFU多下行的设计，多人RTC进行音视频通话时，多路视频可能会出现不同步，且对下行带宽的要求也较高。图10展示了SFU服务器的工作流程，包括接收、选路和转发。
基于SFU还有Simulcast模式和SVC(Scalable Video Coding)编码模式，前者由发送端推送多路不同分辨率的视频流，由下行接收端适配网络状况拉取不同分辨率的数据流，例如，在多方RTC通话(如视频会议、直播等)场景下，推流端发送360P/720P/1080P三路不同分辨率的视频流，接收端可基于对网络状况的测量选择性拉取不同分辨率的视频流;后者则是采用SVC编码格式，可通俗理解为将视频划分为自底向上的层级结构，越靠上层画面越清晰，相应需要带宽也越大，因此，接收端可以根据自身网络状况选择不同的视频分层进行拉流呈现。
此外，基于微服务的设计理念，SFU还可以配合编转码、混流等外接服务，选择性地插拔额外功能，较为灵活，因此，也是当前互联网厂商建设音视频网络时广泛采用的方案。无论是SFU还是MCU，在WebRTC协议栈下，最核心的特点是服务器把自己 “伪装” 成了一个 WebRTC的Peer客户端，并且服务器一般拥有可达的公网地址，因此，在与端侧建立连接时，P2P打洞建连流程也可以大大简化。
4、从终端到服务
基于上述，用户使用移动终端使用运营商或互联网公司的RTC产品时，数据流向如图11所示，其中主要包括了互联网产品移动接入的场景，固网接入与移动场景类似，不再单独说明。
在OTT平面，图11主要介绍了以WebRTC SFU组网为代表RTC产品的部署方案。相较于运营商，不同的互联网公司会根据自身情况，酌情在全国范围内搭建机房节点，通过购买不同运营商的底层接入专线，让不同区域内的用户能够根据位置就近接入OTT厂商自建的音视频网络。与其他互联网类产品类似，互联网厂商自建音视频网络，仍是运行在运营商建设的数据网络之上。但是，互联网虽然是开放互联的，但是互联网RTC应用却是相对封闭的，不同互联网RTC类产品，会经过用户终端APP入口，然后通过运营商的接入网传输到核心网，最终出口到互联网后到达对应服务提供商的音视频应用机房内，整条链路以公司为单位，鲜有不同互联网公司之间的音视频网络能够互通。
在运营商平面，4G/5G 通话类业务都已IP化，通过分组交换的方式互联互通。随着IMS网络不断升级演进，无论是4G VoLTE，还是5G VoNR，IMS已然是媒体类应用的控制/用户面数据流的承载体，特别是5G VoNR持续发展的当下，IMS有望承载更多各类的新型业务，如AR通话、实时3D通信等5G新通话类业务。与互联网OTT平面不同的是，不同运营商之间能够且必须做到互联互通，例如移动号码必须能够打通联通和电信的号码，在具体实施时，不同IMS网络的TrGW(Transition Gateway)网关通过Izi接口交换彼此的RTC通话媒体流，从而实现IMS网络的在运营商平面内的互联。从这一点上讲，运营商平面的RTC基础设施比互联网厂商各自为政的RTC音视频网络更加开放一些。
此外，由于本质上都采用了IP分组交换，大多数互联网厂商基于WebRTC协议自建音视频网络和运营商IMS专网之间的互联互通，已经在标准组织内进行讨论， 3GPP关于IMS与WebRTC技术结合的标准已经出台，也体现出来通信网与互联网融合的大趋势。
5、小结
本文主要介绍了互联网厂商与运营商在RTC领域的异同，重点包括运营商IMS网络、互联网厂商音视频网络(重点围绕WebRTC协议)等内容。后续将探讨运营商与互联网厂商在RTC领域如何互惠互利。
参考文献
[1] VoLTE Service Description and Implementation Guidelines. Version 1.1. 2014.
[2] 「电信RTC通信」vs「互联网RTC通信」.
[3] WebRTC access to IMS - network-based architecture. 3GPP TR 23.228 Annex U.
[4] 马泽芳,马瑞涛.IMS网间互通架构演进及网内实施方案[J].邮电设计技术,2020(09):61-65.
[5] ETSI TS 123 334 V10.2.0.
