@james said in MiroTalk Update regularly fails after update:

Does this have any other effects?

In theory, it shouldn’t have any other effects, as long as the user can switch between these two modes. I’m not entirely sure why Mediasoup doesn’t use a server SFU by default, but you could ask the Mediasoup support forum for clarification.

Port allocation behavior

By default, when SFU_SERVER is set to false, the application uses a range of 100 ports.

when SFU_SERVER=true it allocate ports starting from 40000 default + CPU core eg if your server has 4CPU so become 40000 - 40003 (only 3 ports needed)

More about: https://mediasoup.discourse.group/t/mediasoups-webrtcserver-concerning-firewall-settings-and-port-binding/5965/5

---

Cloudron integration

To support this behavior on Cloudron, SFU_SERVER should be exposed as a toggle (switch button) in the MiroTalk SFU app settings (Location).
When the switch is enabled, the port allocation logic in start.sh can be updated something as follows:

# Enable / disable SFU server (default: false)
readonly SFU_SERVER="${SFU_SERVER:-false}"

# Number of CPU cores (used only when SFU is enabled)
readonly CPU_CORES="$(nproc)"

# Base TCP port (default: 25000)
readonly SFU_TCP_BASE="${SFU_TCP:-25000}"

if [[ "$SFU_SERVER" == "true" ]]; then
    # SFU enabled:
    # allocate one port per CPU core
    readonly SFU_MAX_PORT=$(( SFU_TCP_BASE + CPU_CORES - 1 ))
else
    # Default behavior:
    # allocate 100 ports starting from the base port
    readonly SFU_MAX_PORT=$(( SFU_TCP_BASE + 100 ))
fi

---

Benefits of this approach

• Fewer ports allocated
  Only the ports that are actually needed are opened, especially in SFU mode.

• Reduced port conflicts
  Smaller port ranges significantly lower the chance of clashes with other services on the same host.

• Better Cloudron compatibility
  Minimal port exposure aligns well with Cloudron’s strict networking and security model.

• Scales with hardware
  Port allocation automatically adapts to the number of CPU cores available.

• User control
  Exposing SFU_SERVER as a switch allows users to explicitly choose whether to run in SFU mode or keep the default behavior.

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, @canadaduane for the great analysis!

In case it’s helpful, here are some examples of API usage in different languages:

• JavaScript
• PHP
• Python
• Bash

You can find full working examples here:
https://docs.mirotalk.com/mirotalk-sfu/api/

@timconsidine said in Thank you, Cloudron!:

Tried out Mirotalk P2P and very pleased with it.
Thank you for a great product.

Thanks for the kind words! Glad you’re enjoying MiroTalk P2P. For larger meetings, you can also check out our MiroTalk SFU variant.

@james said in Thank you, Cloudron!:

Thanks you very much!

It’s a pleasure! Keep building

As a token of appreciation for your continuous support of MiroTalk, we’ve also added a dedicated section to our official documentation:

https://docs.mirotalk.com/cloudron/cloudron/

We’ve also included acknowledgments on both of our GitHub repositories.

Sometimes it’s important to say thank you to those who truly deserve.

Wishing the entire Cloudron team and all MiroTalk supporters a great weekend ahead!

Best,
Miroslav

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.

Ops:

[Server] Rec Finalization error 'Invalid room ID'

Edit: Done in MiroTalk SFU v2.0.24

@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

@shrey said in MiroTalk SFU: Recording not possible?:

Expectation:
Recording should get uploaded to S3 regardless of the path taken to 'stop' the meeting and without explicitly stopping the recording.

Done in MiroTalk SFU v.2.0.20

• Commit
• Build

@shrey said in MiroTalk SFU: Recording not possible?:

If, in Step 3:
i stop the Recording and then stop the meeting, then the Recording gets uploaded to S3.

Thanks for pointing that out! I’ll take a look.

IMPORTANT Update in MiroTalk SFU v.2.0.19

To avoid confusion, I’ve updated the environment variables and configuration keys to use a global S3_ prefix. This makes the configuration compatible with any S3-compatible storage, not just AWS.

Example: DigitalOcean Spaces Configuration

# Recording
RECORDING_UPLOAD_TO_S3=true           # Upload recordings to S3-compatible storage (MinIO, Wasabi, DigitalOcean Spaces, etc.) (true|false)

