|
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, 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, password protected conferences, and more.
How Web Conferencing Works
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.
When set up properly, your Webmail users should be able to sign in using the Pro theme and then start audio and video conference sessions with other users belonging to the same domain. You can optionally allow users to join conferences with users of other domains, as long as those domains are also hosted on the same MDaemon server.
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
By default, Webmail's Web Conference page only lists contacts belonging to the same MDaemon domain as the user, for joining or inviting to conferences. Click this box if you wish to allow users to see the users belonging to other local MDaemon domains as well.
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.
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.
