Error installing Miro SFU
-
@avatar1024 I don't have the issue on yours either.
-
same behaviour on my app instance. after a few seconds "producer transport fails" (and the console says something with
WebRTC: ICE failed, add a STUN server and see about:webrtc for more details
). No problem with the instance of @avatar1024 -
Mine install predate the latest changes on ports stuff so I've still got the old config:
-
I just tried installing using the default 40000 ports on another Cloudron and it works fine there. I guessing changing those values just doesn't work. I wish I knew which other app on my main Cloudron was blocking those ports: is there anyway to find out?
-
-
@MiroTalk sorry to come back to you here, but I am trying to update the app with the port fixes, however it is not entirely clear to me how the port range (default 40000 - 40100) https://github.com/miroslavpejic85/mirotalksfu/blob/main/app/src/config.template.js#L342 and 44444+ from https://github.com/miroslavpejic85/mirotalksfu/blob/main/app/src/config.template.js#L401 is related.
Are both required and can you share what the difference is?
On top of this there is also another
listenInfos
at https://github.com/miroslavpejic85/mirotalksfu/blob/main/app/src/config.template.js#L408 this one does not mention any ports at all, is this correct? -
-
@jdaviescoates said in Error installing Miro SFU:
I just updated Cloudron to 7.7.1 and tried to install Miro SFU but I got this error:
An error occurred during the install operation: Docker Error: (HTTP code 500) server error - driver failed programming external connectivity on endpoint 45483bcf-5f54-47ef-b28d-a13d377e493c (947cbd4cbf34d00ad0c0e0a55e41113ab4505551212b3cffa5c45768c2f29908): listen udp4 0.0.0.0:40026: bind: address already in use
This no longer happens with the latest version.
Nor this:
Looking forward to trying this out in an actual meeting soon! Thanks all
-
Hi @nebulon, i will answer you bellow:
Port Ranges and Firewall Configuration:
MiroTalk SFU (Mediasoup) employs a defined port range (40000:40100) for media transmission in WebRTC applications. This contiguous UDP/TCP port range facilitates the seamless sending and receiving of media streams. Ensuring that these ports remain unblocked by the firewall is crucial for uninterrupted service. If blocked, users must create inbound rules to allow traffic through these ports. While the default range is customizable, it's essential to select bindable and accessible ports.
Dynamic Port Assignment with WebRtcServerActive:
The
webRtcServerActive
option in the config.js file,disabled by default
, activates MiroTalk SFU's dynamic port assignment feature. In this mode, the SFU incrementally allocates ports based on the server's CPU configuration. For example, with three CPUs, ports 44444, 44445, and 44446 would be utilized. In such cases, the traditional port range (40000:40100) becomes unnecessary as theWebRtcServer
manages ports internally. It's vital to ensure that dynamically assigned ports remain unblocked by the firewall and are exclusive to MiroTalk SFU to avoid conflicts with other services. More info about you can find in this topicListen Infos Configuration:
The
listenInfos
configuration dictates the IP addresses and ports where the MiroTalk SFU server listens for incoming connections. Notably, the announcedAddress must be a static IPv4 address of the server, ensuring consistency in addressing. For instance, on Amazon EC2, this would typically be an Elastic IP. While EC2 instances are assigned public IP addresses by default, these may change upon instance stop and start. In contrast, an Elastic IP remains associated with the account, providing consistent addressing across instance lifecycle changes. -
@MiroTalk thanks for the clear explanation. Since Cloudron does not support dynamic configuration of the firewall while an app is running, the explicit port range (40000:40100) is great then and we will just not enable the
webRtcServer
, as the default is anyways. So looks like we are all set with SFU version then. -
Great, and yes it all seems to be working well, except for the authentication issue. But I don't know if this is an upstream issue or specific to the Cloudron package. @MiroTalk, any clues?
-
@nebulon said in Error installing Miro SFU:
thanks for the clear explanation. Since Cloudron does not support dynamic configuration of the firewall while an app is running, the explicit port range (40000:40100) is great then and we will just not enable the webRtcServer, as the default is anyways. So looks like we are all set with SFU version then.
You're welcome! Sure thing, just stick with the default port range configuration. Just double-check they're not in use by other services and aren't blocked by the firewall, and you're good to go!
-
Hi @avatar1024, it should be
already fixed
. Are you still encountering the same issue with MiroTalk SFU latest version? If yes, could you please provide the exact steps to reproduce it? Thank you. -
@MiroTalk Yes I just treid again last night and still have the issues:
Steps are:
- go and edit the config.js file
- set protected: true (but leave user_auth: false)
- uncomment the lines regarding usernames and passwords
- Restart the app
- launch the app, there I am prompt for a login
- login using details set in the config.js file
- Create a room
- take another computer (or my phone in 5g), try to connect to the room (e.g. talksfu.chourmo.net/join/test), but there I land on a login page and I have to login to be able to join.
my config.js file:
// All options at https://github.com/miroslavpejic85/mirotalksfu/blob/main/app/src/config.template.js module.exports = { host: { /* Host Protection (default: false) To enhance host security, enable host protection - user auth and provide valid usernames and passwords in the users array. */ protected: true, user_auth: false, users: [ { username: 'gusername', password: 'password', }, { username: 'username2', password: 'password2', }, ] }, presenters: { /* By default, the presenter is identified as the first participant to join the room, distinguished by their username and UUID. Additional layers can be added to specify valid presenters and co-presenters by setting designated usernames. */ list: [], join_first: true, // Set to true for traditional behavior, false to prioritize presenters } };
I'll leave the test room open for a while if you wanna try to join (you can use username2 if you like, username1 won't work though)
-
@avatar1024 said in Error installing Miro SFU:
try to connect to the room (e.g. talksfu.chourmo.net/join/test), but there I land on a login page and I have to login to be able to join.
I just went there too and do indeed see this:
-
@avatar1024 As I can see you are using MiroTalk SFU @version
1.3.95
, update please to latest1.4.11
and try again. Thank you. -
@avatar1024 Ops, my typo error, fixed in this commit. Ok, We'll take a look at it again. Thank you.
-
@avatar1024 Just to add that the issue is also there with p2p version.
-
@jdaviescoates said in Error installing Miro SFU:
@jdaviescoates said in Error installing Miro SFU:
I just updated Cloudron to 7.7.1 and tried to install Miro SFU but I got this error:
An error occurred during the install operation: Docker Error: (HTTP code 500) server error - driver failed programming external connectivity on endpoint 45483bcf-5f54-47ef-b28d-a13d377e493c (947cbd4cbf34d00ad0c0e0a55e41113ab4505551212b3cffa5c45768c2f29908): listen udp4 0.0.0.0:40026: bind: address already in use
This no longer happens with the latest version.
Nor this:
Looking forward to trying this out in an actual meeting soon! Thanks all
Oh, strange. Actually whilst on 1.4.11 Cloudron package 0.4.0 it did still do the same thing again:
The configure operation failed with the following error: Docker Error: (HTTP code 500) server error - driver failed programming external connectivity on endpoint dbe699a5-2cf0-46bc-80d8-2445c327f52c (20cbe800ec18f4d4e5ebc030db6fa822a5ec0d47d48172970d6dfff1f8fd096f): listen tcp4 0.0.0.0:40092: bind: address already in use
But then it worked again after hitting the Retry configure button.
Now going to update to the latest packages to test the auth issue people are having too...