Android WebRTC 音视频开发总结（三）-- 信令服务和媒体服务

前面介绍了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,客户端压力可大大减轻。 

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

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