5G时代必学的WebRTC音视频通话技术

什么是WebRTC

◼ WebRTC(Web Real-Time Communication)是 Google于2010以6829万美

元从 Global IP Solutions 公司购买,并于2011年将其开源,旨在建立一个互联

网浏览器间的实时通信的平台,让 WebRTC技术成为 H5标准之一。在这里插入图片描述
WebRTC时代来临

所有主要的浏览器的兼容

WebRTC现在得到了所有主要浏览器的支持和采用,包括谷歌Chrome、

苹果Safari、Mozilla Firefox 、QQ浏览器、360浏览器和Microsoft Edge。

IE支不支持webrtc?

威胁传统音视频提供商 声网(跨国,跨印度)、即构科技、融云

一波新的会议供应商正在使用WebRTC技术来勇闯互联网,对传统音视频提供

商给予了致命的一击。

WebRTC可靠性和易用性(声网在web端调用的是标准的API(WebRTC api) W3C)

WebRTC通过web浏览器普及会议体验,支持点击开始,并消除了额外软件的麻烦,

从而使这种体验成为可能。

WebRTC应用案例

教育行业解决方案在这里插入图片描述
互动电商解决方案在这里插入图片描述
企业视频协作/OA办公解决方案

在这里插入图片描述
WebRTC浏览器支持检测

1.是否是H5支持的平台:https://cloud.tencent.com/document/product/647/16863。

2.能力检测能否通过:https://sxb.qcloud.com/webrtc-samples/abilitytest/index.html。

WebRTC发展前景

WebRTC虽然冠以“web”之名,但并不受限于传统互联网应用或浏览

器的终端运行环境。实际上无论终端运行环境是浏览器、桌面应用、

移动设备(Android或iOS)还是IoT设备,只要IP连接可到达且符

合WebRTC规范就可以互通。

全球领先的技术研究和咨询公司Technavio最近发布了题为“全球网络

实时通讯(WebRTC)市场,2017-2021”的报告。报告显示,2017-

2021年期间,全球网络实时通信(WebRTC)市场将以34.37%的年

均复合增长率增长,增长十分迅速。增长主要来自北美、欧洲及亚

太地区。

WebRTC框架在这里插入图片描述
IE

edge

Chrome Opera

Firefox

Safari

WebRTC通话原理

首先思考的问题:

两个不同网络环境的(具备摄像头/麦克风多媒体设备的)客户端(浏览器或

APP),要实现点对点的实时音视频对话,难点在哪里?

哪部分问题需要我们解决,哪部分问题由Google解决。

  1. 音视频编解码能力沟通

  2. 网络传输数据

  3. 如何发现对方在这里插入图片描述
    WebRTC通话原理-1媒体协商-音视频编解码

彼此要了解

对方支持的媒体格式在这里插入图片描述
比如:Peer-A端可支持VP8、H264多种编码格式,而Peer-B端支持VP9、H264,要保

证二端都正确的编解码,最简单的办法就是取它们的交集H264

注:有一个专门的协议 ,称为Session Description Protocol (SDP),可用于描述上述这类信

息,在WebRTC中,参与视频通讯的双方必须先交换SDP信息,这样双方才能知根知底,而

交换SDP的过程,也称为"媒体协商"。

WebRTC通话原理-2网络协商(1)

彼此要了解对方的网络情况,这样才有可能找到一条相互通讯的链路在这里插入图片描述
理想的网络情况是每个浏览器的电脑都是私有公网IP,可以直接进行点对点连接。

WebRTC通话原理-2网络协商(2)在这里插入图片描述
实际情况是:我们的电脑和电脑之前或大或小都是在某个局域网中,需要NAT

(Network Address Translation,网络地址转换)。

WebRTC通话原理-网络协商(3)在这里插入图片描述
NAT(Network Address Translation,网络地址转换)。

WebRTC通话原理-STUN(1)

STUN(Session Traversal Utilities for NAT,NAT会话穿越应用程序)是一种网络

协议,它允许位于NAT(或多重NAT)后的客户端找出自己的公网地址(ip+port),

查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的Internet端

端口。在这里插入图片描述
在这里插入图片描述
WebRTC通话原理-STUN(2)

