Cloudron Forum

@robi said in Customizable front page + auth:

I'd also like to see an option to stop the telemetry and stats tracking by default. Didn't see an env var for thatI

I have made statistics configurable in this commit. To implement this feature, add the following variables to your .env file:

# Stats
# Umami: https://github.com/umami-software/umami
# We utilize our self-hosted Umami instance to track aggregated usage statistics for service improvement.

STATS_ENABLED=true # Set to true or false
STATS_SCR=YourUmamiEndpoint
STATS_ID=YourInstanceId

If you prefer not to share your statistics with us for service enhancement, set STATS_ENABLED=false.

Enjoy using MiroTalk P2P v.1.2.77!

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

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

Hello @luckow @robi,

I kindly request you to try our official live demo at https://p2p.mirotalk.com

Could you please share whether you have encountered any issues during your experience?

Additionally, it would be helpful if you could provide details on the operating system and browser you were using when you faced this problem. If possible, could you outline the steps to reproduce it?

Also checking the web console logs may help

Thank you!

Dear Cloudron,

We extend our gratitude for seamlessly integrating MiroTalk P2P into cloudron.io!

MiroTalk P2P boasts a WebRTC Mesh (Peer-to-Peer) architecture, finely tuned for small group video calls with 5 to 8 participants per room. Delve into the intricacies of our WebRTC architecture here

MiroTalk offers specialized variants to meet diverse video conferencing needs. Explore MiroTalk SFU for large-scale conferences, MiroTalk C2C for engaging cam-to-cam video calls, MiroTalk BRO for efficient P2P broadcasting, and MiroTalk WEB for a versatile solution.

Upon creating an account on MiroTalk WEB and confirming it via email, you gain direct access to all these versions. Effortlessly organize meeting rooms, send invitations, and relish the flexibility of our diverse solutions.

Privacy and Data Usage in MiroTalk: A Clarification

In adherence to our Privacy Policy, MiroTalk employs telemetry requests upstream for the sole purpose of tracking aggregated usage statistics. This information is crucial for enhancing our service, and it is important to note that the creator of MiroTalk has no intention of personally using or selling any of the collected data.

To further prioritize user control, a configuration option will be introduced in the .env file, allowing users to decide whether they want to track their specific instance of MiroTalk. This feature, already done in MiroTalk SFU, will be implemented in the near future also for MiroTalk P2P.

Screen Sharing issue

If you've encountered any issues with screen sharing, we recommend checking the behavior in our official live demo and providing some browsers console logs can help us to understand the issue, Additionally, ensure that your Turn server is configured correctly; detailed information can be found here.

Host Protection and User Authentication Settings

Discover the latest updates on MiroTalk's security measures, focusing on P2P host protection and user authentication. For detailed insights, refer to this official GitHub commit: MiroTalk Commit 285c9260.

Doubits or Questions

Should you have any doubts or questions, we encourage you to engage with our community on our dedicated forum: https://discord.gg/rgGYfeYW3N.

Thank you for being part of the MiroTalk experience, dedicated to catering to all your video conferencing needs!

Warm Regards,
Miroslav Pejic

Typically if there is a bug on our official live demo the template to follow to help us better understand the problem is the following:

# MiroTalk Version

Specify the MiroTalk version being used: P2P, SFU, C2C, BRO, or WEB.

# Bug Description

Provide a clear and concise description of the encountered bug.

# Steps to Reproduce

Outline the steps to reproduce the behavior:

1. Navigate to '...'
2. Click on '....'
3. Scroll down to '....'
4. Observe the error.

# Desktop - Mobile

Please complete the following information:

- Device or OS: [e.g., iPhone6, Android, Linux, Mac, Windows]
- Browser: [e.g., Chrome, Safari]
- Version: [e.g., 22]

# Expected Outcome

Clearly articulate what you expected to happen in contrast to the observed behavior.

# Screenshots

Include relevant screenshots if available to facilitate a better understanding of the issue.

## Additional Context

Share any supplementary information such as console logs or other relevant details that could assist in troubleshooting the problem.

Thank you!

@nebulon

Hi and welcome here @MiroTalk
Deviating the discussion here a bit, but first of all, you have built something really great. Quite impressive!

Yes forgive me, Thank you and I'm very thrilled you like MiroTalk projects!

Given how MiroTalk has separated the backends neatly, our current plan was to package them individually, since they seem to cover slightly different use-cases.

