基于WebRTC的Android移动端无线视频传输-AET-电子技术应用

基于WebRTC的Android移动端无线视频传输

胡勋，周渊平

（四川大学电子信息学院，四川成都 610065）

摘要： 视频传输技术在现代社会广泛应用，人们对其的要求也越来越高，其发展的趋势是方便、快捷、随时随地。传统的视频传输过于依赖线路，线路的走向限制了传输的很多可能，所以无线传输才是发展的方向。本文提出了一种基于WebRTC的Android移动端视频传输技术，介绍了信令与WebRTC连接实现机制，以及穿透的具体过程。

关键词： 信令安卓 WebRTC

Abstract：

Key words :

　　摘要：视频传输技术在现代社会广泛应用，人们对其的要求也越来越高，其发展的趋势是方便、快捷、随时随地。传统的视频传输过于依赖线路，线路的走向限制了传输的很多可能，所以无线传输才是发展的方向。本文提出了一种基于WebRTC的Android移动端视频传输技术，介绍了信令与WebRTC连接实现机制，以及穿透的具体过程。

　　关键词：信令；安卓；WebRTC

0 引言

　　本文提出了一种在移动端上（Android）的视频传输技术，选取了两台Android设备作为测试设备，方便快捷，而且可携带性强。移动智能终端作为监控端也是一个最佳的应用平台。随着谷歌Android的飞速发展[1]，越来越多的人选择Android平台来观察视频数据。

1 技术简介

　　（1）Android系统

　　Android是基于Linux开放性内核的操作系统，也是一个开放的移动终端操作系统平台，为移动设备提供了一个包含了操作系统及应用程序的软件叠层架构。Android作为Google最具创新的产品之一[2]，越来越多地被移动终端厂商使用和二次开发。Android具有很多特性，最大的特性是开放性，还有就是在其平台上开发的应用程序权限由开发人员决定。

　　（2）WebRTC

　　WebRTC是Google于2011年6月3日开源的即时通讯项目[3]。它是一个支持网页浏览器进行实时语音对话或视频对话的技术，其出现可以帮助Web浏览器、个人电脑或手机实现实时多媒体通信功能。WebRTC提供了各种实现视频会议的核心技术，包括音视频的采集、编解码、信号优化和处理以及网络传输等。

2 系统设计及实现

　　系统设计主要包含三个部分：音视频模块、信令服务和打洞服务。

　　2.1 音视频模块

　　VoiceEngine（WebRTC音频引擎）是包含一系列音频多媒体处理的框架，包括从视频采集卡到网络传输端等整个解决方案。ISAC（Internet Speech Audio Codec）是针对VoIP和音频流的宽带和超宽带音频编解码器，是WebRTC音频引擎的默认编解码器。NetEQ for Voice是针对音频的语音信号处理算法、自适应抖动控制算法以及语音包丢失隐藏算法。能够快速且高解析度地适应不断变化的网络环境，确保音质优美且缓冲延迟最小，能够有效地处理由于网络抖动和语音包丢失对语音质量产生的影响。VideoEngine（WebRTC视频处理引擎），是包含一系列视频处理的整体框架，是从摄像头采集视频到视频信息网络传输再到视频显示整个完整过程的解决方案。VP8视频图像编解码器是WebRTC视频引擎的默认编解码器，VP8适合实时通信应用场景，因为它主要是针对低延时而设计的编解码器。Video Jitter Buffer（视频抖动缓冲器），可以降低由于视频抖动和视频信息包丢失带来的不良影响。对音视频模块VoiceEngine和VideoEngine进行编译使用，首先要到Google上下载安卓NDK，然后还要安装其他一些工具。以下对两个库文件简单解释，voe_audio_processingadds消噪（NS）：自动增益控制和回声控制；voe_rtp_rtcp：增加了RTCP发送器报告、RTP／RTCP统计、前向纠错（FEC）和RTP实时捕捉。

　　2.2 信令服务

　　信令服务的作用是在通信双方都不知道对方的IP以及端口的情况下建立连接。由服务器建立连接来实现。WebRTC实现了两个API，分别是：MediaStream：通过MediaStream的API能够通过设备的摄像头及话筒获得视频、音频的同步流；RTCPeerConnection：RTCPeerConnection是WebRTC用于构建点对点之间稳定、高效的流传输的组件。WebRTC使用RTCPeerConnection传递数据，但传递数据之前，需要一种机制来协调通信并发送控制信息，而这种机制就是信令机制。WebRTC并没有制定任何信令的机制和协议，所以可以灵活选择任何信令协议[4]。Openfire是一种开源的实时协作（RTC）服务器，本文设计用它作为信令服务器。

