多人会议采用 webrtc 作为方案 部署了 coturn 作为中继服务器。现在发现视频质量不高以及多人视频某一客户端的视频会卡一小会后又恢复正常，作为服务端 应到 turnserver 配置哪些东西呢？解决了请喝杯咖啡

[funky]

问 AI 问了一圈也不明白到底哪个是对的

[mimiphp]

如果用了中继服务器，只要打动失败，实际上所有流量都会经过中继服务器转发了。目前大陆的网络环境，百分百只能走中继服务器。。。。所以实际上你应该清楚问题所在了。你的服务器耗不起视频流量的。

[snow0]

我记得有个开源的基于 webrtc 视频通话应用，自己搭的话还是需要很多细节去处理的

[funky]

@snow0 waterbus?

[funky]

但是我看 go 有个 livekit 不知道用那个视频质量如何

[funky]

@mimiphp 用云厂商的 turn 服务怎么样

[wenyifancc]

turn 使用 tcp 协议传输即可缓解这个问题
在 turn 的 URI 末尾增加?transport=tcp
例如:
turn:stun.xxxx.com:3478?transport=tcp

原因是国内网络对 UDP 有 QOS

[funky]

@wenyifancc 好的我试试

[funky]

@wenyifancc 'iceServers': [
{
"urls": "stun:127.0.0.1:3478",
},
{
"urls": "turn:127.0.0.1:3478?transport=udp",
"username": "waterbus",
"credential": "waterbus",
}
],这是我们客户端的配置具体加在哪

[wenyifancc]

@funky
"urls": "turn:127.0.0.1:3478?transport=udp" 改为 "urls": "turn:127.0.0.1:3478?transport=tcp"

[wenyifancc]

@funky 另外,turn 的 Url 地址使用 127.0.0.1 是有问题的,这个应该是站在客户端的角度,客户端获取了这个配置然后连接 turn 服务器,设置 127.0.0.1 会导致客户端无法连接 turn 服务器,应该设置公网暴露的地址

[funky]

@wenyifancc 加了 tcp 另外正式环境是域名

[funky]

@wenyifancc 域名可访问

[funky]

@wenyifancc {"urls": "stun:xxxx.com"},
{
"urls": ["turn:xxxx.com?transport=udp",
"turn:xxxx.com?transport=tcp"],
"username": "aaaaa",
"credential": "aaaaa"
}
]

[abc1310054026]

你这多人会议有混流吗？

[funky]

@abc1310054026 混流啥意思

[afeiche]

用 mediasoup 或者 livekit ，走服务器转发其实都还好，但是流量确实比较大，如果纯 P2P 的话，感觉就只能看客户端之间的网络情况了，不可控，可以统计一下多少是走 p2p 的，多少是走服务器转发的

[funky]

@afeiche 那我只走服务器转发呢 另外统计分流情况具体怎么操作

[SocratesQ]

看题主描述猜测应该是用的 SFU ，这样的话一个客户端卡一会儿又恢复，应该是没断，可以从网络方面监控查下具体状态，因为单说这个情况可能性很多

[funky]

@SocratesQ 我用的就是 SFU

[SocratesQ]

嗯，你会 Server 端、client 端做网络监控和抓包吗，建议试试看

[SocratesQ]

比没有目标的尝试改设置可能会增加不少试错成本。另外如果团队没有 RTC 工程师劝告谨慎上一体式的方案（前提还是要看自己场景哈）。

[funky]

@SocratesQ flutter 不是我写的
没办法 鸭子上赶着

[funky]

@SocratesQ 客户端怎么进行抓包分析呢

[funky]

@SocratesQ 我服务端怎么监控流量呢

[afeiche]

webrtc 客户端有统计功能的，可以在客户端埋点把网络和视频流的数据报上来

[funky]

@afeiche 谢谢

[funky]

我这个能全部走服务器转发么 我把 udp 去掉了感觉质量下降了 视频掉帧

[funky]

turn 服务用云服务怎么样

[TArysiyehua]

首先你自己要测试服务端多段测试没啥问题不会卡，从而确认是服务器端还是客户端问题。
k 和双人会卡很大概率是接的数据过大，每个包改小一点，100k 以下，我记得它每个包有一个最大的限制，但是客户端不要使用那个最大值，用了那个最大值必卡

[funky]

