基于RTP的WebRTC音视频传输优化方法

李 波, 李雪梦, 王彦本

(西安邮电大学 通信与信息工程学院, 陕西 西安 710121)

网页实时通信(Web real-time communication,WebRTC)集成了音视频的采集和显示、网络传输等核心技术，可在不同平台下，实现浏览器之间的音视频通信[1]。与C/S和B/S架构相比， WebRTC无需下载相关插件，方便快捷[2]。但是，无线信道带宽资源属于稀有资源，在数据传输过程中，WebRTC受到无线信道自身时变及带限等特点的影响，容易造成音视频数据传输不流畅和质量低等问题。

目前，WebRTC主要采用实时传输协议(real-time transport protocol，RTP)进行音视频实时传输，对RTP报文结构进行压缩，或者调整RTP的分包方式，可减小传输数据的大小，减缓网络压力，但不能从实质上避免无线网络环境下WebRTC音视频传输中出现的网络延时和丢包问题[3]。本文拟在RTP协议进行音视频数据实时传输时，根据网络状况及时开启丢包重传机制，同时动态调整抖动缓冲区大小，以期降低丢包率，保证音视频传输质量。

1 RTP/RTCP协议

RTP协议[4]作为实时传输协议，可以在单个发送者与单个接收者或单个发送者与多个接收者的情况下工作，其目的是提供时间信息以及实现流同步，但仅有RTP协议并不能保证传输的可靠性。在传输过程中，还需依靠实时传输控制协议(real-time transport control protocol,RTCP)提供流量控制和拥塞控制[5]。RTP协议之所以能实现数据传输的实时性，主要依靠报文中序列号和时间戳等关键信息。RTP头字段格式如图1所示。

RTP协议与RTCP协议在工作中相互协作，一般承载在用户数据报协议(user datagram protocol,UDP)之上。RTP协议使用一个偶数UDP端口号，RTCP协议则使用一个相邻的奇数UDP端口号；RTP保证数据传输的实时性，RTCP协议则负责数据的可靠传输，以保证服务质量[6]。

2 RTP传输优化方法

WebRTC是基于Web浏览器的实时音视频的通信技术[7]，主要包括音频模块、视频模块和传输模块3个部分，其结构如图2所示。其中传输模块由RTP/RTCP协议负责，RTP报文头部提供了负载类型、时间戳、序列号和同步源等信息保证基本的音视频传输需求[8]。

在WebRTC中，发送端采集好数据，由传输模块对其进行封包并交给网络模块进行发送；同理，在接收端将收到的数据进行解包，再交由其他模块进行处理[9]。开启一个RTP会话之后，参与此会话的通信双方将周期性的发送RTCP报文，报文中包含通信双方发送及接收数据的具体统计信息，对服务质量做出反馈[10]。根据RTCP协议的反馈，可在网络传输层通过丢包重传和动态调整抖动缓冲区大小等方法降低丢包率，以此提高音视频传输质量。

2.1 丢包重传

实时音视频传输过程中，丢包现象会导致音视频不流畅。丢包重传机制(negative-acknowledge character,NACK)[11]就是否定应答，在实时音视频传输中，对于丢失的包，可以给对端发送NACK包，请求对端重新发送[12]。依据RTCP报文的反馈，选择性发起NACK请求，若丢失的包对整体数据没有太大影响，则不需要进行重传，可通过其他容错机制保障可靠性，减少因重传而带来的延时问题。NACK报文是RTCP扩展反馈报文，具体格式如图3所示。

图3 NACK报文格式

图3中， NACK报文统计RTP包丢失的序列号，以及继该包之后的16个RTP数据包的丢失情况。在每个NACK报文中，都可以携带一个或多个RTP序列号，接收端会依次进行处理[13]。接收端收到NACK请求后，分析报文，根据报文中包含的RTP序列号，到相应的RTP缓存中查找需要的RTP包，如果找到，则把数据包发送到网络，丢失的数据包就会重新发送到接收端，完成丢包重传。

