Nextcloud talk

Guide d’installation et de configuration : Serveur de signalisation Nextcloud Talk (HPB)

Pour obtenir des appels audio et vidéo fluides à plusieurs participants sur Nextcloud Talk, la mise en place d’un serveur de signalisation (High Performance Backend) est indispensable. Ce système repose sur quatre composants principaux :

  • Coturn : Serveur STUN/TURN essentiel pour relayer les flux médias lorsque les routeurs/pare-feu bloquent les connexions directes.
  • Janus : Passerelle WebRTC qui distribue les flux audio et vidéo entre les clients.
  • NATS : Serveur de messagerie extrêmement rapide pour la communication interne.
  • Spreed Signaling Server : Le cœur du système qui relie Nextcloud, Janus et NATS.
⚠️ Avertissement d’Architecture (Très Important) : Un serveur dédié est requis

Il est fortement recommandé d’installer ce serveur de signalisation (HPB) et Coturn sur un serveur distinct (comme un petit VPS abordable) et non sur la même machine qui héberge votre base Nextcloud.

Pourquoi ? Le traitement vidéo en temps réel et le routage WebRTC de Janus consomment énormément de bande passante et de ressources CPU. Si vous mutualisez tout sur une seule machine, vos appels de groupe risquent d’être fortement saccadés, et les performances globales de votre interface Nextcloud s’effondreront pendant les réunions. Toutefois, les appels à 2 personnes seront tout à fait optimaux.

1. Mise en place de Coturn (Serveur STUN/TURN)

Le serveur Coturn permet aux appareils de se trouver sur Internet et relaie l’audio/vidéo quand la connexion directe (P2P) échoue.

sudo apt update
sudo apt install coturn

Activation du démon Coturn

Pour que Coturn démarre automatiquement, modifiez son fichier par défaut :

sudo nano /etc/default/coturn

Décommentez ou ajoutez cette ligne :

TURNSERVER_ENABLED=1

Configuration de Coturn

Générez un mot de passe secret (statique) qui sera utilisé par Nextcloud et le Signaling Server :

openssl rand -hex 16

Notez bien cette clé, elle sera appelée la_clé_générée dans la suite du guide.

Ensuite, sauvegardez le fichier de configuration original et créez-en un nouveau :

sudo mv /etc/turnserver.conf /etc/turnserver.conf.bak
sudo nano /etc/turnserver.conf

Collez la configuration de production suivante. Attention : Prenez soin de remplacer les valeurs en majuscules par vos propres informations. (Astuce : utilisez la commande ip a dans votre terminal pour trouver le nom de votre carte réseau, comme eth0 ou ens3).

listening-device=VOTRE_NOM_DE_CARTE_RÉSEAU
listening-port=3478
listening-ip=IP_PUBLIQUE_DU_SERVEUR
relay-ip=IP_PUBLIQUE_DU_SERVEUR
external-ip=IP_PUBLIQUE_DU_SERVEUR
min-port=49152
max-port=65535
fingerprint
use-auth-secret
static-auth-secret=la_clé_générée
server-name=turn.votre_domaine.com
realm=turn.votre_domaine.com
total-quota=100
bps-capacity=0
no-tls
no-dtls
stale-nonce
log-file=/var/tmp/turn.log
syslog
simple-log
no-multicast-peers
proc-user=turnserver
proc-group=turnserver

Redémarrez et activez le service :

sudo systemctl restart coturn
sudo systemctl enable coturn

2. Mise en place de Janus (Passerelle WebRTC)

Sur Ubuntu 24.04, vous pouvez utiliser le paquet officiel. (Pour les versions plus anciennes, un PPA externe peut être requis).

sudo apt install janus

Configuration de Janus

Vous devez modifier trois fichiers de configuration situés dans /etc/janus/.

1. janus.jcfg (Section nat: { ... }) :
Remplacez votre domaine STUN/TURN. Générez une clé pour le champ turn_rest_api_key avec la commande openssl rand -hex 16. Conservez cette clé, elle sera réutilisée plus tard.

nat: {
    stun_server = "turn.votredomaine.com"
    stun_port = 3478
    nice_debug = false
    full_trickle = true
    turn_rest_api_key = "VOTRE_CLE_SECRETE_GENEREE"
}

2. janus.transport.http.jcfg (Section general: { ... }) :

general: {
    base_path = "/janus"
    http = true
    port = 8088
    ip = "127.0.0.1"
    https = false
}

3. janus.transport.websockets.jcfg (Section general: { ... }) :

