android WebRTC视频通话

转自：http://www.cnblogs.com/lingyunhu/p/3578218.html

http://www.cnblogs.com/lingyunhu/p/3621057.html

总共20多篇文章，写得很不错，可以一片片参考

本系列文章主要总结和分享WebRTC开发过程中的一些经验，转载请说明出处（博客园RTC.Blacker），更多交流请看页面上方的子标题！

 

一、WebRTC是什么？

    可能您还不知道WebRTC是什么，但您一定用过他里面的东西，因为QQ就用到了他的核心技术，不过那时候这些东西还不叫WebRTC，他也还掌握在GIPS手里（他们家的语音技术可谓独步天下），而且当年小马哥也给人家交了不少USD，扯远了。

 

    WebRTC是Google于2011年6月3日开源的即时通讯项目，旨在使其成为客户端视频通话的标准。其实在Google将WebRTC开源之前，微软和苹果各自的通讯产品已占用很大市场份额（如Skype），Google也是为了快速扩大市场，所以将他给开源。经常接触开源的人应该很容易理解Google这种策略，只不过在国内大家都喜欢弄成SDK，然后按年按月按用户数给你收费，总让你觉得不爽。

 

    刚接触WebRTC的时候你会被里面的一堆概念搞晕，特别是对没接触过音视频的人来说，如WebRTC, ICE, STUN, TURN, P2P, NAT, Jingle, TALK, VOIP, FFMPEG, H264, VP8, NACK, RTP, RTCP, RTSP, RTMP, SIP, XMPP, ISAC, ILBC, OPUS, G711, G722.   晕了吧，凡事都要有个过程的，一步步来吧！不懂了就问问度娘或GOOGLE，再不懂就发个邮件给我（左边有联系方式），咱们一起交流，不过问之前请先将问题描述清楚，节省大家时间也便于交流。

 

二、WEBRTC代码如何获取和编译。

1、环境准备:对刚入门的人来说编译WEBRTC很头疼，特别是对没接触过linux的人来说，虽然网上有很多资料，但是实际编译过程中总会出现这样或那样的错误，很多错误都不知所措。其实编译不过的主要原因就是有些文件下载不下来（因为国家防火墙限制），所以这里给出一个编译WebRTC的最简单的解决方案：

A、买一个付费的VPN账号。

B、参考：http://www.webrtc.org/reference/getting-started，很详细，看仔细。

这个方案屡试不爽，我已经成功编译过好几次了，如果还有问题可以联系我（对andorid开发者来说最好使用ubuntu 64位环境，不要在windows下面搞。）。

C、最近这个代码越来越难下了，所以我也不会去轻易更新，或者我就直接去香港下载，强吧！

 

三、运行WebRTCDemo。

A、安装WebRTC/Trunk/out/WebRTCDemo-debug.apk，他支持点对点视频，在其SETTINGS页签中设置好对方IP，点击MAIN页签中的StartCall即可与对方开始视频通话。

 

 

四、AppRTCDemo如何使用？

    WebRTCDemo可以直接做成P2P的效果，AppRTCDemo则需要另外一个服务端（也可直接连接：https://apprtc.appspot.com/），当然你也可以自己部署这个服务端，他是利用libjingle和XMPP来处理信令交互的，而且基于ICE协议实现P2P，至于什么是ICE,什么是STUN,TURN我在后面的文章中都有陆续讲到。

 

    AppRTCDemo的最大问题就是很多人不知道服务端怎么部署，而且他也没有实现手机对手机的效果，这个应用是很广泛的，最起码有智能家居，安防监控等行业的用户就请我帮他们做过这方面的技术支持，所以后面我打算将它做成一个通用的产品，供别人学习和使用。目前android和服务端已经完成了，IOS正在抽时间处理。

 

五、

前面介绍了WebRTCDemo的基本结构，本节主要介绍WebRTC音视频服务端的处理，，转载请说明出处（博客园RTC.Blacker）。

 

通过前面的例子我们知道运行WebRTCDemo即可看到P2P的效果，实际应用中我们不可能让用户自己去里面设置对方的IP和音视频端口，

而且即使设置了对方的IP和端口也不一定能运行起来，因为P2P如果双方不在同一个网段则还需穿透NAT，那服务端具体该如何部署呢？

 

1、信令服务：

想知道信令服务的作用前您先想想通讯双方彼此都不知道对方在哪里，怎么与对方建立连接，怎么给对方发起视频请求？

想到这里我们是不是会想到双方都应该先跟一个服务器建立连接，所以这就是信令服务的作用，具体如下图：

2、打洞服务：打洞的原理理解了其实很简单，主要思路就是通过STUN服务器获取自己的ip,port及NAT信息，

然后通过信令服务器交换这些信息,最后两客户端根据各自得到的ip,port,NAT信息进行相应的穿透，

现在开源STUN代码很多，网上也有很多介绍这方面的问题，有兴趣的可以找相关资料看看.

补充:不过对NAT进步一研究你会发现内网下多重NAT穿透是个比较麻烦的事情，网上有一些专门研究多层NAT穿透的论文,

正因为STUN方式不能完全解决P2P问题,所以后面出现了ICE,而libjingle就是ICE思想的具体实现。

 

 

3、媒体转发服务：P2P失败时，客户端先将RTP包发给媒体服务，然后再通过服务器转发给对方，

实际上很多视频会议都是这么实现的,在多人视频通讯的情况下如果都通过P2P来实现则会给客户端带来很大的压力,

特别是手机端负载有限的情况下,这宗点点的转发方式的弊端尤为明显,但如果通过RelayServer,客户端压力可大大减轻。 

补充：如果要考虑多人视频，直播，如三方会议同时广播给几千人观看，这就设置到服务端的编解码，混音，屏幕叠加等等功能，

这是一个比较负责的课题，也是语音通信厂商的核心技术，后面会整理一篇文章专门介绍这方面的内容。