2.2 缓冲区大小的动态调整

网络中存在路由变化和网络拥塞等问题，在传输数据包时，它并不总是按时间和顺序均匀到达，此时需要设置缓冲区存放这些数据包并对这些数据包重新进行排序，消除网络中存在的网络抖动等状况[14]。

若缓冲区设置过小，缓存的数据包较少，系统会发起重传，导致重传较多；若缓冲区设置过大，又会增加在缓冲区中等待的延时。因此，根据网络状况动态调整缓冲区大小，在网络条件好的时候，将缓冲区大小设置为较小缓冲区，此时发起丢包重传，可在较短时间内完成，从而降低延时；网络条件较差的时候，将缓冲区大小设置为较大缓冲区，但此时网络条件较差，较多的重传会加重恶化网络环境。缓冲区运行机制如图4所示。

缓冲区首次接收到RTP数据包时，会将其放置在从空帧队列弹出的空帧块当中。之后每次接收到一个RTP包，就会根据时间戳在已存在的帧中寻找，确定是否已经接收过相同时间戳的包，再找到具有相同时间戳的RTP数据包，弹出此帧块，否则将会从空帧再次弹出一个空帧。根据RTP包的序列号，找到应该插入帧的位置，并更新帧状态。其中帧状态有空、残缺、可解码和完整4个状态，空表示没有数据的状态；残缺表示至少有一个包的状态；可解码表示当前的帧处于可解码状态；完整表示这一帧所有数据都已经到齐，可以进行其他操作。

图4 buffer运行机制

3 测试系统搭建

在Linux环境下搭建WebRTC的房间服务器(room server)、信令服务器(signaling room)和穿越服务器(ICE Server)，构建音视频会话测试系统。

3.1 房间服务器

房间服务器用于创建和管理会话。在AppRTC房间服务器[15]的基础上，通过获取其源码并配置constants.py文件，将IP地址改为本机IP地址，创建房间服务器。访问房间服务器如图5 所示。

图5 房间服务器

3.2 信令服务器

信令服务器用于管理和协助通话终端建立点对点通话，主要有控制通信发起或者结束，及通信双方建立安全连接等作用。通过信令服务器，通信双方可以获知对方的IP地址等相关信息，还可以就会话媒体类型、编解码方式、传输协议和媒体格式等相关信息进行协商。信令服务器的搭建沿用了Collider服务器[15]。

3.3 穿越服务器

穿越服务器用于穿越防火墙或者带有网络地址转换(network address translation，NAT)功能的路由器,让两个同处于私有网络里的计算机能够通信[15]。

穿越服务器的结构如图6所示。

图6 穿越服务器示意图

4 测试结果及分析

在音视频会话测试系统里，将PC端与手机端分别接入网络，并保证没有其他设备连接同一网络，开启音视频通话，与此同时打开WireShark抓包工具，获取在网络状况较好时，音视频通话过程中传输的RTP/RTCP包；再将手机端移至WiFi信号差的位置，重复上述过程，获取网络状况较差时的RTP/RTCP包，对比两种情况下丢包率的测试结果如图7所示。

图7 两种情况下丢包率的对比结果

由图7可以看出，在网络状况较差的情况下，丢包率仍能控制在7%以下，能够保证音视频的流畅传输。通过丢包重传机制和动态调整抖动缓冲区大小能够保证在无线环境下的音视频传输质量。

5 结语

采用RTP协议进行音视频实时传输时，WebRTC音视频传输的优化方法通过开启丢包重传机制，动态调整抖动缓冲区大小，能够保证音视频的流畅传输。构建音视频会话测试系统，利用WireShark抓包，分析实时音视频的丢包率。测试结果表明，该方法有效改善了无线环境下音视频的传输质量，在网络状况较差时，系统仍能保证音视频通信的流畅性。