软路由openwrt详细设置（WebRTC入门教程WebRTC信令控制与STUN）

网络信息消息网络信息消息用于两个客户端之间交换网络信息。在WebRTC中有三种类型的候选者，它们分别是：主机候选者反射候选者中继候选者主机候选者，表示的是本地局域网内的IP地址及端口。其优先级低于主机候选者。在WebRTC内部会探测用户的NAT类型，最终采用不同的方法进行NAT穿越。在WebRTC信令服务器端，收到网络消息信令，即message消息时，不做任何处理，直接转发。offer消息中的内容是Amy的SDP信息。第七步，Bob将anwser消息通过信令服务器传给Amy。

软路由openwrt详细设置?在前面的文章中已经向大家介绍了如何构建信令服务器但构建的信令服务器是如何工作的？哪些消息需要信令服务器控制和中转？这些此前并没有做详细的说明，而本文将对这些问题做详细的讨论，下面我们就来说一说关于软路由openwrt详细设置?我们一起去了解并探讨一下这个问题吧!

软路由openwrt详细设置

在前面的文章中已经向大家介绍了如何构建信令服务器。但构建的信令服务器是如何工作的？哪些消息需要信令服务器控制和中转？这些此前并没有做详细的说明，而本文将对这些问题做详细的讨论。

另一方面，在真实的网络中，WebRTC是如何进行NAT穿越的呢？如果穿越不成功，我们又该如何保证用户服务的呢？这些知识也将在本文中给出答案。

信令

WebRTC 信令控制的架构图如下所示：

信令服务器用于交换三种类型的信息：

会话控制消息：初始化/关闭，各种业务逻辑消息以及错误报告。
网络相关：外部可以识别的IP地址和端口。
媒体能力：客户端能控制的编解码器、分辩率，以及它想与谁通讯。

下面我们就来详细讨论一下这三类消息：

会话控制消息

会话控制消息比较简单，像房间的创建与销毁、加入房间、离开房间、开启音频/关闭音频、开启视频/关闭视频等等这些都是会话控制消息。

对于一个真正商业的WebRTC信令服务器，还有许多的会话控制消息。像获取房间人数、静音/取消静音、切换主讲人、视频轮询、白板中的画笔、各种图型等等。但相对来说都是一引起比较简单的消息。

在我们之前的例子中，服务端只处理了一个会话消息 create or join，即房间的创建与加入消息。代码如下：

...socket.on('create or join', function(room) {var clientsInRoom = io.sockets.adapter.rooms[room];var numClients = clientsInRoom ? Object.keys(clientsInRoom.sockets).length : 0;if (numClients === 0) {socket.join(room);logger.debug('Client ID 'socket.id' created room 'room);socket.emit('created', room, socket.id);} else if (numClients === 1) {io.sockets.in(room).emit('join', room);socket.join(room);socket.emit('joined', room, socket.id);io.sockets.in(room).emit('ready');} else { // max two clientssocket.emit('full', room);}});...

该代码的逻辑非常简单，当收到 create or join 消息后，判断房间里当前人数，如果房间里的人数为 0，说明是第一个人进来，此时，需要向连接的客户端发送 created 消息；如果房间里的人数为 1，说明是第二个人进来，需要向客户端发送 joined消息；否则发送 full 消息，说明房间已满，因为目前一个房间最多只允许有两个人。

网络信息消息

网络信息消息用于两个客户端之间交换网络信息。在WebRTC中使用 ICE 机制建立网络连接。

在WebRTC的每一端，当创建好 RTCPeerConnection 对象，且调用了setLocalDescription 方法后，就开始收集 ICE候选者 了。

在WebRTC中有三种类型的候选者，它们分别是：

主机候选者
反射候选者
中继候选者

主机候选者，表示的是本地局域网内的 IP 地址及端口。它是三个候选者中优先级最高的，也就是说在 WebRTC 底层，首先会偿试本地局域网内建立连接。

反射候选者，表示的是获取 NAT 内主机的外网IP地址和端口。其优先级低于 主机候选者。也就是说当WebRTC偿试本地连接不通时，会偿试通过反射候选者获得的 IP地址和端口进行连接。

其结构如下图所示：

在上面这幅图中可以看到，WebRTC通过 STUN server 获得自己的外网IP和端口，然后通过信令服务器与远端的WebRTC交换网络信息。之后双方就可以尝试建立 P2P 连接了。

以上就是我们通常所说的 P2P NAT 穿越。在WebRTC内部会探测用户的 NAT 类型，最终采用不同的方法进行 NAT 穿越。不过，如果双方都是对称NAT 类型，是无法进行 P2P NAT 穿越的，此时只能使用中继了。

中继候选者，表示的是中继服务器的IP地址与端口，即通过服务器中转媒体数据。当WebRTC客户端通信双方无法穿越 P2P NAT 时，为了保证双方可以正常通讯，此时只能通过服务器中转来保证服务质量了。

所以中继候选者的优先级是最低的，只有上述两种候选者都无法进行连接时，才会使用它。

在 WebRTC 信令服务器端，收到网络消息信令，即 message 消息时，不做任何处理，直接转发。代码如下：

socket.on('message', function(message) {socket.broadcast.emit('message', message);});

客户端接收到 message 消息后，会做进一步判断。如果消息类型为 candidate，即网络消息信令时，会生成 RTCIceCandidate 对象，并将其添加到 RTCPeerConnection 对象中，从而使 WebRTC 在底层自动建立连接。其代码如下：

socket.on('message', function(message) {...} else if (message.type === 'candidate') {var candidate = new RTCIceCandidate({sdpMLineIndex: message.label,candidate: message.candidate});pc.addIceCandidate(candidate);} else if (...) {...}});

交换媒体能力消息

在WebRTC中，媒体能力最终通过 SDP 呈现。在传输媒体数据之前，首先要进行媒体能力协商，看双方都支持哪些编码方式，支持哪些分辨率等。协商的方法是通过信令服务器交换媒体能力信息。

WebRTC 媒体协商的过种如上图所示。

第一步，Amy 调用 createOffer 方法创建 offer 消息。offer 消息中的内容是 Amy 的 SDP 信息。

第二步，Amy 调用 setLocalDescription 方法，将本端的 SDP 信息保存起来。

第三步，Amy 将 offer 消息通过信令服务器传给 Bob。

第四步，Bob 收到 offer 消息后，调用 setRemoteDescription 方法将其存储起来。

第五步，Bob 调用 createAnswer 方法创建 answer 消息，同样，answer 消息中的内容是 Bob 的 SDP 信息。

第六步，Bob 调用 setLocalDescription 方法，将本端的 SDP 信息保存起来。

第七步，Bob 将 anwser 消息通过信令服务器传给 Amy。

第八步，Amy 收到 anwser 消息后，调用 setRemoteDescription 方法，将其保存起来。

通过以上步骤就完成了通信双方媒体能力的交换。