用SRS搭建WebRTC流媒体服务器实战

Webrtc已经成为视频及时互动的标配，日常业务系统中，很多需要web打开就能视频通话，实现类似微信视频聊天的功能，但实施是在web上，由于还有业务app集成，同时也要在app原生端实现。

经过多次分析和参考google的官方demo,开发总结了一下：

1，webrtc库尽量要匹配，如现在主流浏览器支持的是webrtc，m79,原生端尽量用这个原生库打包。

2，web的全平台兼容挺难的，特别是ios上只支持safari内置版本，api和chrome稍有差异。

3，实施上视频摄像头对chrome 64位兼容不不是太好，建议自行封装成chrome内核的客户端

4，webrtc如只是p2p不需要特别服务器，自已开发信令服务就可以啦，当要安装turn server 国内常有打洞不成功需要转发。

效果：

​​​

测试：>WebRTC需要通过长链接查找到通信双方，然后通过 peer to peer 的方式传输音频数据。

WebRTC中最主要的就是一个叫做 PeerConnection 的对象，这个是WebRTC中已经封装好的对象。每一路的音视频会话都会有唯一的一个 PeerConnection 对象，WebRTC通过这个 PeerConnection 对象进行视频的发起、传输、接收和挂断等 *** 作。
PeerConnection中包含的属性如下：

PeerConnection 中还包含了一些方法：

RTCSessionDescription 类型中包含了两个属性：

A向B发起通信请求

首先WebRTC需要一个信令服务器，也就是一个socket链接用来发起视频通信，发送WebRTC中的 offer 和回复 answer 。
如何搭建一个简单的socket服务器，可以找我的这篇文章《》，也可以是用webSocket搭建信令服务器。

WebRTC需要打洞服务器（一个 stun ，一个 turn ）来穿透防火墙等，我们需要配置打洞服务器：

WebRTC由于是未来的一种即时通信的标准，所以目前在Chrome、Firefox和Opera浏览器中有内置插件，均提供一个全局的PeerConnection类。

创建PeerConnection的对象：

创建时需要传入打洞服务器的配置信息，如果不穿入打洞服务器的配置信息，则只可以在内网中使用实时音频通讯。

由于PeerConnection是全局的，所以我们可以通过另外的一种方式进行创建：

如何判断浏览器是否支持WebRTC：

WebRTC也提供了一个全局单例来获取本地的音视频信息：

GetUserMedia需要传入三个参数，第一个参数为配置信息，第二个参数为获取成功的回调，第三个参数为获取失败的回调。
获取到视频流之后

创建一个offer并发送给指定的对象：

创建offer时要同时发送打洞服务器配置信息，WebRTC给了一个监听：

返回的参数中有一个 candidate 属性，便是打洞服务器的配置信息。

音频通话请求是通过socket发来的，需要通过socket去监听。

如果收到了offer，那么需要将offer存到自己的peerConnection中，并且创建一个answer发送回对方。
将offer存入peerConnection中：

创建一个answer并返回给对方：

如果收到了打洞服务器的配置信息，那么需要将打洞服务器的配置信息存入到 peerConnection 中：

发送给对方answer后便可以等待接受对方的数据流了：

至此，整个简单的WebRTC的流程就完成了

在不同的网络环境(带有摄像头/麦克风多媒体设备)中，为两个浏览器实现点对点实时视频/语音通信有什么困难

1、了解对方的媒体格式、支持的最大分辨率和其他媒体信息？

2、要了解彼此的网络，就有可能找到一条通信链路？

3、两个终端还没有建立连接时,如何交换“媒体信息”和“网络信息”呢
为了保证两端都有正确的编码和解码，最简单的方法就是取它们的交集H264

注:有一种特殊的协议叫做Session Description protocol (SDP)，可以用来描述上述信息 。

在webrtc中，参与视频通信的双方必须首先交换SDP信息，这样双方才能了解基本的SDP交换过程。
同样，在复杂的网络环境中，要在两端之间建立连接，必须有一个双方都可以访问的链路。
从图中可以看出，他们可以使用公用网段192沟通。

在web brtc通信过程中，这些与网络相关的信息也必须进行交换，以找到共同的交集。这个过程也被称为“网络协商”。
两个终端还没有建立连接时,如何交换“媒体信息”和“网络信息”呢

此时，所谓信号服务器信号服务器应该出现:
如上图所示,两个浏览器可以抽象的上层一层信令服务器(可以是一个或多个,根据实际的应用程序中,如果两个浏览器可以访问公共网络环境,如公共如果没有公共网络环境中,您可以设置一组服务器两端,即信号服务器A和信号服务器B，但这两套信令服务器必须能够相互通信)，在信令服务器的帮助下，可以实现上述SDP信息和网络信息的交换。
交换SDP的过程大致如图所示:
1 Amy(假设一个人的名字)通过setLocalDescription方法保存自己的SDP信息，然后通过offer方法发送给信令服务器。

2 信息服务器将Amy的SDP转发给另一端的Bob(另一个虚构的名字)，Bob将首先调用setremotedescription来保存Amy的SDP。

3然后Bob调用setLocalDescription方法来保存他的SDP，然后使用answer方法通过信令服务器将他的SDP发送给Amy

4 Amy收到Bob的SDP后，调用setRemoteDescription进行保存，双方完成SDP交换，找到交集。如果他们能达成协议，他们就可以建立一个p2p连接并开始通信。
但现实往往是残酷的。在中国的网络环境下，据统计，至少有一半的网络不能直接连接。我个人认为根本原因是:在互联网发展的早期，绝大多数IP4地址资源都被国外所占据。当轮到中国等发展中国家使用IP地址时，大多数计算机没有公网IP地址，只能通过路由器和交换机进行NAT转换，相当一部分NAT是对称的。基本上，没有办法播放它。在这种情况下，您只能使用前一节提到的转向服务器进行转移。此外，在视频对话框中，通常会有房间(或组)的概念，用来隔离一些服务。这部分逻辑也在信号服务器中实现。对端、信令服务器、stun/转接服务器后，整个1对1实时视频通信顺序图如下:
主要流程如下:

1 双方首先调用getUserMedia打开本地摄像头

2 向信令服务器发送apply_join请求以加入房间

3信令服务器通知我成功加入(joined)，同时向其他人广播加入消息(other_joined)

4 第二个端开始创建peerConnection连接

5 PeerB创建报价，同时将SDP保存到本地机器(setLocalDescription)，并通过信令服务器将SDP传递给peerA

6 在setLocalDescription之后，PeerB将异步触发“候选网络链接”的集合，这大致决定了它自己所有的NAT映射通过Stun退出。如果Stun返回的NAT是“对称的”，它将基本上无法穿透。再次通过Turn得到中继应答地址，并通过信令服务器将网络候选链接信息发送给peerA(即:启动网络协商)

7 peerA收到peerB的SDP后，开始响应(createAnswer)，仍然通过信令服务器将SDP发送给peerB

8 同时，peerA也会开始收集网络候选链路，并通过信令服务器(即网络协商)将自己的网络信息发送给peerB。

通过这种方式，peerA和peerB相互交换了媒体信息和网络信息。如果他们能达成一致(即找到交叉点)，他们就能开始沟通。

---