Cloudron Forum

When the broadcaster leaves or a viewer disconnects, the viewer will be redirected to a new page.

@luckow said in MiroTalk Bro flavor: “home page link" (viewer perspective):

Have you seen anything that allows you to configure the URL of the home page? The moment a viewer clicks “Exit”, they are redirected to the Cloudron OIDC (login) form. Perhaps there is a more “elegant” way to redirect users.

The improvements are now live in MiroTalk BRO v1.0.66. For reference, please check the details here: MiroTalk BRO v1.0.66 Improvements.

@cvachery said in Use Cloudron Logins for host protected settings:

Thanks to @MiroTalk in the latest version it works and the config is nearly perfect
Only issue is still one identified erlier that anonymous users can create room if they go to the specific

Should be fixed in both MiroTalk P2P v.1.3.79 & MiroTalk SFU v.1.5.80. Cheers.

Hi everyone,

Are we still encountering the same popup message as before, or is this a new one (see attached image)?

If it’s this new one, did you notice any further issues after the popup appeared?

If it’s not, has anyone been able to consistently reproduce the original issue? If so, could you please share the exact steps to replicate it?

Thanks!

Should be fixed in MiroTalk SFU v.1.5.72. Cheers.

Hi @girish,
The ServerAway event occurs when the client socket disconnects from the MiroTalk SFU instance. This typically happens when a new release is deployed, necessitating a MiroTalk SFU restart to apply changes. As soon as the MiroTalk SFU comes back on (usually within a few seconds), all clients should automatically reconnect to the MiroTalk SFU again. Cheers.

@avatar1024 said in Use Cloudron Logins for host protected settings:

Otherwise, while guest cannot enter the app base domain without a login, they can still create rooms freely by creating a url: mirotalkappprefix.mydomain.com/join/roomname

@MiroTalk is that behaviour intended?

Not a behaviour intended! I'm considering a refinement where guests are only allowed to join specified rooms that have already been created by authenticated users. This approach might offer better control and security. Will be released in the next version.

@cvachery said in Use Cloudron Logins for host protected settings:

@Mirotalk did the update that was deployed to cloudron include the openid logins?

The OIDC (OpenID Connect) option is available in both MiroTalk P2P v.1.3.29 And MiroTalk SFU v.1.4.32.

It works like this:

1. Authentication Prompt: When someone wants to access restricted features on MiroTalk, they're asked to log in using a service like Auth0 or Other providers. This sends them to Auth0's login page to prove they're who they say they are.

2. Room Creation and Sharing: After logging in successfully, users can create and share rooms with others. This lets them collaborate easily within MiroTalk.