general: {
    ws = true
    ws_port = 8188
    ws_ip = "127.0.0.1"
    wss = false
}

Modification du Service Systemd pour Janus

Par défaut, la configuration de base de Janus peut être capricieuse et nécessiter un redémarrage manuel à chaque fois que vous redémarrez votre serveur. Pour corriger cela de façon permanente et optimiser les performances :

sudo nano /lib/systemd/system/janus.service
💡 Retour d’expérience (Production) :
Sans la directive Type=forking, Systemd gère mal le mode démon de Janus et échoue au démarrage. De plus, sans LimitNOFILE=65536, le serveur plantera sous la charge (erreur « Too many open files ») dès que plusieurs utilisateurs activeront leur caméra. La configuration ci-dessous corrige définitivement ces deux problèmes critiques.

Remplacez tout le contenu par cette configuration de production blindée :

[Unit]
Description=Janus WebRTC gateway
After=network.target
Wants=network-online.target
Documentation=https://janus.conf.meetecho.com/docs/index.html

[Service]
Type=forking
ExecStart=/usr/bin/janus --disable-colors --daemon --log-stdout
Restart=always
RestartSec=5
# Limite augmentée pour gérer des milliers de connexions simultanées
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

Appliquez les changements et démarrez le service :

sudo systemctl daemon-reload
sudo systemctl enable --now janus
sudo systemctl status janus

3. Mise en place de NATS (via Docker)

Le serveur NATS s’occupe de la messagerie instantanée en interne. La méthode la plus simple, propre et stable pour le faire tourner est d’utiliser Docker avec une politique de redémarrage automatique.

Lancement du conteneur

Nous allons lancer le conteneur NATS en attachant son port de communication (4222) uniquement à l’interface locale de votre serveur (127.0.0.1) pour des raisons de sécurité. Nous lui disons également de toujours redémarrer (--restart=always) même après un crash ou un reboot du VPS :

sudo docker pull nats:latest
sudo docker run --name=nats -d -p 127.0.0.1:4222:4222 --restart=always nats:latest
💡 Note de production (Utilisateurs avancés) :
Pour une utilisation standard avec Nextcloud Talk, la commande ci-dessus est parfaite. Cependant, si vous gérez une très grosse infrastructure et que vous avez besoin de régler le monitoring (port 8222) ou les limites de mémoire, vous pouvez créer un fichier nats-server.conf sur votre machine hôte et le lier au démarrage du conteneur en ajoutant :
-v /chemin/local/nats-server.conf:/nats-server.conf et l’argument --config nats-server.conf à la fin de votre commande Docker.

Vérifiez que le conteneur tourne correctement et que son statut indique « Up » :

sudo docker ps | grep nats

4. Installation de Spreed Signaling Server

Nous allons compiler le serveur depuis ses sources à l’aide de Go.

Téléchargement et Compilation

sudo apt install git make golang-go
cd /etc/
sudo git clone https://github.com/strukturag/nextcloud-spreed-signaling.git
cd /etc/nextcloud-spreed-signaling
sudo make build

Configuration du serveur de signalisation

C’est ici que la magie opère. Le fichier nextcloud-signaling.conf est le « cerveau » qui va relier Nextcloud, Janus et Coturn. La gestion des clés de sécurité peut être un vrai casse-tête, suivez donc attentivement le tableau explicatif ci-dessous.

Copiez le fichier d’exemple et ouvrez-le :

sudo cp server.conf.in /etc/nextcloud-signaling.conf
sudo nano /etc/nextcloud-signaling.conf

Effacez le contenu d’origine et remplacez-le par cette configuration de production claire et optimisée :

[http]
listen = 127.0.0.1:8090

[app]
debug = false

[sessions]
hashkey = CLE_ALEATOIRE_1
blockkey = CLE_ALEATOIRE_2

[clients]
internalsecret = CLE_ALEATOIRE_3

[backend]
backends = backend1
allowall = false
timeout = 10
connectionsperhost = 8

[backend1]
url = https://cloud.votredomaine.com
secret = SECRET_PARTAGE_NEXTCLOUD

[nats]
url = nats://localhost:4222

[mcu]
type = janus
url = ws://127.0.0.1:8188

