stun

我们用SIP 客户端呼叫的时候，经常遇到复杂的网络NAT环境，这个时候需要我们安装STUN Server / Turn Server 做穿透用。 这里简单记录下 STUN Server的安装启动步骤： yum -y install gcc yum -y install make yum -y install boost # For Boost yum -y install openssl # For OpenSSL wget http://www.stunprotocol.org/stunserver-1.2.3.tgz tar zxvf stunserver-1.2.3.tgz cd stunserver make 检查环境 是否OK ./stuntestcode nohup /usr/local/stunserver/stunserver --mode basic --primaryinterface 172.31.78.132 & nohup ./stunserver --mode full --primaryinterface eth0 --altinterface eth0 & 全功能模式 需要2个IP ./stunserver --mode full --primaryinterface 47.52.229.136 --altinterface 172.31.78

上一篇 P2P通信标准协议(一) 介绍了在NAT上进行端口绑定的通用规则，应用程序可以根据这个协议来设计网络以外的通信。 但是， STUN/RFC5389 协议里能处理的也只有市面上大多数的 Cone NAT （关于NAT类型可以参照 P2P通信原理与实现 ）， 对于 Symmetric NAT ，传统的P2P打洞方法是不适用的。因此为了保证通信能够建立，我们可以在没办法的情况下用保证成功的中继方法（Relaying）， 虽然使用中继会对服务器负担加重，而且也算不上P2P，但是至少保证了最坏情况下信道的通畅，从而不至于受NAT类型的限制。 TURN/RFC5766 就是为此目的而进行的拓展。 TURN简介 TURN的全称为Traversal Using Relays around NAT，是STUN/RFC5389的一个拓展，主要添加了Relay功能。如果终端在NAT之后， 那么在特定的情景下，有可能使得终端无法和其对等端（peer）进行直接的通信，这时就需要公网的服务器作为一个中继， 对来往的数据进行转发。这个转发的协议就被定义为TURN。TURN和其他中继协议的不同之处在于，它允许客户端使用同一个中继地址（relay address） 与多个不同的peer进行通信。 使用TURN协议的客户端必须能够通过中继地址和对等端进行通讯，并且能够得知每个peer的的IP地址和端口

STUN STUN协议为终端提供一种方式能够获知自己经过NAT映射后的地址，从而替代位于应用层中的私网地址，达到NAT穿透的目的。STUN协议是典型的Client-Server协议，各种具体应用通过嵌入STUN客户端与STUN Server端通讯来完成交互。 在典型的运用STUN进行NAT穿透的场景中，STUN客户端首先向位于公网上的STUN服务器 发送Binding Request消息，STUN服务器接收到请求消息后识别出经过NAT转换后的公网地址60.1.1.1:12345，将其附加在Binding Response消息中返回给客户端。客户端得到这个地址 后用它替换SDP中的私网地址与终端B完成媒体协商。使用STUN进行NAT穿透对应用的要 求是必须使用同样的端口与STUN服务器交互和进行应用层通讯，比如当希望使用端口 37000进行RTP包的NAT穿透时，必须同样使用37000端口与STUN服务器通讯，否则从STUN 服务器获得的NAT映射后的地址一般与实际地址时不一样的。另一个要求是STUN客户端与 服务器端的通讯和应用使用获得的NAT映射地址进行应用层通讯在时间上必须有连贯性， 这源于NAT设备建立的绑定有生存时间，当原绑定消亡后，NAT设备为同一个私网地址建 立的新绑定往往不同，因此转换后的公网地址是不同的。 STUN方案的特性如下表： 特性 说明 实现复杂度 实现简单