3. Guest Access Control: Guests (people who aren't logged in) can't access certain parts of MiroTalk, like the landing page or new room creation. They can only join rooms shared with them by someone who's logged in. This ensures that only verified users can use all of MiroTalk's features, keeping things safe and private.

How Does OIDC Fit In?

Now, instead of the old way where MiroTalk checked a config file or called an API to see if a user was valid, we can use OIDC for authentication. Here's how:

1. Full Authentication: If authRequired is set to true, everything in MiroTalk requires logging in. No login, no access.

2. Optional Authentication: With this setup, certain parts of MiroTalk might need authentication while others don't. Enabling OIDC with host_protection means that authenticated users can access the platform, while Guests can join room, like the old logic but in conjuction with OIDC.

3. No Authentication: In some cases, you might want MiroTalk to be completely open, no login needed. This is good for things like public resources or demos.

4. OIDC disabled: When OIDC is disabled, the previous logic remains in place.

That's the gist of it! OIDC gives us more options for keeping MiroTalk secure and flexible for different situations. Furthermore, for those who opt out of OIDC usage, our existing security measures remain intact.

@nebulon We're working on integrating OpenID Connect, and you can expect it to roll out with our upcoming release.

@cvachery Regarding room security, you have the option to set passwords for rooms directly from the Settings menu under Room/Lock Room.

@CptPlastic said in SFU ERROR?:

Anyone know what causes this error to popup after a few sec. Is it port related?

The issue likely stems from a misconfiguration of the Real-Time Communication (RTC) ports within the firewall settings. It's crucial to verify that the RTC ports are correctly configured to allow traffic through. Specifically, ensure that ports within the default range of 40000 to 40100 for both UDP and TCP protocols are open in the firewall settings and also not utilized by other services to prevent conflicts. Double-checking this configuration should resolve the error you're encountering.

We recently created a script to check if the specified ports for RTC (Real-Time Communication) traffic are bindable and not being used by other services. The green dot indicates that the port is not being used by any service, while the red dot indicates the opposite. To run the script, use the command: node bindable.js.

This script is useful for checking if specific ports are available for use by RTC applications without conflicting with other services running on the same machine. The script likely attempts to bind to the specified ports and then checks if the binding was successful or not. Green dots signify that the port is available, while red dots signify that the port is already in use by another service.

@imc67 said in participants have to authenticate even with user_auth: false:

This setting:

host: {
    protected: true,
    user_auth: false,

should make it possible to start as host an authenticated video conference and ANY participant that has the URL can join without authentication.

It should be fixed in the latest MiroTalk SFU version 1.4.18.

@nebulon Good, You're welcome!

Hi everyone, Please try it now in the MiroTalk SFU v1.4.16. If the issue persists, then as soon as I have a bit more time available, I'll take a deeper look into it.

Any contributions to the project are always highly valued and appreciated!

Thank you all for your involvement in MiroTalk SFU.
We'll keep making it better with your feedback!

@avatar1024 Ops, my typo error, fixed in this commit. Ok, We'll take a look at it again. Thank you.

@avatar1024 As I can see you are using MiroTalk SFU @version 1.3.95, update please to latest 1.4.11 and try again. Thank you.

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.

@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 @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 the WebRtcServer 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 topic

Listen 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.

@nebulon More or less yes.

1. SFU Instance Deployment: When you deploy MiroTalk SFU on a server, it dynamically creates WebRtcServers based on the available CPU cores of the server if you enable this option in the config.js

2. Example CPU Core Count: For instance, if the server where you deploy MiroTalk SFU has 2 CPU cores, MiroTalk will create 2 WebRtcServers dynamically (config.mediasoup.numWorkers)

3. Port Allocation: These WebRtcServers are started from a base port number (in this case, 44444) and are internally incremented by logic for each server created.

4. Console Logs Example:

[3/26/2024, 17:37:17:682] [Server] Create a WebRtcServer {
  worker_pid: 41060,
  webRtcServerOptions: {
    listenInfos: [
      {
        protocol: 'udp',
        ip: '0.0.0.0',
        announcedAddress: 'Your-Public-IPv4',
        port: 44444
      },
      {
        protocol: 'tcp',
        ip: '0.0.0.0',
        announcedAddress: 'Your-Public-IPv4',
        port: 44444
      }
    ]
  }
}
[3/26/2024, 17:37:17:730] [Server] Create a WebRtcServer {
  worker_pid: 41061,
  webRtcServerOptions: {
    listenInfos: [
      {
        protocol: 'udp',
        ip: '0.0.0.0',
        announcedAddress: 'Your-Public-IPv4',
        port: 44445
      },
      {
        protocol: 'tcp',
        ip: '0.0.0.0',
        announcedAddress: 'Your-Public-IPv4',
        port: 44445
      }
    ]
  }
}
...

• The console logs I provided illustrate the creation of two WebRtcServers.
• Each server is associated with a unique worker process ID (worker_pid).
• Each server is configured with both UDP and TCP protocols, listening on all available IPv4 addresses (0.0.0.0) and a specific port number.
• The port numbers for each server are incremented sequentially. In this example, the first server listens on port 44444, and the second server listens on port 44445.

5. Listen Infos: Each WebRTC server's configuration (webRtcServerOptions) includes details about the protocols it supports, the IP address it listens on, the announced address (typically the public IPv4 address of your server), and the port it's listening on.

In this scenario, the application requires permission to allow traffic on ports 44444 and 44445.

Anyone noticed a similar behavior in our official Mirotalk-P2P live demo at https://p2p.mirotalk.com?

It's possible that the issue stems from incorrect Turn server configuration. The Turn demo server specified in our repo .env file has a traffic limit of 50GB per month, which have already been exceeded. Remember to install your own TURN server using the documentation available here.

For more information on Stun/Turn servers, you can refer to our documentation here