MDaemon Technologies Blog

MDaemon includes a built-in Web Conferencing Server (added in version 25.5.0), allowing users to start audio, video, screen sharing, and chat sessions directly from MDaemon Webmail. Because the entire system runs on your own server, no conference data passes through a third-party cloud service unless you specifically choose to add one.

Most of the support requests we see about Web Conferencing come down to the same handful of gaps: a firewall port that was never opened, a certificate that isn't valid for the URL users connect through, or a setting that wasn't adjusted for a multi-domain environment. This article covers what the feature requires, how its pieces fit together, and how to resolve the issues administrators run into most often.

Web Conferencing System Requirements

Web Conferencing is built into MDaemon itself. There is no separate add-on license to buy or activate; you only need MDaemon 25.5.0 or later. A few prerequisites determine whether it will work correctly:

• Operating system: Windows 10 or Windows Server 2016 or newer, per the MDaemon 25.5 release notes.
• HTTPS enabled for MDaemon Webmail with a valid certificate. Web Conferencing applies MDaemon's SSL/TLS certificate at startup, so Webmail needs to be served over HTTPS with a certificate that is valid for the hostname users connect through.
• The Pro theme. Currently, MDaemon’s Web Conferencing feature requires the Pro theme in MDaemon Webmail, however, in our next major release (coming soon), the WorldClient theme will also be supported.
• A current browser. Chrome, Edge, Firefox, or Safari all work, but keep MDaemon patched. An early bug prevented audio and video from working in Chrome-based browsers; it was resolved in MDaemon 25.5.1. If a deployment is still on 25.5.0, that alone explains a “call connects but no audio or video” report.

The Moving Parts: RTCServer, STUN, and the Media Engine

Understanding what's actually running helps when something breaks. As explained in the MDaemon product manual, the feature is made up of two systems:

1. RTCServer.exe, the WebRTC signaling server. It uses Socket.IO, an open-source library for real-time, two-way communication between a browser and a server, to connect users, handle room chat, and negotiate sessions. This is the process that listens on the primary port, TCP 3443 by default.
2. A Selective Forwarding Unit (SFU), a media-server design where each participant uploads a single stream that the server simply forwards to everyone else in the room, rather than decoding, mixing, and re-encoding it the way an older-style MCU (Multipoint Control Unit) would. That makes an SFU far more scalable than either an MCU or a full mesh of direct connections between every participant. MDaemon's SFU is built on Mediasoup, an open-source WebRTC media library, and runs as the mediasoup-worker.exe process, which is what actually carries the audio, video, and screen sharing streams between participants.

A built-in STUN server, also part of RTCServer, helps clients find a reachable path to each other and to the SFU. STUN alone is enough for most networks. A TURN server, a relay server that both sides connect to when a direct or STUN-negotiated path isn't possible, is optional and only needed for the subset of connections that STUN can't traverse, typically users behind especially restrictive corporate firewalls or double NAT.

The STUN server spins up one “worker” per CPU core, and each worker needs its own port. If your server has 4 cores and you've entered 2 IP addresses in the Web Conferencing settings, expect roughly 8 ports to be allocated. You don't have to guess at this: every time RTCServer starts, it logs the exact ports it assigned to the MDaemon-YYYY-MM-DD-RTCServer-Media.log file, in a line similar to this:

Use that log entry to confirm the real port range before you touch the firewall, rather than opening the entire default range (10000 to 11000) just to be safe.

Where to Configure It

Web Conferencing Server is configured entirely in MDaemon Remote Administration (MDRA), under Main | Web Conference Server. It does not have a configuration page in the desktop MDaemon Console.

From that page you can enable the service, set the primary port, enter your STUN Server IPs, define the STUN port range, set a maximum conference room size (2 to 60 participants, 20 recommended), enable the option to include all domains in a user's buddy list, and configure a TURN provider.

The Most Common Issues (and How to Fix Them)

1. The contacts list is empty, or everyone shows as offline

This is the single most common report we see, and it almost always traces back to one of three causes.

Domain scoping is working as designed. By default, the Web Conferencing contacts list only shows accounts within the same MDaemon domain as the logged-in user. If a user expects to see people from another domain on the same server, that's expected behavior - unless you've enabled the option covered in issue 5 below.

The STUN Server IPs field is empty or incomplete. If no IP addresses are entered, MDaemon falls back to the server's FQDN, which does not work correctly with Firefox and can leave users showing as offline even when the service is running (discussed here in our community forums). Go to Main | Web Conference Server in MDRA and enter every IP address associated with MDaemon, both the LAN IP and the public IP if users connect from both inside and outside your network.

The STUN ports aren't open on the firewall. If port 3443 is reachable but the STUN port range isn't, users can open the Web Conferencing window, but the contact list stays empty or shows everyone offline. Check the RTCServer-Media log for the exact ports in use, then confirm they're open for both TCP and UDP, not just TCP.

2. "Unable to connect to server"

This message points to the primary connection itself, not the contact list. Work through these in order:

• Confirm TCP 3443 (or your configured primary port) is open inbound on the firewall and forwarded correctly if MDaemon sits behind NAT. You can check connectivity by pointing your web browser to https://mail.yourdomain.com:3443 (where “mail.yourdomain.com” is your domain or host name used in MDaemon).
• Confirm the certificate Webmail presents is valid for the exact hostname being used to connect. A certificate that's valid for one hostname but accessed through another (for example, an internal name versus the public URL) is a frequent cause of this error, and it often shows up as working from outside the network but failing from inside, or the reverse.
• Restart the RTCServer service from MDRA (Main | Web Conference Server, Stop Server, then Start Server) after making any changes. Configuration changes don't always take effect until the service is restarted.
• If the problem persists, pull MDaemon-YYYY-MM-DD-RTCServer-Main.log, which logs certificate handling and connection details, for review.