We made a versatile solution for a variety of communication needs. We've crafted five distinct Mirotalk WebRTC projects, each designed to cater to specific requirements. Whether it's for virtual meetings, collaborative sessions, or any other communication purpose.

We also plan on packaging the web call scheduler, which allows to integrate those backends as standalone apps on Cloudron.

For detailed instructions on how to self-host MiroTalk WEB and integrate Mirotalk desired components, refer to our comprehensive documentation at https://docs.mirotalk.com/mirotalk-web/self-hosting/.

Initially I packaged them all at once, but that seemed a bit cumbersome, as on Cloudron it would require the user to allocate 5 (sub)domains for all to work, so we decided to split this, as we saw the main use-case to provide calls with say up to 10 people. Cloudron is not targeting audiences which require massive scaling, so that seemed fine. The initial package is the p2p flavor, since it works quite well and the SFU backend needs a port range, which is currently not supported by Cloudron. We hope to add this soon though if possible.

MiroTalk P2P boasts a WebRTC Mesh (Peer-to-Peer) architecture, optimized for small group video calls with 5 to 8 participants per room. On the other hand, MiroTalk SFU (Selective Forwarding Unit) offers scalability and robust performance, capable of handling approximately 100 concurrent participants with just a single CPU. Although it requires port ranges, the scalability ensures a seamless and efficient communication environment.

If you have any thoughts on that, very welcome and much appreciated, as you are the expert on your app.

Thanks a bunch for the kudos! I'm just a developer like you, passionate about what I do. It's awesome connecting with fellow devs who share the love for coding. If you ever want to chat or share cool dev stories, I'm all ears! Happy coding!

@robi @girish @nebulon

I'm not tested it but to self-host MiroTalk WEB that includes all MiroTalk WebRTC projects using a SINGLE DOMAIN NAME, the solution can be something like this:

1. On the same server, put all Mirotalk projects and install all the requirements it needs.
2. Start all Mirotalk instances on the same server, they listen on localhost on different ports.
3. In the MiroTalk WEB config, instead of pointing to different subdomains or domains, point to the Mirotalk instances running.

"use-strict";

module.exports = {
  //...
  MiroTalk: {
    P2P: {
      Visible: true,
      Home: "https://YOUR-DOMAIN/p2p",
      Room: "https://YOUR-DOMAIN/p2p/newcall",
      Join: "https://YOUR-DOMAIN/p2p/join/",
      //...
    },
    SFU: {
      Visible: true,
      Home: "https://YOUR-DOMAIN/sfu",
      Room: "https://YOUR-DOMAIN/sfu/newroom",
      Join: "https://YOUR-DOMAIN/sfu/join/",
      //...
    },
    C2C: {
      Visible: true,
      Home: "https://YOUR-DOMAIN/c2c",
      Room: "https://YOUR-DOMAIN/c2c/?room=",
      //...
    },
    BRO: {
      Visible: true,
      Home: "https://YOUR-DOMAIN/bro",
      Broadcast: "https://YOUR-DOMAIN/bro/broadcast?id=",
      Viewer: "https://YOUR-DOMAIN/bro/viewer?id=",
      //...
    },
  },
  //...
};

4. Configure Nginx to route traffic based on paths to the corresponding Mirotalk instances.

