Auto-héberger un récepteur SRTLA

LOLS IRL parle le srtla standard compatible BELABOX, donc votre propre récepteur se comporte exactement comme nos relais hébergés. Voici quoi faire tourner, quels ports comptent, et l'unique erreur qui empêche une liaison mobile d'atteindre votre machine.

Vous n'avez rien à héberger : les relais LOLS Cloud gratuits existent pour que le bonding marche sans bricoler, ou vous pouvez auto-héberger votre propre récepteur et ne dépendre de personne. On choisit d'héberger pour de bonnes raisons. Vous voulez que le stream atterrisse sur une infrastructure que vous contrôlez, vous voulez une machine physiquement proche de vous là où nous n'avons pas de relais, vous ne voulez aucun quota en tête, ou vous préférez simplement faire tourner vos propres choses. Rien dans l'appli n'est lié à nos serveurs, donc changer revient à changer un nom d'hôte et rien d'autre.

Ce que vous construisez

téléphone (wifi + mobile)
   |
   |  srtla, UDP, un socket par réseau
   v
srtla_rec          écoute sur un port UDP public, réassemble les liaisons
   |
   |  SRT simple, UDP, en localhost
   v
serveur média      MediaMTX ou équivalent
   |
   +--> OBS, ou une rediffusion vers Twitch / Kick / YouTube

Deux éléments, chacun avec un seul rôle. srtla_rec, du projet BELABOX, est la partie qui comprend le bonding : chaque liaison ouverte par votre téléphone s'y enregistre comme membre d'un même groupe, et il retransforme ce groupe en un seul stream SRT ordinaire. Il envoie ensuite ce stream à un écouteur SRT, et c'est là qu'un serveur média prend le relais. MediaMTX est le choix habituel et peut passer le stream à OBS, le republier ou l'enregistrer, mais tout ce qui accepte SRT fera l'affaire.

Où le faire tourner

Le récepteur doit être joignable depuis chaque réseau sur lequel votre téléphone streame, ce qui en pratique veut dire une adresse publique. Un petit VPS suffit largement : c'est du transfert de paquets, pas du transcodage, donc les mégabits et un processeur modeste comptent bien plus que le nombre de cœurs. Mettez-le géographiquement près de là où vous streamez, pour la même raison que vous choisissez le relais le plus proche : la distance est un délai qu'on ne récupère pas, et il se repaie à chaque retransmission.

L'erreur qui piège presque tout le monde

Un récepteur sur votre LAN à la maison, à une adresse du genre 192.168.1.50, est joignable depuis votre Wi-Fi et de nulle part ailleurs. Votre liaison mobile ne peut pas router vers une adresse privée, donc elle ne s'enregistre jamais et vous n'êtes pas en bonding : vous streamez sur le Wi-Fi avec des étapes en plus, et les stats vous montreront une liaison au lieu de deux.

Soit vous hébergez sur une machine avec une adresse publique, soit vous redirigez le port UDP de votre routeur vers la machine de votre LAN et vous pointez l'appli vers l'adresse publique de votre routeur. Un nom DNS dynamique vous évite de la retaper à chaque changement d'adresse.

Ports

Port	À quoi ça sert
UDP, votre port srtla, entrant depuis Internet	Le seul port que touche le téléphone. 5000 est la convention. Chaque liaison en bonding arrive depuis sa propre adresse et son propre port source, donc il n'y a rien à ouvrir ni à régler par liaison.
UDP, votre écouteur SRT, local	L'endroit où `srtla_rec` envoie le stream réassemblé. MediaMTX écoute le SRT sur 8890 par défaut. Il n'a pas besoin d'être exposé à Internet, sauf si vous voulez aussi que des clients SRT simples y publient.
Ce que sert votre serveur média	RTMP, RTSP, HLS ou WebRTC vers OBS ou vers un spectateur, c'est entièrement votre choix et ça ne fait pas partie du trajet du bonding.

