webRTC-音视频通讯整理及方案参考

最新推荐文章于 2024-08-24 09:12:57 发布

邪神大叔

最新推荐文章于 2024-08-24 09:12:57 发布

阅读量582

点赞数

分类专栏： Mac 文章标签： webrtc im 音视频通讯

本文链接：https://blog.csdn.net/qq_17213067/article/details/110425628

版权

Mac 专栏收录该内容

27 篇文章 0 订阅

订阅专栏

背景：公司由于业务原因需要用到音视频通讯相关技术，一个好基友推荐了webRTC，研究了半天，产出一些成果，需要有错误还请指出，多多包涵；

WebRTC（Web Real-Time Communication）是 Google于2010以6829万美元从 Global IP Solutions 公司购买，并于2011年将其开源，旨在建立一个互联网浏览器间的实时通信的平台，让 WebRTC技术成为 H5标准之一

首先，webRTC是一个由端到端的音视频通讯技术【意思就是不需要有服务端【吹】就可以完成视频通话，而且效率、质量、性能各方面很牛逼】

开源，丰富的文档，W3标准多端支持。（web，Android，ios，桌面）
数据加密
生态完善，后续的维护、调优和问题定位可以通过各方面渠道去获取资料
成熟：从2013年开始，由google牵头，当前apple，微软这些巨头都支持，已经形成w3标准，很多商用公司已经采用

主要包含三大块：

音频处理和编解码（webrtc官方库实现）
视频处理和编解码（webrtc官方库实现）
网络传输（webrtc官方库实现大部分）

ICE/STUN/TURN : 解决点对点通讯的网络连接
DTLS：类似于TLS，实现对UDP报文进行加密
SRTP(Secure Real-Time Transport Protocol)：传输多媒体数据的通道（vedio，audio）
SCTP(Stream Control Transport Protocol)：实现了一个类似tcp的可靠消息通道，可以用于传输文本，文件之类的信息
SDP：纯文本格式，主要包含音视频的编码信息，以及传输地址信息（ip地址，端口号）

问题来了：

WebRTC不是端到端连接吗？是的，但是这些对等端需要能够找到对方。问题是你的浏览器只对自己的地址有一个认识。想象一下你问你的朋友她家地址是什么，她回答你“我住在一个红房子里”，但是你还是要知道她住在哪个城市哪个街道等等，而且即便你知道了这些信息，你还需要挨个门的敲来找到她到底住在哪。

这个过程叫做“交互式连通建立”，简称ICE，它需要一个外部服务器在对等端之间传递SDP信号，以及可能还需要额外的STUN或者TURN服务器来客服NAT。想要了解更多内容，我强烈推荐Louis Stowasser写的WebRTC及首字母缩写词集合这篇文章，以及WebRTC Glossary。

什么是信令

信令是协调通信的过程。为了使WebRTC应用程序能够建立一个“通话”，其客户端需要交换以下信息：

会话控制消息用于打开或关闭通信
错误消息
媒体元数据，如编解码器和编解码器设置，带宽和媒体类型
密钥数据，用于建立安全的连接
网络数据，如：外界看到的主机IP地址和端口

此信令过程需要一种方法让客户端来回传递消息。 WebRTC API不实现该机制：你需要自己构建它。

What is ICE?

交互式连接设施Interactive Connectivity Establishment (ICE) 是一个允许你的浏览器和对端浏览器建立连接的协议框架。在实际的网络当中，有很多原因能导致简单的从A端到B端直连不能如愿完成。这需要绕过阻止建立连接的防火墙，给你的设备分配一个唯一可见的地址（通常情况下我们的大部分设备没有一个固定的公网地址），如果路由器不允许主机直连，还得通过一台服务器转发数据。ICE通过使用以下几种技术完成上述工作。

STUN

NAT的会话穿越功能Session Traversal Utilities for NAT (STUN) (缩略语的最后一个字母是NAT的首字母)是一个允许位于NAT后的客户端找出自己的公网地址，判断出路由器阻止直连的限制方法的协议。

客户端通过给公网的STUN服务器发送请求获得自己的公网地址信息，以及是否能够被（穿过路由器）访问。

NAT

