WebRTC中的RTP协议、RTCP协议、DSP协议

实时互动直播系统必须使用UDP作为数据传输的协议，为什么一定是UDP。TCP是一种可靠的传输协议，会保证在传输的过程中不丢包，UDP传输的速度快，但是不可靠，尤其是用户网络质量很差的情况下，会出现大量的丢包，基本无法保证音视频的服务质量。

假如我们使用TCP协议作为数据传输的协议，在极端网络情况下，TCP为了保证传输的可靠性，就会进入“发送->确认；超时->重发”的反复过程。

比如，A和B之间使用TCP进行通信，A首先向B发送数据，并启动一个计时器，当B接收到来自A的数据之后，B会向A发送一个ACK确认信息，表示当前包已经成功接收，反复这样的操作，数据源就会安全的从A流向B。在这个过程中，要是由于某些原因，A一直没有收到B的ACK确认消息，当A的计时器超时之后，A就会重新向B发送这个没有被B确认接收的消息包。

TCP为了避免重传次数过多，定时器会按照2的倍数增长，假如第一次设置的超时时长是1秒，把么第二次就是2秒，第三次就是4秒....第七次就是64秒。如果第七次仍然超时，则断开TCP链接。那么在极端网络情况下，从A和B之间开始传输数据超时，到A主动断开TCP链接需要经历的超时时长会达到2分07秒。而这样的超时时长在直播系统中是无法接受的。

基于上面的原因，实时直播系统的数据传输协议必须是UDP。

RTP/RTCP

在一般情况下，实时互动直播系统在传输音视频流数据的时候，并不直接把音视频数据交给UDP传输，而是首先给音视频数据添加RTP头，然后再交给UDP进行传输。

以视频帧为例（一个视频帧包括I/P/B帧），一个I帧的数据量是非常大的，至少需要几十K，而以太网的最大传输单元是1.5k，所以一个视频帧完整的传输到对端是需要发送几十个包才能完成的，而当数据包传输到对端之后，对端还需要将这几十个数据包重新组装，这样才可以正确的解码还原出一副完整的图像帧。对端接收到的数据包理论上是杂乱无序的，为了能够解码出一幅幅完整有序的图像帧，接收到的包中至少包含三个信息：

序号：用于标示传输包的序号，这样就可以知道一个传输包是帧的第几个分片数据了；

• 起始标记：记录一个帧的第一个UDP包数据；
• 结束标记：记录一个帧的最后一个UDP包数据。

有了上面3个标记字段，就可以将一大堆无序的UDP数据包中进行有序的排列分割，从而解码出一幅幅图像帧。

RTP协议：

上面就是RTP协议，其中一些重要的字段以及含义：

• sequence number:序号，在数据拆分的时候用于记录数据包的顺序，以便对端在重新组合时候进行有序的组装；
• timestamp：帧的时间戳，同一帧的不同分片包的时间戳是一样的，而不同帧的时间戳一定是不一样的，这样对端在接收到数据之后，就可以把时间戳一样的包归档在一起，同一帧内部再通过序号进行排列，从而解析一个图像帧，这样就省去了UDP数据包的起始和结束的标志；
• PT：PayloadType，数据的负载类型，音频流的PT值和视频流的PT值是不一样的，根据PT值可以区分当前的包是哪种类型的数据。

...
{V=2,P=0,X=0,CC=0,M=0,PT:98,seq:13,ts:1122334455,ssrc=2345},
{V=2,P=0,X=0,CC=0,M=0,PT:111,seq:14,ts:1122334455,ssrc=888},
{V=2,P=0,X=0,CC=0,M=0,PT:98,seq:14,ts:1122334455,ssrc=2345},
{V=2,P=0,X=0,CC=0,M=0,PT:111,seq:15,ts:1122334455,ssrc=888},
{V=2,P=0,X=0,CC=0,M=0,PT:98,seq:15,ts:1122334455,ssrc=2345},
{V=2,P=0,X=0,CC=0,M=0,PT:111,seq:16,ts:1122334455,ssrc=888},
{V=2,P=0,X=0,CC=0,M=0,PT:98,seq:16,ts:1122334455,ssrc=2345},
{V=2,P=0,X=0,CC=0,M=0,PT:111,seq:17,ts:1122334455,ssrc=888},
{V=2,P=0,X=0,CC=0,M=0,PT:98,seq:17,ts:1122334455,ssrc=2345},
{V=2,P=0,X=0,CC=0,M=0,PT:111,seq:18,ts:1122334455,ssrc=888},
{V=2,P=0,X=0,CC=0,M=0,PT:98,seq:18,ts:1122334455,ssrc=2345},
{V=2,P=0,X=0,CC=0,M=0,PT:111,seq:19,ts:1122334455,ssrc=888},
{V=2,P=0,X=0,CC=0,M=0,PT:98,seq:19,ts:1122334455,ssrc=2345},
{V=2,P=0,X=0,CC=0,M=0,PT:111,seq:20,ts:1122334455,ssrc=888},
{V=2,P=0,X=0,CC=0,M=1,PT:98,seq:20,ts:1122334455,ssrc=2345}, 
...

