WebRTC音视频-前言介绍

目录

效果预期

1:WebRTC相关简介

1.1:WebRTC和RTC

1.2:WebRTC前景和应用

2:WebRTC通话原理

2.1:媒体协商

2.2:网络协商

2.3:信令服务器


效果预期

1:WebRTC相关简介

1.1:WebRTC和RTC

        WebRTC(Web Real-Time Communication)是一项开放标准的实时通讯技术,旨在通过浏览器和移动应用程序直接进行音频、视频和数据传输,而无需借助插件或其他第三方软件。

        RTC是一个更广泛的概念,涵盖了各种实时通信技术和协议,RTC是Real-Time Communication(实时通信)的缩写。它是一种技术和协议集合,用于在用户之间传输数据和媒体,实现实时的音频、视频和数据通信。

        WebRTC 则是 Google 基于 RTC 协议实现的一个开源项目,WebRTC是一个免费的开放项目,它通过简单的API为浏览器和移动应用程序提供实 时通信(RTC)功能。

RTC 有一个非常重要的特性,它是一个支持点对点直接传输的 P2P 协议;P2P在下面会介绍

webrtc官网   https://webrtc.org

1.2:WebRTC前景和应用

WebRTC(Web Real-Time Communication)的确以“web”命名,但其设计并不受限于传统的互联网浏览器环境。实际上,无论终端运行环境是浏览器、桌面应用、移动设备(如Android或iOS)还是IoT设备,只要满足IP连接可达和符合WebRTC规范的条件,这些设备都可以进行互通。

这一特性极大地扩展了WebRTC的应用范围,释放了大量智能终端以及运行在这些终端上的应用程序的实时通信能力。以下是WebRTC适用的主要应用领域:

  1. 在线教育: 教育机构可以利用WebRTC实现远程教学和学习,包括实时的视频和音频教学内容传输,互动问答和屏幕共享等功能。

  2. 视频会议: 企业和团队可以通过WebRTC搭建高效的视频会议系统,实现多方实时视频通话、协作编辑和虚拟会议室等功能,提升远程工作的效率。

  3. 视频社交: 社交平台和应用可以利用WebRTC提供实时视频聊天和直播功能,增强用户之间的互动和社交体验。

  4. 远程协助和支持: 客户服务和技术支持可以通过WebRTC提供远程协助和问题解决,包括远程控制、共享文档和实时注释等。

  5. 远程操控: IoT设备和工业控制系统可以通过WebRTC实现远程监控和操控,包括设备状态的实时显示和远程操作指令的传输。

综上,WebRTC的跨平台和广泛适用性使其在实时交互性要求较高的各种应用场景中都有广泛的应用前景。通过其开放的标准和协议,WebRTC不仅促进了多种设备和应用之间的互通,还为创新的实时通信应用提供了丰富的技术支持

2:WebRTC通话原理

        假如在保证两个可以正常联网 且(具备摄像头/麦克风多媒体设备的)正常的两个浏览器,如何实现互通呢?

主要分为两个部分,第一个部分 是媒体协商 ,另一个是网络协商 

2.1:媒体协商

        例如:当两个对象 A和B存在多种编码格式,例如上面图示,当A邀请B时,A会将自己的能力传递给B,然后B得到A的能力后,选择与A共有的能力,比如H264视频编码能力,然后传递给A,表示你的能力中,我符合H264,然后A得到信息后,便会也采用H264这个能力与B进行交互,这个过程就是媒体协商,这个只是一个示例,当然不止这个视频编码能力的协商交互,还包括音频能力、自己的媒体信息等其他信息交互。

        这个过程则是使用专门的协议,称为Session Description Protocol (SDP),在WebRTC中,参 与视频通讯的双方必须先交换SDP信息,这样双方才能知道对方的能力是什么,而交换SDP的过程,也称为"媒体协商"

WebRtC中媒体协商,主要是指SDP交换。又比如WebRTC建立中的信令媒体协商逻辑大概如下:

  • 发起端创建 Offer

    • Amy(发起端)通过创建一个 SDP(Session Description Protocol)Offer 来描述她的本地媒体能力和网络信息。
    • Amy 调用 setLocalDescription 方法将这个 Offer 设置为本地描述,并将其保存起来。
  • Offer 通过信令服务器传送给接收端

    • Amy 将她的 Offer 信息通过信令服务器发送给接收端 Bob。
  • 接收端处理 Offer

    • Bob(接收端)收到来自 Amy 的 Offer 信息后,通过调用 setRemoteDescription 方法将这个 Offer 设置为远端描述,保存起来。
  • 接收端创建 Answer

    • Bob 基于收到的 Offer 信息,创建一个 SDP Answer 来描述他的本地媒体能力和网络信息。
    • Bob 调用 setLocalDescription 方法将这个 Answer 设置为本地描述,并将其保存起来。
  • Answer 通过信令服务器传送给呼叫端

    • Bob 将他的 Answer 信息通过信令服务器发送回给呼叫端 Amy。
  • 呼叫端处理 Answer

    • Amy 收到来自 Bob 的 Answer 信息后,通过调用 setRemoteDescription 方法将这个 Answer 设置为远端描述,保存起来。