网络地址转换协议Network Address Translation (NAT) 用来给你的（私网）设备映射一个公网的IP地址的协议。一般情况下，路由器的WAN口有一个公网IP，所有连接这个路由器LAN口的设备会分配一个私有网段的IP地址（例如192.168.1.3）。私网设备的IP被映射成路由器的公网IP和唯一的端口，通过这种方式不需要为每一个私网设备分配不同的公网IP，但是依然能被外网设备发现。

一些路由器严格地限定了部分私网设备的对外连接。这种情况下，即使STUN服务器识别了该私网设备的公网IP和端口的映射，依然无法和这个私网设备建立连接。这种情况下就需要转向TURN协议。
TURN

一些路由器使用一种“对称型NAT”的NAT模型。这意味着路由器只接受和对端先前建立的连接（就是下一次请求建立新的连接映射）。

NAT的中继穿越方式Traversal Using Relays around NAT (TURN) 通过TURN服务器中继所有数据的方式来绕过“对称型NAT”。你需要在TURN服务器上创建一个连接，然后告诉所有对端设备发包到服务器上，TURN服务器再把包转发给你。很显然这种方式是开销很大的，所以只有在没得选择的情况下采用。

 重申： TURN用于中继对等端之间的音频/视频/数据流，而不是信令数据。
 
 TURN服务器具有公共地址，因此即使对等端位于防火墙或代理之后也可以与其他人联系。 
 TURN服务器有一个概念上来讲简单的任务—中继数据流—
 但是与 STUN服务器不同的是，
 他们会消耗大量的带宽。换句话说， TURN服务器需要更加的强大。

SDP

会话描述协议Session Description Protocol (SDP) 是一个描述多媒体连接内容的协议，例如分辨率，格式，编码，加密算法等。所以在数据传输时两端都能够理解彼此的数据。本质上，这些描述内容的元数据并不是媒体流本身。

What is an Offer/Answer and Signal Channel?

不幸的是，如果没有某种服务器，WebRTC 无法创建连接。我们称之为信号通道。这是任何类型的沟通渠道，以交换信息之前建立连接，无论是通过电子邮件，邮政编码或信鸽...由你决定。

我们需要交换的信息是要约和答案，它只包含上述 SDP。

作为连接发起人的对等方 A 将创建Offer。然后，他们将使用所选信号通道将此Offer发送给对等方 B。对等方 B 将从信号通道接收报价并创建答案。然后，他们将沿信号通道将其发送回对等方 A。

What is an ICE candidate?

除了交换有关媒体的信息（在提供/应答和 SDP 中讨论），对等方还必须交换有关网络连接的信息。这被称为 ICE 候选者，并详细说明对等体能够通信的可用方法（直接或通过 TURN 服务器）。

The entire exchange in a complicated diagram

复杂图表中的整个交换

WebRTC使端到端能够通信。

但是…

WebRTC仍然需要服务器：

让客户端交换元数据来协调通信：这被称为信令（signaling）

处理网络地址转换（NATs）和防火墙

详细资料可以参考：

真实世界中的WebRTC：STUN, TURN and signaling

代码可以参考

Webrtc_Java

im 消息聊天系统，服务器和android客户端

鉴于webRTC需要借助另外的IM服务器，并且在STUN服务器解析的IP:PORT无法接通的情况下需要TURN服务器直接传输视频流信息，此服务器的带宽CPU等等消耗异常大，故暂时不考虑此方案。建议使用腾讯云、阿里云等开放音视频通讯产品

总结：虽然webRTC很牛逼，

但是，他需要单独的一个IM服务器用来充当信令服务器【A要通话B，需要告诉B：我要和你通话了，我的地址，请告诉我你的地址等等】，以及一个TRUN服务器【干嘛的？里面有个STUN服务器用来解析A和B的公网IP和端口，以及是否可以进行通信。如果STUN解析出来的公网IP及端口无法通讯，就需要用到TRUN充当中间载体，A将发给B的视频流发给TRUN，然后TRUN再发给B】这个TRUN服务器选择一个可以通讯的方式的过程叫做ICE。

所以，如果STUN解析的IP:PORT可以通信，还好，如果不行，那TRUN服务器占用的带宽将非常大，这就是为什么，Google提供的一个公开的TRUN服务器经常凉的原因。

综合考虑，如果公司主要业务是IM，可以自己搭建此套技术。如果IM只是业务的一部分，可以考虑使用第三方服务产品。