- 更新:2020-09-26 21:50:04
- 首发:2020-08-20 20:09:34
- 教程
- 7923
coturn是主流的开源 TURN
and STUN
服务器软件,支持诸多规范、功能和数据库。coturn
的出现对于WebRTC
的发展有着举足轻重的影响。
鉴于官方文档已经非常详尽,本文仅列举几个常见问题,具体的部署方法不再一一赘述。
coturn
开源仓库地址:https://github.com/coturn/coturn
配置参数
external-ip=IP
user=username:password
realm=turn.example.com
以上三个参数为满足系统运行最基本的参数。监听的是默认端口3478
。
需要注意的是,external-ip
需填写公网IP地址或公共IP地址(参考下文中“关于内网WebRTC”)。如果服务器位于NAT之后,则可以填写为external-ip=1.2.4.8/192.168.1.1
这样的形式,即public-ip[/private-ip]
。
realm
参数则为新版本的必填参数。(不知道从什么时候开始,这个参数变为必填参数,网上大部分文章都没有提到该参数,不填则系统无法正常工作。参照李超
老师的指导,随便填一个值就行,域名也不用解析)
以守护进程方式运行coturn
:
turnserver -L <public_ip_address> -o -a -f -r <realm-name>
基于Docker部署需要注意的问题
https://github.com/instrumentisto/coturn-docker-image,此项目是较多star的coturn docker image。
使用此项目的镜像,需要注意三个问题:
- 建议以
--network=host
方式运行coturn
的Docker
容器。Docker
部分版本在监听大量端口的时候,会消耗非常多的资源并可能产生异常。 Dockerfile
中默认指定了--external-ip=$(detect-external-ip)"
的参数,其中detect-external-ip
命令是请求外网服务器并返回公网IP地址,此方法不适用于内网WebRTC部署
。同时,由于该参数的存在,配置文件中就不能再填写external-ip
,可以直接覆盖此参数。- 使用
Docker
运行coturn
,在进行相应的健康检查时,需要留意对使用的端口状态也进行检查,避免因端口异常导致影响业务。
关于内网环境下的WebRTC部署
WebRTC的TURN/STUN服务
可以在内网进行部署,但是大部分场景下需要确保所有地址都可以访问到一个公共IP地址
。例如政务内网和企业专网处于不同的网段,但都可以通过31.1.2.3
的地址访问到TURN/STUN服务器
,这样就可以确保系统正常使用。
如果不处于同一网段,则可以考虑在路由器或其它网关设备上进行NAT设置,也就是进行IP转发。例如A内网访问B内网服务器使用31.1.2.3
这个IP,但是在B内网访问A内网中同一台服务器是10.0.0.3
这个IP,在A内网和B内网网段不冲突的情况下,可以将10.0.0.3
转发到31.1.2.3
来实现互通。
sudo iptables -t nat -A OUTPUT -d 10.0.0.3 -j DNAT --to-destination 31.1.2.3
基于Docker
内网部署,可以参考《Docker 内网部署 离线部署》。
如果不能设置到同一个公共IP,或者服务器本身存在多张网卡,亦或者中继服务器位于多层NAT后。这些情况都是可以实现互通的,接受付费咨询。
WebRTC部署调试技巧
- 可以访问
http://getip.icu/地址获取不同条件下当前客户端的公网IP地址(仅供WebRTC开发人员测试网络使用),也可以使用curl getip.icu
获取到公网IP地址。【2023年7月更新:该地址滥用人数过多,已被关闭】 - 经过授权的情况下,调试内网环境WebRTC可以参考《MacOS同时使用内网和外网(双网卡同时联网)》。
- 可以在一段通过
nc -l <端口>
监听端口,再在另一端通过nc -v <IP> <端口>
检查对应端口的连通情况。 - 可以通过https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/测试
TURN/STUN服务
部署的情况。其中ICE
选项里的IceTransport
为relay
,是测试仅TURN
服务下的情况。返回的数据中,显示Type
为srflx
表示STUN
服务可用。显示Type
为relay
且最终Done
表示TURN
服务可用。该项目也可克隆到内网环境进行ICE测试。
暂无内容
感谢回复! Clang 在生成时沿用了 GCC 的版本号标识,我是不是可以理解为Clang 18.1.4生成时使用的就是GCC4.8,所以我后续使用gcc 9.4
gcov
就会有不兼容的问题抱歉,这块我也不太清楚,尝试寻求AI的帮助吧。
我在这个过程中遇到了各种问题- -,现在在UDC core: g_serial: couldn't find an available UDC卡住了,请问大佬有什么解决方案吗,还是说我前置的设置就错了呢,> 这个需求很特殊。是可以的,但是比较困难,需要修改驱动配置。
好思路呀!!
关于hex编辑器,网上没找到特别好用的(小白没办法),最后在vscode上扩展一搜hex,第一个安装一下就可以用vscode进行hex编译了