其中:setLocalDescription、setRemoteDescription 都是WebRTC都是接口API.

而什么又是Offer、Answer呢?

在双方要建立点对点通信时,发起端发送的 SDP 消息称为 Offer,接收端发送的 SDP 消息称为 Answer

所以,offer 和 answer 本质就是存有 SDP 信息的对象,所以也会叫做 SDP Offer 和 SDP Answer。

简单的理解:WebRTC 的信令协商过程就像人们在交换名片一样。每个人都准备了自己的名片(Offer 或 Answer),并将它们递交给对方。同时,每个人也接收并保存了对方的名片,这样双方就可以在需要联系时,通过这些名片上的信息找到彼此,并建立起通信。这种理解就概括了 WebRTC 中信令协商的基本原理和过程

2.2:网络协商

     当媒体协商完成后,WebRTC 就开始建立网络连接,其过程称为 ICE(Interactive Connectivity Establishment)交互式连接建立。ICE 不是一种协议,整合了 STUNTURN 两种协议(用于 NAT 穿透)的框架。

注意:ICE 是在各端调用 setLocalDescription() 后就自动开始了,并且是多次尝试去网络连接。也就是收集 Candidate的过程。

   WebRtc中很重要的一个环节,便是网络协商(网络协商 包括了“打洞”,但不仅仅只是打洞),也就是打通两个浏览器端之间的网络。两者不是都可以访问网络吗?为什么还要 再次打通网络呢?

那是 因为理想的网络情况:是每个浏览器的电脑都是私有公网IP,可以直接进行点对点连接。

例如下图:

        但是实际上,随着入网的设备越来越多,IPV4的地址池慢慢见底,新接入互联网的设备很难再分配到单独公网的 IPv4 地址,为了解决这个问题,引入了一个叫 NAT(Network address translation)的协议;新接入的设备不再直接分配公网的 IPv4 地址,而是躲在 NAT 设备(路由器等)之后,NAT 会给后面的每一个设备都分配一个单独的内网地址,就像家庭 或者 公司网络中一般都是一个公网IP出口,然后其他设备都是躲在这个公网地址后的内网地址。

     

简单解释下:

 NATNAT(Network Address Translation,网络地址转换)是一种网络技术,用于解决专用网络内部设备与公共网络之间的连接问题。其主要功能是将内部网络(私有网络)中的IP地址转换为外部网络(公共网络)的IP地址,以便内部设备能够访问互联网或与外部设备进行通信,同时保护内部网络不被直接访问。

NAT墙的进一步了解 和P2P协议,参考连接:

深入浅出WebRTC传输协议https://zhuanlan.zhihu.com/p/661166646

Candidate(候选者)Candidate(候选者)是WebRTC中用于描述设备可以使用的网络地址和传输协议的概念。在WebRTC建立对等连接的过程中,每个设备会收集自己的候选者信息,并交换给对方,以便在复杂的网络环境中找到可用的通信路径。简单的说 就是服务器的 IP 地址、端口号以及使用的传输协议。知道了这些信息,才能建立连接。而 Candidate 正是 WebRTC 用来描述它可以连接的远端的基本信息,因此 Candidate 是至少包括 IP 地址、端口号、协议的一个信息集合。

STUN:(Session Traversal Utilities for NAT,NAT会话穿越实用程序)是一种网络协议,旨在帮助设备位于NAT后面的客户端发现其真实的公网IP地址和端口号。它允许位于NAT(或多重 NAT)后的客户端找出自己的公网地址,查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的 Internet端端口。说白了就是 帮打洞的机制叫 ICE,帮忙打洞的服务器叫 STUN 服务。STUN 服务器用于获取计算机的公网 IP 地址。

TURN(Traversal Using Relays around NAT)是一种网络协议和服务,是STUN的扩展,用于解决无法通过STUN直接建立连接的情况,也就是当STURN搞不定网络的时候,就摆烂了,开始换个思路走了,也就是搞不定我就直接使用 TURN服务直接代理转发了

TURN 服务器会作为中转,转发多媒体数据就意味着会消耗大量的带宽。

但是,ICE打洞连同网络时,我们只需要配置好 STURN和TURN对应的地址,然后调用函数就行了,WebRTC已经帮我们完成了工作。

2.3:信令服务器

现在客户端都有媒体信息和网络信息 ,但是要去转发交换,现在则需要一个信令服务器(Signal server)转发对端的媒体信息和网络信息。

信令服务器在WebRTC中充当中介和调度者的角色,它不传输实际的媒体数据(音视频流),而是传递连接所需的控制信息和元数据。

作为中间人帮助建立连接,主要负责:

1:信令的处理,如媒体协商消息的相互转发传递

2:管理房间信息。比如房间进出、人员信息变化、状态连接变化等。所以也叫信令服务器也叫房间服务器。

下一篇继续,下一篇介绍环境搭建

上一篇:19.x86游戏实战-创建MFC动态链接库


下一篇:鸿蒙 LazyForEach 踩坑