diff --git a/.cursor/rules/docs-reader-persona-security-sam.mdc b/.cursor/rules/docs-reader-persona-security-sam.mdc new file mode 100644 index 00000000000..42d62f319d7 --- /dev/null +++ b/.cursor/rules/docs-reader-persona-security-sam.mdc @@ -0,0 +1,48 @@ +--- +description: Persona for reviewing Mattermost docs through the lens of a security and networking policy reviewer +globs: **/*.md,**/*.rst +alwaysApply: false +--- + +# Reader Persona: Security Sam + +When reviewing or iterating on documentation, evaluate it through the lens of this persona. + +## Who They Are + +**Name:** Security Sam +**Role:** Security-conscious IT Administrator, Security Engineer, or Platform Owner +**Experience:** 7+ years reviewing infrastructure, network boundaries, access controls, and secure deployment practices for enterprise software in commercial and federal environments +**Background:** Familiar with security review expectations for regulated deployments, including network segmentation, least-privilege access, change control, auditability, and deployment hardening +**Mindset:** Assumes documentation will be followed exactly in production and looks for places where convenience could accidentally become risk, policy drift, or unnecessary exposure + +## What Security Sam Watches For + +- **Overexposed services**: Instructions that expose ports, endpoints, or admin surfaces without clearly stating when and why +- **Unnecessary network access**: Firewall openings, security group rules, ingress paths, or east-west traffic allowances that exceed what the feature actually requires +- **Weak secret handling**: Credentials, tokens, certificates, or keys placed in insecure locations or shown in unsafe examples +- **Overly broad permissions**: Guidance that uses root, admin, wildcards, permissive file modes, or open network rules without justification +- **Missing transport security**: TLS, certificates, hostname validation, reverse proxy hardening, or secure defaults omitted where they matter +- **Authentication and authorization gaps**: Steps that skip identity, role, or access-control implications for admin features and integrations +- **Unsafe production carryover**: Local testing shortcuts presented without warning that they should not be used in staging or production +- **Compliance and privacy blind spots**: Logging, telemetry, retention, AI, or data-handling guidance that could expose sensitive information +- **Policy mismatches**: Guidance that would conflict with common commercial or federal deployment expectations around restricted outbound access, approved network paths, boundary controls, or documented justification for exposed services + +## What Good Documentation Looks Like for Security Sam + +- Security-sensitive steps clearly separate test-only shortcuts from production guidance +- Secrets are referenced with secure handling practices, not pasted casually into examples +- Permissions, firewall rules, and exposed ports follow least-privilege principles and are justified by the actual deployment architecture +- Risky actions include a brief explanation of the impact and the safer alternative +- Warnings and important callouts are used when a mistake could create security exposure +- Network requirements are explicit about direction, protocol, source/destination scope, and whether the access is mandatory or optional + +## How to Use This Persona When Reviewing Docs + +- Flag text that could normalize insecure defaults or ambiguous security posture +- Call out when guidance should distinguish development, test, and production environments +- Identify missing prerequisites related to TLS, secret management, network boundaries, or access control +- Flag any instruction that asks the reader to open ports, protocols, or routes that are not clearly required by the deployment design +- Apply the principle of least privilege to network policy, service exposure, credentials, permissions, and admin access +- Suggest a stronger admonition level when the consequence is security exposure, not just confusion +- Quote the exact text, explain the security risk in plain language, and provide a safer replacement diff --git a/source/_static/css/homepage-v1.css b/source/_static/css/homepage-v1.css index 85de6275eaf..bc55e039f2b 100644 --- a/source/_static/css/homepage-v1.css +++ b/source/_static/css/homepage-v1.css @@ -358,6 +358,34 @@ section#important-upgrade-notes table.align-default th:last-child { width: 75% !important; } +/* Let short columns in Calls deployment tables shrink naturally. */ +section#mattermost-calls-deployment-guide table.align-default { + width: 100% !important; + min-width: unset !important; + table-layout: auto !important; +} + +section#mattermost-calls-deployment-guide table.align-default td, +section#mattermost-calls-deployment-guide table.align-default th { + min-width: 0 !important; + vertical-align: top !important; + overflow-wrap: break-word !important; +} + +/* The first column is short across the checklist and verification tables. */ +section#mattermost-calls-deployment-guide table.align-default tr > :first-child { + width: 1% !important; + white-space: nowrap !important; +} + +/* Port tables use 6 columns; the first 3 columns are consistently short. */ +section#mattermost-calls-deployment-guide table.align-default tr > :nth-child(1):nth-last-child(6), +section#mattermost-calls-deployment-guide table.align-default tr > :nth-child(2):nth-last-child(5), +section#mattermost-calls-deployment-guide table.align-default tr > :nth-child(3):nth-last-child(4) { + width: 1% !important; + white-space: nowrap !important; +} + ::-moz-selection { /* Code for Firefox */ background: rgba(255, 188, 31, 0.2); diff --git a/source/administration-guide/configure/calls-deployment-guide.md b/source/administration-guide/configure/calls-deployment-guide.md new file mode 100644 index 00000000000..b421fff1fa3 --- /dev/null +++ b/source/administration-guide/configure/calls-deployment-guide.md @@ -0,0 +1,1017 @@ +# Mattermost Calls Deployment Guide + +```{include} ../../_static/badges/all-commercial.md +``` + +```{toctree} +:maxdepth: 1 +:hidden: + +RTCD Setup and Configuration +Calls Offloader Setup and Configuration +Calls Metrics and Monitoring +Deploy Calls on Kubernetes +Calls Logging +``` + +This guide walks System Administrators step-by-step through deploying Mattermost Calls, from preparation and network readiness through to pilot testing and production rollout. You'll find clear decision points, verification checks, and troubleshooting tips to help you confirm each phase of the deployment is working before you move on. + +No prior experience with Mattermost Calls is required - this guide assumes you're starting fresh and will introduce essential concepts and best practices. + +## Calls Overview + +Mattermost Calls offers self-hosted audio calling and screen sharing, enabling sovereign real-time collaboration fully contained within your infrastructure. This means no call media or metadata traverses third-party systems. + +Calls is uniquely suited for mission-critical operations across defense, intelligence, security and critical infrastructure - where data sovereignty, control, and compliance are non-negotiable. It is designed to function in isolated networks without internet access, supporting deployments that demand full airgap compliance. + +Functionality includes: +- **1:1 and Group Calling**: Initiate real-time voice communication between two or more participants. +- **Screen Sharing**: Share your screen during calls to collaborate visually on tasks, review documents, or troubleshoot live issues. +- **Call Recording and Transcription**: Record voice sessions for asynchronous review. *(Enterprise, Enterprise Advanced)* +- **Live Captioning**: Generate real-time subtitles for accessibility. *(Enterprise, Enterprise Advanced)* + +## Deployment Overview + +This guide is organized into sequential deployment phases with numbered steps. Each phase begins with prerequisites and ends with verification checks. Before you begin any phase, make sure the listed prerequisites are met, then move to the next phase only after the verification checks are passing. This structure helps you catch and fix issues early, when they are easiest to isolate. + +**Deployment Phases:** + +1. [**Preparation and Networking**](#phase-1-preparation-and-networking) + + Choose your deployment architecture, make networking decisions, provision required servers, and confirm the required network ports and paths are open before deployment. + +2. [**Install and Configure Calls**](#phase-2-install-and-configure-calls) + + Complete the installation and configuration for the deployment architecture you selected in Phase 1. You will only follow one path: + + - [**Path A: Configure Integrated Calls**](#path-a-configure-integrated-calls) + + Use the built-in Calls service on the Mattermost server for simpler deployment at small scale. + + - [**Path B: Install and Configure RTCD**](#path-b-install-and-configure-rtcd) (Optional) + + Use the RTCD (Real-Time Communication Daemon) service for larger scale production deployments. RTCD offloads media processing tasks from the Mattermost server for optimized performance and scalability. + +3. [**Install and Configure Recording**](#phase-3-install-and-configure-recording) (Optional) + + Calls Offloader is a service required to deliver recording, transcription and live captions. + +4. [**Pilot Rollout**](#phase-4-pilot-rollout) + + Expand testing to a small group of pilot users to watch for client, network, and environment-specific issues under real usage. + +5. [**Production Rollout**](#phase-5-production-rollout) + + Rollout to all users in controlled waves with appropriate communication and monitoring, and be ready to pause or roll back if needed. + + +## Deployment Prerequisites + +Use this checklist to confirm you have the infrastructure, skills, and access required before you begin deploying Calls. Completing these prerequisites now helps prevent delays caused by missing dependencies later in the deployment process. + +#### Deployment Infrastructure Requirements + +- [ ] You have a running Mattermost server on v10.0+. + + _See {doc}`System Information <../../end-user-guide/collaborate/view-system-information>` to check your Mattermost edition and version._ + +- [ ] Your Mattermost server is configured to use HTTPS. + + _See {doc}`Configure TLS <../../deployment-guide/server/setup-tls>` if you need to set up HTTPS._ + +- [ ] You know how many active users you have in your current Mattermost deployment + + _See {doc}`Site Statistics <../../administration-guide/manage/statistics>` to access usage metrics._ + +- [ ] You can provision at least one dedicated Linux server or VM if you plan to use the RTCD service. + + _See [Infrastructure Decisions](#infrastructure-decisions) (Step 1.2) if you're unsure if you need RTCD._ + +- [ ] You can provision a dedicated Linux server or VM for the `calls-offloader` service if you need recording, transcription, or live captions. +- [ ] You are prepared to deploy a TURN server if your users cannot reliably reach the media service on UDP or TCP `8443`. + + _See [Networking Decisions](#networking-decisions) (Step 1.3) if you're unsure if you need a TURN server._ + +- [ ] You have the appropriate {doc}`Mattermost edition and license <../../product-overview/editions-and-offerings>` for the features you need: + - **Mattermost Entry or Team Edition**: 1-1 calling and screen sharing (Up to 40 minutes) + - **Mattermost Professional**: Group calling and screen sharing (No time limit) + - **Mattermost Enterprise or Enterprise Advanced**: Required for: + - RTCD service for scale (50+ users) and production reliability. + - Recording, transcription, or live captions. + +#### Skills and Access Requirements + +- [ ] You are comfortable with basic Linux administration, or you have someone available who is. You will need to connect to servers over SSH, edit configuration files, manage systemd services, inspect logs, and run shell commands. +- [ ] You have System Admin access to your Mattermost server. + + _See {doc}`Mattermost roles <../../end-user-guide/collaborate/learn-about-roles>` to learn about roles and permissions._ + +#### Networking Requirements + +- [ ] You know how end users will connect to Calls (From private networks, VPN, or from the public internet) + + _This impacts your [networking decisions](#networking-decisions) (Step 1.3)_ + +- [ ] You can open the required inbound and outbound firewall rules, or you can engage the network or security team that manages them. + +#### Validation Resources + +- [ ] You have two test accounts available for smoke testing during Calls installation and configuration. +- [ ] You have a small pilot group (5-10 users) available for validation across the client types and networks you care about. + +#### Contacting Support + +- [ ] You know how to open a [request](https://support.mattermost.com) with Mattermost support if you encounter issues. + + _Please include the exact **step number** (e.g. 2A.2.1) that failed, along with your {doc}`Mattermost support packet <../../administration-guide/manage/admin/generating-support-packet>` and [Calls logs](calls-logging.md)._ + +```{note} +If you need expert help deploying Calls, contact your Account Manager or [talk to a Mattermost expert](https://mattermost.com/contact-sales/) to learn about professional service offerings. +``` + +--- + +## Phase 1: Preparation and Networking + +### 1.1 Prerequisites + +Before you start, confirm the following: + +- [ ] You know how many active users you have in your current Mattermost deployment. +- [ ] You know whether recording, transcription, or live captions are required for your deployment. +- [ ] You can provision additional servers if your chosen architecture requires RTCD or Recording services. +- [ ] You can open inbound and outbound network ports on the servers involved in your deployment. + + _If a network or security team manages your firewalls, you'll need to involve them before continuing._ + +### 1.2 Infrastructure Decisions + +Here you will make two important infrastructure decisions: First you'll choose your media processing architecture, then decide whether you need recording. Reference topology for each architecture is provided. + +#### Media Service: RTCD or Integrated + +**Integrated** + +This is the simplest deployment model, since you do not need to provision a separate service to handle media processing. In Integrated mode, the Calls plugin runs its built-in media service directly on the Mattermost server. + +**RTCD** + +RTCD is a dedicated real-time communications service for Mattermost Calls that processes call media outside the main Mattermost server. In most production deployments, **RTCD is the recommended deployment model** because it improves performance, scalability, and stability by isolating call traffic and reducing load on the Mattermost server. + +To determine if you'll need RTCD, start by answering the following questions about your deployment: + +- **Are you deploying Calls on Kubernetes?** + - **Yes:** You'll need to deploy RTCD as it's the only supported way to run Calls. See the {doc}`Kubernetes <../../administration-guide/configure/calls-kubernetes>` Calls deployment guide for details. + - **No:** Continue to the next question. +- **What is the *Total User* count of your existing Mattermost deployment?** _(Check {doc}`Site Statistics <../../administration-guide/manage/statistics>`)_ + - **Up to 50:** You can use the **Integrated** deployment model. + - **More than 50:** You'll need to deploy RTCD to avoid impacting messaging performance of the Mattermost server. + +Use the tabs below to view the reference architecture for each deployment model: + +````{tab} Integrated + +An **Integrated** deployment does not require any additional infrastructure: + +```{image} ../../images/calls-deployment-integrated.png +:alt: Integrated Calls deployment +:height: 300px +``` + +**When to use it** + +- You are evaluating Calls for the first time. +- You expect fewer than 50 people to use Calls. +- You want the simplest possible deployment. + +**Components** + +- **Mattermost server**: Calls plugin is pre-installed, and no additional infrastructure is needed. + +**License** + +- **Mattermost Entry**: 1:1 Calls + Screen Sharing (Up to 40 minutes) +- **Mattermost Professional, Enterprise, or Enterprise Advanced**: Group Calls + Screen Sharing (No time limit) + +#### Recording + +The **Recording** service (`calls-offloader`) can optionally be added to an **Integrated** Calls deployment if you need to enable recording, transcription, and live captions. + +Reference architecture when using the Recording service with Integrated Calls: + +```{image} ../../images/calls-deployment-integrated-recording-v2.png +:alt: Calls deployment with Integrated Calls and recording +:height: 450px +``` + +**Components** + +- **Mattermost server**: Calls plugin is pre-installed. +- **Calls Offloader**: Job service that manages recording, transcription and live captions. + +**License** + +- **Mattermost Enterprise** or **Enterprise Advanced** + +```` + +````{tab} RTCD + +An **RTCD Server** is added as a dedicated media service that processes all call audio and screen sharing media. + +```{image} ../../images/calls-deployment-rtcd.png +:alt: Calls deployment with RTCD +:height: 300px +``` + +The Mattermost server is still responsible for signaling (setting up, managing, and ending calls) and channel state (who is joining or leaving, who has muted, and overall call status), but the call media itself flows directly between clients and the RTCD server, completely bypassing the Mattermost server. + +**When to use it** + +Use RTCD if you need optimized performance, scalability, and the best possible user experience for Mattermost Calls. Specifically: + +- You want to keep call media traffic off your main Mattermost server to improve overall server performance and reduce CPU usage spikes. +- You need your deployment to easily scale as call volume increases; additional RTCD servers can be added for load balancing. +- You want the lowest possible media latency and highest reliability for Calls. +- You are deploying Mattermost on Kubernetes, where RTCD is required. + +**Components** + +- **Mattermost server**: Calls plugin is pre-installed. +- **RTCD Server**: Dedicated media service. Clients connect to it directly for media traffic. + +**License** + +- **Mattermost Enterprise** or **Enterprise Advanced** + +#### Recording + +The **Recording** service (`calls-offloader`) can optionally be added to an **RTCD** Calls deployment if you need to enable recording, transcription, and live captions. + +Reference architecture when using the Recording service with RTCD: + +```{image} ../../images/calls-deployment-rtcd-recording.png +:alt: Calls deployment with RTCD and recording +:height: 450px +``` + +**Components** + +- **Mattermost server**: Calls plugin is pre-installed. +- **RTCD Server**: Dedicated media service. Clients connect to it directly for media traffic. +- **Calls Offloader**: Job service that manages recording, transcription and live captions. + +**License** + +- **Mattermost Enterprise** or **Enterprise Advanced** + +```{note} +For most production deployments that need recording, RTCD plus `calls-offloader` is the recommended combination because it keeps call media off the Mattermost server and scales more predictably. +``` + +```` + +### 1.3 Networking Decisions + +#### 1.3.1 STUN for Public IP Discovery + +STUN is a protocol that helps the media server discover its public IP address automatically so remote clients can connect to Calls. + +Mattermost provides a default STUN server (`stun.global.calls.mattermost.com`). No call media or signaling traffic is sent through this service; it is used only for STUN lookups. Use this decision tree to determine if you need to allow outbound access from your media server to the Mattermost global STUN service for public IP discovery. + +```{note} +Your media server is the Mattermost server in the case of an **Integrated** Calls deployment, or it's the **RTCD server** in the case of an RTCD Calls deployment. +``` + +**STUN Decision Tree** + +1. **Are all users and your media server in the same private network, VPN, or air-gapped environment, with no outside clients?** + - **Yes**: You do not need STUN for public IP discovery. You will use the private address of your media server for configuration in Phase 2. + - **No**: Continue to the next question. + +2. **Does your media server have a stable public IP address or DNS name that clients on the public internet can reach?** + - **Yes**: You do not need STUN for public IP discovery. You will use the stable public address of your media server for configuration in Phase 2. + - **No**: You will need STUN. You must open outbound UDP 3478 from your media server to `stun.global.calls.mattermost.com`. + +If your deployment requires STUN for public IP discovery, note that now so you can include it when opening ports in Step 1.5. + +#### 1.3.2 TURN Server + +TURN is a relay service used only when clients cannot reach the Calls media service directly. If STUN helps clients discover where to connect, TURN acts as a backup route when direct connectivity is not possible. + +Provisioning a TURN server is necessary if both of these conditions are true: + +- Clients connect from networks that cannot reliably use UDP on port `8443` for media traffic (preferred). +- Clients connect from networks that cannot reliably use TCP on port `8443` (fallback). + +TURN is typically a last resort as it adds latency and infrastructure complexity. Only plan to deploy TURN if your answers indicate that you cannot rely on UDP or TCP for media, and users need an alternative route. + +```{important} +TURN is a fallback service, not a default requirement. If clients can reliably reach the media service over UDP or TCP `8443`, do not deploy TURN. If you do deploy TURN, only open the TURN listener ports and transports you actually use, and scope client access according to your organization's network policy. +``` + +### 1.4 Provision Infrastructure + +Now you'll provision the servers or VMs required to support your Calls deployment. You are only preparing infrastructure here; software installation and service configuration happen in later phases. This step matters because you need the IP addresses or DNS names of these servers before you can finish the networking configurations in the next step. + +Infrastructure requirements depend on the deployment infrastructure you selected in Step 1.2. If you provision additional hardware, write down the IP addresses or DNS names now because you will use them in Step 1.5: + +**Integrated** + +Since the Mattermost server is handling all media processing, you can skip this step and proceed to network configuration in Step 1.5. + +**RTCD** + +You will need to provision a new server for RTCD. Use the [performance baselines](calls-metrics-monitoring.md#performance-baselines) for benchmark examples of hardware sizing. The RTCD service supports [horizontal scaling](calls-rtcd-setup.md#horizontal-scaling), but we recommend starting with one server and then scaling out if your expected workload requires it. + +**Recording** + +You will need to provision a new server for the `calls-offloader` service. The recommended starting point is **8 vCPU / 16 GB RAM**, or you can use these [performance benchmarks](https://github.com/mattermost/calls-offloader/blob/master/docs/performance.md) to estimate recording capacity and transcription load. + +**TURN Server** + +If you've determined in Step 1.3.2 that your users cannot reliably reach the media server over UDP or TCP `8443`, you will need to provision your TURN server now. + +Mattermost recommends installing [coturn](https://github.com/coturn/coturn). + +Before moving to Step 1.5, confirm the following: + +- [ ] Every required server or VM has been created. +- [ ] Every required server has the IP address or DNS name you plan to use later in configuration. +- [ ] You have administrative access to every required server. (validate with `ssh @`) + +### 1.5 Network Configuration + +This section lists the network ports that must be opened for each server involved in your Calls deployment. The server instances must exist before you can configure these rules, which is why provisioning in Step 1.4 comes first. + +**How you open ports depends on your environment:** + +- **Cloud deployments (AWS, Azure, GCP):** Configure inbound and outbound rules in your cloud console security group or network ACL for each instance. +- **On-premises or self-managed VMs:** Use `firewalld` (RHEL, Rocky Linux, AlmaLinux) or `ufw` (Ubuntu/Debian) commands directly on each server. +- **Centrally managed firewall:** If a network team manages your firewall, share the tables below with them and request the rules before proceeding. + +Work through one server at a time so you can verify nothing is missed before moving on. + +**Only open the ports relevant for your chosen deployment architecture (Integrated or RTCD):** + + +````{tab} Integrated + +##### Mattermost server ports + +| Port | Protocol | Direction | Source | Destination | Notes | +|---|---|---|---|---|---| +| 443 | TCP | Inbound | Mattermost clients | Mattermost server | HTTPS and WebSocket signaling. | +| 8443 | UDP | Inbound | Mattermost clients | Mattermost server | Media traffic (Integrated mode). | +| 8443 | TCP | Inbound | Mattermost clients | Mattermost server | Media traffic fallback (Integrated mode). | +| 3478 | UDP | Outbound | Mattermost server | `stun.global.calls.mattermost.com` | (Optional - Step 1.3.1) Public IP discovery using STUN. | + + +```{important} +If you use NGINX as a reverse proxy in front of Mattermost, note that NGINX cannot forward UDP traffic. Port 8443 must be opened directly on the server running the media service - not on NGINX. Port 443 is the only port NGINX handles for Calls. +``` + +##### Recording server ports + +If you deployed a calls-offloader server in Step 1.4, open these ports: + +| Port | Protocol | Direction | Source | Destination | Notes | +|---|---|---|---|---|---| +| 4545 | TCP | Inbound | Mattermost server | calls-offloader server | Job service API (Internal only. Restrict this rule to the Mattermost server or approved application subnet only.) | +| 8443 | UDP | Outbound | calls-offloader server | Mattermost server | Recorder and transcriber jobs connect to the media service as call participants. | +| 8443 | TCP | Outbound | calls-offloader server | Mattermost server | Media traffic fallback. | +| 443 | TCP | Outbound | calls-offloader server | Mattermost server | Recorder and transcriber jobs post results back to Mattermost. | + +##### TURN server ports + +If you deployed a TURN server in Step 1.4, open only the ports required by the transports you actually configure. If you are using `coturn`, these are common defaults: + +| Port | Protocol | Direction | Source | Destination | Notes | +|---|---|---|---|---|---| +| 3478 | UDP / TCP | Inbound | Mattermost clients | TURN server | TURN relay. | +| 5349 | TCP | Inbound | Mattermost clients | TURN server | (Optional) If you configure TURN over TLS. Do not open this port unless you are explicitly using it. | +| 49152-65535 | UDP | Inbound | Mattermost clients | TURN server | TURN relay port range required to relay media. | + + +```` + +````{tab} RTCD + +##### Mattermost server ports + +| Port | Protocol | Direction | Source | Destination | Notes | +|---|---|---|---|---|---| +| 443 | TCP | Inbound | Mattermost clients | Mattermost server | HTTPS and WebSocket signaling. | +| 3478 | UDP | Outbound | Mattermost server | `stun.global.calls.mattermost.com` | (Optional - Step 1.3.1) Public IP discovery using STUN. | + +##### RTCD server ports + +| Port | Protocol | Direction | Source | Destination | Notes | +|---|---|---|---|---|---| +| 8443 | UDP | Inbound | Mattermost clients and calls-offloader server | RTCD server | Media traffic. | +| 8443 | TCP | Inbound | Mattermost clients and calls-offloader server | RTCD server | Media traffic fallback. | +| 8045 | TCP | Inbound | Mattermost server | RTCD server | RTCD API (Internal only. Restrict this rule to the Mattermost server or approved application subnet only.) | +| 3478 | UDP | Outbound | RTCD server | `stun.global.calls.mattermost.com` | (Optional - Step 1.3.1) Public IP discovery using STUN. | + +```{important} +If you use NGINX as a reverse proxy in front of Mattermost, note that NGINX cannot forward UDP traffic. Port 8443 must be opened directly on the server running the media service - not on NGINX. Port 443 is the only port NGINX handles for Calls. +``` + +##### Recording server ports + +If you deployed a calls-offloader server in Step 1.4, open these ports: + +| Port | Protocol | Direction | Source | Destination | Notes | +|---|---|---|---|---|---| +| 4545 | TCP | Inbound | Mattermost server | calls-offloader server | Job service API (Internal only. Restrict this rule to the Mattermost server or approved application subnet only.) | +| 8443 | UDP | Outbound | calls-offloader server | RTCD server | Recorder and transcriber jobs connect to the media service as call participants. | +| 8443 | TCP | Outbound | calls-offloader server | RTCD server | Media traffic fallback. | +| 443 | TCP | Outbound | calls-offloader server | Mattermost server | Recorder and transcriber jobs post results back to Mattermost. | + +##### TURN server ports + +If you deployed a TURN server in Step 1.4, open these ports. If you are using `coturn`, these are the common defaults: + +| Port | Protocol | Direction | Source | Destination | Notes | +|---|---|---|---|---|---| +| 3478 | UDP / TCP | Inbound | Mattermost clients | TURN server | TURN relay. | +| 5349 | TCP | Inbound | Mattermost clients | TURN server | (Optional) If you configure TURN over TLS. Do not open this port unless you are explicitly using it. | +| 49152-65535 | UDP | Inbound | Mattermost clients | TURN server | TURN relay port range required to relay media. | + +```` + +### 1.6 Networking Checks + +These checks test firewall rules and network reachability only. They do not require Calls, RTCD, or `calls-offloader` to be installed yet. + +First, install `nmap` on each machine you will run checks from. For example: + +- Ubuntu or Debian: `sudo apt install nmap` +- RHEL, Rocky Linux, or AlmaLinux: `sudo dnf install nmap` + +When you execute each check below, `nmap` returns `open`, `closed`, or `filtered`. + +**Pass**: +- `open`: Port is reachable and the service is running. Expected if you've already installed the RTCD or Recording services in Phases 2-3. +- `closed`: Port is reachable but the service is not running. Expected if you just provisioned the infrastructure in Step 1.4. + +**Fail**: +- `filtered`: Firewall is blocking the port. Revisit your networking configuration in Step 1.5 before continuing. + +```{note} +In the commands below, replace `TARGET_IP` with the actual IP address of the server you are testing. For example, if your Mattermost server IP is `10.0.1.50`, run `sudo nmap -sU -p 8443 10.0.1.50`. +``` + +**Integrated deployments** + +Run from a client machine on the same network as your users: + +| Check | Command | `TARGET_IP` | Description | +|---|---|---|---| +| 1.6.1 | `sudo nmap -sU -p 8443 TARGET_IP` | Mattermost server IP | Clients can send UDP media to the Mattermost server | +| 1.6.2 | `nmap -p 8443 TARGET_IP` | Mattermost server IP | Clients can reach the Mattermost server for TCP media fallback | + +**RTCD deployments** + +Run from a client machine on the same network as your users: + +| Check | Command | `TARGET_IP` | Description | +|---|---|---|---| +| 1.6.3 | `sudo nmap -sU -p 8443 TARGET_IP` | RTCD server IP | Clients can send UDP media to the RTCD server | +| 1.6.4 | `nmap -p 8443 TARGET_IP` | RTCD server IP | Clients can reach the RTCD server for TCP media fallback | + +Run from the Mattermost server: + +| Check | Command | `TARGET_IP` | Description | +|---|---|---|---| +| 1.6.5 | `nmap -p 8045 TARGET_IP` | RTCD server IP | Mattermost can reach the RTCD API | + +**Recording deployments** + +Run from the Mattermost server: + +| Check | Command | `TARGET_IP` | Description | +|---|---|---|---| +| 1.6.6 | `nmap -p 4545 TARGET_IP` | calls-offloader server IP | Mattermost can reach the calls-offloader API | + +Run from the calls-offloader server: + +| Check | Command | `TARGET_IP` | Description | +|---|---|---|---| +| 1.6.7 | `sudo nmap -sU -p 8443 TARGET_IP` | RTCD server IP (or Mattermost server IP if using Integrated mode) | Calls Offloader can send UDP media to the media service to join calls for recording | +| 1.6.8 | `nmap -p 8443 TARGET_IP` | RTCD server IP (or Mattermost server IP if using Integrated mode) | Calls Offloader can reach the media service for TCP media fallback | +| 1.6.9 | `nmap -p 443 TARGET_IP` | Mattermost server IP | Calls Offloader can post recordings back to Mattermost | + +**TURN deployments** + +Run from a client machine on the same network as your users: + +| Check | Command | `TARGET_IP` | Description | +|---|---|---|---| +| 1.6.10 | `sudo nmap -sU -p 3478 TARGET_IP` | TURN server IP | Clients can reach the TURN server on UDP 3478 | +| 1.6.11 | `nmap -p 3478 TARGET_IP` | TURN server IP | Clients can reach the TURN server on TCP 3478 | +| 1.6.12 | `nmap -p 5349 TARGET_IP` | TURN server IP | (Optional) Clients can reach the TURN server over TLS | +| 1.6.13 | `sudo nmap -sU -p 49152 TARGET_IP` | TURN server IP | Spot check of the TURN relay port range | + +### 1.7 Verification Checks + +Before proceeding to Phase 2, confirm all of the following: + +- [ ] You have chosen your deployment architecture and provisioned the required servers. +- [ ] You have confirmed your Mattermost license supports the architecture and features you plan to deploy. +- [ ] Every required firewall rule and network path for your chosen architecture has been opened. +- [ ] Every relevant network check in Step 1.6 returned the expected result (`open` or `closed`, but not `filtered`). +- [ ] If you need STUN, outbound UDP `3478` is allowed to `stun.global.calls.mattermost.com`. + +```{important} +**Do not proceed to Phase 2 until all checks in this section relevant to your deployment architecture are passing. If any check fails, go to [Appendix A: Troubleshooting](#appendix-a-troubleshooting).** +``` + +--- + +## Phase 2: Install and Configure Calls + +Now you will configure Calls following the relevant path for your deployment architecture. Do not complete both paths for the same deployment. + +- **Path A** if you are using the **Integrated** Calls deployment model. +- **Path B** if you are using the **RTCD** Calls deployment model. + +Select your path in the tab below to follow the appropriate installation and configuration instructions: + +````{tab} Path A: Integrated + +### Path A: Configure Integrated Calls + +#### 2A.1 Prerequisites + +- [ ] Phase 1 verification checks passed +- [ ] Integrated is the base architecture you selected in Step 1.2 +- [ ] Two test accounts on your Mattermost server +- [ ] System Admin permissions on your Mattermost server + +#### 2A.2 Configure the Calls plugin + +The Calls plugin is prepackaged with Mattermost self-hosted deployments. Go to **System Console > Plugins > Calls > Settings** and complete the following steps: + +**2A.2.1: Enable the plugin** + +Set **Enable Plugin** to `true`. This enables editing for the rest of the configuration settings on the page. + +**2A.2.2: Enable test mode** + +Set **Test mode** to `on`, so Calls stays restricted during initial validation. In this mode, System Admins control where Calls is available and can enable it in specific channels for testing. + +**2A.2.3: Configure the host media address** + +Set **ICE Host Override** to the IP address or DNS name clients will use to reach the media service. ICE (Interactive Connectivity Establishment) is the protocol your users' devices use to find a path to the media server. The ICE Host Override tells Calls which address to advertise to them. Base this value on the STUN decision tree from Step 1.3.1. + +- If your users are in a private network, VPN, or air-gapped environment, set it to the private address of the Mattermost server they can reach. +- If your Mattermost server has a stable public IP, set it to that IP. +- Otherwise, leave it empty for automatic public address discovery using STUN. + +**2A.2.4: Configure TURN Servers** + +If TURN is being used, replace or extend the **ICE server configurations** array with your TURN server details: + +```json +[ + { + "urls": ["turn:turn.example.com:3478"], + "username": "", + "credential": "" + } +] +``` + +If your TURN deployment uses short-lived generated credentials, also set **TURN Static Auth Secret** and **TURN Credentials Expiration**. + +**2A.2.5: Save configuration** + +Click **Save** on the Calls settings page. It is also recommended that you restart the plugin after changing media server settings: + +1. Go to **System Console > Plugins > Plugin Management**. +2. Disable **Calls** and wait a few seconds. +3. Enable **Calls** again. + +#### 2A.3 Verification Checks + +Now smoke test your Calls deployment with your test accounts: + +- Create a test channel such as `calls-test`. +- Open the **Channel menu**, then select **Enable calls**. +- Invite your test users into the channel so you can validate a real call. + +| Check | Action | Pass criteria | +|---|---|---| +| 2A.3.1 | Start a call from the test channel with a second user | Both users are in the call | +| 2A.3.2 | Speak during the call | Both users can hear each other clearly | +| 2A.3.3 | Share your screen from a desktop app or supported browser | Screen sharing is visible to the other user | +| 2A.3.4 | End the call | The call indicator disappears from the channel | + +```{important} +**Do not continue until all of the checks pass. If any check fails, go to [Appendix A: Troubleshooting](#appendix-a-troubleshooting).** +``` + +```` + +````{tab} Path B: Install and Configure RTCD + +### Path B: Install and Configure RTCD + +#### 2B.1 Prerequisites + +- [ ] Phase 1 verification checks passed +- [ ] RTCD is the base architecture you selected in Step 1.2 +- [ ] RTCD server is provisioned (1.4) and RTCD networking checks passed (1.6.3-1.6.5) +- [ ] Mattermost Enterprise or Enterprise Advanced license is active on your server +- [ ] Two test accounts on your Mattermost server +- [ ] System Admin permissions on your Mattermost server + +#### 2B.2 Install RTCD + +Follow the [RTCD Setup and Configuration](calls-rtcd-setup.md) guide for the actual installation. The guide covers: + +- Binary installation +- `rtcd.toml` configuration +- Service setup +- TURN configuration (if applicable) + +```{note} +If you are deploying on Kubernetes, also use the [Calls Deployment on Kubernetes](calls-kubernetes.md) guide for cluster-specific installation and Helm-based configuration. +``` + +Before proceeding, run these checks from the Mattermost server to confirm RTCD is running and reachable: + +| Check | Command | Pass criteria | +|---|---|---| +| 2B.2.1 | `nmap -p 8045 YOUR_RTCD_SERVER` | `open` - RTCD is running and accepting connections. | +| 2B.2.2 | `curl http://YOUR_RTCD_SERVER:8045/version` | Returns a JSON version string | + +#### 2B.3 Connect Mattermost to RTCD + +Once RTCD is installed, configured, and reachable, update the Calls plugin to use it: + +1. Go to **System Console > Plugins > Calls > Settings**. +2. Set **Enable Plugin** to `true`. This enables editing for the rest of the Calls settings on the page. +3. Set **Test mode** to `on`, so Calls stays restricted during initial validation. In this mode, System Admins control where Calls is available and can enable it in specific channels for testing. +4. Set **RTCD Service URL** to your RTCD address. If RTCD credentials were generated during setup, embed them directly in the URL: + + ``` + http://clientID:authKey@rtcd.internal:8045 + ``` + + Replace `clientID` and `authKey` with the values generated during RTCD setup. The first connection to RTCD self-registers the client and stores the authentication key in the database. + + Alternatively, set credentials via environment variables on the Mattermost server: `MM_CALLS_RTCD_CLIENT_ID` and `MM_CALLS_RTCD_AUTH_KEY`. + +5. Click **Save** and restart the Calls plugin so the change takes effect. + +#### 2B.4 Configure Calls Monitoring + +Before your pilot, set up Calls monitoring so you can see sessions, errors, CPU, and memory while real users are testing. + +Calls monitoring uses Prometheus (a tool that collects metrics from your servers) and Grafana (a dashboard that visualizes those metrics). If you don't have these set up yet, see [Mattermost monitoring setup](../../administration-guide/scale/deploy-prometheus-grafana-for-performance-monitoring.md) before continuing. If you already have Prometheus and Grafana running, add the following scrape targets and import the dashboard: + +- **RTCD metrics**: `http://YOUR_RTCD_SERVER:8045/metrics` +- **Calls plugin metrics**: `http://YOUR_MATTERMOST_SERVER:8067/plugins/com.mattermost.calls/metrics` +- **Grafana dashboard**: Import dashboard ID `23225` + +See [Calls Metrics and Monitoring](calls-metrics-monitoring.md) for full configuration details. + +#### 2B.5 Verification Checks + +Now smoke test your RTCD deployment with your test accounts: + +- Create a test channel such as `calls-test`. +- Open the **Channel menu**, then select **Enable calls**. +- Invite your test users into the channel so you can validate a real call. + +| Check | Action | Pass criteria | +|---|---|---| +| 2B.5.1 | Start a call from the test channel with a second user | Both users are in the call | +| 2B.5.2 | Speak during the call | Both users can hear each other clearly | +| 2B.5.3 | Share your screen from a desktop app or supported browser | Screen sharing is visible to the other user | +| 2B.5.4 | End the call | The call indicator disappears from the channel | + +If these checks fail, try these troubleshooting techniques first: + +- Re-run checks `2B.2.1` and `2B.2.2` to confirm RTCD is listening and responding. +- Confirm **RTCD Service URL** is correct and includes credentials if your RTCD setup requires them. +- Check that the Mattermost server can reach RTCD on port `8045`, and review RTCD logs before changing other settings. + +```{important} +**Do not continue until all of the checks pass. If any check fails, go to [Appendix A: Troubleshooting](#appendix-a-troubleshooting).** +``` + +```` + +--- + + +## Phase 3: Install and Configure Recording + + +Now we will install and configure the `calls-offloader` job service that handles call recording, transcription, and live captions. + +**You can skip this phase if you do not need recording, transcription, or live captions.** + +### 3.1 Prerequisites + +- [ ] `calls-offloader` server is provisioned (1.4) and relevant networking checks passed (1.6.6-1.6.9) +- [ ] If you are using Integrated mode: Phase 2A verification checks passed (2A.3.1-2A.3.4). +- [ ] If you are using RTCD: Phase 2B verification checks passed (2B.5.1-2B.5.4). +- [ ] Mattermost Enterprise or Enterprise Advanced license is active on your server +- [ ] System Admin permissions on your Mattermost server + +### 3.2 Install calls-offloader + +Follow the [Calls Offloader Setup and Configuration](calls-offloader-setup.md) guide for installation. The guide covers: + +- Binary installation +- `config.toml` configuration +- Systemd service setup +- Docker-backed jobs +- Private network overrides +- Air-gapped installation + +Before proceeding, run these checks from the Mattermost server to confirm `calls-offloader` is running and reachable: + +| Check | Command | Pass criteria | +|---|---|---| +| 3.2.1 | `nmap -p 4545 YOUR_OFFLOADER_SERVER` | `open` - calls-offloader is running and accepting connections. | +| 3.2.2 | `curl http://YOUR_OFFLOADER_SERVER:4545/version` | Returns a JSON version string | + +### 3.3 Connect calls-offloader to Mattermost + +1. Go to **System Console > Plugins > Calls > Settings**. +2. Set **Job Service URL** to the calls-offloader address, for example `http://calls-offloader.internal:4545`. +3. Enable **Call Recordings** if needed. +4. Enable **Call Transcriptions** if needed. Transcriptions require recordings to be enabled. +5. Enable **Live Captions** if needed. Live captions require both recordings and transcriptions to be enabled. +6. Click **Save** and restart the Calls plugin so the change takes effect. + +### 3.4 Verification Checks + +Now smoke test recording-related features with your test accounts: + +| Check | Action | Pass criteria | +|---|---|---| +| 3.4.1 | Start recording as a call host | Recording starts without error. | +| 3.4.2 | End the call or stop the recording | An MP4 file appears in the call thread after processing completes. | +| 3.4.3 | With transcription enabled, end a recorded call | An MP4 file and transcript file appear in the call thread after processing completes. | +| 3.4.4 | With live captions enabled, start a recorded call | Captions appear during the call within 1-3 seconds after participants speak. | + +If a recording-related check fails, isolate the problem before retrying: + +- **3.4.1 or 3.4.2 fails**: Confirm the **Job Service URL** is correct, the `calls-offloader` service is running, and the Mattermost server can reach port `4545`. +- **3.4.3 fails**: Confirm recordings are enabled first, then confirm transcription is enabled. +- **3.4.4 fails**: Confirm both recordings and transcriptions are enabled before testing live captions. + +```{important} +**Do not continue until all of the checks pass. If any check fails, go to [Appendix A: Troubleshooting](#appendix-a-troubleshooting).** +``` + +--- + +## Phase 4: Pilot Rollout + +Now that the technical configuration is complete and validated, run a small pilot with real users before broad rollout. The goal is to confirm Calls works reliably across the clients and locations your organization uses, and that your servers stay healthy under normal usage. + +### 4.1 Prerequisites + +- [ ] If using Integrated mode: Phase 2A verification checks passed (2A.3.1-2A.3.4) +- [ ] If using RTCD: Phase 2B verification checks passed (2B.5.1-2B.5.4) +- [ ] If using Recording: Phase 3 verification checks passed (3.4.1-3.4.4) +- [ ] 5 to 10 volunteer pilot users from different locations +- [ ] Access to the metrics dashboard and logs on your Calls infrastructure +- [ ] Pilot users have current [Mattermost desktop and mobile apps](https://mattermost.com/apps/) + +### 4.2 Preparation and Communication + +For a successful pilot, make sure pilot users know what to test, how to start a call, and how to report problems. + +After inviting your pilot users into the `calls-test` channel, post a short message there so everyone is testing the same things. A template is provided below: + +
+Pilot user communication template + +```markdown +## Mattermost Calls pilot + +Thank you for volunteering to test Mattermost Calls before a wider rollout. After 3-5 days of pilot testing, we will ask everyone to share their findings and experiences. Please keep track of any issues or feedback so you can summarize them when requested. + +**How to start** + +Calls is enabled in this channel for pilot testing. You can select **Start call** in the channel header to begin, or join an existing call if one is already started. + +You can learn more about Mattermost Calls in the {doc}`documentation <../../end-user-guide/collaborate/make-calls>`. + +**Test Cases** + +| Test | Action | Pass criteria | Client Types | +|---|---|---|---| +| T1 | Group call with 3-5 participants | All participants can hear each other clearly | Web, Desktop, Mobile | +| T2 | Group call lasting 15 minutes or longer | No unexpected drops or audio degradation | Web, Desktop, Mobile | +| T3 | Participants join calls from outside the main office network | Call quality is acceptable from that network | Web, Desktop, Mobile | +| T4 | Participants share screen during a call | Screen sharing works and is visible to all participants | Desktop, Web | +| T5 | Record a group call, if recording is enabled | MP4 and transcription file appear in the call thread after processing completes | Web, Desktop, Mobile | +| T6 | Enable Live Captions during a group call, if captions are enabled | Captions appear during the call within 1-3 seconds after participants speak | Web, Desktop | + +**Reporting Issues** + +If you encounter an issue, please report it by posting in this channel and including: + +- Test number +- Reproduction steps +- What you expected to happen +- What actually happened (with screenshots) +- Your client type (desktop, browser, or mobile) +``` + +
+ +### 4.3 Verification Checks + +**Monitoring** + +| Check | Action | Pass criteria | +|---|---|---| +| 4.3.1 | Check your metrics dashboard during a pilot call | Active sessions and participants are visible and counted correctly | +| 4.3.2 | If using RTCD, check RTCD error metrics after pilot calls (`rtcd_rtc_errors_total`) | No elevated error counts | +| 4.3.3 | If using RTCD, check CPU and memory metrics during a pilot call (`rtcd_process_cpu_seconds_total`, `rtcd_process_resident_memory_bytes`) | No CPU or memory spikes observed | +| 4.3.4 | Review Mattermost logs, plus RTCD and calls-offloader logs if those services are deployed | No recurring `ERROR` lines, and no unexpected `WARN` patterns | + +**Production readiness** + +Collect feedback from your pilot users after 3-5 business days and use it to evaluate production readiness: + +| Check | Requirement | +|---|---| +| 4.3.5 | Audio quality rated acceptable by 80%+ of pilot users | +| 4.3.6 | No blocking issues found in the pilot test cases | +| 4.3.7 | All pilot users confirm readiness for production rollout | + +If the pilot users find issues, do not expand the rollout yet: + +- Fix the issue in the smallest possible scope. +- Repeat the affected pilot test case. +- Stay in pilot until the failing scenario is consistently passing. + +You can also run `/call stats` in the Mattermost message area after a failed test for additional diagnostic clues. + +```{important} +**Do not continue to a production rollout until all relevant checks are passing. If any check fails, go to [Appendix A: Troubleshooting](#appendix-a-troubleshooting).** +``` + +--- + +## Phase 5: Production Rollout + +Now you will execute a broader rollout to all users in production. + +### 5.1 Prerequisites + +- [ ] Phase 4 production readiness checks passed (4.3.1-4.3.7) +- [ ] Rollback plan documented and understood +- [ ] System Admin permissions on your Mattermost server +- [ ] Access to the metrics dashboard and logs on your Calls infrastructure + +### 5.2 Rollback plan + +You should be familiar with your rollback options before you begin the staged production rollout. If something goes wrong, choose the smallest rollback that solves the problem: + +**Per-channel rollback** + +Disables Calls in specific channels. + +1. Navigate to the impacted channel. +2. Select the **Channel menu**, then select **Disable calls**. + +**Test mode rollback** + +Restricts Calls to channels where it has been enabled by a System Admin. + +1. Go to **System Console > Plugins > Calls > Settings**. +2. Set **Test Mode** to `on`. + +**Full rollback** + +Disables Calls completely for everyone. + +1. Go to **System Console > Plugins > Plugin Management**. +2. **Disable** the Calls plugin. + +If you have an existing conferencing tool, keep it available until Calls is stable in production. + +### 5.3 Preparation and Communication + +Before announcing Calls to users, create a `calls-support` public channel. This gives users a clear place to report issues and gives your admins a single place to track rollout problems. + +Also prepare a short announcement to share in an all-hands channel or similar high-visibility location. A template is provided below: + +
+Production rollout communication template + +```markdown +## Mattermost Calls rollout + +We're enabling Mattermost Calls across this server. Starting today, you can start audio calls in select channels directly within Mattermost - no need to switch to a separate tool. + +We're rolling out gradually, starting with a select set of channels before expanding to everyone. + +**Calls features** + +- Start or join 1:1 and group audio calls +- Share your screen from the desktop app or browser +- Record calls and generate transcripts, if enabled +- Use live captions during recorded calls, if enabled + +You can learn more about Mattermost Calls in the [documentation](https://docs.mattermost.com/end-user-guide/collaborate/make-calls.html). + +**How to start a call** + +Select **Start call** in the channel header. Anyone in the channel can join. + +**Things to know** + +- We recommend updating your [desktop and mobile apps](https://mattermost.com/apps/) to the latest version +- Your browser or desktop app may ask for microphone permission the first time you join a call. +- Screen sharing may also require a screen capture permission prompt. + +**Need help?** + +Post in `~calls-support` and include what you were trying to do, what happened, and a screenshot if possible. +``` +
+ +### 5.4 Rollout Stages + +We recommend enabling Calls in stages instead of enabling it everywhere at once. This way you can watch real usage, catch problems early, and rollback cleanly if needed. + +| Stage | Channels / departments | Suggested timeline | Rollback approach | +|---|---|---|---| +| Stage 1 | IT and Admin channels | Days 1-3 | Per-channel rollback | +| Stage 2 | Engineering or power user channels | Days 4-7 | Per-channel rollback | +| Stage 3 | Full organization | Day 8+ | Test mode (if issues are isolated) or full rollback | + +If a rollout stage introduces problems, pause the rollout, use the rollback option listed for that stage, fix the issue, and repeat the same stage before moving to the next one. + +### 5.5 Monitor and optimize + +Once Calls is live, monitor it actively for the first two weeks and tune based on what you see. + +**5.5.1: Watch server health during peak call hours** + +Monitor CPU and memory on the media server (RTCD or Mattermost server) daily during peak usage. If CPU utilization consistently exceeds 70%, consider increasing hardware specs, or adding RTCD nodes before the next rollout stage. + +**5.5.2: Review logs daily** + +Check Mattermost, RTCD, and calls-offloader logs each day for recurring `ERROR` or `WARN` lines. Address any patterns before they become user-facing problems. + +**5.5.3: Tune Max Call Participants** + +If you see resource pressure during large calls, lower **Max Call Participants** in **System Console > Plugins > Calls**. By default there is no participant limit (configured as `0`, which means unlimited). A practical ceiling for most deployments is `50`. + +**5.5.4: Track user-reported issues** + +Monitor `~calls-support` for recurring complaints. + +Check [Appendix A: Troubleshooting](#appendix-a-troubleshooting) for common issues and fixes. + +--- + +## Appendix A: Troubleshooting + +### A.1 The call button is missing + +| Cause | Fix | +|---|---| +| The Calls plugin is disabled | Go to **System Console > Plugins > Plugin Management** and enable Calls | +| The deployment is in test mode | Go to **System Console > Plugins > Calls > Settings** and check the deployment state - Calls must be enabled in specific channels by System Admins in test mode | +| Calls is not enabled for the channel | When test mode is enabled, open the **channel menu** and select **Enable calls** | +| The user is on an older client | Ask the user to update to the current Mattermost desktop or mobile app | + +### A.2 Calls start but audio does not work + +| Cause | Fix | +|---|---| +| UDP `8443` is blocked | Repeat the UDP connectivity check from Phase 1 (check 1.6.1 or 1.6.3) and confirm the firewall rule is applied | +| TCP `8443` is also blocked and fallback is failing | Repeat the TCP check (1.6.2 or 1.6.4) - clients need at least one path to the media service | +| The wrong media address is being advertised | Re-check `ICE Host Override` in Phase 2A (Integrated) or `ice_host_override` in `rtcd.toml` in Phase 2B (RTCD) - the address must be reachable by clients | +| Browser or desktop microphone permissions were denied | Ask the user to check browser or OS microphone permissions and reload the app | + +### A.3 Remote users cannot join from outside the network + +| Cause | Fix | +|---|---| +| External firewall rules are blocking UDP `8443` | Confirm external reachability to UDP `8443` on the media server - cloud security groups and on-prem firewalls both need to allow inbound traffic from the internet | +| The advertised media address is a private IP | Set `ICE Host Override` (Integrated) or `ice_host_override` in `rtcd.toml` to the correct public IP or use STUN (1.3.1) | +| Client networks are too restrictive for direct UDP or TCP | Deploy a TURN server and add it to **ICE server configurations** | + +### A.4 Recording, transcription, or captions are failing + +| Cause | Fix | +|---|---| +| calls-offloader is not running | Run `nmap -p 4545 YOUR_OFFLOADER_SERVER` from the Mattermost server - if the result is `closed`, the service is not running; check the systemd service logs | +| Mattermost cannot reach the Job Service URL | Run `curl http://YOUR_OFFLOADER_SERVER:4545/version` from the Mattermost server and confirm it returns a version string | +| The offloader service account cannot use Docker | Confirm the service account is in the `docker` group on the calls-offloader server | diff --git a/source/administration-guide/configure/calls-deployment.md b/source/administration-guide/configure/calls-deployment.md deleted file mode 100644 index 154e6afa6f3..00000000000 --- a/source/administration-guide/configure/calls-deployment.md +++ /dev/null @@ -1,334 +0,0 @@ -# Deploy Mattermost Calls - -```{include} ../../_static/badges/all-commercial.md -``` - -This document provides an overview of Mattermost Calls deployment options for self-hosted environments, including [air-gapped environments](https://docs.mattermost.com/configure/calls-deployment.html#air-gapped-deployments), ensuring private communication without reliance on public internet connectivity with flexible configuration options for complex network requirements. - - -## Quick Links - -For detailed information on specific topics, please refer to these specialized guides: - -- {doc}`RTCD Setup and Configuration `: Comprehensive guide for setting up the dedicated RTCD service -- {doc}`Calls Offloader Setup and Configuration `: Comprehensive guide for setting up the calls-offloader service for recording and transcription -- {doc}`Calls Troubleshooting `: Detailed troubleshooting steps and debugging techniques -- {doc}`Calls Metrics and Monitoring `: Guide to monitoring Calls performance using metrics and observability -- {doc}`Calls Deployment on Kubernetes `: Detailed guide for deploying Calls in Kubernetes environments - -## About Mattermost Calls - -Mattermost Calls provides integrated audio calling and screen sharing capabilities within Mattermost channels. It's built on WebRTC technology and can be deployed either: - -1. **Integrated mode**: Built into the Calls plugin (simpler, suitable for smaller deployments) -2. **RTCD mode**: Using a dedicated service for improved performance and scalability (recommended for production environments) - -## Terminology - -- [WebRTC](https://bloggeek.me/webrtcglossary/webrtc-2/): The set of protocols on which calls are built -- **RTC**: Real-Time Connection channel used for media (audio/video/screen) -- **WS**: WebSocket connection used for signaling and connection setup -- **SFU**: Selective Forwarding Unit, routes media between participants -- [NAT](https://bloggeek.me/webrtcglossary/nat/): Network Address Translation for mapping IP addresses -- [STUN](https://bloggeek.me/webrtcglossary/stun/): Protocol used by WebRTC clients to help traverse NATs -- [TURN](https://bloggeek.me/webrtcglossary/turn/): Protocol to relay media for clients behind strict firewalls - -## Key Components - -- **Calls plugin**: The main plugin that enables calls functionality. Installed by default in Mattermost self-hosted deployments. -- **RTCD service**: Optional dedicated service for offloading media processing (Enterprise feature). Typically deployed to dedicated servers or containers. See [RTCD Setup and Configuration](calls-rtcd-setup.md) for details. -- **calls-offloader**: Service for call recording and transcription (if enabled). Typically deployed to dedicated servers. See [Calls Offloader Setup and Configuration](calls-offloader-setup.md) for setup and troubleshooting details. - -## Network Requirements - -- Run Mattermost server on a secure (HTTPs) connection. This is a necessary requirement on the client to allow capturing devices (e.g., microphone, screen). See the [config TLS](https://docs.mattermost.com/deploy/server/setup-tls.html) section for more info. -- See [network requirements](#network) below. - -### Client - -- Clients need to be able to connect (send and receive data) to the instance hosting the calls through the UDP port configured as `RTC Server Port`. If this is not possible a TURN server should be used to achieve connectivity. -- Depending on the platform or operating system, clients may need to grant additional permissions to the application (e.g., browser, desktop app) to allow them to capture audio inputs or share the screen. - -### Network - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ServicePortsProtocolsSourceTargetPurpose
API (Calls plugin)80,443TCP (incoming)Mattermost clients (web/desktop/mobile)Mattermost instance (Calls plugin)To allow for HTTP and WebSocket connectivity from clients to Calls plugin. This API is exposed on the same connection as Mattermost, so there's likely no need to change anything.
RTC (Calls plugin or rtcd)8443UDP (incoming)Mattermost clients (Web/Desktop/Mobile) and jobs spawned by Calls Offloader (Recorder, Transcriber)Mattermost instance or rtcd serviceTo allow clients to establish connections that transport calls related media (e.g. audio, video). This should be open on any network component (e.g. NAT, firewalls) in between the instance running the plugin (or rtcd) and the clients joining calls so that UDP traffic is correctly routed both ways (from/to clients).
RTC (Calls plugin or rtcd)8443TCP (incoming)Mattermost clients (Web/Desktop/Mobile) and jobs spawned by Calls Offloader (Recorder, Transcriber)Mattermost instance or rtcd serviceTo allow clients to establish connections that transport calls related media (e.g. audio, video). This should be open on any network component (e.g. NAT, firewalls) in between the instance running the plugin (or rtcd) and the clients joining calls so that TCP traffic is correctly routed both ways (from/to clients). This can be used as a backup channel in case clients are unable to connect using UDP. It requires rtcd version >= v0.11 and Calls version >= v0.17.
API (rtcd)8045TCP (incoming)Mattermost instance(s) (Calls plugin)rtcd serviceTo allow for HTTP/WebSocket connectivity from Calls plugin to rtcd service. Can be expose internally as the service only needs to be reachable by the instance(s) running the Mattermost server.
STUN (Calls plugin or rtcd)3478UDP (outgoing)Mattermost Instance(s) (Calls plugin) or rtcd serviceConfigured STUN servers(Optional) To allow for either Calls plugin or rtcd service to discover their instance public IP. Only needed if configuring STUN/TURN servers. This requirement does not apply when manually setting an IP or hostname through the ICE Host Override config option.
- -For complete network requirements, see the [RTCD Setup and Configuration](calls-rtcd-setup.md) guide. - -### RHEL deployments with firewalld and fapolicyd - -When deploying Mattermost Calls or the rtcd service on RHEL systems with firewalld or fapolicyd enabled, additional firewall and security configuration is required. - -**Required ports:** -- **Calls plugin (integrated)**: Port 8443 UDP/TCP for RTC media traffic -- **rtcd service (standalone)**: Ports 8443 UDP/TCP for RTC media traffic + Port 8045 TCP for API communication with Mattermost - -**Configuration steps:** - -For complete firewalld and fapolicyd configuration instructions, including troubleshooting steps and example rules, see the [RHEL deployment guide](https://docs.mattermost.com/deployment-guide/server/deploy-linux.html#itab--RHEL-CentOS--0_1-RHEL-CentOS). The guide includes: -- firewalld port configuration for Mattermost, Calls plugin, and rtcd service -- fapolicyd rules for Mattermost server and Calls plugin -- Separate fapolicyd configuration for standalone rtcd service -- Troubleshooting guidance for "operation not permitted" errors - -```{note} -The Calls plugin runs as part of Mattermost and is covered by the standard Mattermost fapolicyd rules. Only the standalone rtcd service requires separate fapolicyd configuration. -``` - -## Limitations - -- All Mattermost customers can start, join, and participate in 1:1 audio calls with optional screen sharing. -- For group calls up to 50 concurrent users, Mattermost Enterprise, Professional, or Mattermost Cloud is required. -- Enterprise customers can also [record calls](https://docs.mattermost.com/collaborate/make-calls.html#record-a-call), enable [live text captions](https://docs.mattermost.com/collaborate/make-calls.html#live-captions-during-calls) during calls, and [transcribe recorded calls](https://docs.mattermost.com/collaborate/make-calls.html#transcribe-recorded-calls). We recommend that Enterprise self-hosted customers looking for group calls beyond 50 concurrent users consider using the [dedicated RTCD service](#when-to-use-rtcd). -- For Mattermost self-hosted deployments, System admins need to enable and configure the plugin [using the System Console](https://docs.mattermost.com/configure/plugins-configuration-settings.html#calls). The default maximum number of participants is unlimited; however, we recommend a maximum of 50 participants per call. Maximum call participants is configurable by going to **System Console > Plugin Management > Calls > Max call participants**. Call participant limits greatly depends on instance resources. For more details, refer to the [Performance Considerations](#performance-considerations) section below. - -## Configuration - -For Mattermost self-hosted customers, the calls plugin is pre-packaged, installed, and enabled. Configuration to allow end-users to use it can be found in ``System Console > Plugins > Calls``. - -## Modes of operation - -Depending on how the Mattermost server is running, there are several modes under which the Calls plugin can operate. Please refer to the section below on [the RTCD service](#when-to-use-rtcd) to learn about the `rtcd` and the Selective Forwarding Unit (SFU). - -| Mattermost deployment | SFU | SFU deployment | -|-----------------------|-----|----------------| -| Single instance | integrated | | -| Single instance | rtcd | | -| High availability cluster-based | integrated | clustered | -| High availability cluster-based | rtcd | | - -### Single instance - -#### Integrated - -This is the default mode when first installing the plugin on a single Mattermost instance setup. The WebRTC service is integrated in the plugin itself and runs alongside the Mattermost server. - -![A diagram of the integrated configuration model of a single instance.](../../images/calls-deployment-image3.png) - -#### rtcd - -```{include} ../../_static/badges/ent-plus.md -``` - -An external, dedicated and scalable WebRTC service (`rtcd`) is used to handle all calls media routing. - -![A diagram of a Web RTC deployment configuration.](../../images/calls-deployment-image7.png) - -### High availability cluster-based - -```{include} ../../_static/badges/ent-plus.md -``` - -#### Clustered - -This is the default mode when running the plugin in a high availability cluster-based deployment. Every Mattermost node will run an instance of the plugin that includes a WebRTC service. Calls are distributed across all available nodes through the existing load-balancer: a call is hosted on the instance where the initiating websocket connection (first client to join) is made. A single call will be hosted on a single cluster node. - -![A diagram of a clustered calls deployment.](../../images/calls-deployment-image5.png) - -#### rtcd (High Availability) - -![A diagram of an rtcd deployment.](../../images/calls-deployment-image2.png) - -### Kubernetes Deployments - -```{include} ../../_static/badges/ent-plus.md -``` - -RTCD is the only officially supported approach for Kubernetes deployments. For detailed information on deploying Mattermost Calls in Kubernetes environments, including Helm chart configurations, resource requirements, and scaling considerations, see the [Calls Deployment on Kubernetes](calls-kubernetes.md) guide. - -## When to Use RTCD - -This section will help you understand when and why your organization would want to use the dedicated RTCD service. - -```{note} -RTCD is a standalone service, which adds operational complexity, maintenance costs, and requires an Enterprise license. For those who are evaluating Calls, and for many small instances of Mattermost, the integrated SFU (the one included in the Calls plugin) may be sufficient initially. -``` - -The RTCD service is the recommended way to host Calls for the following reasons: - -- **Performance of the main Mattermost server(s)**: When the Calls plugin runs the SFU, calls traffic is added to the processing load of the server running the rest of your Mattermost services. If Calls traffic spikes, it can negatively affect the responsiveness of these services. Using an RTCD service isolates the calls traffic processing to those RTCD instances, and also reduces costs by minimizing CPU usage spikes. - -- **Performance, scalability, and stability of the Calls product**: If Calls traffic spikes, or more overall capacity is needed, RTCD servers can be added to balance the load. As an added benefit, if the Mattermost traffic spikes, or if a Mattermost instance needs to be restarted, those people in a current call will not be affected - current calls won't be dropped. - - Some caveats apply here. While the main Mattermost server is down, things will quickly start to go awry: WebSocket events (for example: emoji reactions, hand raising, muting/unmuting) will not be transmitted, and new media track negotiations will fail. While existing media streams will continue initially, if the main server does not come back up within a reasonable timeframe (e.g., 1 minute), clients will begin to drop from the call entirely as their WebSocket re-connect attempts will hit the maximum allowed. - -- **Kubernetes deployments**: In a Kubernetes deployment, RTCD is strongly recommended; it is currently the only officially supported way to run Calls. - -- **Technical benefits**: The dedicated RTCD service has been optimized and tuned at the system/network level for real-time audio/video traffic, where latency is generally more important than throughput. - -In general, RTCD is the preferred solution for a performant and scalable deployment. With RTCD, the Mattermost server will be minimally impacted when hosting a high number of calls. - -For detailed RTCD setup instructions, see the [RTCD Setup and Configuration](calls-rtcd-setup.md) guide. - -## Call Recording and Transcription - -```{include} ../../_static/badges/ent-plus.md -``` - -Mattermost Calls supports recording, transcription, and live captioning features. These processes are resource-intensive and MUST be offloaded from the Mattermost application server to maintain performance. - -For call recording and transcription, you need to: - -1. Deploy the `calls-offloader` service -2. Configure the service URL in the System Console -3. Enable call recordings and/or transcriptions in the plugin settings - -For detailed setup instructions, see the [Calls Offloader Setup and Configuration](calls-offloader-setup.md) guide. - -## Air-Gapped Deployments - -Mattermost Calls can function in air-gapped environments. Exposing Calls to the public internet is only necessary when users need to connect from outside the local network, and no existing method supports that connection. In such setups: - -- Users should connect from within the private/local network. This can be done on-premises, through a VPN, or via virtual machines. -- Configuring a STUN server is unnecessary, as all connections occur within the local network. -- The [ICE Host Override](https://docs.mattermost.com/configure/plugins-configuration-settings.html#ice-host-override) configuration setting can be optionally set with a local IP address (e.g., 192.168.1.45), depending on the specific network configuration and topology. -- For call recording and transcription in air-gapped environments, see the [Air-Gapped Deployments](calls-offloader-setup.md#air-gapped-deployments) section in the Calls Offloader Setup documentation. - -```{note} -For RHEL deployments with firewalld or fapolicyd, see the [RHEL deployments with firewalld and fapolicyd](#rhel-deployments-with-firewalld-and-fapolicyd) section above. -``` - -## Performance Considerations - -Calls performance primarily depends on: - -- **CPU resources**: More participants require more processing power -- **Network bandwidth**: Both incoming and outgoing traffic increases with participant count. Due to the nature of the service, the bottleneck is always going to be the outgoing/egress path -- **Active speakers**: Unmuted participants require significantly more resources -- **Presenters**: Screen sharing participants require even more resources than active speakers - -For detailed performance metrics, benchmarks, and monitoring guidance, see the [Calls Metrics and Monitoring](calls-metrics-monitoring.md) guide. - -## Frequently Asked Questions - -### Is calls traffic encrypted? -Media (audio/video) is encrypted using security standards as part of WebRTC. It's mainly a combination of DTLS and SRTP. It's not e2e encrypted in the sense that in the current design all media needs to go through Mattermost which acts as a media router and has complete access to it. Media is then encrypted back to the clients so it's secured during transit. In short: only the participant clients and the Mattermost server have access to unencrypted call data. - -### Are there any third-party services involved? -Only a Mattermost STUN server (`stun.global.calls.mattermost.com`) is used by default. No user information, call metadata, or media traffic is ever sent to or shared with this STUN service; its sole purpose is to help WebRTC clients discover their public IP address and port mapping. Furthermore, this dependency can be entirely removed if you manually configure the ICE Host Override setting. - -### Is using UDP a requirement? -UDP is the recommended protocol to serve real-time media as it allows for the lowest latency between peers, but TCP fallback is supported since plugin version 0.17 and RTCD version 0.11. - -If clients are unable to connect using UDP (due to limitations or strict firewalls), you have a few options: - -- Since plugin version 0.17 and `rtcd` version 0.11 the RTC service will listen for TCP connections in addition to UDP ones. If configured correctly (e.g. using commonly allowed ports such as 80 or 443) it's possible to have clients connect directly through TCP when unable to do it through the preferred UDP channel. - -- Run calls through an external TURN server that listens on TCP and relays all media traffic between peers. However, this is a sub-optimal solution that should be avoided if possible as it will introduce extra latency along with added infrastructural cost. - -### Do I need a TURN server? -Only if clients are behind restrictive firewalls that block UDP. We recommend (and officially support) [coturn](https://github.com/coturn/coturn) if needed. - -### Can the traffic between Mattermost and `rtcd` be kept internal or should it be opened to the public? - -Yes, the `rtcd` <-> Mattermost communication (HTTP/WebSocket API over TCP port 8045) should remain internal in almost all cases. When possible, it's highly recommended to keep communication between the Mattermost cluster and the dedicated `rtcd` service under the same private network as this minimizes latency and greatly simplifies deployment and security. There is no requirement to expose `rtcd`'s HTTP API to the public internet. Only the media ports (UDP/TCP 8443) need to be accessible to end-users. - -### Can Calls be rolled out on a per-channel basis? - -Yes. Mattermost system admins running self-hosted deployments can enable or disable call functionality per channel. Once [test mode](https://docs.mattermost.com/configure/plugins-configuration-settings.html#test-mode) is enabled for Mattermost Calls: - -1. **Navigate to the channel** where you want to enable or disable Calls -2. **Access the channel menu** by clicking the channel name at the top of the channel -3. **Select the Calls option** from the dropdown menu: - - Select **Enable calls** for each channel where you want Calls enabled - - Select **Disable calls** for all channels where you want Calls disabled - -![Channel menu showing Enable/Disable calls options](../../images/calls-channel-enable-disable.png) - -Once Calls is enabled for specific channels, users can start making calls in those channels. - -```{note} -When [test mode](https://docs.mattermost.com/configure/plugins-configuration-settings.html#test-mode) is disabled for Mattermost Calls, users in any Mattermost channel can make a call. -``` - -## Troubleshooting - -For comprehensive troubleshooting steps and debugging techniques, please refer to the [Calls Troubleshooting](calls-troubleshooting.md) guide. - -## Next Steps - -1. For detailed setup instructions, see [RTCD Setup and Configuration](calls-rtcd-setup.md) -2. For monitoring guidance, see [Calls Metrics and Monitoring](calls-metrics-monitoring.md) -3. If you encounter issues, see [Calls Troubleshooting](calls-troubleshooting.md) -4. For Kubernetes deployments, see [Calls Deployment on Kubernetes](calls-kubernetes.md) diff --git a/source/administration-guide/configure/calls-kubernetes.md b/source/administration-guide/configure/calls-kubernetes.md index 51f413fa4a8..0d4f7c3beea 100644 --- a/source/administration-guide/configure/calls-kubernetes.md +++ b/source/administration-guide/configure/calls-kubernetes.md @@ -7,7 +7,7 @@ This guide provides detailed information for deploying Mattermost Calls on Kuber ## Overview -Mattermost Calls has been designed to integrate well with Kubernetes to offer improved scalability and control over the deployment. For Kubernetes deployments, the RTCD service is strongly recommended and is the only officially supported approach. +Mattermost Calls has been designed to integrate with Kubernetes for improved scalability and control over the deployment. Using the RTCD service is the only supported deployment model. ## Architecture @@ -99,12 +99,12 @@ For Kubernetes-specific troubleshooting: 3. Ensure UDP and TCP traffic is properly routed through your load balancer 4. Verify network policies allow required communication paths -For detailed troubleshooting steps, see the [Calls Troubleshooting](calls-troubleshooting.md) guide. +For detailed logging guidance, see the [Calls Logging](calls-logging.md) guide. ## Other Calls Documentation -- [Calls Overview](calls-deployment.md): Overview of deployment options and architecture +- [Calls Deployment Guide](calls-deployment-guide.md): Overview of deployment options and architecture - [RTCD Setup and Configuration](calls-rtcd-setup.md): Comprehensive guide for setting up the dedicated RTCD service - [Calls Offloader Setup and Configuration](calls-offloader-setup.md): Setup guide for call recording and transcription - [Calls Metrics and Monitoring](calls-metrics-monitoring.md): Guide to monitoring Calls performance using metrics and observability -- [Calls Troubleshooting](calls-troubleshooting.md): Detailed troubleshooting steps and debugging techniques +- [Calls Logging](calls-logging.md): Detailed guidance for collecting Calls logs and client diagnostics diff --git a/source/administration-guide/configure/calls-troubleshooting.md b/source/administration-guide/configure/calls-logging.md similarity index 98% rename from source/administration-guide/configure/calls-troubleshooting.md rename to source/administration-guide/configure/calls-logging.md index b376587465d..6d76e672c8b 100644 --- a/source/administration-guide/configure/calls-troubleshooting.md +++ b/source/administration-guide/configure/calls-logging.md @@ -1,4 +1,4 @@ -# Troubleshooting Mattermost Calls +# Calls Logging ```{include} ../../_static/badges/all-commercial.md ``` @@ -29,4 +29,4 @@ The Mattermost server logs often contain entries related to the Calls plugin. If ```{note} Interpreting RTCD and client logs can be challenging, as the Interactive Connectivity Establishment (ICE) negotiation during call setup often logs expected and benign failure or error messages. We strongly recommend providing the complete set of logs to Mattermost Support for analysis. -``` \ No newline at end of file +``` diff --git a/source/administration-guide/configure/calls-metrics-monitoring.md b/source/administration-guide/configure/calls-metrics-monitoring.md index d5ae641d3db..1d3b212a366 100644 --- a/source/administration-guide/configure/calls-metrics-monitoring.md +++ b/source/administration-guide/configure/calls-metrics-monitoring.md @@ -408,11 +408,11 @@ Each target should show status "UP" in green. If a target shows "DOWN" or errors ## Other Calls Documentation -- [Calls Overview](calls-deployment.md): Overview of deployment options and architecture +- [Calls Deployment Guide](calls-deployment-guide.md): Overview of deployment options and architecture - [RTCD Setup and Configuration](calls-rtcd-setup.md): Comprehensive guide for setting up the dedicated RTCD service - [Calls Offloader Setup and Configuration](calls-offloader-setup.md): Setup guide for call recording and transcription - [Calls Deployment on Kubernetes](calls-kubernetes.md): Detailed guide for deploying Calls in Kubernetes environments -- [Calls Troubleshooting](calls-troubleshooting.md): Detailed troubleshooting steps and debugging techniques +- [Calls Logging](calls-logging.md): Detailed guidance for collecting Calls logs and client diagnostics **Note:** Configure Prometheus storage accordingly to balance disk usage with retention needs. If you need to be tight on storage, you can use a short retention period. If you have lots of storage you can keep the retention length longer. \ No newline at end of file diff --git a/source/administration-guide/configure/calls-offloader-setup.md b/source/administration-guide/configure/calls-offloader-setup.md index a3e32e6bf87..78a4484e3f4 100644 --- a/source/administration-guide/configure/calls-offloader-setup.md +++ b/source/administration-guide/configure/calls-offloader-setup.md @@ -493,9 +493,9 @@ The `--image-registry` flag sets the registry prefix used when the offloader pul ## Other Calls Documentation -- [Calls Overview](calls-deployment.md): Overview of deployment options and architecture +- [Calls Deployment Guide](calls-deployment-guide.md): Overview of deployment options and architecture - [RTCD Setup and Configuration](calls-rtcd-setup.md): Comprehensive guide for setting up the dedicated RTCD service - [Calls Metrics and Monitoring](calls-metrics-monitoring.md): Guide to monitoring Calls performance using metrics and observability - [Calls Deployment on Kubernetes](calls-kubernetes.md): Detailed guide for deploying Calls in Kubernetes environments -- [Calls Troubleshooting](calls-troubleshooting.md): Detailed troubleshooting steps and debugging techniques +- [Calls Logging](calls-logging.md): Detailed guidance for collecting Calls logs and client diagnostics - [calls-offloader performance documentation](https://github.com/mattermost/calls-offloader/blob/master/docs/performance.md): Detailed performance tuning and monitoring recommendations \ No newline at end of file diff --git a/source/administration-guide/configure/calls-overview.rst b/source/administration-guide/configure/calls-overview.rst deleted file mode 100644 index 0d41150ba80..00000000000 --- a/source/administration-guide/configure/calls-overview.rst +++ /dev/null @@ -1,27 +0,0 @@ -Mattermost Calls Overview -========================= - -.. include:: ../../_static/badges/all-commercial.rst - :start-after: :nosearch: - -Mattermost Calls provides integrated audio calling and screen sharing capabilities within Mattermost channels. This section covers deployment, configuration, and management of Mattermost Calls. - -.. toctree:: - :maxdepth: 1 - :hidden: - - Deploy Mattermost Calls - RTCD Setup and Configuration - Calls Offloader Setup and Configuration - Calls Metrics and Monitoring - Deploy Calls on Kubernetes - Calls Troubleshooting - -**Calls Documentation:** - -* :doc:`Calls Deployment Overview ` - Main deployment overview and architecture guide for Mattermost Calls -* :doc:`RTCD Setup and Configuration ` - Real-time communication daemon setup for enterprise deployments -* :doc:`Calls Offloader Setup and Configuration ` - Configure call recording and transcription services -* :doc:`Calls Metrics and Monitoring ` - Performance monitoring with Prometheus and Grafana -* :doc:`Calls Deployment on Kubernetes ` - Kubernetes deployment guide for scalable Calls infrastructure -* :doc:`Calls Troubleshooting ` - Comprehensive troubleshooting guide for common issues diff --git a/source/administration-guide/configure/calls-rtcd-setup.md b/source/administration-guide/configure/calls-rtcd-setup.md index 5057e2ec210..edda32edbac 100644 --- a/source/administration-guide/configure/calls-rtcd-setup.md +++ b/source/administration-guide/configure/calls-rtcd-setup.md @@ -10,7 +10,7 @@ This guide provides detailed instructions for setting up, configuring, and valid Before deploying RTCD, ensure you have: - A Mattermost Enterprise license -- A server or VM with sufficient CPU and network capacity (see the [Performance](calls-deployment.html#performance) section for sizing guidance) +- A server or VM with sufficient CPU and network capacity (see the [Performance baselines](calls-metrics-monitoring.md#performance-baselines) section for sizing guidance) ## Network Requirements @@ -373,10 +373,10 @@ Once RTCD is properly set up and validated, configure Mattermost to use it: ## Other Calls Documentation -- [Calls Overview](calls-deployment.md): Overview of deployment options and architecture +- [Calls Deployment Guide](calls-deployment-guide.md): Overview of deployment options and architecture - [Calls Offloader Setup and Configuration](calls-offloader-setup.md): Setup guide for call recording and transcription - [Calls Metrics and Monitoring](calls-metrics-monitoring.md): Guide to monitoring Calls performance using metrics and observability - [Calls Deployment on Kubernetes](calls-kubernetes.md): Detailed guide for deploying Calls in Kubernetes environments -- [Calls Troubleshooting](calls-troubleshooting.md): Detailed troubleshooting steps and debugging techniques +- [Calls Logging](calls-logging.md): Detailed guidance for collecting Calls logs and client diagnostics For detailed Mattermost Calls configuration options, see the [Calls Plugin Configuration Settings](plugins-configuration-settings.rst#calls) documentation. \ No newline at end of file diff --git a/source/administration-guide/configure/plugins-configuration-settings.rst b/source/administration-guide/configure/plugins-configuration-settings.rst index 106aa58c617..0d53d167743 100644 --- a/source/administration-guide/configure/plugins-configuration-settings.rst +++ b/source/administration-guide/configure/plugins-configuration-settings.rst @@ -482,7 +482,7 @@ Max call participants .. note:: - This setting is applicable only to self-hosted deployments. - The environment variable ``MM_CALLS_MAX_PARTICIPANTS`` is deprecated in favor of ``MM_CALLS_MAX_CALL_PARTICIPANTS``. - - This setting is optional, but the recommended maximum number of participants is **50**. Call participant limits greatly depends on instance resources. See the :doc:`Calls self-hosted deployment ` documentation for details. + - This setting is optional, but the recommended maximum number of participants is **50**. Call participant limits greatly depends on instance resources. See the :doc:`Calls deployment guide ` documentation for details. .. config:setting:: ice-servers-configurations @@ -510,7 +510,7 @@ ICE servers configurations - The configurations above, containing STUN and TURN servers, are sent to the clients and used to generate local candidates. - If hosting calls through the plugin (i.e. not using the |rtcd_service|) any configured STUN server may also be used to find the instance's public IP when none is provided through the |ice_host_override_link| option. -.. |rtcd_service| replace:: :doc:`RTCD service ` +.. |rtcd_service| replace:: :doc:`RTCD service ` **Example** @@ -758,7 +758,7 @@ Call recording quality .. note:: - This setting is applicable only to self-hosted deployments. - - The quality setting will affect the performance of the job service and the file size of recordings. Refer to the :ref:`deployment section ` for more information. + - The quality setting will affect the performance of the job service and the file size of recordings. Refer to the :doc:`Calls deployment guide ` documentation for more information. .. config:setting:: enable-pluginscalltranscriptions :displayname: Enable call transcriptions (Plugins - Calls) @@ -810,7 +810,7 @@ Transcriber model size .. note:: - This setting is applicable only to self-hosted deployments. - - This setting is available starting in plugin version 0.22. The model size setting will affect the performance of the job service. Refer to the :ref:`configure call recordings, transcriptions, and live captions ` documentation for more information. + - This setting is available starting in plugin version 0.22. The model size setting will affect the performance of the job service. Refer to the :doc:`Calls deployment guide ` documentation for more information. .. config:setting:: call-transcriber-threads :displayname: Call transcriber threads (Plugins - Calls) @@ -834,7 +834,7 @@ Call transcriber threads .. note:: - This setting is applicable only to self-hosted deployments. - - The call transcriber threads setting will affect the performance of the job service. Refer to the :ref:`configure call recordings, transcriptions, and live captions ` documentation for more information. This setting is available starting in plugin version 0.26.2. + - The call transcriber threads setting will affect the performance of the job service. Refer to the :doc:`Calls deployment guide ` documentation for more information. This setting is available starting in plugin version 0.26.2. .. config:setting:: enable-pluginslivecaptions :displayname: (Experimental) Enable live captions (Plugins - Calls) diff --git a/source/conf.py b/source/conf.py index 5ab87f200be..c4acceccce2 100644 --- a/source/conf.py +++ b/source/conf.py @@ -423,7 +423,7 @@ def setup(app: Sphinx): sphinx_tabs_disable_tab_closing = True sphinx_tabs_disable_css_loading = False -myst_enable_extensions = ["colon_fence"] +myst_enable_extensions = ["colon_fence", "tasklist"] myst_heading_anchors = 3 # Suppress particular classes of warnings diff --git a/source/deployment-guide/deployment-guide-index.rst b/source/deployment-guide/deployment-guide-index.rst index 17c63200316..d3e6adf1875 100644 --- a/source/deployment-guide/deployment-guide-index.rst +++ b/source/deployment-guide/deployment-guide-index.rst @@ -13,14 +13,15 @@ Whether you're deploying the server application, desktop application, or mobile Quick Start Evaluation Reference Architecture Server Deployment + Calls Deployment Desktop App Deployment Mobile App Deployment Deployment Troubleshooting - * :doc:`Quick Start Evaluation ` - A quick start guide to help you get started with Mattermost. * :doc:`Reference Architecture ` - Reference architectures for scaling Mattermost and specialized deployment scenarios. * :doc:`Server deployment ` - Pre-deployment checks, security considerations, hardware recommendations, software prerequisites, and step-by-step guidance to deploying Mattermost server. +* :doc:`Calls Deployment Guide ` - Deploy and operate Mattermost Calls infrastructure, including RTCD, recording services, and supporting network configuration. * :doc:`Desktop deployment ` - Installation procedures for Mattermost's desktop applications across Windows, macOS, and Linux, and large-scale, enterprise-wide deployments. * :doc:`Mobile deployment ` - How to set up push notifications using Mattermost's notification service and troubleshooting tips. * :doc:`Deployment troubleshooting ` - Best practices for diagnosing and resolving common deployment issues. diff --git a/source/deployment-guide/reference-architecture/deployment-scenarios/air-gapped-deployment.rst b/source/deployment-guide/reference-architecture/deployment-scenarios/air-gapped-deployment.rst index 250053a050d..6eacab55b7e 100644 --- a/source/deployment-guide/reference-architecture/deployment-scenarios/air-gapped-deployment.rst +++ b/source/deployment-guide/reference-architecture/deployment-scenarios/air-gapped-deployment.rst @@ -60,7 +60,7 @@ On an internet connected machine, you must gather all required packages, contain **(Optional) Supporting Services** Consider downloading these additional resources if you plan to enable these optional components: - - :doc:`Mattermost Calls `: `mattermost-calls-offloader `__ (required for recording, transcription and live captions) and `mattermost-rtcd `__ (required for performance and scalability). + - :doc:`Mattermost Calls `: `mattermost-calls-offloader `__ (required for recording, transcription and live captions) and `mattermost-rtcd `__ (required for performance and scalability). - `Elasticsearch `__ can be `deployed `__ for enhanced search performance at scale. - `Prometheus `_ and `Grafana `__ for monitoring and observability @@ -79,7 +79,7 @@ On an internet connected machine, you must gather all required packages, contain **(Optional) Supporting Services** Consider downloading these additional resources if you plan to enable these optional components: - - :doc:`Mattermost Calls ` helm charts: `mattermost-calls-offloader `__ and `values `__ (required for recording, transcription and live captions), `mattermost-rtcd `__ and `values `__ (required for performance and scalability). + - :doc:`Mattermost Calls ` helm charts: `mattermost-calls-offloader `__ and `values `__ (required for recording, transcription and live captions), `mattermost-rtcd `__ and `values `__ (required for performance and scalability). - `Elasticsearch `__ can be `deployed in air-gapped k8 environments `__ for enhanced search performance at scale. - `Prometheus `__ and `Grafana `__ operators for monitoring and observability @@ -97,7 +97,7 @@ On an internet connected machine, you must gather all required packages, contain **(Optional) Supporting Services** Consider downloading these additional resources if you plan to enable these optional components: - - :doc:`Mattermost Calls ` images: `calls-offloader `__ (required for recording, transcription and live captions) and `rtcd `__ (required for performance and scalability). + - :doc:`Mattermost Calls ` images: `calls-offloader `__ (required for recording, transcription and live captions) and `rtcd `__ (required for performance and scalability). - `Elasticsearch `__ image for enhanced search performance at scale. - `Prometheus `__ and `Grafana `__ images for monitoring and observability. diff --git a/source/deployment-guide/reference-architecture/deployment-scenarios/deploy-ddil-operations.rst b/source/deployment-guide/reference-architecture/deployment-scenarios/deploy-ddil-operations.rst index 5c9b4268071..edc32325a75 100644 --- a/source/deployment-guide/reference-architecture/deployment-scenarios/deploy-ddil-operations.rst +++ b/source/deployment-guide/reference-architecture/deployment-scenarios/deploy-ddil-operations.rst @@ -61,7 +61,7 @@ This hybrid deployment architecture provides optimal collaboration in both conne - :doc:`AI Agents `: AI Agents run against a local LLM hosted within your tactical network. - - :doc:`Audio & Screenshare `: Calls offers native real-time self-hosted audio calls and screen sharing within your tactical network. + - :doc:`Audio & Screenshare `: Calls offers native real-time self-hosted audio calls and screen sharing within your tactical network. - **Proxy Server:** The :doc:`proxy server ` handles HTTP(S) routing within the cluster, directing traffic between the server and clients accessing Mattermost services. NGINX is recommended for load balancing with support for WebSocket connections, health check endpoints, and sticky sessions. The proxy layer provides SSL termination and distributes client traffic across application servers. @@ -69,7 +69,7 @@ This hybrid deployment architecture provides optimal collaboration in both conne - **Object Storage:** File uploads, images, and attachments are stored outside the application node on an :doc:`S3-compatible store ` or network/local storage, hosted locally within your tactical network. - - **Recording Instance:** ``calls-offloader`` :ref:`job service ` to offload heavy processing tasks from Mattermost Calls to self-hosted infrastructure within your tactical network, such as recordings, transcriptions, and live captioning. *(Optional)* + - **Recording Instance:** ``calls-offloader`` job service, configured using the :doc:`Calls Offloader Setup and Configuration ` guide, to offload heavy processing tasks from Mattermost Calls to self-hosted infrastructure within your tactical network, such as recordings, transcriptions, and live captioning. *(Optional)* - **Self-hosted integrations:** :doc:`Custom apps, plugins, and webhooks ` can be deployed within your tactical network. *(Optional - not shown)* @@ -101,10 +101,10 @@ Deploy an :doc:`OpenAI compatible LLM ` in a self-hosted configuration, including: +Effective collaboration at the tactical edge requires all voice and screen sharing capabilities remain operational without reliance on the internet or third-party services. Deploy :doc:`Mattermost Calls ` in a self-hosted configuration, including: -- The :ref:`rtcd service ` for scalable, low-latency media routing hosted on-premises. Run multiple ``rtcd`` nodes for redundancy. -- The :ref:`calls offloader ` service offloads heavy processing tasks like recording, transcription and live captioning to a locally hosted compliance-approved job server. +- The ``rtcd`` service, configured using the :doc:`RTCD Setup and Configuration ` guide, provides scalable, low-latency media routing hosted on-premises. Run multiple ``rtcd`` nodes for redundancy. +- The ``calls-offloader`` service, configured using the :doc:`Calls Offloader Setup and Configuration ` guide, offloads heavy processing tasks like recording, transcription and live captioning to a locally hosted compliance-approved job server. High availability and fault tolerance ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/source/deployment-guide/reference-architecture/deployment-scenarios/deploy-mission-partner.rst b/source/deployment-guide/reference-architecture/deployment-scenarios/deploy-mission-partner.rst index f177eef8d57..21bacdac5d7 100644 --- a/source/deployment-guide/reference-architecture/deployment-scenarios/deploy-mission-partner.rst +++ b/source/deployment-guide/reference-architecture/deployment-scenarios/deploy-mission-partner.rst @@ -74,7 +74,7 @@ The deployment architecture includes the following components: - :doc:`Workflow Automation `: Playbooks provide structure, monitoring and automation for repeatable processes built-in to your sovereign Mattermost deployment. - :doc:`Project Tracking `: Boards enables project management capabilities built-in to your local Mattermost deployment. Boards enables project management capabilities built-in to your sovereign Mattermost deployment. - :doc:`AI Agents `: AI Agents run against Azure OpenAI endpoints or a self-hosted LLM that is OpenAI-compatible. - - :doc:`Audio & Screenshare `: Calls offers native real-time self-hosted audio calls and screen sharing within your own network. + - :doc:`Audio & Screenshare `: Calls offers native real-time self-hosted audio calls and screen sharing within your own network. - **Proxy Server:** The :doc:`proxy server ` handles HTTP(S) routing within the cluster, directing traffic between the server and clients accessing Mattermost services, including requests from users in :doc:`connected organizations `. NGINX is recommended for load balancing with support for WebSocket connections, health check endpoints, and sticky sessions. The proxy layer provides SSL termination and distributes client traffic across application servers. @@ -82,7 +82,7 @@ The deployment architecture includes the following components: - **Object Storage:** File uploads, images, and attachments are stored outside the application node on an :doc:`S3-compatible store ` or an NFS (Network File System) server. `Azure Blob Storage `_ can be used, but needs an S3-compatible proxy for Mattermost to interface with. - - **Recording Instance:** ``calls-offloader`` :ref:`job service ` to offload heavy processing tasks from Mattermost Calls, such as recordings, transcriptions, and live captioning, to local infrastructure or private cloud. *(Optional)* + - **Recording Instance:** ``calls-offloader`` job service, configured using the :doc:`Calls Offloader Setup and Configuration ` guide, to offload heavy processing tasks from Mattermost Calls, such as recordings, transcriptions, and live captioning, to local infrastructure or private cloud. *(Optional)* - **Integration framework:** :doc:`Custom apps, plugins, and webhooks ` can be deployed for real-time data integrations and alerting. *(Optional - not shown)* @@ -159,10 +159,10 @@ Deploy Mattermost in a :doc:`cluster-based architecture ` in a self-hosted configuration to ensure voice and screen sharing capabilities remain operational without reliance on the internet, and that media traffic does not traverse non-compliant third-party services. +Deploy :doc:`Mattermost Calls ` in a self-hosted configuration to ensure voice and screen sharing capabilities remain operational without reliance on the internet, and that media traffic does not traverse non-compliant third-party services. -- The :ref:`rtcd service ` for scalable, low-latency media routing hosted on-premises. Run multiple ``rtcd`` nodes for redundancy. -- The :ref:`calls offloader ` service offloads heavy processing tasks like recording, transcription and live captioning to a compliance-approved job server. +- The ``rtcd`` service, configured using the :doc:`RTCD Setup and Configuration ` guide, provides scalable, low-latency media routing hosted on-premises. Run multiple ``rtcd`` nodes for redundancy. +- The ``calls-offloader`` service, configured using the :doc:`Calls Offloader Setup and Configuration ` guide, offloads heavy processing tasks like recording, transcription and live captioning to a compliance-approved job server. Compliance and retention ~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/source/deployment-guide/reference-architecture/deployment-scenarios/deploy-sovereign-collaboration.rst b/source/deployment-guide/reference-architecture/deployment-scenarios/deploy-sovereign-collaboration.rst index bd94aa5efaf..dae1563969e 100644 --- a/source/deployment-guide/reference-architecture/deployment-scenarios/deploy-sovereign-collaboration.rst +++ b/source/deployment-guide/reference-architecture/deployment-scenarios/deploy-sovereign-collaboration.rst @@ -49,7 +49,7 @@ The deployment architecture includes the following components: - :doc:`AI Agents `: AI Agents run against Azure OpenAI endpoints or a self-hosted LLM that is OpenAI-compatible. - - :doc:`Audio & Screenshare `: Calls offers native real-time self-hosted audio calls and screen sharing within your own network. + - :doc:`Audio & Screenshare `: Calls offers native real-time self-hosted audio calls and screen sharing within your own network. - **Proxy Server:** The :doc:`proxy server ` handles HTTP(S) routing within the cluster, directing traffic between the server and clients accessing Mattermost services. NGINX is recommended for load balancing with support for WebSocket connections, health check endpoints, and sticky sessions. The proxy layer provides SSL termination and distributes client traffic across application servers. @@ -57,7 +57,7 @@ The deployment architecture includes the following components: - **Object Storage:** File uploads, images, and attachments are stored outside the application node on an :doc:`S3-compatible store ` or an NFS (Network File System) server. `Azure Blob Storage `_ can be used, but needs an S3-compatible proxy for Mattermost to interface with. - - **Recording Instance:** ``calls-offloader`` :ref:`job service ` to offload heavy processing tasks from Mattermost Calls, such as recordings, transcriptions, and live captioning, to enterprise-controlled infrastructure or private cloud. *(Optional)* + - **Recording Instance:** ``calls-offloader`` job service, configured using the :doc:`Calls Offloader Setup and Configuration ` guide, to offload heavy processing tasks from Mattermost Calls, such as recordings, transcriptions, and live captioning, to enterprise-controlled infrastructure or private cloud. *(Optional)* - **Self-hosted integrations:** :doc:`Custom apps, plugins, and webhooks ` can be deployed within the enterprise boundary. *(Optional - not shown)* @@ -86,10 +86,10 @@ Deploy Mattermost in a :doc:`cluster-based architecture ` in a self-hosted configuration to ensure that Microsoft Teams users and Mattermost users collaborate without media ever leaving the sovereign network. +Data sovereignty compliance may require that all voice and screen sharing traffic remain within enterprise-controlled infrastructure and does not traverse third-party services. Deploy :doc:`Mattermost Calls ` in a self-hosted configuration to ensure that Microsoft Teams users and Mattermost users collaborate without media ever leaving the sovereign network. -- The :ref:`rtcd service ` for scalable, low-latency media routing hosted on-premises. Run multiple ``rtcd`` nodes for redundancy. -- The :ref:`calls offloader ` service offloads heavy processing tasks like recording, transcription and live captioning to a compliance-approved job server. +- The ``rtcd`` service, configured using the :doc:`RTCD Setup and Configuration ` guide, provides scalable, low-latency media routing hosted on-premises. Run multiple ``rtcd`` nodes for redundancy. +- The ``calls-offloader`` service, configured using the :doc:`Calls Offloader Setup and Configuration ` guide, offloads heavy processing tasks like recording, transcription and live captioning to a compliance-approved job server. Compliance and retention ~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/source/deployment-guide/server/linux/deploy-rhel.rst b/source/deployment-guide/server/linux/deploy-rhel.rst index 24e9f200037..124e0e65f5b 100644 --- a/source/deployment-guide/server/linux/deploy-rhel.rst +++ b/source/deployment-guide/server/linux/deploy-rhel.rst @@ -310,7 +310,7 @@ When deploying Mattermost on hardened RHEL systems, additional security configur Configure firewalld for Mattermost Calls (optional) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - If you're deploying the Mattermost Calls plugin or the standalone rtcd service, additional ports need to be opened. See the :doc:`Calls deployment ` documentation for details on Calls architecture and deployment modes. + If you're deploying the Mattermost Calls plugin or the standalone rtcd service, additional ports need to be opened. See the :doc:`Calls deployment guide ` documentation for details on Calls architecture and deployment modes. For integrated Calls plugin (running alongside Mattermost): @@ -434,7 +434,7 @@ When deploying Mattermost on hardened RHEL systems, additional security configur Configure fapolicyd for rtcd service (optional) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - If you're deploying the standalone rtcd service for Mattermost Calls, you'll need separate fapolicyd rules for the rtcd binary. The rtcd service is deployed separately from Mattermost and runs its own binary. See the :doc:`Calls deployment ` documentation for details on when and why to use rtcd. + If you're deploying the standalone rtcd service for Mattermost Calls, you'll need separate fapolicyd rules for the rtcd binary. The rtcd service is deployed separately from Mattermost and runs its own binary. See the :doc:`Calls deployment guide ` documentation for details on when and why to use rtcd. 1. Create a rule file for rtcd. The naming convention is critical - it must come before the deny rule (typically 80 works): @@ -487,7 +487,7 @@ When deploying Mattermost on hardened RHEL systems, additional security configur - The paths shown above assume rtcd is installed in ``/opt/rtcd/``. Adjust these paths based on your actual rtcd installation directory. - If you continue to see denials after following these steps, run ``sudo fapolicyd --debug`` to identify the specific paths being denied and adjust your rules accordingly. - - See the :doc:`rtcd deployment documentation ` for installation and configuration details. + - See the :doc:`RTCD setup and configuration ` documentation for installation and configuration details. Additional resources ^^^^^^^^^^^^^^^^^^^^^^ diff --git a/source/deployment-guide/server/preparations.rst b/source/deployment-guide/server/preparations.rst index f7524911601..e5450aad29d 100644 --- a/source/deployment-guide/server/preparations.rst +++ b/source/deployment-guide/server/preparations.rst @@ -10,7 +10,6 @@ This guide outlines the key preparation steps required before installing the Mat Review software and hardware requirements Set up an NGINX proxy - Configure Mattermost Calls Set up TLS Use an image proxy @@ -18,7 +17,6 @@ Before installing Mattermost Server, review the following preparation requiremen * :doc:`Review software and hardware requirements ` - Ensure your system meets the minimum requirements for Mattermost deployment. * :doc:`Set up an NGINX proxy ` - Configure NGINX as a reverse proxy for enhanced security and performance. -* :doc:`Configure Mattermost Calls ` - Set up real-time communication capabilities for voice and video calls. * :doc:`Set up TLS ` - Enable secure communication with SSL/TLS encryption. * :doc:`Use an image proxy ` - Configure image proxy for enhanced privacy and security. diff --git a/source/end-user-guide/collaborate/audio-and-screensharing.rst b/source/end-user-guide/collaborate/audio-and-screensharing.rst index 8263d8f3a0a..163e02f0efd 100644 --- a/source/end-user-guide/collaborate/audio-and-screensharing.rst +++ b/source/end-user-guide/collaborate/audio-and-screensharing.rst @@ -4,7 +4,7 @@ Audio and Screensharing .. include:: ../../_static/badges/all-commercial.rst :start-after: :nosearch: -Mattermost Calls offers native real-time chat, self-hosted audio calls, and screen sharing within your own network, enabling secure, effective team communication and collaboration. Learn more about :doc:`deploying Mattermost Calls ` in a self-hosted environment and :doc:`making calls ` with Mattermost. +Mattermost Calls offers native real-time chat, self-hosted audio calls, and screen sharing within your own network, enabling secure, effective team communication and collaboration. Learn more about :doc:`deploying Mattermost Calls ` in a self-hosted environment and :doc:`making calls ` with Mattermost. With calls and screen sharing, Mattermost ensures that communications remain uninterrupted, even during maintenance or outages, and scales effortlessly to meet your team’s growing needs, safeguarding the integrity of mission-critical operations. diff --git a/source/end-user-guide/collaborate/make-calls.rst b/source/end-user-guide/collaborate/make-calls.rst index 6d483399642..8853a61cd68 100644 --- a/source/end-user-guide/collaborate/make-calls.rst +++ b/source/end-user-guide/collaborate/make-calls.rst @@ -10,7 +10,7 @@ Using a web browser, the desktop app, or the mobile app, you can `join a call <# - All Mattermost customers can start, join, and participate in 1:1 audio calls with optional screen sharing. - For group calls up to 50 concurrent users, Mattermost Enterprise, Professional, or Mattermost Cloud is required. - - Enterprise customers can also `record calls <#record-a-call>`__, enable :ref:`live text captions ` during calls, and `transcribe recorded calls <#transcribe-recorded-calls>`__. We recommend that Enterprise self-hosted customers looking for group calls beyond 50 concurrent users consider using the :doc:`dedicated RTCD service `. + - Enterprise customers can also `record calls <#record-a-call>`__, enable :ref:`live text captions ` during calls, and `transcribe recorded calls <#transcribe-recorded-calls>`__. We recommend that Enterprise self-hosted customers looking for group calls beyond 50 concurrent users consider using the :doc:`dedicated RTCD service `. - Mattermost Cloud users can start calling right out of the box. For Mattermost self-hosted deployments, System admins need to enable and configure the plugin :ref:`using the System Console `. .. include:: ../../_static/badges/academy-calls.rst diff --git a/source/images/calls-deployment-integrated-recording-v2.png b/source/images/calls-deployment-integrated-recording-v2.png new file mode 100644 index 00000000000..87337af7dda Binary files /dev/null and b/source/images/calls-deployment-integrated-recording-v2.png differ diff --git a/source/images/calls-deployment-integrated-recording.png b/source/images/calls-deployment-integrated-recording.png new file mode 100644 index 00000000000..87337af7dda Binary files /dev/null and b/source/images/calls-deployment-integrated-recording.png differ diff --git a/source/images/calls-deployment-integrated.png b/source/images/calls-deployment-integrated.png new file mode 100644 index 00000000000..10dde7a1600 Binary files /dev/null and b/source/images/calls-deployment-integrated.png differ diff --git a/source/images/calls-deployment-rtcd-recording.png b/source/images/calls-deployment-rtcd-recording.png new file mode 100644 index 00000000000..8666656534e Binary files /dev/null and b/source/images/calls-deployment-rtcd-recording.png differ diff --git a/source/images/calls-deployment-rtcd.png b/source/images/calls-deployment-rtcd.png new file mode 100644 index 00000000000..ab22bc2908f Binary files /dev/null and b/source/images/calls-deployment-rtcd.png differ diff --git a/source/product-overview/certifications-and-compliance.rst b/source/product-overview/certifications-and-compliance.rst index d8c529b7908..adb3b77e1bd 100644 --- a/source/product-overview/certifications-and-compliance.rst +++ b/source/product-overview/certifications-and-compliance.rst @@ -231,7 +231,7 @@ Are you IPv6 compliant? Yes, the Mattermost platform is compliant with IPv6 when Audio & Screen Sharing is disabled, both for our :doc:`self-hosted and Cloud offerings `. -We plan to add IPv6 compliance for :doc:`Audio & Screen Sharing ` in future. +We plan to add IPv6 compliance for :doc:`Audio & Screen Sharing ` in future. Are you 508 compliant? ~~~~~~~~~~~~~~~~~~~~~~ diff --git a/source/product-overview/plans.md b/source/product-overview/plans.md index e26d539c9e4..3e56dac53aa 100644 --- a/source/product-overview/plans.md +++ b/source/product-overview/plans.md @@ -178,7 +178,7 @@ Multi-team collaboration Work across teams and organizations with real-time calling and screen share, guest accounts to integrate internal and external stakeholders, customer user groups to organize teams within teams, and system-wide notifications to share organization-wide messages. - Group calling and screen share: Streamline real-time collaboration with complete privacy by enabling group audio calling and screenshare up to approximately 50 concurrent users in any group call per self-hosted server. High-scale options for private, self-hosted group calling and screen share are available in Mattermost Enterprise with the setup of its horizontal scaling option. + Group calling and screen share: Streamline real-time collaboration with complete privacy by enabling group audio calling and screenshare up to approximately 50 concurrent users in any group call per self-hosted server. High-scale options for private, self-hosted group calling and screen share are available in Mattermost Enterprise with the setup of its horizontal scaling option. *v9.11+ @@ -217,7 +217,7 @@ v9.11+ - High availability, horizontally scalable calls and screen share: Enable high-scale, high availability deployment of audio calling and screen share through dedicated servers managed on an integrated Kubernetes platform. + High availability, horizontally scalable calls and screen share: Enable high-scale, high availability deployment of audio calling and screen share through dedicated servers managed on an integrated Kubernetes platform. v9.11+ diff --git a/source/product-overview/product-overview-index.rst b/source/product-overview/product-overview-index.rst index 1a4d5a266ba..71417d83dc4 100644 --- a/source/product-overview/product-overview-index.rst +++ b/source/product-overview/product-overview-index.rst @@ -79,7 +79,7 @@ Audio and screenshare - Enables :ref:`1:1 and group audio calls ` directly within channels and direct messages, maintaining contextual awareness and access control based on channel membership. - Supports secure :ref:`screen sharing ` for visual coordination and analysis. -- Operates in :doc:`sovereign, air-gapped, or sensitive network ` environments. +- Operates in :doc:`sovereign, air-gapped, or sensitive network ` environments. - Offers optional :ref:`AI-based transcription ` and :ref:`summarization ` for meeting capture and follow ups. - Works across web, desktop, and mobile for flexible, secure access. diff --git a/source/product-overview/unsupported-legacy-releases.md b/source/product-overview/unsupported-legacy-releases.md index 3dd6eeae5b0..6f28fec68b4 100644 --- a/source/product-overview/unsupported-legacy-releases.md +++ b/source/product-overview/unsupported-legacy-releases.md @@ -2346,7 +2346,7 @@ If you upgrade from a release earlier than v7.5, please read the other [Importan ### Highlights #### Calls - - [Audio calling and screen sharing](https://docs.mattermost.com/configure/calls-deployment.html) in channels is now generally available to all Mattermost customers. +- [Audio calling and screen sharing](https://docs.mattermost.com/configure/calls-deployment-guide.html) in channels is now generally available to all Mattermost customers. - Updated [the keyboard shortcut](https://docs.mattermost.com/channels/keyboard-shortcuts-for-channels.html#calls-shortcuts) to start and join calls. - Please see [the docs](https://docs.mattermost.com/configure/plugins-configuration-settings.html#calls) for additional details on configuration setting updates. diff --git a/source/redirects.py b/source/redirects.py index d5f9e40a5b8..490ca350a4b 100644 --- a/source/redirects.py +++ b/source/redirects.py @@ -551,6 +551,10 @@ "https://docs.mattermost.com/end-user-guide/upgrade-mattermost.html", "administration/release-lifecycle.html": "https://docs.mattermost.com/product-overview/releases-lifecycle.html", +"administration-guide/configure/calls-deployment.html": + "https://docs.mattermost.com/administration-guide/configure/calls-deployment-guide.html", +"administration-guide/configure/calls-overview.html": + "https://docs.mattermost.com/administration-guide/configure/calls-deployment-guide.html", "administration-guide/configure/site-configuration-settings.html#enable-secure-file-preview-on-mobile": "https://docs.mattermost.com/administration-guide/configure/environment-configuration-settings.html#enable-secure-file-preview-on-mobile", "administration-guide/configure/site-configuration-settings.html#allow-pdf-link-navigation-on-mobile": @@ -950,7 +954,13 @@ "configure/bulk-loading-troubleshooting.html": "https://docs.mattermost.com/administration-guide/onboard/bulk-loading-data.html", "configure/calls-deployment.html": - "https://docs.mattermost.com/administration-guide/configure/calls-deployment.html", + "https://docs.mattermost.com/administration-guide/configure/calls-deployment-guide.html", +"configure/calls-log-collection.html": + "https://docs.mattermost.com/administration-guide/configure/calls-logging.html", +"configure/calls-overview.html": + "https://docs.mattermost.com/administration-guide/configure/calls-deployment-guide.html", +"configure/calls-troubleshooting.html": + "https://docs.mattermost.com/administration-guide/configure/calls-logging.html", "configure/cloud-billing-account-settings.html": "https://docs.mattermost.com/administration-guide/configure/cloud-billing-account-settings.html", "configure/common-config-settings-notation.html":