3. Users connect, but audio, video, or screen sharing doesn't work

If both participants can join a room and see the interface, but cannot hear or see each other, the signaling connection (port 3443) is working while the media connection is not. This is a strong sign that the STUN port range isn't fully open, or that Windows Firewall is blocking the underlying executables even though the ports themselves look open.

In at least one case our support staff worked through with one of our partners, opening the ports at the network firewall wasn't enough because Windows Firewall was still blocking the applications locally.

Adding explicit program-level rules resolved it:

Run these on the server hosting MDaemon, adjusting the path if MDaemon isn't installed to the default location. We generally recommend opening specific ports over allow-listing applications, so treat this as a targeted workaround for this specific symptom rather than a standard step.

NOTE: MDaemon 26.5 (coming soon) and up will automatically add Windows firewall rules for MDaemon and all of its components by allow-listing applications.

4. It works in one browser but not another

Chromium-based browsers and Firefox both work with Web Conferencing, but browser-specific bugs have occurred, most notably the Chrome audio and video issue fixed in MDaemon 25.5.1. If you're troubleshooting a browser-specific complaint, check which MDaemon version is installed before assuming it's a configuration problem. Keeping the server current avoids a category of issues that have already been fixed upstream.

5. Contacts in a second domain don't show up

If your server hosts multiple domains and you want users to see each other across domains by default, enable the “Include all domains in the user buddy list” option under Main | Web Conference Server in MDRA. Even without this enabled, users can still invite anyone by email address; the invitee receives a join link and a verification code and connects with a reduced interface.

Multi-domain environments are also where domain-related STUN and firewall issues tend to surface first, since a domain that works fine internally may behave differently once external users from a second domain try to connect. If contacts still don't appear correctly after enabling this option, revisit issue 1 and confirm your STUN Server IPs and port range are configured correctly for every domain involved.

6. You need a TURN server for remote or heavily firewalled users

STUN handles the majority of connections, but some networks, particularly ones with symmetric NAT or very restrictive outbound rules, need a TURN server to relay media instead of connecting peer to peer. MDRA includes ready-made templates for three commercial TURN providers, and they serve different needs. Metered is a self-serve, developer-friendly option with a small free tier and tiered monthly plans. Twilio bills purely on a pay-as-you-go basis per gigabyte of relayed traffic, priced by region, with no monthly subscription, and tends to suit organizations already standardized on Twilio's broader communications platform. Xirsys is a WebRTC-specialist provider with flat monthly subscription tiers and free STUN. Whichever you choose, you enter your provider credentials in MDRA and MDaemon handles the rest.

A Custom template is also available for other providers, including self-hosted, open-source TURN servers such as coturn. To use it, you'll need your TURN provider's URL, any required URL variables, HTTP headers, and authentication method. Keep in mind that MDaemon supports the configuration fields for a custom TURN provider, but does not provide setup or troubleshooting support for third-party TURN software itself, including self-hosted options. If you're deploying coturn or a similar open-source server, plan on your own team or a systems integrator handling that side of the configuration.

Use the Test TURN Configuration button in MDRA after setup to confirm the values are working before rolling it out to users.

7. Meeting invitation links look broken in Outlook

When a conference is scheduled ahead of time, the join link is placed in the calendar invitation's Location field. Outlook enforces a 255-character limit on that field, which can truncate longer URLs or, in some cases, cause the link to stop rendering as clickable. This is most noticeable with links generated for external, non-domain participants, since those URLs tend to be longer.

MDaemon 26.5 (coming soon) addresses this by also placing the join link in the body of the invitation, which doesn't have the same character limit. Until that update reaches general availability, if you're seeing this on an active deployment, check whether a shorter internal URL is usable for local participants, and confirm external users are copying the link directly from the message body if the Location field link looks incomplete.

A Quick Deployment Checklist

Before rolling Web Conferencing out to your users, confirm the following:

• MDaemon is on 25.5.1 or later (ideally the current 26.0.x release).
• Webmail runs over HTTPS with a certificate valid for the hostname used.
• The default domain theme is set to Pro, or users have been instructed to switch to it (until version 26.5, which introduces support for the WorldClient theme).
• Every IP address associated with MDaemon, LAN and public, is entered under Main | Web Conference Server in MDRA.
• TCP port 3443 is open, and the exact STUN port range from the RTCServer-Media log is open for both TCP and UDP.
• Windows Firewall allows RTCServer.exe and mediasoup-worker.exe if you're using program-level rules rather than port-based ones.
• For multi-domain servers, "Include all domains in the user buddy list" is enabled if cross-domain visibility is expected.

When to Contact Support

If you've confirmed the items above and are still running into problems, our support team can help track down the cause. Having the following ready before you open a ticket will speed things up considerably:

• MDaemon-YYYY-MM-DD-RTCServer-Main.log
• MDaemon-YYYY-MM-DD-RTCServer-Media.log
• The MDaemon version currently installed
• The browsers used on both ends of a failed test
• Whether the users tested were on the same LAN as the server, on separate networks, or a mix of both

Most Web Conferencing issues come down to network and certificate configuration rather than a defect in the product itself, and working through the checklist above resolves the majority of them before a ticket is ever needed.