.WebRTC后台服务: 通话的房间服务器(Room Server) 房间服务器是用来创建和管理通话会话的状态维护,是双方通话还是多方通话,加入与离开房间等等,我们暂时沿用Google部署在GAE平台上的AppRTC这个房间服务器实现,该GAE App的源码可以在github.com上获取.该实现是一个基于Python的GAE应用,我们需要下载Google GAE的离线开发包到我们自己的Linux服务器上来运行该项目,搭建大陆互联网环境下的房间服务器. 通话的信令服务器(Signaling Server) 信令服务器是用来管理和协助通话终端建立去中心的点对点通话的一个角色.这个角色要负责一下任务: 1. 用来控制通信发起或者结束的连接控制消息 2. 发生错误时用来相互通告的消息 3. 各自一方媒体流元数据，比如像解码器、解码器的配置、带宽、媒体类型等等 4. 两两之间用来建立安全连接的关键数据 5. 外界所能看到的网络上的数据，比如广域网IP地址、端口等 信令服务器的具体协议实现没有严格规定,只要实现功能就OK. 我们这里依然沿用Google提供的基于GO语言和WebSocket的信令服务器Collider.和上面的房间服务器一并在Github上可以获取.获取到我们自己的Linux服务器上用GO语言的运行环境来运行该信令服务器. 防火墙打洞服务器(STUN/TURN/ICE

前面介绍了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失败时

搭建stun服务器的学习历程 选择stun服务器 最初先是寻找百度和github，然后基本定下来是coturn工具，打算参考 文章1 但是在这的配置过程中，发现需要配置openssl，于是转而搞openssl 又发现openssl是搭建https的重要工具，刚好webrtc在chrome中如果想要正常使用必须要https才可以，于是决定先搭个https的网站作为尝试 现在到了如何搭建https网站的时候了，参考用 这篇文章 总结起来，openssl在建https时可以先产生密钥，然后产生证书请求，再用请求获得证书，这样的过程。 其中当配置好了https后，发现原本的websocket被禁止了，可以参考 这篇文章 虽然现在搭好了https，但是由于正规流程还需要绑域名，做ssl认证，审核，还要改后台等等，最后还是不再继续搞了，继续使用openssl搭建stun服务器。 继续按照上面的教程，但是在最后key格式不对报错，于是转而参考其他文章： 文章1 文章2 之后由于我是centos环境，又参考了文章： 文章1 文章2 终于在文章2的配置下搭成了环境： 但是在 测试网站 上仍旧有问题 来源： CSDN 作者： wwwumr 链接： https://blog.csdn.net/qq_42116185/article/details/104123977

本文简介了Turnserver（Turn + Stun）服务器的搭建。Turnserver主要提供了stun服务，支撑NAT、防火墙穿透，turn服务器，支撑打洞失败时的数据中转。使用场景上类似于前端使用的WEBRTC音视频数据服务，在不同网络环境下可通过stun服务器进行打洞以及turn服务器进行中转，最终实现web前端上的音视频通信。 Turnserver 搭建 简介 webrtc的p2p穿透部分，一般都需要借助于turnserver，步骤大概是这样的 尝试直连 通过stun服务器进行NAT、防火墙穿透 穿透失败则依赖于turn服务器中转 一、安装turnserver（CentOS） 下载安装依赖库（依赖于libevent，最好也安装下mysql） 12345678910 yum install -y make automake gcc cc gcc-c++ wget #一般系统都带了gcc4，无需升级yum install -y openssl-devel libevent libevent-devel mysql-devel mysql-serverwget https://github.com/downloads/libevent/libevent/libevent-2.0.21-stable.tar.gztar -zxvf libevent-2.0.21-stable

上一篇文章分析了比特币P2P网络中，一个节点是如何发现并连接到相邻节点的。在P2P网络中，一个节点既是客户又是服务器，它还要接受其他节点的连接，为网络中其他节点提供服务。这篇文章着重分析一下比特币P2P网络中是如何通过upnp来实现端口映射的。 1 从腾讯的一道面试题说起 笔者所在团队的总监在面试的时候必然要问面试者这样一个问题： 有两台手机同时连到了一个WIFI上，然后它们都访问了外网中某个服务器，那么网络是如何做到区分出这两台设备，把服务器的应答数据分发到合适的手机上呢？ 如果在毫无准备的情况下来回答这个问题，自己还真是答不出来。 再想象一个场景：假设我们自己写了个小的服务器程序，然后在家里的电脑上运行，此时你想让另一个同事连接你的服务器，来验证你的服务器程序是不是能正确运行，但是明显你的网络和同事家的网络是两个不同的局域网，所以除非你去同事家或者让同事提上电脑到你家，否则无法连通。那么有什么办法做到让同事在自己家里就能点对点连上你的服务来调试么？ 2 NAT和NAT穿透 上一节提到的两个问题，实际上都和NAT有关。要弄清楚上一节的问题，需要先了解NAT，所以这里先来补点网络课，了解一下NAT以及NAT穿透。 2.1 NAT 2.1.1 NAT是什么 NAT是个什么鬼？它的全称是Network Address Translation，翻译过来就是网络地址转换