文章目录

前言
什么是 WebRTC？
WebRTC 架构
WebRTC 通讯内容
WebRTC 通讯协议
WebRTC 连接建立过程
后记

前言

最近在做关于考试系统的项目，其中有一项需求分析是要做在线监考模块，因为之前没有做过这方面的东西，还是比较迷茫的，在查阅了大量的资料之后，再结合系统是以 H5 的形式展示的，最后选用了 WebRTC 框架为主体来实现这一模块，本文会介绍其基本理论；

什么是 WebRTC？

WebRTC，名称源自网页即时通信（英语：Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的 API。与直播常用的 RTMP 协议相比，WebRTC 拥有极低的延迟，并且整合了大量的终端多媒体问题和传输问题的应对方案的实现，包括音视频的编解码、同步、带宽预测、QoS，AEC等，因此使用支持 WebRTC 的设备和浏览器可以轻松实现 P2P 实时语音通话的功能。

WebRTC 是一个由 Google 发起的实时通讯解决方案，其中包含视频音频采集，编解码，数据传输，音视频展示等功能，我们可以通过技术快速地构建出一个音视频通讯应用。虽然其名为 WebRTC，但是实际上它不光支持 Web 之间的音视频通讯，还支持 Android 以及 IOS 端，此外由于该项目是开源的，我们也可以通过编译 C++ 代码，从而达到全平台的互通。

WebRTC 架构

Your Web App

Web 开发者开发的程序，Web 开发者可以基于集成 WebRTC 的浏览器提供的 web API开发基于视频、音频的实时通信应用。

Web API

面向第三方开发者的 WebRTC 标准 API（Javascript），使开发者能够容易地开发出类似于网络视频聊天的 web 应用，需要注意的是可能在不同浏览器中 API 接口名会不太一样, 所以推荐使用这个 JS 适配器来协调各个浏览器的不同接口。这些 API可分成Media API、 RTCPeerConnection、Peer-to-peer Data API 三类；

Media API

MediaStream：用来表示一个媒体数据流。
MediaStreamTrack：在浏览器中表示一个媒体源。

RTCPeerConnection

RTCPeerConnection：一个 RTCPeerConnection 对象允许用户在两个浏览器之间直接通讯。
SDP: 用来描述当前连接者想要传输的内容，支持的协议类型，支持的编解码类型等。
RTCIceCandidate：表示一个 ICE 协议的候选者，简单的说，就是目标节点的 IP 以及端口。
RTCIceServer：表示一个 ICE Server，其主要用于当前主机的 IP 发现，通过和 ICE Server 通讯，我们会得到一组可供连接使用的 IP:Port 候选值，双方通过交换 ICE 候选值来建立起连接。

Peer-to-peer Data API

DataChannel：数据通道(DataChannel)接口，表示一个在两个节点之间的双向的数据通道，该通道可以设置成可靠传输或非可靠传输。

WebRTC Native C++ API

本地 C++ API 层，使浏览器厂商容易实现 WebRTC 标准的 Web API，抽象地对数字信号过程进行处理。

Transport / Session

传输部分可基于 TCP/UDP，会话层组件采用了 libjingle 库的部分组件实现。

AudioEngine

音频引擎是包含一系列音频多媒体处理的框架，包括从视频采集卡到网络传输端等整个解决方案。

VideoEngine

视频引擎是包含一系列视频处理的整体框架，从摄像头采集视频到视频信息网络传输再到视频显示整个完整过程的解决方案。

WebRTC 通讯内容

首先，两个客户端想要创建连接，一般来说需要有一个双方都能访问的服务器来帮助他们交换连接所需要的信息。有了交换数据的中间人之后，他们首先要交换的数据是SessionDescription（SD），这里面描述了连接双方想要建立怎样的连接。

SD 从哪来

一般来说，在建立连接之前连接双方需要先通过 AP I来指定自己要传输什么数据（Audio，Video，DataChannel），以及自己希望接受什么数据，然后客户端 A 调用 CreateOffer() 方法，获取 offer 类型的 SessionDescription，通过公共服务器传递给客户端 B，同样地客户端 B 通过调用 CreateAnswer()，获取 answer 类型的 SessionDescription，通过公共服务器传递给客户端 A。在这个过程中无论是哪一方创建 Offer（Answer）都无所谓，但是要保证连接双方创建的 SessionDescription 类型是相互对应的。客户端 A = Answer 客户端 B = Offer | 客户端 A = Offer 客户端 B = Answer；

SD 包含什么内容