server {
    listen 443 ssl;
    server_name YOUR-DOMAIN;

    ssl_certificate /path/to/ssl_certificate.crt;
    ssl_certificate_key /path/to/ssl_certificate_key.key;

    location /p2p/ {
        proxy_pass http://localhost:P2P-PORT/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Socket.IO Support
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }

    location /sfu/ {
        proxy_pass http://localhost:SFU-PORT/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Socket.IO Support
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }

    location /c2c/ {
        proxy_pass http://localhost:C2C-PORT/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Socket.IO Support
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }

    location /bro/ {
        proxy_pass http://localhost:BRO-PORT/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Socket.IO Support
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Replace YOUR-DOMAIN, P2P-PORT, SFU-PORT, etc., with the actual domain name and port numbers used by your Mirotalk instances. Ensure that the SSL certificate paths are correctly specified.

Now, when you access the specified Mirotalk URLs over HTTPS, Nginx will proxy the requests to the corresponding instances running on localhost. Adjust the configuration according to your specific setup and requirements.

Hi @nebulon, @girish

1. Purpose:

   • The purpose here is to configure MiroTalk SFU to utilize WebRTCServer for handling WebRTC connections per Worker (CPU). This can potentially optimize resource usage and improve scalability.

2. WebRTCServer:

   • WebRTCServer is a class introduced in Mediasoup version 3.10.0. It allows listening into a single port for WebRTC connections. This is advantageous for cases where multiple workers (CPUs) are involved, as each worker can have its own WebRTCServer instance.

3. MiroTalk SFU Configuration:

   • webRtcServerActive: true: This parameter indicates whether to activate the WebRTCServer. Setting it to true activates the feature.

   • webRtcServerOptions: This object holds the configuration options for the WebRTCServer.

   • listenInfos: This array contains objects specifying the listening information for the WebRTCServer.

     • Each object within listenInfos represents a listening endpoint for the WebRTCServer, specifying the protocol (UDP or TCP), IP address, and port.

     • In the provided example, both UDP and TCP protocols are used, with the same IP address (IPv4) and port number (44444) for simplicity. In practice, you might need to adjust these values based on your network setup.

4. Scaling with Workers:

   • If MiroTalk SFU starts a Worker for each CPU, each Worker will have its own WebRTCServer instance.

   • The port number for each WebRTCServer is incremented by one for each additional Worker. For instance, if you have 4 CPUs and thus 4 Workers, the ports used would be 44444, 44445, 44446, and 44447 respectively.

5. Port Range:

   • By default, each WebRTCServer internally handles the rtcMinPort and rtcMaxPort. This means that you only need to open ports for the number of Workers you have, rather than a range of ports for each Worker.

Overall, this configuration optimizes the handling of WebRTC connections in MiroTalk SFU by distributing them among multiple Workers, each with its own WebRTCServer instance listening on a specified port.

Here the corrispective configuration for MiroTalk SFU in app/src/config.js:

webRtcServerActive: true, // Set to true to activate it
webRtcServerOptions: {
    listenInfos: [
        { protocol: 'udp', ip: IPv4, port: 44444 },
        { protocol: 'tcp', ip: IPv4, port: 44444 },
    ],
},

In this configuration:

• webRtcServerActive: true activates the WebRTCServer feature.
• webRtcServerOptions contains the configuration options for the WebRTCServer.
• listenInfos specifies the listening endpoints for the WebRTCServer, including both UDP and TCP protocols on the specified IPv4 address and starting port 44444.

Here's the configuration with the additional setup for being behind a NAT:

// Behind NAT with Announced Address
webRtcServerActive: true, // Set to true to activate it
webRtcServerOptions: {
    listenInfos: [
        { protocol: 'udp', ip: '0.0.0.0', announcedAddress: IPv4, port: 44444 },
        { protocol: 'tcp', ip: '0.0.0.0', announcedAddress: IPv4, port: 44444 },
    ],
},

In this configuration:

• webRtcServerActive: true activates the WebRTCServer feature.
• webRtcServerOptions contains the configuration options for the WebRTCServer.
• listenInfos specifies the listening endpoints for the WebRTCServer, including both UDP and TCP protocols.
• ip: '0.0.0.0' indicates that the server should listen on all available network interfaces.
• announcedAddress: IPv4 specifies the announced address to be used in signaling. This is typically the public IPv4 address of the server.
• port: 44444 specifies the starting port number to listen on for both UDP and TCP protocols.

This configuration is suitable for environments where the server is behind a NAT and needs to announce its public IPv4 address for signaling purposes.

Cheers,
Miroslav Pejic

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

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

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

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

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.

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.

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!

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

@Neiluj If you have OIDC enabled, you can safely remove the entire host: { ... } section from your configuration. Simply rely on OIDC for authentication, and let me know if everything works as expected. Thank you!

No...,Please if someone want to test the provided configuration and inform me of its functionality. Happy coding!

@robi Maybe I understand what you mean by screen sharing doesn't work

The audio from the video should be picked up from the system w/o the mic needing to be enabled.

The getDisplayMedia API in web browsers typically does not support capturing system audio directly. The getDisplayMedia API is primarily designed for capturing the contents of a user's screen or a specific application window and often includes options to capture audio from the user's microphone.

Screen sharing does indeed function as intended, capturing the audio input from the microphone by default. However, in situations where a device lacks a microphone, an alternative option is available: sharing a specific tab within the web browser. This is particularly useful for sharing audio from platforms like YouTube or Spotify and so on.

In the case of sharing a browser tab without a microphone, the system typically captures the audio output from that specific tab. But this actually is not handled by MiroTalk P2P.

Ideally, it could be beneficial to share both the audio from the microphone and the browser tab simultaneously, providing a more comprehensive and inclusive experience. This feature is available on MiroTalk SFU