coturn的用于webrtc的测试

coturn是一个开源的turn/stun的服务器,大家可以使用它进行webrtc的测试搭建。当然也可以用于生产环境。此文只是介绍其用于测试环境如何配置其用户于验证。这里可以配合apprtc-go的测试进行说明。

coturn服务器是包括了turn和stun这两个服务的。如果你只需要stun服务。按照下边的命令启动就可以。(假设turn服务器和apprtc-go服务器都运行在192.168.2.170上,另外,如果需要测试turn服务,需要把连接的两台机器分别放在不同的网段,相互之间不能访问,才能发挥turn的功效)

turnserver --no-auth --stun-only -v
参数说明:
--no-auth  不做用户认证,只有stun可以不用用户认证,
                turn服务,在iceServer中必须给出用户名认证等,
                要不然页面建立peerConnect的时候报错。
--stun-only  服务器制作stun服务,不做turn服务。
-v       打印log信息。请不要用-V,大V的信息量太多了。

apprtc-go的启动需要添加stun参数給,命令如下

./apprtc-go -cert=$GOPATH/src/github.com/daozhao/apprtc-go/mycert.pem \
                      -key=$GOPATH/src/github.com/daozhao/apprtc-go/mycert.key  \
                      -httpport=8080 -httpsport=8888 \
                      -stun=192.168.2.170:3478

iceServer返回json,只有stun服务器列表。

{"iceServers":[
{
   "urls": [
           "stun:192.168.2.170:3478"
           ]
}
]}

这样在浏览器就可以键入https://192.168.2.170:8080,就可以进行测试。建议使用两台机器,并连接到不同的的子路由器下进行测试。

测试turn服务,固定用户名,密码

turnserver -v  --user=daozhao:12345 --realm apprtc  --no-stun
参数说明:
--no-stun 不启动stun服务,所有stun的包都被忽略。
--user  用户名和密码 组合形式username:password
--realm  域标志,其实这个在这里随便写就可以。
             但是不能不写,要不然认证失败401

apprtc-go启动的时候添加turn服务器参数,使用静态用户名密码。

./apprtc-go -cert=$GOPATH/src/github.com/daozhao/apprtc-go/mycert.pem \
            -key=$GOPATH/src/github.com/daozhao/apprtc-go/mycert.key \
            -httpport=8080 -httpsport=8888 \
            -turn=192.168.2.170:3478 -turn-username=daozhao -turn-password=12345

iceServers返回,注意,如果使用turn服务列表,必须有username和credential。这里的用户名密码是静态的。

{"iceServers":[
{
    "urls": [
      "turn:192.168.2.170:3478?transport=udp"
    ],
    "username": "daozhao",
    "credential": "12345"
  }
]}

测试turn服务,动态验证用户名,密码:

turnserver -v  --user=daozhao  --realm apprtc --static-auth-secret=654321  --no-stun
参数说明:
--static-auth-secret  认证加密需要的key
--user   有static-auth-secret设置时候,这里只需要写用户名。
             不要写密码,要不然认证失败401

apprtc-go启动命令行。

./apprtc-go -cert=$GOPATH/src/github.com/daozhao/apprtc-go/mycert.pem \
            -key=$GOPATH/src/github.com/daozhao/apprtc-go/mycert.key \
            -httpport=8080 -httpsport=8888 \
            -turn=192.168.2.170:3478 -turn-username=daozhao -turn-static-auth-secret=654321

iceServers返回,注意这里是一个动态的用户名密码。这个用户名密码的计算方法:
用户名由两段组成 timestamp:username
credential的计算方式 base64(sha1_HMAC(timestamp:username,secret-key))
详细的参考这里

{"iceServers":[
{
    "urls": [
      "turn:192.168.2.170:3478?transport=udp"
    ],
    "username": "1504596938:daozhao",
    "credential": "k/yZNM4Jfofkqqa7ygBP5yCstow="
  }
]}

下边是一个完全事例。

turnserver -v  --user=daozhao  --realm apprtc --static-auth-secret=654321 
./apprtc-go -cert=$GOPATH/src/github.com/daozhao/apprtc-go/mycert.pem \
            -key=$GOPATH/src/github.com/daozhao/apprtc-go/mycert.key \
            -stun=192.168.2.170:3478 \
            -turn=192.168.2.170:3478 -turn-username=daozhao -turn-static-auth-secret=654321 \
            -httpport=8080 -httpsport=8888

iceServer返回:

{"iceServers":[
{
    "urls": [
      "stun:192.168.2.170:3478"
    ]
  }
,
{
    "urls": [
      "turn:192.168.2.170:3478?transport=udp"
    ],
	"username": "1504598153:daozhao",
	"credential": "+pUWOR9wKKgBRXQoLJ7tl2PlFSA="
  }
]}

参考链接:

http://www.cnblogs.com/lingdhox/p/4209659.html

http://www.cnblogs.com/kakawater/p/7112925.html

https://stackoverflow.com/questions/30745153/turn-server-for-webrtc-with-rest-api-authentication?noredirect=1&lq=1

在chrome上调试webrtc踩坑记

最近又再次用chrome测试webrtc的demo(https://appr.tc/)。 为了有更多的控制性,和测试两个客户端不同的网络环境的情况是否可以通讯。此网站是google提供的测试网站并且提供了网站的全部源代码(https://github.com/webrtc/apprtc)。可以自行部署在自己的机器上。部署webrtc的服务器,如果想访问摄像头的功能必须部署https。或者你只能通过localhost来访问。apprtc提供的代码是需要部署 Google App Engine SDK for Python的。或者使用使用这个docker(piasy/webrtc-build),使用说明。不过存在一个问题,就是它们都不支持https的访问,如果用chrome来调试,就只能本机访问。或者你在做一个https和wss的转发代理。

上述的方法我并没有采用,我是用golang重写了一次这个demo的python部分。代码请去https://github.com/daozhao/apprtc-go。为什么重写这个,当然有原因,这里就不说了。

先说说我的发现的bug。我发现在windows的chrome经常建立不了呼叫和应答,出不了视频图像。有时候可以有时候不可以。搞不懂。使用的官方的appr.tc的网站测试和自己搭建的测试环境都一样。但是我在mac OS X上的chrome肯定是可以的。实在搞不懂。

测试了很久,终于发现规律了。就是我如果是通过Mac OS X 上的Microsoft Remote Desktop去登陆windows进行操作,进行测试是没有任何问题的。但是如果我是直接在windows的主机上操作就是老出不到图像。或者,先remote过windows,chrome进行过呼叫,并出过图像,然后再在windows主机操作,这样也是可以的。这个真的令我奇怪不已。

不过找其他同事的windows机器测试并没有此问题。真的傻了,chrome升级了一遍又一遍,卸载重装。问题依旧。后来细心思考了一会儿,估计出问题是截屏问题,因为我的windows是台式机,并没有摄像头。呼叫或者应答的时候是输出桌面的截屏视频的。后来我在主机接上了一个usb摄像头。并在chrome的设置使用该摄像头。发觉问题解决了。这个问题搞了我2天。真的TMD。

在这个bug解决后,我继续思考。chrome的桌面输出是需要在启动的时候添加参数才可以。我由第一次使用chrome测试webrtc就没有打开过这个参数,就可以输出桌面的。我开始并不以为然。以为网上的资料有错,由或者我之前打开了chrome的测试模式。现在看来这个桌面输出并不是chrome自带的。而且我安装了一个第三方的截屏输出的驱动。而chrome把它也当作一个摄像头。我查询了一下这个截屏输出是screen-capture-recorder。原来这个东西和chrome有点不合。不过我在别的同事也安装了这个插件的机器上,并没有我的问题。看来是版本的原因。

WebRTC Native code在MacOS编译踩坑记

想编译WebRTC的源代码,想测试下一些东西。其实官方有说明怎样编译的。理论上也是比较简单的。但是非常不幸的是。webrtc的源代码在墙外。这个源代码据称有8G那么大。不过最后发觉压缩后还有10G多。

代码怎样下载?虽然webrtc用的是git管理代码,但是他的下载是用另外一套工具下载的,具体为什么我也不知道。而且我发觉他下载的代码除了webrtc外还包含了chrome的代码,还有一些第三方的工具。下载这个代码最困难的是由于是巨大的容量,而且不支持断点续传。google是怎样想的,这么大的容量还不支持断点。虽然可以挂VPN进行代码下载。但是需要非常稳定的VPN。而且速度也要快。我想不出哪里可以提供这么稳定的vpn,有时候不是vpn不稳定,而是自身网络也不一定稳定。现在想到的办法是在海外创建VPS服务,把代码拉好了。然后打包下载回来。

由于本身在DigitalOcean有VPS。所以就在上边进行拉取。由于用的是最低的配置,没有拉多久,git就报内存不足了。TMD的。谁叫你穷,买的是512M的内存服务器,现在手机的内存都比你多尼?最后找了国内的云主机供应商的香港云主机。搞个4G内存。下载代码就是非常快了。最后把代码拉到Mac上。不过发觉编译有问题。

第一个问题:

>gn gen out/mac –args=’target_os=”mac” target_cpu=”x64″ is_component_build=false’
gn.py: Could not find gn executable at: /Users/daozhao/Documents/sourcecode/WebRTCdemo/webrtc_macos_test/src/buildtools/mac/gn

找不到命令,怎么搞的。居然找不到命令。看了看gn的代码,发觉有一个chromium编译路径可设置在环境变量的。然后我设置了这个,在这个目录下再创建了一个mac的目录。把depot tools工具都放在这个mac目录中。

export CHROMIUM_BUILDTOOLS_PATH=XXXXXXXX

这样重要可以运行gn生成工具了。结果有悲剧了。又显示了一个错误。

gn fork: Resource temporarily unavailable

网上google了这个错误。没有发现编译webrtc的时候有别人出现这个错误,在其他地方会会出现这个错误,原因是mac os系统有限制创建线程数量。大家可以输入。

>launchctl limit
cpu         unlimited unlimited
file size  unlimited unlimited
data        unlimited unlimited
stack      8388608 67104768
core       0 unlimited
rss         unlimited unlimited
memlock unlimited unlimited
maxproc 709 1064
maxfiles 256 unlimited

最后把参数调大。但是还是报同样的错误。现在我怀疑mac有专用的gn工具的。在同步代码的时候应该是根据系统下载相关的工具。由于我是使用linux系统下载的代码,下载了linux的编译工具,没有下载mac的工具。需要再次运行gclient sync,当然运行这个命令是需要vpn的。但是由于有之前的下载,不用所有东西都重新下载,只是下载很少一部分工具而已。

rm src/links #需要先删除这个文件,要不然会报错。
gclient sync
rm -rf src/third_party/llvm-build
gclient sync

这时候可以从新运行gn生成工具了。

>gn gen out/mac –args=’target_os=”mac” target_cpu=”x64″ is_component_build=false’
Done. Made 347 targets from 107 files in 5461ms

到了这里就可以编译了,编译时间比较久,

WebRTC入门指导

这篇文章是记录之前研究的webRTC的记录,最近准备再次走进WebRTC,所有写下一些资料,以免忘记的时候可以看看。

入门看什么文章比较好,当然是WebRTC的官方网站的Getting Started。不过资料比较多,而且上边列表的资源重复也不少。

Getting started的推荐的2013的google IO关于WebRTC的视频就别睇了,没有什么营养。大家看这三篇对webRTC入门的文章比较好,Getting Started with WebRTCWebRTC in the real world: STUN, TURN and singlingWebRTC data channels,基本上把WebRTC的结构说得个明白。可以对WebRTC有一个很好的整体了解。

对于入门的代码例子就看这个codelab,进阶少少的例子就看WebRTC samplesWebRTC-Experiment,还有一个完全可以用的Demo的线上例子,别忘记了这个Demo的有很多参数可以调整的,请查看参数设置

看完上边的资料,你已经对WebRTC有了基本的了解了。如果你做WebRTC的前端或者关于Signaling的后端开发,这些知识基本够用了。不够如果要深入研究WebRTC,需要做二次开发或者做MCU的话就需要进入步研究了。

由于WebRTC是P2P的,首先需要研究的了解UDP打洞。关于打洞的问题请看Peer-to-Peer Communication Across Network Address Translators这个是关于P2P的网络神作。如果觉得文章复杂,不如先看看这些入门级的文章:穿越防火牆技術P2P通信原理与实现。再找些开源的STUN服务器研究下。

其实需要研究的东西还是比较多的,不过站在巨人的肩膀好办事。这里列几个比较出名的WebRTC开源项目吧,

1. http://www.kurento.org/

2.Licode

https://doubango.org/ 这个是项目有SIP的部分,有webrtc2sip的转换。兼容SIP系统较好选择。

4. https://mediasoup.org/ 这个是nodejs + c的项目,属于SFU,不是mcu。

5. https://janus.conf.meetecho.com/ Janus一个比较出名的项目,纯C写的项目。

WebRTC有一个比较烦人的问题,Web服务必须使用https来部署,要不然浏览器不给使用相关的api,这样做开发测试的时候比较麻烦。