如何使用WebRTC创建视频呼叫应用

2020-06-15 09:04:38

常见的视频应用程序使用这项技术,称为WebRTC。WebRTC是最近的一项技术,允许开发人员使用您的日常互联网浏览器在Web上交换数据甚至媒体。这是十年来的一次技术变革,因为这样的功能只能作为插件使用,比如同花顺插件。

即使您没有听说过WebRTC,您可能以前已经使用过它。它们被用于WhatApps,Facebook,甚至Google讲义等。这就是所谓的Web实时通信,它允许你在浏览器之间进行直接连接。这项技术至少已经存在7年了,但我最终还是迎头赶上了!我设法创建了我自己的WebRTC应用程序,以便更好地了解该工具。

这是我的WebRTC应用程序,作为我的新玩具!请看这里。

魔术并不是真正的魔术。这只是一堆在表面下完成的密集工作。就像鸭子一样,它们看起来只是在水面上优雅地游动和滑行。但是当你看到这背后的作品时,你会发现这是一大堆老掉牙的玩意儿。

Web应用程序具有不同的组件。大多数都是看不见的,看不见的,比如服务器等等,但它们就像你的汽车引擎。当你开车的时候,你看不到它(除非你开的是一辆Doge Charger R/T),但这并不意味着引擎也不在那里。

本节我们将详细介绍在整个过程中如何以及何时需要STUN服务器。

这一节我们就简单介绍一下,你什么时候需要轮到服务器。并不是在所有情况下都需要它,但是如果您必须处理稍微不那么直接的用例,那么它是一个需要的组件。

5.对于不同的使用情形和优化的房间容量,可能的WebRTC架构有哪些

当我们谈论WebRTC时,主要有4种体系结构。当您使用ZOOM时,您有没有想过一台服务器如何能够处理多达160名成员的会议?这不是魔术,它实际上需要传输大量的数据,简单地说10分钟的通话就需要万亿字节的数据。

当我在玩我的新玩具时,我设法找到了一些有趣的工具和资源,以适合简单WebRTC应用程序的不同组件。

当我们第一次开始视频聊天会话时,您首先需要向房间发出信号,表示您已经到达。这种告诉别人你到了的方式叫做发信号。如果你是第一个到达聚会场所的人,严格来说,你仍然会打招呼,但不会有人回应你。

从技术意义上讲,信令是交互式连接建立框架的一部分,是通过交换媒体信息找到对方然后协调通信的过程。信令利用会话描述协议(SDP)来收集网络信息,例如用于媒体交换的网际协议地址(IP地址)和端口号。

会话描述协议(SDP),用作通告和管理会话邀请的标准方法。它以基于文本的格式表示浏览器功能和首选项。

为了使您的浏览器连接到其他浏览器,在SDP中交换的信息包含以下内容:

网络数据,例如外部世界看到的主机的IP地址和端口。

您需要有一个Web应用程序,该应用程序能够在加载或单击按钮时建立连接,然后在同一聊天室中显示由您的同行发送的视频数据。

从更专业意义上讲,您需要创建RTCPeerConnection产品,并将其发送到远程对等点以存储在自己的计算机中。一旦您完成了Web应用程序,您需要将您的Web应用程序托管在Web服务器中的某个位置,以便您的朋友可以公开访问它。

还记得我们提到的信号吗?它用于向特定房间中的所有成员表明您已到达。当您到达时,房间中的每个成员都会通过SDP记录您的远程信息和详细信息,并将其存储到他们的机器上-准备接收来自您的媒体数据。

从技术上讲,WebRTC负责SDP信息的创建和处理,而不是SDP信息的发送和接收部分。因此,此传输需要服务器。利用WebSocket服务器进行此传输和初始化是相当常见的。

此服务器用于检索远程对等方的公用IP地址。为了避免涉及技术细节,我们每个人都有一个公共IP地址,而STUN服务器是用来获取这些信息的。然后,此信息将成为您刚到达时需要发送给您的同行的SDP信息的一部分。

此服务器用作中间人,以便在您需要时为您传递消息,并且无法直接与您的远程对等方联系。有人在Quora中提出了这个问题,您可以在这里查看。

NAT会话穿越实用程序(STUN)。双方都必须至少知道其对等方的IP地址和分配的UDP端口。

无论使用哪种架构,我们总是需要一个信令服务器来注册和出席。我们需要一台TURN服务器来进行网络遍历,并确保内部IP地址可以映射到外部公有IP地址。

现在您可以看到,您的浏览器使用STUN服务器请求您的公共IP地址。这些都是在引擎盖下完成的,看不见。我学到的一件事是,魔术从来不是真正的魔术。幕后有很多事情在发生。如果你想学魔术的话?你必须学会这些幕后的步骤。

使用中继NAT的穿越是用于中继网络流量的协议。有时,当您使用TURN服务器并设法检索远程对等点的公共IP地址时,由于防火墙和一些与网络相关的工具(如果您有兴趣了解,请使用NAT),您需要一个网络可公开访问的TURN服务器来为您进行媒体中继。这有点像你的中间人帮你传递信息。

客户端对客户端,在电话会议中有3个客户端的情况下,将有2个连接需要加密和建立。正如您在下面的屏幕截图中所看到的,每个人都与每个人联系:

选择性转发单元在会话中间充当智能媒体中继。每个客户端连接到SFU一次以发送媒体,然后每隔一个客户端再连接一次,从而导致每个客户端管理n个单向连接,其中n是连接的客户端的数量。虽然此架构的总连接数为n^2,但客户端只在连接初始化时加密一次,这减轻了设备本身的压力,尤其是对于移动设备。

转发需要额外的服务器基础设施,如SFU,但效率很高。除非激活记录或对数据进行解码,否则SFU不会尝试解密数据包。

混合依赖于多点控制单元(MCU),它在会话中间充当高性能的媒体混合器。每个客户端连接到MCU一次,无论连接多少个客户端,都只需处理一个双向连接。该连接将用于从服务器发送和接收媒体。

就像转发一样,加密和上传只进行一次,但现在我们也只下载和解密一次。此方法在客户端上效率最高,但从服务器角度看效率最低。解包、解码、混合、编码和打包的负担完全在服务器上执行。此方法具有相当繁重的操作集,需要大量服务器资源才能实时完成。

对于具有大量活动参与者的应用程序(如虚拟教室)或设备特别受资源限制(如带宽)的情况,可以考虑使用此方法。这种架构是以服务器成本为代价的。

顾名思义,混合架构是网状、转发和/或混合的组合。因此,您可以根据最有意义的内容为参与者创建会话。

对于简单的两方呼叫,网格设置很简单,只需要最少的服务器资源。

对于小组会议、广播和现场活动,转发将最适合满足需求。

对于较大的小组会议或电话集成,混合通常是需要考虑的开放式实用选项。

WebRTC应用程序的问题一次又一次地发生在规模化的时候。它消耗了大量的数据。因此,如果您打算扩展WebRTC应用程序,考虑合适的体系结构将是第一场胜利。第二场战斗是数据流量问题。

在对500名参与者进行压力测试的情况下,分成5个参与者只运行6.5分钟的多方通话组。服务器实际上双向传输了52 GB的媒体流量。不到10分钟。

我找到了一个全面的YouTube视频,它可以帮助人们理解WebRTC应用程序是如何工作的。有趣的是,我们发现所有与WebRTC相关的YouTube视频都至少有几年的历史了。WebRTC已经有7年的历史了。我猜约书亚终于赶上了,我希望我今天能设法让你们了解这项古老的技术!