Mesibo Video and Voice Calls

Custom TURN Server Configuration

Overview

TURN (Traversal Using Relays around NAT) servers enable peer-to-peer communication between users behind firewalls or NAT devices. When direct peer-to-peer connections fail, the TURN server acts as a relay, forwarding media traffic between participants to ensure call connectivity even in restrictive network environments.

mesibo TURN Server

By default, mesibo's TURN server is enabled for all users, providing reliable call connectivity across various network configurations.

mesibo provides an option to enable or disable the TURN server in User Access Control (UAC), although it is strongly recommended not to disable it as this may prevent calls from connecting in certain network environments.

Custom TURN Server

If you prefer to use your own TURN infrastructure (such as coturn), you can configure a custom TURN server in User Access Control.

Authentication Format

mesibo uses time-based authentication for maximum security. Your TURN server must support the following authentication scheme:

Username Format

mesibo-<uid>-<callid>-<timestamp>

Where:

• uid: mesibo user ID
• callid: unique random call identifier generated per call
• timestamp: current epoch time in seconds

Example:

mesibo-123-32439874-1770223138

Password Format

sha256(username + "-" + user_access_token)

Example:

sha256("mesibo-123-32439874-1770223138-AbCdEf123456...")

Server-Side Verification Procedure

When your TURN server receives an authentication request:

1. Parse the username to extract the UID, call ID, and timestamp:
   content_copy

   username = "mesibo-123-32439874-1770223138"
   uid = 123
   callid = 32439874
   timestamp = 1770223138

Since TURN servers are UDP-based, they often receive allocation and authentication attempts with random or brute-forced usernames. You can safely drop or reject any request where the username does not start with the prefix mesibo-. This early filtering helps discard unauthenticated traffic quickly, saving CPU, memory, and relay resources.

2. Verify the timestamp - Check that the time difference between the current time and the timestamp is within acceptable limits (e.g., ±5 minutes) to prevent replay attacks:

   content_copy

   if (abs(current_time - timestamp) > 300) {
       reject_authentication();
   }

3. Retrieve the user access token from your database using the UID

4. Generate the expected password:

   content_copy

   expected_password = sha256(username + "-" + user_access_token)

5. Compare passwords - Verify the provided password matches the expected password

6. (Optional) Verify call ID - If you are using mesibo on-premise, you can cross-reference the call ID against the calls table in your database for additional security

Legacy Authentication

There is an option to use a fixed password format based on the SHA-256 hash of the user access token alone. However, this method will be phased out and should not be used for new implementations.