Calls not working on updated instances past v2.2.22

[msbt]

I have two Mirotalks and both stopped working after upgrading past v2.2.22. I'm guessing some changes in this commit didn't work well on migrated instances. Participants can see other people join, but the loading circles never disappear, so no video and/or audio.

However, copying the .env settings, installing a fresh Mirotalk and pasting those settings worked out in the end, but it's not great if the rolling updates crash existing instances.

[james]

Hello @msbt

Thanks for reporting. Under normal circumstances this should not cause any issues.
But I have reproduced the issue.
Installing version 2.2.22 and upgrading to 2.3.1 not touching anything leads to a meeting where the feed is just loading endlessly.

After changing the ports to 25000 in the location settings it worked again.
I'm currently investigating why the old default of 40000 is now leading to issues.

[james]

TL;DR

Changing the port from 40000 to 25000 in the location view after the update to 2.3.1 fixes this issue.

---

Some debugging details

It seems with the new defaults of 25000 the old settings of 40000 is now causing ICE connection failures.
This can be viewed, when using Chromium with chrome://webrtc-internals and with Firefox about:webrtc.

Chromium view:

I can see the packages arriving on the Linux system with tcpdump portrange 40000-401000-i eth0 and udp and tcpdump portrange 25000-25100 and udp -i br-e1aa4ec2a833

After changing the port to 25000 in version 2.3.1 I can see my desktop and mobile device in the tcpdump and the ICE connection is successful for the ICE channel for audio and video.

eth0 interface:

14:21:48.079032 IP 61.8.145.254.10753 > my.cloudron.dev.25023: UDP, length 1171
14:21:48.079032 IP 61.8.145.254.10753 > my.cloudron.dev.25023: UDP, length 1154
14:21:48.079032 IP 61.8.145.254.10753 > my.cloudron.dev.25023: UDP, length 1154
14:21:48.079033 IP 61.8.145.254.10753 > my.cloudron.dev.25023: UDP, length 1154
14:21:48.079094 IP 61.8.145.254.10753 > my.cloudron.dev.25023: UDP, length 1154
14:21:48.079094 IP 61.8.145.254.10753 > my.cloudron.dev.25023: UDP, length 1154
14:21:48.079201 IP my.cloudron.dev.25099 > ip5f5ae97c.dynamic.kabel-deutschland.de.3826: UDP, length 1162
14:21:48.079256 IP my.cloudron.dev.25099 > ip5f5ae97c.dynamic.kabel-deutschland.de.3826: UDP, length 1162
14:21:48.079291 IP my.cloudron.dev.25099 > ip5f5ae97c.dynamic.kabel-deutschland.de.3826: UDP, length 1162
14:21:48.079326 IP my.cloudron.dev.25099 > ip5f5ae97c.dynamic.kabel-deutschland.de.3826: UDP, length 1162
14:21:48.079363 IP my.cloudron.dev.25099 > ip5f5ae97c.dynamic.kabel-deutschland.de.3826: UDP, length 1162

and the docker bridge interface br-e1aa4ec2a833

14:21:46.994191 IP ip5f5ae97c.dynamic.kabel-deutschland.de.3824 > 172.18.16.195.25057: UDP, length 1130
14:21:46.994199 IP ip5f5ae97c.dynamic.kabel-deutschland.de.3824 > 172.18.16.195.25057: UDP, length 1130
14:21:46.994203 IP ip5f5ae97c.dynamic.kabel-deutschland.de.3824 > 172.18.16.195.25057: UDP, length 1130
14:21:46.994230 IP ip5f5ae97c.dynamic.kabel-deutschland.de.3824 > 172.18.16.195.25057: UDP, length 1130
14:21:46.994234 IP ip5f5ae97c.dynamic.kabel-deutschland.de.3824 > 172.18.16.195.25057: UDP, length 1130
14:21:46.994326 IP 172.18.16.195.25061 > 61.8.145.254.10763: UDP, length 1138
14:21:46.994395 IP 172.18.16.195.25061 > 61.8.145.254.10763: UDP, length 1138
14:21:46.994434 IP 172.18.16.195.25061 > 61.8.145.254.10763: UDP, length 1138
14:21:46.994472 IP 172.18.16.195.25061 > 61.8.145.254.10763: UDP, length 1138
14:21:46.994508 IP 172.18.16.195.25061 > 61.8.145.254.10763: UDP, length 1138

What is noticeable that the amount of "hops" when comparing 40000 and 25000 is less.
Sadly, I lack the knowledge as of now to debug this any further than this.

---

Maybe @mirotalk-57bab571 has some spontaneous insights?
Also while looking into it.
It seems MiroTalk SFU can not be configured to use STUN/TURN, right?

[jdaviescoates]

@james said in Calls not working on updated instances past v2.2.22:

It seems MiroTalk SFU can not be configured to use STUN/TURN, right?

Wasn't it previously configued to use the Clouron STUN/TURN? I'm not at all certain, but I thought that was the case (otherwise what's the different between the SFU and P2P versions?)

[msbt]

@james thanks for digging deeper and figuring out the port thing, I didn't have time yet to debug it myself!

[james]

@jdaviescoates said in Calls not working on updated instances past v2.2.22:

Wasn't it previously configued to use the Clouron STUN/TURN?

The MiroTalk SFU App had the turn/stun add-on in its manifest.

@nostrdev said in Participants can't see eachother?:

It appears the turn server is no longer used as an addon in SFU - could this explain why the app just does not work for many of our participants for several months now?

https://git.cloudron.io/packages/mirotalksfu-app/-/commit/05013ccfb0cbd9342433783e8ffe7c3fb14fa600

But it seems MiroTalk SFU itself has no option to configure TURN/STUN.

[MiroTalk]

otherwise what's the different between the SFU and P2P versions?

• MiroTalk P2P → Works without a central media server. All peers connect directly to each other. For this reason, it does need STUN/TURN configuration. STUN helps peers discover their public IP/port, and TURN relays media when direct connections aren’t possible (e.g. behind strict NAT/firewalls).

• MiroTalk SFU → Works through a Selective Forwarding Unit (based on mediasoup). Here, all peers send their media streams to the SFU, which then forwards them to others. Because every client only needs to connect to the SFU, it doesn’t require TURN in most cases. The SFU is the “meeting point,” so peers don’t have to negotiate direct NAT traversal with each other. STUN/TURN isn’t part of its configuration by default, since mediasoup handles the media routing internally.

But it seems MiroTalk SFU itself has no option to configure TURN/STUN.

• P2P → needs STUN/TURN for NAT traversal.
• SFU → doesn’t usually require STUN/TURN, since the media server acts as the central hub for all streams. However, you must ensure that the necessary port ranges are open and not blocked by firewalls or the ISP.

[james]

Hello @mirotalk-57bab571
Thanks for the clarification.

[MiroTalk]

@james said in Calls not working on updated instances past v2.2.22:

Thanks for the clarification.

You're welcome