@TArysiyehua 数据包的设置服务端和客户端都需要设置?哪里设置呢

[funky]

实测本地接入的视频不卡 看对方的才觉得卡

[funky]

只是清晰度有点低

[npcoci]

SFU 最后拼的是中继服务器能力，到最后你会发现用第三方云服务会解决 99%的问题

[funky]

@npcoci 可我这里还有视频录制呢 只是流量转发完全可以借助云服务

[TArysiyehua]

@funky 数据包设置是客户端搞的，具体要问客户端的同学，我不太记得是哪个了

[funky]

@TArysiyehua 谢谢 我试试

[bleaker]

这里面坑还是很多的，建议直接用声网之类的第三方服务

[ninjaJ]

@funky #16 大概意思就是所有参会人员的视频流混成一个，而不用两两相交点对点，这样人一多，带宽指数级增长（我的理解不一定对

[funky]

@ninjaJ 你说的是混流？ 目前看起来不是混流

[funky]

@bleaker 到最后没办法了再去和老板提接入第三方服务

[andyskaura]

打洞成功了吗？
多人会议有合流吗？

[nrtEBH]

视频流传输这种 极度依赖底层优化的 不建议自建 用成熟 paas 集成或者 saas 外包就好了
自建不要期望效果能打败大厂
好歹最少套个 cdn 呢

[npcoci]

@funky 云录制，很多第三方都有提供，再说即便不支持，你也可以扩展，多一路视频拿来录制即可

[npcoci]

@funky 最后需要考虑的是你们的产品收益能不能覆盖云服务费用，自建想要稳定也是要花钱加中继的

[funky]

我心里大概有数了 自建惹麻烦

[waye121]

需要 MCU

[funky]

@waye121 展开讲讲

[funky]

我用的 SFU 不需要 MCU

[funky]

@mimiphp 我才 1 ，2 个人 视频都不清晰和流畅

[funky]

@andyskaura 我走的转发应该是

[funky]

@andyskaura 多人会议没有合流

[andyskaura]

@funky #51 你观察一下服务器的流量，全是转发应该不太对，我们厂站里的监控基本全是打洞，除了联通 5g

[funky]

压根还没到服务器上限 才 2 人就视频不清晰和不流畅 我感觉问题还在客户端上

[funky]

@andyskaura 服务端有什么观测手段

[andyskaura]

@funky #55 就是看带宽是不是跑满了

[funky]

@andyskaura 属实有点抽象

[funky]

@andyskaura 这种观测手段不太靠谱把

[andyskaura]

@funky #58 一步一步排查啊，你在这儿赛博许愿一次性给你搞定嘛

[funky]

@andyskaura 服务器带宽没打满

[andyskaura]

@funky #60 没满就接着观察，如果是客户端某特定网络出现问题，就有可能是路由器策略导致丢包了，毕竟都是 udp 包，各凭本事。
看现象是关键帧丢了，观察下卡一小会儿的间隔时间，是不是在关键帧间隔范围内，带宽够用的情况下先降低关键帧间隔看看效果。

[funky]

@andyskaura 我手机直连 wifi 上网 也会由于路由器策略丢包？但是我强制用 tcp 连 turn 中继服务 情况并无改善呢

[funky]

@andyskaura 客户端就没正常过只要和人互联之后接收的视频流就有延迟和丢包

[funky]

还是 tcp

[funky]

@andyskaura 您厂里的监控都是打洞?如何监控的

[andyskaura]

@funky #63 听你这描述，感觉客户端到你服务器的网络自身就不太好，你试试持续 ping 一下 1000-1500 字节，看看延迟效果

[funky]

@andyskaura 我用我本机 ping 的无丢包 响应在 90ms

[andyskaura]

@funky #67 难道是你客户端上传就有问题？
厂站几百个摄像头都接入了 rtsp 转了 webrtc ，外网同时看 20 路没啥问题，也是 sfu

[waye121]

需要 MCU
@funky 用 SFU 也可以呀，带宽足够就行。

[funky]

@andyskaura 我明天顺着这个思路排查

[funky]

@andyskaura 你们什么场景 摄像头监控集群?

[funky]

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 信息

[funky]

我的是 SFU 服务端能截获到流 而且就算转发的时候我服务端收到的转发流是正常的

[funky]

@andyskaura 只是给客户端渲染出了问题

[funky]

这是我在服务器端和本地跑的
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)