@rapiz 我的理解是相当于每个 peer 都和服务器建立 peer 连接了，服务器会对房间里的 peer 的音频 track 做转发。如果不用 sfu ，光是 p2p 这种，客户端每次需要发送 n-1 条音频给其他 peer ，但现在只需要发给服务器一次就可以了

上 cloudflare 吧

@PrtScScrLk servercat

@WLW 随便找个视频会议在线的网站就可以

@steptodream
@WLW

公司视频会议有很多系统方案可以用，公司的需求也很复杂，视频、桌面分享、权限管理、录屏啥的，还不如直接用商业方案好了

@lqzhgood 你查查 sfu

@XTTX 有没有研究过相关法律法规？服务器在国外的话需要遵循哪些条款？

@XTTX 语音要存储的确会导致成本飙升，还有审核的问题，我这个站很简单不需要考虑这些，也没有存储，如果做 sdk 肯定有很多别的要求，但只是做实时语音通讯技术倒不复杂（底层还是挺复杂的，但技术已经发展了十多年来，现在比较成熟）

@XTTX 一开始我就准备用 IaC 部署的，后来因为觉得没必要，就一台服务器手工部署半天搞定（熟练估计半小时搞定），所以只是记录了操作指南

@XTTX 没想到这都可以商业化，实际上这个技术挺成熟的，费用也没那么高，不知道为啥收费这么贵，我这服务器全部费用也才 5 美刀一个月，能支持 100 多个人实时通话应该没问题

@over140 大佬现身了，我只是用你们开源的搭建了这个网站，感谢你们的开源精神👍期望之后能给你们贡献代码😄

@qq316107934 ipv6 应该不支持吧，不知道底层的 pion 是否支持
@HXM 服务器在新加坡，降噪得靠耳机和麦了，浏览器做降噪的方案不知道有没有
@Chism 一对一聊天可以用这种模式，类似于游戏里组队 pk😂

@Funnyang 不支持，主要是语音，未来可能加文字，全功能的应用用 App 就好了，这个工具主要是简单
@Akagi201 rust 比 go 太复杂了，玩不了
@avastms erlang 的确更合适，但是还是语言和生态的问题，没选择
@ferock 不支持 docker ，主要是端口通信的问题，服务器端需要很大一个 udp 和 tcp 端口范围用来和客户端建立 p2p ，docker 有点麻烦
@XTTX 目前 server 实现了 turn （ coturn ），signal 的功能，也包括用户 token 生成（访问 turn ）。turn 本身就可以做 stun 的功能，turn 就是中转（ relay ）。功能不想做的太复杂，主要是基于语音找一些场景应用。
@Biwood p2p 直连在用户多的时候客户端负载太大了（指数关系），服务器目前是 sfu 架构，客户端直连服务器，服务器中转，这样 p2p 连接数只和用户数成线性

@LiuJiang 安卓的新版本 chrome 应该还行
@legendORld 我 iPhone 聊了一整天，没怎么发热
@cweijan 这个安装花了我一整天时间，主要是有一些小坑，但 c++开发的那些库功能很齐全，搞起来可能很复杂，go 这个代码也挺简单的

@okakuyang 如果是全部中转了，那按目前的采样率数据还挺小的，实时在线 20 多人，服务器网络流量每秒才 30-40KB （上行与下行都差不多这个范围）

@lloovve SFU 并不是用户与用户的连接，而是这种模式 https://excalidraw.com/#json=2AAmNFc0WMiDurA5ejiB4,Hjs5fMMQh5ollETmhfgWWw

@5sheep 通过一个产品去持续练技术，就当技术实验田吧，当然 webRTC 也一直在发展，不能说已经成熟到不变的地步了，还有其他技术可以玩，甚至可以在技术上找一些好的场景，比如在线会议已经很成熟了，那这个产品只能走极端，比如在语音中找一些玩法、场景，找需求点（比如语言学习等场景），这些都是一些可尝试的点，并不是重复造轮子

@keith1126 和沙特阿拉伯那边聊了一小时多，其中也有国内深圳、珠海、云南、陕西的人进来，我持续测试了一天，因为我们工作也在用 zoom （在家办公，一挂一整天），我对比在同样的网络环境下，感觉就是比 zoom 要好一些，当然环境的问题很复杂，但测试的感受就是这样的

@cat9life 目前只有语音，你说的这种在线会议就可以，有很多开源的框架可以弄