有了RTP协议，上面的这组UDP数据包我们就可以很容易的进行有序的组装了。

RTCP协议

在使用RTP协议传输协议的时候，难免会发生丢包、抖动的问题：

• 网络质量引起的丢包；
• 数据传输过程中超过了带宽限制引起的丢包；
• 信号干扰引起的丢包；

WebRTC在处理各种情况下的丢包情况都会有相应的处理策略，但是在处理这些问题之前，WebRTC的两端首先需要知道自己和对方的网络情况，这就是RTCP的作用。

RTCP中有两个重要的报文：RR（Reciver Report）和SR（Sender Report），通过这两个报文的交换，各端就可以知道自己的网络状况了。

上面是RTCP协议的规范

RTCP中除了RR报文和SR报文之外，还有其他的报文，比如FIR报文，即完整帧请求报文，FIR也是RTCP协议中一个非常重要的报文，假如一个房间中有3个人进行视频通信，当第4个人加入该房间的时候，通过之前对音频数据的压缩规范H264可以知道，视频编码器会将一段视频流数据编码成一组一组的GOP（Group Of Picture）发送给接收端，这组GOP中有一个关键帧I帧以及多个P/B帧，要想完整的解码出当前的GOP数据，就必须知道I帧，要是地4个人加入的时候，一直没有新的GOP发送，那么第4个人接收到的只有P/B帧没有I帧，而我们知道没有I帧是无法解码出图像帧的，而I帧只有在一组GOP开始传输的时候才会发送，接下来只发送P/B帧，第4个人为了能够正确的解码视频帧，就会发送一个FIR报文，当其他人接收到这个FIR报文的时候，就会立即将自己的I帧发送给FIR报文的发送者（也就是第4个人），这样第4个人在收到I帧之后，才可以结合后续接收到的P/B帧解码出完整的图像帧。

WebRTC的驱动核心SDP协议

SDP（Session Description Protocal）是用文本描述的各端能力。这里的能力指的是各端所支持的编解码器是什么，这些编解码器需要设定的参数是什么，使用的网络传输协议是什么，以及包含的音视频媒体是什么等等。

两端在建立WebRTC通信的一开始，首先会进行信令交互，而信令交互过程中一个重要的信息就是SDP信息的交换，WebRTC的终端会将自己的编解码器信息、网络传输信息等写入到SDP中传输给对方，在一方收到对方的SDP信息之后，会和自己的SDP信息进行比对，获得双方SDP的交集，作为后续音视频交互的协议。

WebRTC在标准的SDP协议的基础上进行了调整，将SDP按照功能进行了划分：

• Session Metadata：会话的元数据
• Network Description：网络描述
• Stream Description：流描述
• Security Descrition：安全描述
• Qos Grouping Description：服务质量描述

WebRTC利用通过SDP进行媒体协商

媒体协商的作用是为了让双方找到共同支持的媒体能力，WebRTC的双端是使用RTCPeerConnection进行端对端的链接的，RTCPeerConnection对象在WebRTC通信的过程中可以做很多事情，包括媒体协商、NAT穿透、音视频数据的接收和发送、还可以进行非音视频数据的发送和接收。

在双端进行媒体协商之后，通讯双方首先会准备好RTCPeerConnection对象，双方进行媒体协商的过程中会彼此发送SDP信息，关于双方的SDP信息，有两个概念：Offer和Answer：

• Offer：呼叫方发送SDP信息；
• Answer：被呼叫方发送的SDP信息。
• 1. 呼叫方创建Offer类型的SDP信息，调用setLocalDescription方法将该Offer保存到本地Local域中，然后将Offer发送给被呼叫方；
• 2. 被呼叫方收到Offer类型的SDP信息之后，调用setRemoteDescription方法将Offer保存到本地Remote域；
• 3. 被呼叫方创建一个Answer类型的SDP信息，调用setLocalDescription方法保存到本地，并将Answer作为回应发送给呼叫方；
• 4. 呼叫方收到Answer类型的SDP信息之后，调用setRemoteDescription将该SDP信息保存到本地的Remote域。

经过上面的步骤，整个媒体协商过程就完毕了，在WebRTC内部会比较两个域下的SDP信息，并计算获得最终的媒体协商的结果。