# S3-Compatible Storage Configuration
S3_ENABLED=true                       # Enable S3-compatible storage (true/false)
S3_ACCESS_KEY_ID=<key_id>             # Access Key ID (optional if using instance credentials or IAM roles)
S3_SECRET_ACCESS_KEY=<key_secret>     # Secret Access Key (optional if using instance credentials or IAM roles)
S3_BUCKET=<bucket>                    # Name of your bucket (must already exist)
S3_REGION=<region>                    # Region or location (e.g., us-east-2, eu-west-2, or custom for non-AWS providers)
S3_ENDPOINT=https://<region>.digitaloceanspaces.com  # Custom endpoint for S3-compatible services (MinIO, Wasabi, DigitalOcean Spaces, etc.)
S3_FORCE_PATH_STYLE=true              # Use path-style URLs (true/false). Typically true for non-AWS providers

Notes:

• S3_ENDPOINT is optional if your provider supports automatic resolution from the region.
• S3_FORCE_PATH_STYLE=true is usually required for providers like MinIO, Wasabi, or DigitalOcean Spaces.

Created on the fly, I can confirm that the previous configuration works as expected.

@shrey said in MiroTalk SFU: Recording not possible?:

No idea. I'm yet to figure out why uploading to S3 (DigitalOcean Spaces) is not working for me.

I don’t have a DigitalOcean Space to test, but in case you want to try, you can add AWS_REGION to your environment config like this:

RECORDING_UPLOAD_TO_S3=true                       # Enable uploading recordings to S3-compatible storage
AWS_S3_ENABLED=true                               # Enable S3 storage integration
AWS_S3_ENDPOINT=https://YOUR-REGION.digitaloceanspaces.com  # DO Spaces endpoint (replace YOUR-REGION)
AWS_S3_BUCKET=YOUR-BUCKET                         # Target bucket name
AWS_ACCESS_KEY_ID=YOUR-DO-ACCESS-KEY              # Your DO Spaces access key
AWS_SECRET_ACCESS_KEY=YOUR-DO-SECRET-KEY          # Your DO Spaces secret key
AWS_REGION=YOUR-REGION                            # DO Spaces region (required)
AWS_S3_FORCE_PATH_STYLE=true                      # Required for non-AWS S3 providers

Notes

1. Region: Must match your Space’s region (nyc3, ams3, sgp1, etc.).
2. Endpoint: Must include the full URL with https://.
3. MiroTalk SFU: Make sure to use at last the v2.0.17

@shrey said in MiroTalk SFU: Recording not possible?:

AWS_S3_ENDPOINT=https://<region>.digitaloceanspaces.com

Just out of curiosity, on DigitalOcean, the web video preview work there?

I'm going also to add also the correct contentType when the recording is uploaded to any S3-compatible storage to avoid MIME-type issues.

By the way, I opened an issue for MinIO here: https://github.com/minio/minio/issues/21694

It would be great if MinIO could properly show previews for .webm videos as well.
When I store the same recording in a rec folder in Cloudron, the video preview works correctly.
However, when the file is stored in MinIO storage, the preview does not work.

It looks like the MIME type is not detected correctly, which causes the video tag to use:

type="video/mp4"

even though the file is actually a .webm.
This prevents browsers from playing the video.

Proper support for serving .webm with Content-Type: video/webm would fix the issue.

@james said in MiroTalk SFU: Recording not possible?:

PR created @mirotalk-57bab571 https://github.com/miroslavpejic85/mirotalksfu/pull/228

Ops, you’re right, good catch! PR accepted. Thanks for confirming that everything works as expected. MiroTalk SFU can now upload recordings to any S3-compatible storage, not just AWS!

Implemented in MiroTalk SFU v.2.0.16

• Commit
• Build

@james said in MiroTalk SFU: Recording not possible?:

Would it be possible to add the option to configure the S3Client endpoint config and S3Client forcePathStyle config?

So the goal is to avoid hard-coding support only for AWS S3.
To extend the configuration so it also supports any S3-compatible storage (MinIO, Wasabi, DigitalOcean Spaces, etc.), i need to add the following to the .env file:

AWS_S3_ENDPOINT=                     # e.g., http://localhost:9000 for MinIO
AWS_S3_FORCE_PATH_STYLE=false        # Set to true for S3-compatible services

Then expose these values in config.js:

aws: {
    // ...
    endpoint: process.env.AWS_S3_ENDPOINT || '',
    forcePathStyle: process.env.AWS_S3_FORCE_PATH_STYLE === 'true',
},

Finally, update the S3 client configuration in Server.js:

const s3Client = new S3Client({
    // ...
    endpoint: config?.integrations?.aws?.endpoint || undefined,
    forcePathStyle: config?.integrations?.aws?.forcePathStyle === true,
});

With this setup, the application continues to work with AWS S3 as it currently does, but can also switch to any S3-compatible service simply by adjusting environment variables and no additional code changes required.

Sounds good to me! @James just confirm.