//版本
v=0
//<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>
o=- 3089712662142082488 2 IN IP4 127.0.0.1
//会话名
s=-
//会话的起始时间和结束时间，0代表没有限制
t=0 0
//表示音频传输和data channel传输共用一个传输通道传输的媒体，通过id进行区分不同的流
a=group:BUNDLE audio data
//WebRTC Media Stream
a=msid-semantic: WMS
//m=audio说明本会话包含音频，9代表音频使用端口9来传输，但是在webrtc中现在一般不使用，如果设置为0，代表不传输音频
//使用UDP来传输RTP包，并使用TLS加密, SAVPF代表使用srtcp的反馈机制来控制通信过程
//111 103 104 9 0 8 106 105 13 110 112 113 126表示支持的编码，和后面的a=rtpmap对应
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
//表示你要用来接收或者发送音频使用的IP地址, webrtc使用ice传输，不使用这个地址, 关于ICE是什么后面会讲到
c=IN IP4 0.0.0.0
//用来传输rtcp的地址和端口，webrtc中不使用
a=rtcp:9 IN IP4 0.0.0.0
//ice协商过程中的安全验证信息
a=ice-ufrag:ubhd
a=ice-pwd:l82NnsGm5i7pucQRchNdjA6B
//支持trickle，即sdp里面只描述媒体信息, ice候选项的信息另行通知
a=ice-options:trickle
//dtls协商过程中需要的认证信息
a=fingerprint:sha-256 CA:83:D0:0F:3B:27:4C:8F:F4:DB:34:58:AC:A6:5D:36:01:07:9F:2B:1D:95:29:AD:0C:F8:08:68:34:D8:62:A7
a=setup:active
//前面BUNDLE行中用到的媒体标识
a=mid:audio
//指出要在rtp头部中加入音量信息
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
//当前客户端只接受数据，不发送数据，recvonly,sendonly,inactive,sendrecv
a=recvonly
//rtp,rtcp包使用同一个端口来传输
a=rtcp-mux
//下面都是对m=audio这一行的媒体编码补充说明，指出了编码采用的编号，采样率，声道等
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
//对opus编码可选的补充说明,minptime代表最小打包时长是10ms，useinbandfec=1代表使用opus编码内置fec特性
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
//下面就是对Data Channel的描述，基本和上面的audio描述类似，使用DTLS加密，使用SCTP传输
m=application 9 DTLS/SCTP 5000
c=IN IP4 0.0.0.0
//可以是CT或AS，CT方式是设置整个会议的带宽，AS是设置单个会话的带宽。缺省带宽是千比特每秒
b=AS:30
a=ice-ufrag:ubhd
a=ice-pwd:l82NnsGm5i7pucQRchNdjA6B
a=ice-options:trickle
a=fingerprint:sha-256 CA:83:D0:0F:3B:27:4C:8F:F4:DB:34:58:AC:A6:5D:36:01:07:9F:2B:1D:95:29:AD:0C:F8:08:68:34:D8:62:A7
a=setup:active
//前面BUNDLE行中用到的媒体标识
a=mid:data
//使用端口5000，一个消息的大小是1024比特
a=sctpmap:5000 webrtc-datachannel 1024

以上就是一个 SessionDescription 的例子，虽然没有 video 的描述，但是 video 和 audio 的描述是十分类似的。 SDP 中有关于 IP 和端口的描述，但是 WebRTC 技术并没有使用这些内容，那么双方是怎么建立 “直接” 连接的呢？建立起连接最关键的 IP 和端口是从哪里来的呢？且看接下来的 WebRTC 协议介绍；

WebRTC 通讯协议

ICE

交互式连接建立（ICE，Interactive Connectivity Establishment）是一中框架，允许你的网络浏览器与同行连接。有很多原因导致从对等体 A 到对等体 B 的直接连接无法工作。它需要绕过会阻止打开连接的防火墙，如果像大多数情况下你的设备没有公共 IP 地址，就给你一个唯一的地址，如果你的路由器不允许你直接与对等体连接，就通过一个服务器中转数据。ICE 使用 STUN 或 TURN 服务器来实现这一目的。

STUN

Session Traversal Utilities for NAT（STUN）是一个协议，用于发现你的公共地址，并确定你的路由器中的任何限制，这些限制会阻止与同行的直接连接。

客户端将向互联网上的 STUN 服务器发送一个请求，该服务器将回复客户的公共地址以及客户是否可以在路由器的 NAT 后面访问。

NAT

Network Address Translation（NAT）是用来给你的设备一个公共 IP 地址。路由器将有一个公共 IP 地址，而连接到路由器的每个设备将有一个私人 I P地址。请求将从设备的私有 IP 翻译到路由器的公共 IP，并有一个唯一的端口。这样，你不需要为每个设备提供一个独特的公共 IP，但仍然可以在互联网上被发现。

一些路由器会对谁可以连接到网络上的设备有限制。这可能意味着，即使我们有 STUN 服务器发现的公共 IP 地址，也不是任何人都可以建立连接。在这种情况下，我们需要求助于 TURN。

TURN

一些使用 NAT 的路由器采用一种叫做 "对称 NAT " 的限制，这意味着路由器将只接受来自你以前连接过的对等体的连接。

