|
The Web Conference Server configuration page is only available in MDaemon's Remote Administration (MDRA) web interface. |
MDaemon is equipped with a Web Conferencing server, which can provide audio and video communication between your Webmail users (and external users), along with a host of web conferencing features. To use Web Conferencing, users must be signed in to Webmail using HTTPS (Web Conferencing applies MDaemon's SSL/TLS certificate at startup), and using the Pro theme. They can then access this feature from the Web Conference icon on the Pro theme toolbar. Webmail's Web Conference feature includes: video and audio conferences, screen sharing, text chat, presenter and moderator tools, conference scheduling and invites (including invites to external addresses), password protected conferences, and more.
How Web Conferencing Works
Technical Details
MDaemon's Web Conferencing feature is a closed system, meaning that all of the communication data is managed by your MDaemon. No communication data is sent to the cloud, unless you choose to use an external TURN server (see below) to accommodate a restrictive firewall environment.
MDaemon's Web Conferencing is comprised of two systems, the Web Real-Time Communication (WebRTC) signaling server that uses Socket.IO to connect users, and a Selective Forwarding Unit (SFU) that uses mediasoup to connect audio and video using Session Traversal Utilities for NAT (STUN).
A Traversal Using Relays around NAT (TURN) server is not included. A TURN server provides fall back capabilities when STUN facilitated peer to peer connections fail. This is most likely to occur in environments with restrictive or multiple firewalls. Some sources say that about 10% of WebRTC connections online are unable to connect without the use of a TURN server. If your particular environment requires this, a third-party TURN server can be implemented.
User Experience
When set up properly, your MDaemon Webmail users can sign in to the Pro theme, open the Web Conference page from the toolbar, and then start an audio and video conference session, inviting other users of their domain (and optionally other domains hosted on the same MDaemon server) with a contact picker. They can also invite non-Webmail or outside participants by entering each person's email address. For those outside participants, an email invitation containing a special link will be sent to the address, which the person can click to join the conference; they will be required to enter a verification code that they request after following the link. Attendees who join in this way will be shown a different user interface and will not have access to the Conferences History entries related to the conference. For details about the various Web Conferencing features, see the user help system within Webmail.
Configuring Web Conferencing
The configuration page for Web Conferencing can be found in MDaemon Remote Administration at Main | Web Conference Server.
Configuration Settings
MDaemon will restart the Web Conference Server whenever you make any changes to the Configuration Settings.
Enable Web Conference Server
Check this box to enable the Web Conference Server.
Maximum conference room members
This is the maximum number of members that may be in a conference room. You can set this option to 2-60 members, but 20 is the default value and recommended maximum.
Primary Port
This is the TCP port used by Socket.IO for signaling and conference room chat. The default value is TCP port 3443.
STUN Server IPs
This is the list of IPs where your server can be found either inside the network or from the Internet. These IPs and the STUN Server Ports will be utilized together to create audio, video, and screen sharing connections between users in a conference room. You may set a maximum of four IP addresses. Remember that if you wish to allow members to join conferences from both inside and outside your local network, you may need to include both a local and public IP address here.
STUN Server Ports
This is the port range allowed for the STUN server workers (in this case, "worker" refers to a server-side process that handles client connections and traffic; it doesn't mean a person or user). The STUN server can start one worker per processor core, and each worker will use one port per IP address specified. It will listen on one port for TCP and UDP traffic. TCP and UDP inbound connectivity is required.
To determine the size of the needed port range, multiply the number of IP addresses by the number of CPU cores (i.e. 2 IP Addresses X 4 Cores = 8 ports).
Note: Since an IPv4 and IPv6 address can bind to the same port, using both reduces the number of cores needed. For example, three IPv4 addresses and one IPv6 address only need three ports per core rather than four.
The default Minimum Port value is 10000. The default Maximum Port value is 11000. Using the above "8 port" example, these values could be set to "Minimum Port: 10000" and "Maximum Port: 10007".
Log level
Five levels of logging are supported, from the highest to lowest amount of data logged:
Debug |
This is the most extensive log level. Logs all available entries, and is typically only used when diagnosing a problem, or when the administrator wants detailed information. |
Informational |
Moderate logging. Logs general operations without details. This is the default log level. |
Warning |
Warnings, errors, critical errors, and startup/shutdown events are logged. |
Error |
Errors, critical errors, and startup/shutdown events are logged. |
Critical |
Critical errors and startup/shutdown events are logged. |
User Settings
Include all domains in the user buddy list
This option is disabled by default, meaning that Webmail's Web Conference page only treats contacts who belong to the same MDaemon domain as local users, for the purpose of joining or inviting to conferences. Enable this option if you wish to allow users who belong to other local MDaemon domains to be seen as local users as well. When disabled, even though those users are treated as external contacts, you can still invite them (and external contacts) to conferences by entering their email addresses when creating the conference. An email invitation containing a special link will be sent to each address, which the person can click to join the conference; they will be required to enter a verification code that they request after following the link. Attendees who join in this way will be shown a different user interface and will not have access to the Conferences History entries related to the conference.
Users retain this many days of conference history: [xx]
This is the number of days of conference history that will be saved and available to the user on their Web Conference page. Note: Video and audio are not recorded and saved.
This feature allows the creator of a conference to make an audio and video recording of the conference; recording can be started, paused, and stopped during the conference. When recording is started, each attendee will be notified that the conference is being recorded. When the conference ends, a link to download the recording will appear on each attendee's Conferences History page in Webmail. Conferences are recorded in WebM format, which may have limited playback options in some media players, but free WebM to MP4 converters are readily available online. Note: The Conference Recording feature uses a headless Chrome browser to make the recordings, which will be downloaded and installed on the server the first time the recording feature is used. For privacy and security, all telemetry is disabled in that browser.
Allow conference video and audio recording
Enable this option if you wish to allow conference video and audio to be recorded. Only the creator of a conference can record the conference, but other users will be notified when recording is happening.
Retain this many days of recordings for users to download: [xx]
Use this option to specify how many days worth of recordings to retain for attendees to be able to download from their Conference History page in Webmail. This is set to 30 days by default.
Maximum number of conferences recording at one time: [xx]
This option determines the maximum number of conferences that can be recorded simultaneously.
File transfer allows attendees to upload and download files during a conference, and to download files later from their Conference History page in Webmail. Note: Only the uploader of a file and the conference creator can delete a file from a conference.
Allow users to upload files to a conference
This option allows attendees to upload and download files during a conference. It is enabled by default.
Retain this many days of files for users to download: [xx]
Use this option to specify how many days worth of files to retain for attendees to be able to download from their Conference History page in Webmail. This is set to 30 days by default.
Maximum file upload size in MB: [xx]
This is the size limit of any file that attendees may upload to a conference. This is set to 100MB by default.
Allow download links to be reused
By default all download links are single use; files can be downloaded multiple times, but each time the link will be unique. Enable this option if you want the links to be reusable.
TURN Configuration
While STUN helps establish peer-to-peer connections, it does not cover all use cases. TURN relays media through a publicly reachable server, ensuring communication is possible even in the most restrictive network environments. If your particular network environment or firewall restrictions will cause direct peer-to-peer WebRTC connections to fail, you can use this section to configure a third-party or custom TURN server solution. While many third-party TURN servers are fee based, there are also open-source TURN servers available that you can configure and run in your own environment.
Choose a TURN service provider
Use the drop-down list to choose your TURN service provider.
None
This option is selected by default, because in most cases a TURN server isn't needed.
Metered / Twilio / Xirsys
Metered, Twilio, and Xirsys are third-party TURN service providers. Different configuration options will appear when you select one of these services, so that you can enter the required authentication data provided by your service.
Custom
Choose this option to configure a TURN service API manually (see Custom TURN Configuration Options below).
Test TURN Configuration
Click this button to test and verify your TURN server's configuration.
Custom TURN Configuration Options
The following custom configuration options should allow for almost any provider that returns server urls from one request, but these are advanced options that may require prior knowledge of TURN service systems.
Provider URL Template
This is the API endpoint from which TURN server credentials and URLs are retrieved. You may use custom variables like ${VARIABLE_NAME} that can be set under URL Variables.
URL Variables
Define variables that will be substituted into the Provider URL Template.
Example:
Name: channel
Value: my_conference_room
Provider HTTP Request Method
Specifies how the TURN credentials should be requested from the provider: GET, POST, PUT, or PATCH
HTTP Headers
This is for adding any necessary custom headers required by your TURN provider API.
Examples:
Authorization: Basic <base64-encoded-credentials>
Content-Type: application/json
Provider Authentication Type
This is the authentication type required by your provider. Different options will appear based on the authentication type selected: Basic, Bearer, or Custom Auth Header.
Basic Authentication
Username and Password are required.
Bearer
Enter the token in the Auth Token field.
Custom Header
Enter the Auth Header Name and the Auth Header Value
Response Parsing Configuration
To correctly extract TURN server details from the provider's JSON API response, specify the appropriate JSON paths for the following elements:
URLs JSON Response Path
Specifies where the list of TURN server URLs is located in the API response.
Examples:
data[0].urls
data.iceServers[].urls
v.iceServers.urls[]
Username JSON Response Path
Path to the username returned by the TURN provider.
Examples:
data[0].username
data.username
v.iceServers.username
Credential JSON Response Path
Path to the password or credential used for TURN authentication.
Examples:
data[0].credential
data.credential
v.iceServers.credential
NOTE: These paths must follow dot-notation syntax used in JavaScript for navigating JSON objects (e.g. data[0].urls). Ensure your provider's response matches the expected structure.