[turn]
apikey = CLE_API_JANUS
secret = SECRET_COTURN
servers = turn:turn.votredomaine.com:3478?transport=udp,turn:turn.votredomaine.com:3478?transport=tcp
🔑 Le guide de survie des mots de passe (À lire absolument) :
Pour générer une clé aléatoire sécurisée, utilisez toujours la commande suivante dans votre terminal : openssl rand -hex 16
Paramètre dans le fichier À quoi ça sert ? Où doit-on le remettre ?
hashkey
blockkey		 Clés internes pour signer et chiffrer les sessions/cookies du serveur. À insérer uniquement dans ce fichier (/etc/nextcloud-signaling.conf) sous la section [sessions]. Ne les partagez nulle part ailleurs.
[clients]
internalsecret		 Authentification pour les services internes additionnels. À insérer dans ce fichier sous [clients]. À réutiliser uniquement si vous installez plus tard le module optionnel Talk Recording Server.
[backend1] secret Poignée de main avec Nextcloud. Dans l’interface GUI Nextcloud (Admin > Talk > Haute Performance > Secret partagé).
[turn] apikey Poignée de main avec Janus. Doit être 100 % identique au turn_rest_api_key de votre fichier /etc/janus/janus.jcfg.
[turn] secret Poignée de main avec Coturn. Doit être 100 % identique au static-auth-secret de votre fichier /etc/turnserver.conf (Étape 1).

Création du service Systemd

Créons un utilisateur dédié et le fichier de service :

sudo groupadd nextcloud-signaling
sudo useradd --system --gid nextcloud-signaling --shell /bin/false --comment "Nextcloud Signaling" nextcloud-signaling
sudo nano /etc/systemd/system/nextcloud-signaling.service

Collez ce contenu propre :

[Unit]
Description=Nextcloud Talk signaling server
Requires=janus.service 
After=janus.service

[Service]
ExecStart=/etc/nextcloud-spreed-signaling/bin/signaling --config /etc/nextcloud-signaling.conf
User=nextcloud-signaling
Group=nextcloud-signaling
Restart=on-failure

# Hardening
CapabilityBoundingSet=
ExecPaths=/etc/nextcloud-spreed-signaling/bin/signaling /usr/lib /usr/lib64
LockPersonality=yes
MemoryDenyWriteExecute=yes
NoExecPaths=/
NoNewPrivileges=yes
PrivateDevices=yes
PrivateTmp=yes
PrivateUsers=yes
ProcSubset=pid
ProtectClock=yes
ProtectControlGroups=yes
ProtectHome=yes
ProtectHostname=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectProc=invisible
ProtectSystem=strict
RemoveIPC=yes
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
SystemCallArchitectures=native
SystemCallFilter=@system-service
SystemCallFilter=~ @privileged

[Install]
WantedBy=multi-user.target

Démarrez le service :

sudo systemctl daemon-reload
sudo systemctl enable --now nextcloud-signaling

5. Configuration Apache (Proxy Inverse)

Le serveur de signalisation tourne localement sur le port 8090. Nous allons utiliser Apache comme « proxy inverse » pour capter le trafic d’Internet (sur le port 80/443) et le rediriger vers ce service local en toute sécurité.

1. Création du Virtual Host (Port 80)

sudo nano /etc/apache2/sites-available/signaling.conf

Collez cette configuration en remplaçant signaling.votredomaine.com par votre vrai domaine. Les règles de proxy et de réécriture (Rewrite) sont cruciales pour séparer le trafic WebSocket du trafic API standard :

<VirtualHost *:80>
    ServerName signaling.votredomaine.com

    ProxyPreserveHost On
    ProxyRequests Off

    # Proxy WebSocket (ws://) pour les connexions vidéo en temps réel
    ProxyPass /standalone-signaling/ ws://127.0.0.1:8090/
    ProxyPassReverse /standalone-signaling/ ws://127.0.0.1:8090/

    # Configuration Rewrite pour gérer les requêtes API (HTTP classique)
    RewriteEngine On
    RewriteRule ^/standalone-signaling/spreed/$ - [L]
    RewriteRule ^/standalone-signaling/api/(.*)$ http://127.0.0.1:8090/api/$1 [P,L]

    # Entête pour identifier l'adresse IP réelle du client
    RequestHeader set X-Real-IP %{REMOTE_ADDR}s

    ErrorLog ${APACHE_LOG_DIR}/signaling_error.log
    CustomLog ${APACHE_LOG_DIR}/signaling_access.log combined
</VirtualHost>

2. Activation et Sécurisation (Let’s Encrypt)

Activez les modules Apache requis pour le proxying et les WebSockets, puis générez votre certificat SSL. Certbot se chargera automatiquement de dupliquer vos règles de proxy dans un Virtual Host sécurisé (Port 443) !

# Activation des modules Apache
sudo a2enmod rewrite proxy proxy_http proxy_wstunnel headers ssl
sudo a2ensite signaling.conf