Traversal Using Relays around NAT（TURN）是为了绕过对称 NAT 的限制，通过与 TURN 服务器建立连接并通过该服务器转发所有信息。你将创建一个与 TURN 服务器的连接，并告诉所有对等体将数据包发送到该服务器，然后转发给你。这显然会带来一些开销，所以只有在没有其他选择的情况下才会使用它。

SDP

Session Description Protocol （SDP）是一个描述连接的多媒体内容的标准，如分辨率、格式、编解码器、加密等，以便在数据传输后，对等双方能够相互理解。从本质上讲，这是描述内容的元数据，而不是媒体内容本身。

那么，从技术上讲，SDP 不是真正的协议，而是一种用于描述设备间共享媒体的连接的数据格式。

记录 SDP 远远超出了本文档的范围；

WebRTC 连接建立过程

连接双方（Peer）通过第三方服务器来交换（Signalling）各自的 SessionDescription 数据。
连接双方（Peer）通过 STUN 协议从 STUN Server 那里获取到自己的 NAT 结构，子网 IP 和公网 IP，端口，这里的 IP 和端口对我们称之为 ICE Candidate。
连接双方（Peer）通过第三方服务器来交换（Signalling）各自 ICE Candidates，如果连接双方在同一个 NAT 下那他们仅通过内网 Candidate 就能建立起连接，反之如果他们处于非对称型 NAT 下，就需要 STUN Server 识别出的公网 Candidate 进行通讯。
如果仅通过 STUN Server 发现的公网 Candidate 仍然无法建立连接，换句话说就是连接双方（Peer）中至少有一方处于对称 NAT 下，这就需要处于对称 NAT 下的客户端（Peer）去寻求 TURN Server 提供的转发服务，然后将转发形式的Candidate共享（Signalling）给对方（Peer）。
连接双方（Peer）向目标 IP 端口发送报文，通过 SessionDescription 中涉及的密钥以及期望传输的内容，建立起加密长连接。

后记

这篇博文以介绍 WebRTC 为主，下一篇博文将进入实战，【复】基于 WebRTC 的音视频在线监考模块的设计与实现（下）；

参考：

用 Python+WebRTC 和吴彦祖视频
Introduction to WebRTC protocols
WebRTC简介

【复】基于 WebRTC 的音视频在线监考模块的设计与实现（上）相关推荐

基于WebRTC实现音视频及数据通信
文章目录前言一.WebRTC的组成? 二.信令交换的方式三.会话描述四.客户端应用 1.HTML 2.JavaScript 五.效果演示六.项目地址总结前言刚写了篇基于WebRTC使用 ...
技术分享| 如何快速实现音视频在线通话
请问咱们支持像微信一样的音视频呼叫功能吗? 请问呼叫邀请怎么实现? 如果客户端离线了,怎么呼叫到客户? 怎么添加呼叫铃声?以及接收铃声? 经常能听到有用户问上述的问题,今天借此机会向大家讲解下音视频呼 ...
html5音频剪辑,一种基于HTML5Canvas画布音视频分段剪辑方法与流程
技术特征: 1.一种基于html5canvas画布音视频分段剪辑方法,其特征在于:包括如下步骤: 步骤一:首先使用者预先获取源音视频文件,然后使用者对音视频文件分段剪辑时,进入音视频文件分段剪辑主单元 ...
基于FFMPEG的音视频截取（C++Qt 版）
基于FFMPEG的音视频截取(C++Qt 版) 这篇博客是基于上篇博客的: https://blog.csdn.net/liyuanbhu/article/details/121744275 上篇博客 ...
Android音视频点/直播模块开发实践总结-zz
随着音视频领域的火热,在很多领域(教育,游戏,娱乐,体育,跑步,餐饮,音乐等)尝试做音视频直播/点播功能.那么作为开发一个小白,如何快速学习音视频基础知识,了解音视频编解码的传输协议,编解码方式,以及 ...
基于springboot的短视频网站的开发与设计
通知:代本科论文"润色"<基于视频监控的智慧消防系统>,可私聊. [注]该项目<基于springboot的短视频网站的开发与设计>为本人毕业设计.使用的开发 ...
基于B/S架构的在线考试系统的设计与实现
前言这个是我的Web课程设计,用到的主要是JSP技术并使用了大量JSTL标签,所有代码已经上传到了我的Github仓库里,地址:https://github.com/quanbisen/online ...
mysql意见反馈表设计_一个基于PHP和MySQL的意见反馈模块的设计和实现
一个基于PHP和MySQL的意见反馈模块的设计和实现杜大刚 [期刊名称]<计算机与现代化> [年(卷),期]2005(000)003 [摘要]本文涉及的意见反馈模块是一个基于PHP和MyS ...
网站在线客服系统实时语音视频聊天实战开发，利用peerjs vue.js实现webRTC网页音视频客服系统...
webRTC机制和peerjs库的介绍在其他博客中已经有了很多介绍,这里我直接搬运过来一.webrtc回顾 WebRTC(Web Real-Time Communication)即:网页即时通信. ...

【复】基于 WebRTC 的音视频在线监考模块的设计与实现（上）