Android WebRTC 音视频开发总结（三）

前面介绍了WebRTC的基本结构，本节主要介绍WebRTC音视频的实现，通过前面的例子我们知道运行WebRTCDemo即可看到P2P的效果，实际应用中我们不可能让用户自己去里面设置对方的IP和音视频端口，而且即使设置了对方的IP和端口也不一定能运行起来，因为P2P的双方如果不在同一个网段下还需穿透NAT，即打洞，下面介绍两种达到实用效果的方法：



1、增加中转服务器：增加一台公网服务器，客户端先将RTP包发给公网服务器，然后再通过服务器转发给对方，这就不存在打洞的问题了，说到这里有人可能会问，这种做法跟它里面提供的AppRTCDemo有啥区别？其实如果只做一对一视频的话AppRTCDemo可以满足要求，如果要支持多人视频会议则要考虑搭一个中转服务器了。

2、搭建STUN服务器：打洞的原理理解了其实很简单，主要思路就是自己发一个包给STUN服务器，STUN服务器告诉我们自己在公网上的IP和端口，然后将这个公网IP和端口发给对方，对方也是做同样的事情，彼此都得到了对方在共网上的IP和端口后即可开始音视频了，开源STUN代码很多，网上也有很多介绍这方面的问题，有兴趣的可以找相关资料来看，这里面他包括NAT类型判断。



思考：通过对NAT的比较深入的研究，你会发现内网下多重NAT穿透是个比较麻烦的事情，不知道QQ是咋搞的，不过有一点很确定，很多情况下他也没有穿透，最终都是走转发的，希望在这方面有所研究的大侠能指点指点。



实际应用中可能得考虑上面两种方法结合使用，原因如下：

1、P2P方式性能明显优于服务器中转，毕竟手机上受到带宽和硬件性能的限制，效果肯定没有PC好，所以P2P方式更适合用户。

2、在打洞不成功的情况下（有些网络是不能打洞成功的，如进程严格受限的那种路由器），必须使用中转模式。



WEBRTC里面其实已经提供了上面两种解决方案，所以使用AppRTCDemo进行一对一视频的时候，他会分别连接STUN和TURN，前者用来处理打洞，后者用来转发（对应TurnServer和RelayServer），两者相结合就是ICE了，有兴趣的可以看看/article/1436738.html，讲得很好很详细。