WebRtc音视频实时通信--基本术语

墨蓝 2022-05-20 00:23 430阅读 0赞

要实现基于WebRTC的实时音视频通信功能，应至少首先弄清以下以个相关概念，各关键字可以通过RFC相关介绍进一步详细了解，在此仅以最简单的描术方式让您弄清他们大概是什么：

*  候选地址（Candidates）:  
    一个候选地址可理解为一组IP+端口号+优先级+网络类型组成的字符串。每个终端因网络环境不同可能有多个候选地址，比如我们的手机同时具有4G网络地址和wifi给分配的局域网地址。
 *  NAT:   
    可理解为一个防火墙或一个网关或路由器。比如我们的手机在使用wifi的情况下，我们的IP地址一般是192.168.0.1这种局域网地址，这时我们可以说我们在手机端在NAT后面，不是直接拥有公网地址。
 *  STUN服务器：  
    一个位于公网的具有公网IP的服务器，我们位于NAT后面（局域网内）的终端可通过访问STUN服务器来获取我们所有的候选地址。其实就是我在局域网内，我不知道自己的IP地址，不知道自己的公网IP地址也不知道自己的网络类型，这时我可以问STUN服务器，当我向其发消息时，身处公网的STUN服务器会将其收集到的我的网络信息发送给我。STUN服务器可以在github上找到并在某个公网机器上搭建一个，也可以使用已知的公用的一些STUN服务器，网上可以搜到很多。
 *  TURN服务器：  
    这个目前可以先忽略，主要是用来应急用的。当两个想建立连接进行音视频通信的网络环境都很复杂，都处于NAT后面且双方始终无法建立连接时，可通过连接到TURN服务器的方式，用其帮忙转发音视频流。因TURN服务器身处公网，所以大家都可以连接上它。
 *  SDP：  
    是一个媒体信息描述文件，用于描述自身的能力，比如我的浏览器想做为一个终端与另一端进行音视频通信，我应该告诉对方我是否支持音频或视频通信，以及我所支持的编解码格式，我是否支持丢包重传，FEC校验等等。  
    另外，也可以把candidates（候选地址）添加到SDP中，一并告诉对方可以连接到我的地址是哪几个。
 *  OFFER：  
    由通话发起端发出的SDP叫做OFFER
 *  ANSWER：  
    由通话接受端发出的对应对方OFFER的应答SDP文件叫做ANSWER。是SDP文件在通话发起方和接受方的不同名称。
 *  信令服务器（SIP）：  
    是实现WEBRTC通信很重要的一个部件，主要负责交换2个终端的候选地址（Candidates）和媒体信息描述文件（SDP）。  
    当2个终端都在NAT后面时，双方都不知道对方的地址也无法连接到对方，而且双方也不知道对方所支持的媒体类型以及是否支持某些特定的网络协议。因为需要一个身处公网的服务器（信令服务器）来为双方交换这些信息。  
    信令服务器也可以起到房间管理的作用。可以在整个通信过程中与双方客户端始终保持长连接来通知双方房间状态，比如有人离开，会议结束等等。  
    信令服务器仅用于发送一些命令及转发一些连接用的信息和媒体信息，不能用作TURN服务器，TURN服务器是用于在双方无法建立连接的时候代为转发音视频流数据包的。不是必需的，而信令服务器是必需的。
 *  JitterBuffer:   
    是webrtc源码中用于缓存接收到的视频流数据包的一个动态BUFFER，因为网络状态是不稳定的，而且音视频数据包是以UDP的方式发送的，在网络中传输时，无法保证按顺序到达。而为了保证视频流输出流畅，需要在播放端对视频流数据包进行重排序，只要对包进行重排序就需要进行缓存，而缓存长度过大会导致迟延增大，过小会导致丢帧。JitterBuffer是一个可依网络动态变化而变化的BUFFER，会自动伸缩长度。对于视频质量的提高有很大作用。但应注意webrtc中的jitterBuffer吐出的数据是以帧为单位的，目前主要用于接收端。  
    另外，对于H264编码减少B帧的使用对于提高实时性也有一定帮助，因为B帧是中间过度帧，其需要参考前后2个帧才能计算出自身帧数据。因此会等待后面的帧，可能会造成一定延迟。
 *  NetEQ:   
    类似于JitterBuffer的功能，是作用于音频的在播放端的一个动态buffer,对于提高音频通话质量，减少延迟具有很大作用。但需注意它吐出的数据是以10ms固定间隔的。此外NetEq还具有其他一些功能比如加减速丢包隐藏等，来弥补网络差时的情况。
 *  发送者报告（SenderReport）:  
    一般称为SR消息，在任何一端作为数据发送端时，都应该实时以固定间隔（如200ms）发送SR消息给数据接收端。用于报告自己已经发送了多少数据包等信息。
 *  接收者报告（ReveriverReport）:  
    也叫RR消息，在任何一端作为接收端时，当接收数据流的同时应该以固定时间间隔，如500ms发送一个描述自己接收情况的信息给对方，主要包含接收了多少数据包，在接收过程中丢失了多少数据包，上一次接收到的SR消息是谁（可以通过某规则为接收到的每一个SR消息进行标识，双方需要一致）等等。
 *  发送者和接收者报告消息非常重要，很多网络信息需要通过他们获得或根据他们的到达时间来计算出来。这些信息会用于JitterBuffer,NACK，带宽估计等模块。
 *  NACK（丢包重传）：  
    在TCP连接中，我们是通过发送一个包，接收到对方的ACK（确认消息）消息来确认对方正确收到了我们发出的包，继而发送下一个数据包的。但在UDP连接中，我们是不会等待对方反馈的。但对方可以在确定某包丢失未收到的情况下，向发送端发送一个NACK消息来告知发送端某个包或某几个包未收到。希望对方重传。
 *  SSRC （源标识符）  
    比如一个音频流或一个视频流我们可以称为一个发送源，每个源都有一个唯一的标识，叫SSRC，比如一个客户端可以同时接收多路视频流，则也就有了多个SSRC，在一个链路通道中，我们是使用SSRC来区分每一个数据包是属于哪个视频源的。进而将此数据包解码后渲染在正确的窗口。
 *  PacedSender (步长发送器)  
    因为视频是按帧采集的，一帧视频数据量在比较大的时候需要拆分成多个RTP包进行发送，如I帧，如此便 会造成各RTP包的发送间隔不规律，属于一帧的各RTP包可能在很短暂的时间间隔内发送出去了，如1ms内，然后等待了几十ms之后才开始发送第二帧的第一个RTP包，这样各RTP的发送间隔不规律会造成瞬间的发送码率过大，可能会因此丢包等。加入一个PacedSender可尽量平均各RTP包（帧内或帧间）的发送间隔时间。  
    —-未完待续