# Vérification de la syntaxe et redémarrage
sudo apache2ctl configtest
sudo systemctl reload apache2

# Génération du certificat HTTPS
sudo certbot --apache -d signaling.votredomaine.com

(Note : Lors de l’exécution de Certbot, acceptez de rediriger tout le trafic vers HTTPS si la question vous est posée).

6. Sécurité : Pare-feu (UFW ou nftables) et Routeur (NAT)

Votre serveur manipule des flux vidéo en temps réel, les ports UDP et TCP doivent être ouverts avec une précision chirurgicale pour correspondre à vos fichiers de configuration. Choisissez l’une des deux méthodes ci-dessous selon vos préférences d’administration.

Option A : Configuration via UFW (Méthode simple)

# 1. Installer et réinitialiser
sudo apt install ufw -y
sudo ufw default deny incoming
sudo ufw default allow outgoing

# 2. Ports d'administration et Web
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# 3. Ports Coturn (Contrôle et Relais)
sudo ufw allow 3478/tcp
sudo ufw allow 3478/udp
sudo ufw allow 49152:65535/tcp  # Doit correspondre au min/max-port de turnserver.conf
sudo ufw allow 49152:65535/udp

# 4. Ports Janus (Média Direct)
sudo ufw allow 20000:20100/tcp  # Doit correspondre à janus.jcfg
sudo ufw allow 20000:20100/udp

# Activer le pare-feu
sudo ufw enable
sudo ufw status verbose

Option B : Configuration via nftables (Pour les utilisateurs avancés)

Si vous préférez utiliser le framework moderne nftables, éditez le fichier de configuration principal :

sudo nano /etc/nftables.conf

Effacez le contenu existant et remplacez-le par ces règles optimisées :

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;

        # Accepter le trafic établi et local
        ct state established,related accept
        iif "lo" accept

        # 1. Ports d'administration et Web
        tcp dport { 22, 80, 443 } accept

        # 2. Ports Coturn (Contrôle et Relais)
        tcp dport { 3478, 49152-65535 } accept
        udp dport { 3478, 49152-65535 } accept

        # 3. Ports Janus (Média Direct)
        tcp dport 20000-20100 accept
        udp dport 20000-20100 accept
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Appliquez les règles et activez le service au démarrage :

sudo systemctl enable --now nftables
sudo systemctl restart nftables
sudo nft list ruleset

Configuration du Routeur (Port Forwarding)

Si votre serveur est derrière un routeur local, n’oubliez pas de rediriger ces ports vers l’IP locale de votre serveur (ex: 192.168.2.7) :

  • HTTP/HTTPS : 80, 443 (TCP)
  • Coturn Contrôle : 3478 (TCP/UDP)
  • Coturn Relais : 49152 à 65535 (TCP/UDP)
  • Janus Média : 20000 à 20100 (TCP/UDP)

7. Configuration finale dans Nextcloud

Via l’interface graphique (GUI)

  1. Connectez-vous à votre Nextcloud avec un compte administrateur.
  2. Allez dans Paramètres d’administration → Talk.
  3. Serveurs STUN : Ajoutez turn.votredomaine.com:3478 (Remplacez par votre domaine).
  4. Serveurs TURN :
    • Ajoutez turn.votredomaine.com:3478.
    • Secret partagé : Collez ici votre VOTRE_SECRET_COTURN_STATIQUE défini à l’Étape 1.
    • Protocoles : Sélectionnez udp, tcp.
  5. Descendez jusqu’à la section Haute performance (Signaling).
  6. URL du serveur de signalisation : Saisissez https://signaling.votredomaine.com/standalone-signaling/
  7. Secret partagé : Collez ici votre SECRET_PARTAGE_NEXTCLOUD (celui que vous avez défini sous la section [backend1] à l’Étape 4).
  8. Cochez la case Valider le certificat.

Via le fichier config.php

Éditez le fichier de configuration de votre instance Nextcloud (/var/www/nextcloud/config/config.php) pour autoriser le serveur de signalisation.

  'trusted_domains' =>
  array (
    0 => 'cloud.votredomaine.com',
    1 => 'signaling.votredomaine.com',
  ),
  'allow_local_remote_servers' => true,
  'push_url' => 'https://signaling.votredomaine.com/standalone-signaling',

Et voilà ! Si votre configuration est correcte, l’interface de Nextcloud devrait vous indiquer que le serveur de signalisation est fonctionnel. Vous pouvez maintenant lancer des appels vidéo avec des dizaines de participants de manière fluide et sans surcharger votre serveur principal.