UDP n'est pas TCP

Les pare-feu, les groupes de sécurité cloud et les règles de redirection de routeur sont très souvent en TCP par défaut. Un enregistrement srtla envoyé contre une règle TCP seulement disparaît sans aucune erreur nulle part, ce qui ressemble exactement à un récepteur éteint. Si une liaison ne s'enregistre pas, vérifiez le protocole de la règle avant tout le reste.

Stream ids

srtla_rec fait passer le stream id SRT tel quel, donc ce qui va dans le champ Stream id de l'appli, c'est ce qu'attend le serveur derrière. Avec MediaMTX, c'est la forme publish : un chemin et éventuellement des identifiants quand l'authentification est activée :

publish:mypath
publish:mypath:username:password

Activez l'authentification si le port est ouvert à Internet. Un point de publication sans authentification sur une adresse publique finira par être trouvé par quelqu'un d'autre que vous.

Y pointer l'appli

Dans LOLS IRL : Streams → + → SRTLA.
Host : votre nom d'hôte public. Port : le port UDP sur lequel srtla_rec écoute.
Stream id : la chaîne publish qu'attend votre serveur média.
Latency : 2000 ms pour commencer. Une fois en direct, l'appli affiche l'aller-retour qu'elle mesure et suggère une valeur, qui sur une machine proche sera en général plus basse que celle par défaut.
Enregistrez, activez, passez en direct et dépliez l'overlay de stats. Une ligne par liaison. Deux lignes, c'est que les deux réseaux se sont enregistrés.

Vérifier que ça marche vraiment

Comptez les enregistrements. srtla_rec journalise un enregistrement de connexion par liaison, tous sous un même groupe. Deux liaisons doivent donner deux enregistrements dans le même groupe. Si vous n'en voyez toujours qu'un, le second réseau n'atteint pas l'hôte : adresse privée, règle de pare-feu TCP seulement, ou VPN actif sur le téléphone.
Puis cassez-le exprès. En streamant depuis chez vous, coupez le Wi-Fi une minute. Le récepteur doit journaliser la connexion perdue qui expire pendant que le stream continue de couler, puis journaliser un nouvel enregistrement quand le Wi-Fi revient. C'est toute la fonction, et la tester dans votre cuisine vaut bien mieux que la découvrir en direct.
Si SRT se connecte mais que rien n'arrive au serveur média, c'est presque toujours le stream id. Il est transmis tel quel, donc une faute de frappe dans le chemin ou les identifiants donne une connexion qui ne s'authentifie nulle part.

Bon à savoir d'avance

Le bonding sert à tenir, pas à avoir plus de bande passante, quel que soit celui qui héberge le récepteur. Réglez votre débit sur ce qu'une seule bonne liaison peut porter. Voir la FAQ pour comprendre pourquoi.
La bande passante montante de votre VPS porte votre débit complet en continu pendant le stream, et encore tout ce que vous renvoyez ensuite depuis lui. Regardez le quota de bande passante de l'offre, pas seulement la vitesse du port.
Un relais est une machine partagée et la vôtre ne l'est pas, ce qui est le vrai avantage : le stream de personne d'autre n'est dessus.
Vous pouvez garder un relais gratuit configuré comme deuxième destination pendant que vous mettez votre propre machine en route. Passer de l'un à l'autre se fait d'un toucher dans la liste Streams.

Bloqué sur une étape, ou envie d'un deuxième avis sur un récepteur qui n'accepte pas la seconde liaison ? Demandez sur Discord ou écrivez à support@lols.gg. Apportez la région où vous êtes, ce que montre l'overlay de stats et ce que le récepteur a journalisé, et c'est en général une conversation de deux messages.

À lire aussi : le bonding en cinq minutes pour le côté appli et la lecture des indicateurs, utiliser les relais gratuits si vous préférez ne pas héberger, et tous les guides.