前面介绍了WebRTC的基本结构，本节主要介绍WebRTC音视频的实现，通过前面的例子我们知道运行WebRTCDemo即可看到P2P的效果，实际应用中我们不可能让用户自己去里面设置对方的IP和音视频端口，而且即使设置了对方的IP和端口也不一定能运行起来，因为P2P的双方如果不在同一个网段下还需穿透NAT，即打洞，下面介绍两种达到实用效果的方法，转载请说明出处（博客园RTC.Blacker）：
1、增加中转服务器：增加一台公网服务器，客户端先将RTP包发给公网服务器，然后再通过服务器转发给对方，这就不存在打洞的问题了，实际上很多视频会议都是这么实现的,在多人视频通讯的情况下如果都通过P2P来实现则会给客户端带来很大的压力,特别是手机端负载有限的情况下,这个方法的弊端尤为明显,但如果通过RelayServer,客户端压力可大大减轻。
2、搭建STUN服务器：打洞的原理理解了其实很简单，主要思路就是通过STUN服务器获取自己的ip,port及NAT信息，然后通过信令服务器交换这些信息,最后两客户端根据各自得到的ip,port,NAT信息进行相应的穿透，现在开源STUN代码很多，网上也有很多介绍这方面的问题，有兴趣的可以找相关资料看看.
补充:不过对NAT进步一研究你会发现内网下多重NAT穿透是个比较麻烦的事情，网上有一些专门研究多层NAT穿透的论文,有兴趣的可以去了解,正因为STUN方式不能完全解决P2P问题,所以后面出现了ICE,而libjingle就是ICE思想的具体实现,有兴趣请看后面的相关文章。
实际应用中可能得考虑上面两种方法结合使用，原因如下：
1、P2P方式性能明显优于服务器中转，毕竟手机上受到带宽和硬件性能的限制，效果肯定没有PC好，所以P2P方式更适合用户。
2、在打洞不成功的情况下必须使用中转模式。
WEBRTC里面其实已经提供了上面两种解决方案，所以使用AppRTCDemo进行一对一视频的时候，他会分别连接STUN和TURN，前者用来处理打洞，后者用来转发（对应TurnServer和RelayServer），两者相结合就是ICE了，有兴趣的可以看我后面介绍ICE的文章。

本文链接:https://www.it72.com/499.htm