多人会议采用 webrtc 作为方案 部署了 coturn 作为中继服务器。现在发现视频质量不高以及多人视频某一客户端的视频会卡一小会后又恢复正常，作为服务端 应到 turnserver 配置哪些东西呢？解决了请喝杯咖啡
funky 53 天前 3079 次点击这是一个创建于 53 天前的主题，其中的信息可能已经有所发展或是发生改变。
 | 1 funky OP 问 AI 问了一圈也不明白到底哪个是对的 |
 | 2 mimiphp 53 天前 如果用了中继服务器，只要打动失败，实际上所有流量都会经过中继服务器转发了。目前大陆的网络环境，百分百只能走中继服务器。。。。所以实际上你应该清楚问题所在了。你的服务器耗不起视频流量的。 |
 | 3 snow0 53 天前 我记得有个开源的基于 webrtc 视频通话应用，自己搭的话还是需要很多细节去处理的 |
| 5 funky OP 但是我看 go 有个 livekit 不知道用那个视频质量如何 |
 | 7 wenyifancc 52 天前 turn 使用 tcp 协议传输即可缓解这个问题 在 turn 的 URI 末尾增加?transport=tcp 例如: turn:stun.xxxx.com:478?transport=tcp 原因是国内网络对 UDP 有 QOS |
| 8 funky OP @wenyifancc 好的我试试 |
| 9 funky OP @wenyifancc 'iceServers': [ { "urls": "stun:127.0.0.1:3478", }, { "urls": "turn:127.0.0.1:3478?transport=udp", "username": "waterbus", "credential": "waterbus", } ],这是我们客户端的配置具体加在哪 |
| 10 wenyifancc 52 天前 @funky "urls": "turn:127.0.0.1:3478?transport=udp" 改为 "urls": "turn:127.0.0.1:3478?transport=tcp" |
| 11 wenyifancc 52 天前 @funky 另外,turn 的 Url 地址使用 127.0.0.1 是有问题的,这个应该是站在客户端的角度,客户端获取了这个配置然后连接 turn 服务器,设置 127.0.0.1 会导致客户端无法连接 turn 服务器,应该设置公网暴露的地址 |
| 12 funky OP @wenyifancc 加了 tcp 另外正式环境是域名 |
| 13 funky OP @wenyifancc 域名可访问 |
| 14 funky OP @wenyifancc {"urls": "stun:xxxx.com"}, { "urls": ["turn:xxxx.com?transport=udp", "turn:xxxx.com?transport=tcp"], "username": "aaaaa", "credential": "aaaaa" } ] |
 | 15 abc1310054026 52 天前 你这多人会议有混流吗？ |
| 16 funky OP @abc1310054026 混流啥意思 |
 | 17 afeiche 52 天前 用 mediasoup 或者 livekit ，走服务器转发其实都还好，但是流量确实比较大，如果纯 P2P 的话，感觉就只能看客户端之间的网络情况了，不可控，可以统计一下多少是走 p2p 的，多少是走服务器转发的 |
 | 19 SocratesQ 52 天前 看题主描述猜测应该是用的 SFU ，这样的话一个客户端卡一会儿又恢复，应该是没断，可以从网络方面监控查下具体状态，因为单说这个情况可能性很多 |
| 21 SocratesQ 52 天前 嗯，你会 Server 端、client 端做网络监控和抓包吗，建议试试看 |
| 22 SocratesQ 52 天前 比没有目标的尝试改设置可能会增加不少试错成本。另外如果团队没有 RTC 工程师劝告谨慎上一体式的方案（前提还是要看自己场景哈）。 |
| 26 afeiche 52 天前 webrtc 客户端有统计功能的，可以在客户端埋点把网络和视频流的数据报上来 |
| 28 funky OP 我这个能全部走服务器转发么 我把 udp 去掉了感觉质量下降了 视频掉帧 |
| 29 funky OP turn 服务用云服务怎么样 |
 | 30 TArysiyehua 52 天前 首先你自己要测试服务端多段测试没啥问题不会卡，从而确认是服务器端还是客户端问题。 k 和双人会卡很大概率是接的数据过大，每个包改小一点，100k 以下，我记得它每个包有一个最大的限制，但是客户端不要使用那个最大值，用了那个最大值必卡 |
