Mirotalk - Participants can't see each other 2

[james]

Hello @avatar1024
I was unable to reproduce this issue.
Changed the ports from 25000 to 30000 and tested with my desktop and mobile phone with no issues.

[ekevu123]

It has worked again now after changing the port and restarting the app. Does it need to be any port between 25000 and 30000?

[james]

Hello @ekevu123
No. I've also just tested with port 5000.
But the ports need to be free since 100 ports will be used.
So if you set the port to 5000, from port 5000 to port 5100 will be used.
If a port in that range is used by another application, the mirotalk application will have issues.

[MiroTalk]

@james said in Mirotalk - Participants can't see each other 2:

If a port in that range is used by another application, the mirotalk application will have issues.

You can try to enable the WebRtcServer feature by adding the following to your env file:

SFU_SERVER=true

Then, RESTART your instance.

How it works:

• MiroTalk spawns one Worker per CPU core by default.
• Each Worker runs its own WebRtcServer on a dedicated port.
• Ports are assigned sequentially starting from a base port (eg: 25000).
• This approach keeps port management simple: you only need to open as many ports as you have Workers.

Optional: You can manually set the number of Workers using:

SFU_NUM_WORKERS=4

Example:
A server with 4 CPU cores (or 4 Workers) and a base port of 25000 will use the following ports:

25000, 25001, 25002, 25003

You only need to open these 4 ports on your firewall.

More about here

[ekevu123]

Thank you, I will try that!

Since I faced the issue temporarily yesterday, but didn't when I tried to reproduce it with my phone, is the explanation that the port I was trying to use for the conversation was temporarily blocked, and restarting the app later re-assigned the port, so it worked again when starting a new conversation?

[MiroTalk]

You're welcome.
It could also be that another app was using a port within the specified range, maybe not constantly, but whenever it needed it, causing a temporary conflict.

[ekevu123]

That would indeed explain it, but - and that is probably a question to the Cloudron team - shouldn't Cloudron prevent exactly that?

[ekevu123]

I keep having the issue sporadically, which makes it hard to use Mirotalk as a constant video provider without testing the connection before every meeting.

[james]

Hello @ekevu123
Thanks for reporting.

I would rule out the networking issue with the ports since Cloudron does bind these ports on app startup.
Thus, the ports could only interfere on app startup, failing to start the app and not at runtime.
You can check this with:

lsof -i :25000-25100

So there must be something else going on for you.
Is there any pattern to this sporadically appearing issue?

[ekevu123]

No, I can't find any pattern, but I have just tested again after a server restart, and the issue persists

[james]

Hello @ekevu123
Can you share where you are hosting your Cloudron?

[MiroTalk]

Also make sure that the firewall on your VPS/VDS is not enabled or blocking the required ports. For example, on Amazon EC2, if the inbound security group rules for the necessary RTC ports are not configured, the service will not work...

[ekevu123]

@james said in Mirotalk - Participants can't see each other 2:

Hello @ekevu123
Can you share where you are hosting your Cloudron?

Netcup, root server
Don't forget, though, that the issue isn't permanent.

@MiroTalk said in Mirotalk - Participants can't see each other 2:

Also make sure that the firewall on your VPS/VDS is not enabled or blocking the required ports. For example, on Amazon EC2, if the inbound security group rules for the necessary RTC ports are not configured, the service will not work...

Thank you! I only let Cloudron handle this.

[james]

Hello @ekevu123
Next time the issue occurs please save the following logs

• The MiroTalk SFU app log
• the browser console log and network inspection log
• /home/yellowtent/platformdata/logs/box.log
• While this issue is occouring in the browser do:
  • Chrome based browsers go to brave://webrtc-internals/ and press Download the "webrtc-internals dump
  • FireFox based browsers go to about:webrtc and press Save Page

This will help us to further narrow down the cause.

[ekevu123]

It has happened again and I was able to catch a few issues that might be related:

1. WebRTC: ICE failed, add a STUN server and see about:webrtc for more details
2. Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://translate.googleapis.com/element/log?format=json&hasfast=true&authuser=0. (Reason: CORS request did not succeed). Status code: (null).
3. Consumer Transport failed
   Object { id: "9d932828-8aba-4b93-af58-235cb3a06c1b" }

/home/yellowtent/platformdata/logs/box.log - doesn't contain anything related to mirotalk

Network logs: lists that umami is failing (probably blocked by plugin) and googletranslate (see above)

I am sending about:webrtc via e-mail, because it is a huge fail and contains personal information.

[ekevu123]

I just wanted to see if anyone has an idea regarding this?

[james]

Hello @ekevu123
Could it be that you are behind a NAT?

[ekevu123]

Not knowingly!

Did you check the data I sent via email?

[james]

Hello @ekevu123
Yes, I got the mail and reviewed the WebRTC log.
But could not pinpoint the issue from it.

I would like you to run a test.
If it fails once again on your desktop client. Please try to connect to the meeting with two clients that are connected with Mobile data (LTE/5G), so outside your network.
With that, I want to make sure that the issue is not related to your local network.
If the two external clients can connect and use @mirotalk-57bab571 without any issue, we know where to look next.

Also, did you set SFU_SERVER=true in your /app/data/env file as suggested by @mirotalk?

[ekevu123]

You might be on to something here. When I tried to set up a call with myself just now, the issue occurred, but when I switched to mobile hotspot, I could connect. It could be that the co-working I am usually in blocks this, and I didn't realise this pattern, so I assumed this was an irregular failure.
I'll test this again later, just to be sure, but you might have solved the mystery, thanks a bunch!

@james said in Mirotalk - Participants can't see each other 2:

Also, did you set SFU_SERVER=true in your /app/data/env file as suggested by @mirotalk?

Yes!