使用一句话说明STUN做的事情就是:告诉我你的公网IP地址+端口是什么。

问题是:STUN并不是每次都能成功的为需要NAT的通话设备分配IP地址的,P2P

在传输媒体流时,使用的本地带宽,在多人视频通话的过程中,通话质量的好坏

往往需要根据使用者本地的带宽确定。

那么怎么办?TURN可以很好的解决这个问题。

WebRTC通话原理-TURN(1)

TURN的全称为Traversal Using Relays around NAT,是STUN/RFC5389的一个拓展,主要

添加了Relay功能。如果终端在NAT之后, 那么在特定的情景下,有可能使得终端无

法和其对等端(peer)进行直接的通信,这时就需要公网的服务器作为一个中继,

对来往的数据进行转发在这里插入图片描述
WebRTC通话原理-TURN(2)

在STUN分配公网IP失败后,可以通过TURN服务器请求公网IP地址作为中继地址。

这种方式的带宽由服务器端承担,在多人视频聊天的时候,本地带宽压力较小。

以上是WebRTC中经常用到的2个协议,STUN和TURN服务器我们使用coturn开源

项目来搭建。

补充:ICE( Interactive Connectivity Establishment,交互式连接建立)

跟STUN和TURN不一样,ICE不是一种协议,而是一个框架(Framework),它整

合了STUN和TURN。coturn开源项目集成了STUN(打洞)和TURN(中继)的功能。

网络信息:放在 candidate在这里插入图片描述
WebRTC通话原理- 3 媒体协商+ +商 网络协商 数据的交换通道

从上面1/2点我们知道了2个客户端协商媒体信息(SDP)和网络信息(candidate),那怎

么去交换?是不是需要一个中间商去做交换?所以我们需要一个信令服务器

(Signal server)(房间服务器)转发彼此的媒体信息和网络信息。在这里插入图片描述
WebRTC通话原理- 3 媒体协商+ + 网络协商数据的交换通道

访问到的局域网),借助信令服务器,就可以实现上面提到的SDP媒体信息及

Candidate网络信息交换。

信令服务器不只是交换 媒体信息sdp和网络信息candidate,比如:

(1)房间管理

(2)人员进出房间

WebRTC通话原理总结

  1. 媒体协商

  2. 网络协商(每个客户端是有多个 映射地址)

  3. 媒体协商+网络协商数据的交换通道

  4. 信令服务器的开发:SDP/Candidate的交互,房间维护。

AppRTC

WebRTC API

1.MediaStream — MediaStream用来表示一个媒体数据流(通过getUserMedia

接口获取),允许你访问输入设备,如麦克风和 Web摄像机,该 API 允许从其中

任意一个获取媒体流。

WebRTC APIs

1.RTCPeerConnection — RTCPeerConnection 对象允许用户在两个浏览器之间

直接通讯 ,你可以通过网络将捕获的音频和视频流实时发送到另一个 WebRTC

端点。使用这些 Api,你可以在本地机器和远程对等点之间创建连接。它提供了连

接到远程对等点、维护和监视连接以及在不再需要连接时关闭连接的方法。

Web版本:调用JS API

WebRTC通话原理-4 一对一通话

对于WebRTC应用开发人员而言,

主要是关注RTCPeerConnection类,

我们以

(1)信令设计;

(2)媒体协商;

(3)加入Stream/Track;

(4)网络协商

四大块继续讲解通话原理

WebRTC通话信令基本设计

采用json封装格式

• join 加入房间

• resp-join 当join房间后发现房间已经存在另一个人时则返回另一个人的uid;如

果只有自己则不返回

• leave 离开房间,服务器收到leave信令则检查同一房间是否有其他人,如果有

其他人则通知他有人离开

• new-peer 服务器通知客户端有新人加入,收到new-peer则发起连接请求

• peer-leave 服务器通知客户端有人离开

• offer 转发offer sdp

• answer 转发answer sdp

• candidate 转发candidate

有兴趣了解更多音视频 webrtc FFmpeg 流媒体方面的朋友可以扫码加群获取学习资料在这里插入图片描述
在这里插入图片描述

猜你喜欢

转载自blog.csdn.net/Linuxhus/article/details/105390746
今日推荐