| 31 funky OP @TArysiyehua 数据包的设置服务端和客户端都需要设置?哪里设置呢 |
| 32 funky OP 实测本地接入的视频不卡 看对方的才觉得卡 |
| 33 funky OP 只是清晰度有点低 |
 | 34 npcoci 52 天前 SFU 最后拼的是中继服务器能力，到最后你会发现用第三方云服务会解决 99%的问题 |
| 36 TArysiyehua 52 天前 @funky 数据包设置是客户端搞的，具体要问客户端的同学，我不太记得是哪个了 |
| 37 funky OP @TArysiyehua 谢谢 我试试 |
 | 38 bleaker 52 天前 这里面坑还是很多的，建议直接用声网之类的第三方服务 |
 | 42 andyskaura 52 天前 打洞成功了吗？ 多人会议有合流吗？ |
 | 43 nrtEBH 52 天前 视频流传输这种 极度依赖底层优化的 不建议自建 用成熟 paas 集成或者 saas 外包就好了 自建不要期望效果能打败大厂 好歹最少套个 cdn 呢 |
| 46 funky OP 我心里大概有数了 自建惹麻烦 |
 | 47 waye121 52 天前 需要 MCU |
| 49 funky OP 我用的 SFU 不需要 MCU |
| 51 funky OP @andyskaura 我走的转发应该是 |
| 52 funky OP @andyskaura 多人会议没有合流 |
| 53 andyskaura 52 天前 @funky #51 你观察一下服务器的流量，全是转发应该不太对，我们厂站里的监控基本全是打洞，除了联通 5g |
| 54 funky OP 压根还没到服务器上限 才 2 人就视频不清晰和不流畅 我感觉问题还在客户端上 |
| 55 funky OP @andyskaura 服务端有什么观测手段 |
| 56 andyskaura 52 天前 @funky #55 就是看带宽是不是跑满了 |
| 57 funky OP @andyskaura 属实有点抽象 |
| 58 funky OP @andyskaura 这种观测手段不太靠谱把 |
| 59 andyskaura 52 天前 @funky #58 一步一步排查啊，你在这儿赛博许愿一次性给你搞定嘛 |
| 60 funky OP @andyskaura 服务器带宽没打满 |
| 61 andyskaura 52 天前 @funky #60 没满就接着观察，如果是客户端某特定网络出现问题，就有可能是路由器策略导致丢包了，毕竟都是 udp 包，各凭本事。 看现象是关键帧丢了，观察下卡一小会儿的间隔时间，是不是在关键帧间隔范围内，带宽够用的情况下先降低关键帧间隔看看效果。 |
| 62 funky OP @andyskaura 我手机直连 wifi 上网 也会由于路由器策略丢包？但是我强制用 tcp 连 turn 中继服务 情况并无改善呢 |
| 63 funky OP @andyskaura 客户端就没正常过只要和人互联之后接收的视频流就有延迟和丢包 |
| 64 funky OP 还是 tcp |
| 65 funky OP @andyskaura 您厂里的监控都是打洞?如何监控的 |
| 66 andyskaura 52 天前 @funky #63 听你这描述，感觉客户端到你服务器的网络自身就不太好，你试试持续 ping 一下 1000-1500 字节，看看延迟效果 |
| 67 funky OP @andyskaura 我用我本机 ping 的无丢包 响应在 90ms |
| 68 andyskaura 52 天前 @funky #67 难道是你客户端上传就有问题？ 厂站几百个摄像头都接入了 rtsp 转了 webrtc ，外网同时看 20 路没啥问题，也是 sfu |
| 70 funky OP @andyskaura 我明天顺着这个思路排查 |
| 71 funky OP @andyskaura 你们什么场景 摄像头监控集群? |
| 72 funky OP o=- 4335692748102869869 2 IN IP4 127.0.0.1 s=- t=0 0 a=extmap-allow-mixed a=msid-semantic: WMS a=group:BUNDLE 0 1 m=audio 9 UDP/TLS/RTP/SAVPF 96 c=IN IP4 0.0.0.0 a=rtpmap:96 opus/48000/2 a=fmtp:96 minptime=10;useinbandfec=1 a=rtcp:9 IN IP4 0.0.0.0 a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=setup:active a=mid:0 a=recvonly a=ice-ufrag:K/wc a=ice-pwd:MjiqCWR2y85px+rHu7Q+Cv7c a=fingerprint:sha-256 04:6B:27:35:A2:D3:DE:EE:9A:FD:40:F3:86:84:44:39:93:20:E5:F3:39:26:F1:38:AD:27:66:D6:63:8E:C7:C8 a=ice-options:trickle a=rtcp-mux m=video 9 UDP/TLS/RTP/SAVPF 99 c=IN IP4 0.0.0.0 a=rtpmap:99 H264/90000 a=fmtp:99 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f a=rtcp:9 IN IP4 0.0.0.0 a=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid a=setup:active a=mid:1 a=recvonly a=ice-ufrag:K/wc a=ice-pwd:MjiqCWR2y85px+rHu7Q+Cv7c a=fingerprint:sha-256 04:6B:27:35:A2:D3:DE:EE:9A:FD:40:F3:86:84:44:39:93:20:E5:F3:39:26:F1:38:AD:27:66:D6:63:8E:C7:C8 a=ice-options:trickle a=rtcp-mux 这是第一次建立的协商的 sdp 信息 |
| 73 funky OP 我的是 SFU 服务端能截获到流 而且就算转发的时候我服务端收到的转发流是正常的 |
| 74 funky OP @andyskaura 只是给客户端渲染出了问题 |
| 75 funky OP 这是我在服务器端和本地跑的 turnutils_uclient -v -u "cccc" -w "bbbb" aaaa.com 0: : IPv4. Connected from: 192.168.2.147:45624 0: : IPv4. Connected from: 192.168.2.147:45624 0: : IPv4. Connected to: a.b.c.d:xxxx 0: : IPv4. Connected to: a.b.c.d:xxxx 0: : allocate sent 0: : allocate sent 0: : allocate response received: 0: : allocate response received: 0: : allocate sent 0: : allocate sent 0: : allocate response received: 0: : allocate response received: 0: : success 0: : success 0: : IPv4. Received relay addr: a.b.c.d:49742 0: : IPv4. Received relay addr: a.b.c.d:49742 0: : clnet_allocate: rtv=2768477507450501170 0: : clnet_allocate: rtv=2768477507450501170 0: : refresh sent 0: : refresh sent 2: : refresh response received: 2: : refresh response received: 2: : success 2: : success 2: : IPv4. Connected from: 192.168.2.147:38182 2: : IPv4. Connected from: 192.168.2.147:38182 2: : IPv4. Connected to: a.b.c.d:xxxx 2: : IPv4. Connected to: a.b.c.d:xxxx 2: : IPv4. Connected from: 192.168.2.147:52290 2: : IPv4. Connected from: 192.168.2.147:52290 2: : IPv4. Connected to: a.b.c.d:xxxx 2: : IPv4. Connected to: a.b.c.d:xxxx 2: : allocate sent 2: : allocate sent 2: : allocate response received: 2: : allocate response received: 2: : allocate sent 2: : allocate sent 3: : allocate response received: 3: : allocate response received: 3: : success 3: : success 3: : IPv4. Received relay addr: a.b.c.d:49743 3: : IPv4. Received relay addr: a.b.c.d:49743 3: : clnet_allocate: rtv=0 3: : clnet_allocate: rtv=0 3: : refresh sent 3: : refresh sent 3: : refresh response received: 3: : refresh response received: 3: : success 3: : success 3: : allocate sent 3: : allocate sent 3: : allocate response received: 3: : allocate response received: 3: : allocate sent 3: : allocate sent 3: : allocate response received: 3: : allocate response received: 3: : success 3: : success 3: : IPv4. Received relay addr: a.b.c.d:63538 3: : IPv4. Received relay addr: a.b.c.d:63538 3: : clnet_allocate: rtv=2941159566689094446 3: : clnet_allocate: rtv=2941159566689094446 3: : refresh sent 3: : refresh sent 3: : refresh response received: 3: : refresh response received: 3: : success 3: : success 3: : channel bind sent 3: : channel bind sent 5: : cb response received: 5: : cb response received: 5: : channel bind: error 403 (Forbidden IP) 5: : channel bind: error 403 (Forbidden IP) |
Select Language