　　信令交换的信息有：（1）用来控制通信开启或者关闭的连接控制消息；（2）媒体流元数据，比如解码器、解码器的配置、带宽、媒体类型等；（3）发生错误时彼此告知的消息；（4）外界所看到的网络上的数据，如IP地址、端口等；（5）用来建立安全连接的关键数据。

　　具体的连接建立方式由一种叫JSEP（JavaScript Session Establishment Protocol）的协议来规定，使用JSEP的原因在于在JSEP中需要交换的关键信息是多媒体会话描述（Multimedia Session Description）。JSEP将客户端之间传递的信令分为两种：offer信令和answer信令。它们主要内容的格式都遵循会话描述协议（Session Description Protocal，SDP）。通过offer和answer交换SDP描述符，流程如下：

　　（1）A和B双方建立一个RTCPeerConnection实例。

　　（2）A通过createOffer（）方法建立一个包含A的SDP描述符的offer信令。

　　（3）A通过setLocalDescription（）方法，将A的SDP描述符交给A的RTCPeerConnection实例。

　　（4）A将offer信令通过服务器发送给B。

　　（5）B将A的offer信令中所包含的SDP描述符提取出来，并通过setRemoteDescription（）方法交给B的RTCPeerConnection实例。

　　（6）B通过createAnswer（）方法建立一个包含B的SDP描述符的answer信令。

　　（7）B通过setLocalDescription（）方法将B的SDP描述符交给B的RTCPeerConnection实例。

　　（8）B将answer信令通过服务器发送给A。

　　（9）A接收到B的answer信令后，将其中B的SDP描述符提取出来，调用setRemoteDescripttion（）方法交给B的RTCPeerConnection实例。通过这一系列的信令交换之后，A和B所创建的RTCPeerConnection实例都包含了A和B的SDP描述符了。

　　2.3 打洞服务

　　打洞服务就是为了获取连接两端设备的网络地址[5]。要实现P2P视频传输，实际应用中不可能让用户自己去设置对方的IP和音视频端口，而且即使设置了对方的IP和端口也不一定能运行，因为P2P视频传输过程中，如果双方不在同一个网段则还需穿透NAT。

　　打洞原理：主要思路就是通过STUN服务器获取自己的IP、Port及NAT信息，然后通过信令服务器交换这些信息，最后两客户端根据各自得到的IP、Port、NAT信息进行相应的穿透。STUN是一种网络协议，可以让处于NAT后的客户端找出自己所处的公网IP地址，而且可以获取自己的NAT类型，以及一些相关的端口信息，这些信息用来在两个处于NAT之后的主机建立UDP通信。STUN由RFC 5389定义，是一个客户机－服务器协议，由于每个peer可能处于不同的网络中，所以每个peer都需要NAT穿越，确保双方都可访问对方的IP地址和端口以及STUN服务器。在RTCPeerConnection中，使用ICE框架来保证RTCPeerConnection能实现NAT穿越。ICE（Interactive Connectivity Establishment），交互式连接建立，是一种综合性的NAT穿越技术，可以整合各种NAT穿越技术，如STUN、TURN（Traversal Using Relay NAT，中继NAT实现的穿透）。ICE会先使用STUN，如果失败，ICE就会使用一个中继的TURN服务器。图1为iceServers配置信息。

　　在iceServers配置对象（RTCPeerConnection constructor）中设置STUN and/or TURN服务器地址信息，包括IP地址、端口号等。有了这些信息ICE会自动启动。STUN服务架设在外网，它有一个简单的任务：获取一个发送请求的设备（运行在NAT后边的应用）的IP和端口，然后返回这个地址。换句话说，应用使用STUN服务器发现它的外网IP和端口，这个过程确保了一个WebRTC端获得它自己的公共地址，然后通过signaling机制发送这个信息给另一端，这样就可以建立起一个直接连接。在实际应用中，不同的NATs有不同的工作方式，可能有多个NAT层，但是原理是一样的，原理如下：

　　（1）A通过公共IP与服务器建立连接。

　　（2）A发送一个加入某房间的信令，并设置房间号，信令中需要包含该房间的编号。

　　（3）若有新用户B加入，B会向服务器发送一个请求信令（new_peer），信令中包含新加入的用户B的信息以及房间号。

　　（4）若房间号相同，则建立A和B的通信连接。

　　系统框架如图2所示。