MiroTalk Initial package feedback

[nebulon]

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

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 also plan on packaging the web call scheduler, which allows to integrate those backends as standalone apps on Cloudron.

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.

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

[MiroTalk]

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

[MiroTalk]

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

@MiroTalk Thank you kindly for your quick feature add!

You're amazing. Welcome to the Forum and Community.

[robi]

@nebulon said in Customizable front page + auth:

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.

Perhaps this can be resolved by using a single subdomain and multiple sub directories:
mirotalk.dev/p2p
mirotalk.dev/sfu
mirotalk.dev/c2c

Or a combination, like Cryptpad, main app (sub)domain, and a services subdomain which has subdirectories.

[girish]

@robi said in Initial package feedback:

Or a combination, like Cryptpad, main app (sub)domain, and a services subdomain which has subdirectories.

Cryptpad requires separate sandbox subdomain .

[robi]

@girish that is why I mentioned it, however not because of the requirement but because of the pattern.

[MiroTalk]

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

[nebulon]

@MiroTalk that would be possible. Do you know if the backends itself generate relative URLs already?

[MiroTalk]

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

[mave]

Hi,
for me - using/hosting Bigbluebutton - the installation (and trying demo server) doesn't work: Freezing cameras, audio issues, Android (e/OS) not working. Maybe issues on turn/stun-server. But I can't see/understand how config and enable it inside a cloudron installation. The cloudron-turn-server seems not be used. What config file is used for this? (I also did not see this on MiroTalk-Docs ...)

[BrutalBirdie]

@mave
I believe this post is misguided. MiroTalk has nothing to do with BigBlueButton.
Could you please describe a bit more in detail what are you doing?

[mave]

"MiroTalk has nothing to do with BigBlueButton."

Of course. I didn't mix here, only told my experiance with a working BBB-Installation. Curious, I tested MiroTalk on Cloudron. I got typical problems when a turn server was missing or ports failed: audio stops, cameras freezing. So first step for me is, checking the turn server thing, but don't know, if MiroTalk in Cloudron uses the iunternal turn server (seems not to be) and next step: how setting the config with an external tun server?

[nebulon]

@mave can you open a new forum thread with your specific issues with MiroTalk so we don't mix topics. Also mention the MiroTalk flavor (p2p/SFU) which you refer to.