WebRTC 2/2 : les applications

Applications WebRTC

Après avoir découvert WebRTC via sa spécification, dans l'épisode précédent, ce second épisode explore les différentes utilisations, réelles, de cette technologie.

Les thématiques

Déboguer

test.webrtc.org

Avant de vous énerver sur une application, autant commencer par le commencement : le banc de test de webrtc.org.

Attention à allumer la lumière, sinon le robot pensera que les images trop sombres sont un problème de webcam.

En cliquant sur le kebab (les trois traits dans la barre du haut), vous avez accès aux réglages :

• Choix de la caméra
• Choix du micro
• Paramètre du serveur STUN et TURN

Pion-stun

Pion fournit un outil en ligne de commande pour utiliser un serveur STUN. Par contre, il faut le compiler à la mimine (et avoir le SDK golang installé sur sa machine), mais il n'y a rien de compliqué :

git clone https://github.com/pion/stun.git
cd stun
go build -o stun-client cmd/stun-client/stun_client.go

Ensuite, on est dans le classique, un -h nous dit comment l'utiliser

$ ./stun-client -h
Usage of ./stun-client:
./stun-client stun.l.google.com:19302

Pion-turn

Pion fournit un autre outil pour pinguer un serveur TURN en UDP et en TCP, la encore, il faut compiler.

git clone https://github.com/pion/turn.git
cd turn
go build -o turn-udp examples/turn-client/udp/main.go
go build -o turn-tcp examples/turn-client/tcp/main.go

Encore le -h pour connaitre les arguments.

$ ./turn-udp -h
Usage of ./turn-udp:
  -host string
        TURN Server name.
  -ping
        Run ping test
  -port int
        Listening port. (default 3478)
  -realm string
        Realm (defaults to "pion.ly") (default "pion.ly")
  -user string
        A pair of username and password (e.g. "user=pass")

Coder

Atom, l'éditeur de Github, basé sur Electron, et donc Chrome, avait bien bossé sur la question du travail collaboratif, en pair à pair avec le projet Teletype. Le serveur semble avoir été libéré à l'arrache (il s'appuie sur des SAAS farfelus pour de l'auto-hébergement), mais il y a un beau travail sur le CRDT avec teletype-crdt. CRDT tant craint et tant aimé des développeurs.

Ça, c'était avant, avant le rachat de Github par Microsoft, avec son VSCode. Atom et Teletype sont "en l'état" depuis 3 ans, et VSCode propose une solution propriétaire et méchamment efficace pour le partage, avec même une version web.

L'ère de l'Atom est clairement révolue.

Jouer

WebRTC permet de streamer des jeux, il existe des exemples pour des vieux jeux Mame ou pour la Switch, mais bon, au-delà de l'exploit, je ne vois pas l'intérêt. Par contre je vois la bande passante que ça va bouffer. Autant le faire en local, non?

Dessiner

L'excellent Excalidraw permet de partager une session de gribouillage en webrtc. Excalidraw est un excellent produit que nous utilisons régulièrement, et la possibilité de corriger les derniers détails à plusieurs est fort pratique.

[edit] Bon, en vrai, comme le souligne son dev Vjeux, Excalidraw utilise une websocket avec Firestore pour synchroniser l'état de la session entre les participants, et pas WebRTC. Désolé pour la confusion.

Discuter

Partager un flot d'images va mal scaler, mais juste du son reste raisonnable, en point à point. On parlera un peu plus bas dans l'article de services centralisés qui tiendront mieux la charge.

C'est ce que propose Jam, avec un peu de coordination et beaucoup de P2P.

Les bibliothèques

PeerJS

PeerJS propose juste un framework javascript avec un serveur websocket pour négocier des connexions point à point. Pas de SFU, encore moins de MCU, juste du bon gros P2P.

Niveau sécu, ça ne doit pas être au point par ce que le site de démo s'est fait défoncer, ça redirige de sites en site en faisant hurler adblock, pour faire du faux clic sur des pubs, pour arriver sur une page pétée. C'était bien la peine de passer dans Y combinator.

Yjs

Yjs propose un écosystème ambitieux pour construire des applications collaboratives en s'appuyant sur CRDT. Ils fournissent différents modules pour se coordonner dont l'inévitable module pour du point à point.

Comme ils sont gentils, ils ont aussi intégré un certain nombre d'éditeurs :

• Y-Prosemirror
• Y-Codemirror
• Y-Quill
• Y-Monaco

À vous de construire des applications à partir de ça.

Les serveurs

Janus

Janus est un des premiers serveurs webrtc. Janus est écrit en C dans une approche minimaliste. Il se positionne comme SFU, mais il se permet de recompresser l'audio pour la passerelle SIP (vers la téléphonie).

Pour la partie interactive, il faut écrire un module en C, en lua, ou en javascript avec duktape. Le plus sage est de se contenter de ce qui existe déjà.

Le core et les modules sont interrogeables via l'API websocket, depuis le navigateur web, ou un service sidecar (un petit service qui ne sera utilisé que par le service principal).

L'API JS est une tannée à utiliser, avec des conventions Javascript d'avant la modernité. C'est juste pénible, parce que la compatibilité avec les navigateurs hors d'âge n'est pas une option avec la vitesse de développement de webrtc. Vous faites du webrtc avec des navigateurs dans la version stable courante, et puis c'est tout. Donc, vous utilisez du ecmascript moderne avec await et ses amis.

Dans les exemples, il y a une passerelle avec de la VOIP, et pour peu que vous ayez un compte sur une offre VOIP, vous pourrez inviter des amis sur téléphone.

Kurento

Kurento a débuté à l'université Rey Juan Carlos pour finalement être racheté par Twillio. C'est du joli C++, qui utilise Gstreamer pour faire du multimédia. Ils sont tout fiers de leur intégration d'OpenCV qui permet de repérer des visages, des foules, des plaques d'immatriculation ou de suivre un objet. Ces fonctionnalités étranges font partie du projet Fiware pour les smart cities, et reste fasciné par les caméras IP, plus que les webcams.

Kurento peut être utilisé comme SFU, MCU ou comme un service multimédia via 2 flux RTP. Kurento multimédia est par exemple utilisé par MediaSoup et BBB.

Le développement de Kurento se fait sur une Ubuntu, et ça va être compliqué de le compiler sur d'autres distributions. Par contre, il est facile de préparer son image docker, ou de la prendre sur l'étagère.

Openvidiu

OpenVidiu est une application simple de visioconférence écrite en Java. La doc de kurento recommande à chaque page d'aller essayer OpenVidiu pour débuter. Le service est correct, propose les fonctionnalités attendues, mais sans rien qui fasse rêver.

Big Blue Button

BigBlueButton est un machin développé en Java il y a longtemps, en intégrant plein d'outils périmés (comme un etherpad et un whiteboard).

Son architecture est grandiloquente, avec par exemple le choix de Freeswitch pour avoir une passerelle SIP, ou Libreoffice pour convertir les présentations, et un Mongodb pourquoi pas. La doc se permet de dauber la virtualisation qui brimerait le réseau et donc Freeswitch, alors que ça fait des années que les virtio de kvm ont tordu le cou à ce mythe. Le bazar est tellement intriqué dans ses versions de logiciel qu'il faut dédier une VM, avec l'image fournit par BBB. La ribambelle de services émet des flots de logs énormes, et bon courage pour poser des sondes pour surveiller les consommations de ressources matérielles.

BBB a réussi à conclure sur un malentendu, comme un Michel Blanc, profitant du confinement et de la mollesse de l'offre libre de visioconférences : allez voir ailleurs.

Mediasoup

Mediasoup a une approche légère et rafraichissante par rapport à ses concurrents. Il se contente de faire du SFU en implémentant les dernières évolutions de la norme webRTC. Au niveau architecture, c'est aussi minimaliste : pas de services dans un coin avec du code qui consomme une API via une websocket, mais tout simplement une lib C++ pour nodejs.

Ce minimalisme n'empêche pas de brancher Gstreamer ou ffmpeg pour intégrer des clients non-web à une salle de visioconférence.

Edumeet

Edumeet est une application de cours à distance basée sur Mediasoup, développée par UNINETT l'équivalent norvégien de notre RENATER.

Clairement, le logiciel a connu le champ de bataille, la configuration est touffue et propose de se brancher sur un tracker webtorrent, de proposer un TURN proche via geoip, et de proposer par défaut le truandage classique : TURN en tcp sur le port 443.

Jitsi

Jitsi est le héraut de la visioconf libre, bien mise en valeur par Scaleway pendant le premier confinement, confirmé par le dernier CCC et le FOSDEM.

Le client lourd pour ordinateur est sans intérêt, c'est juste un chrome emballé dans electron.

Par contre, un effort a été fait pour les applications smartphones : une application en react native, et un SDK pour Android et iOS (en swift).

Leur architecture serveur est raisonnable : un SFU et des services en java avec un Prosody.

Jitsi fait de gros efforts d'intégration, avec une offre avec une iframe (ce qui est bien ringard en 2021), alors qu'il est possible de faire des intégrations plus fines comme avec le plugin pour Mattermost.

Deux points grattent un peu :

• La discussion se fait en XMPP, étonnement la doc parle de BOSH, du vieux polling HTTP, alors que le serveur de démo utilise websocket, qui est de base dans Prosody. Pour dire bonjour et envoyer des URL c'est bien la peine de dégainer une technologie qui a plus de specs que de code. Les appels d'API sont faits via XMPP, sinon ce n'est pas rigolo. OK, il existe aussi une API REST nommée Colibri
• Jibri, pour enregistrer une session, lance un Chrome qui se connecte à la room et enregistre l'écran. Niveau efficience, on est du niveau de la chasse au moustique au marteau. Gstreamer a un input webrtc par exemple.

Pion

Pion est un projet golang regroupant toutes les bibliothèques nécessaires à WebRTC, sous Linux, Mac ou Windows.

Ça attaque bas niveau avec DTLS (UDP chiffré avec TLS) et SCTP (un meilleur TCP basé sur UDP).

Ensuite on peut attaquer la partie flot multimédia avec RTP (Real-time Transport Protocol) et sa variante sécurisée SRTP (Secure Real-time Transport Protocol), accompagné de RTCP pour la gestion de congestion (RTP Control Protocol). Le tout est ordonné par interceptor qui pour l'instant n'implémente que NACK) (pour Negative ACKnowledgment). ice (comme Interactive Connectivity Establishment) pour négocier une connexion point à point avec potentiellement l'aide de stun (comme Session Traversal Utilities for NAT) ou turn (comme TURN) qui propose un client et un serveur TURN, pour les clients doubles NATés. sdp (comme Session Description Protocol permet de négocier la session.

Un courageux peut implémenter un serveur de VOIP avec ion-sip qui permet de démarrer la discussion en SIP (comme Session Initiation Protocol) et tout le reste.

Pour le multimédia, on a mediadevices, qui va gérer les entrées (micro, caméra, recopie d'écran) et une partie des codecs : H.264, VP8, VP9, Opus (en utilisant des bibliothèques existantes pas en Go, avec pour certaines l'utilisation d'accélération matérielle).

On atteint enfin une implémentation pour webrtc et ion-sfu pour faire des conférences (avec une API grpc et json-rpc).

Voilà, une belle tempête d'acronymes pour faire à peu près tout et n'importe quoi autour de webrtc (avec la liste fournit par awsome pion).

Neko

Neko, au-delà d'une icône inoubliable, est un bureau Linux as a service, dans un conteneur.

Les specs sont simples : Neko permet de s'entasser virtuellement devant un ordi et de partager clavier/souris et le presse-papier, pour regarder un dessin animé en balançant des ❤️ sur la télé.

Techniquement ça rigole plus, on n'est plus dans le LOL des specs. C'est un vrai Linux avec XFCE4 et Openbox (un gestionnaire de fenêtre pour radin) avec XDummy comme server X11 sans clavier ni souris (ça n'existe pas sur le Cloud). Comme on parle d'un desktop Linux, on a aussi un Pulseaudio (qui attends des commandes via une socket UNIX) et du Dbus. Gstreamer utilise X11 et Pulseaudio comme input, et webrtc comme output. Pion sert de glue à tout ça : Gstreamer se connecte au SFU en webrtc qui broadcast à tout le monde. On notera l'implémentation d'un serveur golang implémentant un clavier/souris Xorg, commandé par une websocket.

Les applis essentielles sont Popcorn time, Chromium, Firefox et TOR-browser.

Prévoir un serveur avec 4 ou 6Go de RAM, et du CPU, pour avoir un service fluide.

Pour la convivialité, on a un tchat, la possibilité d'ignorer puis bannir ses amis et d'envoyer des pluies d'emojis.

Le tout est d'assumer.

Screego

Screego est un service tout simple pour partager un écran de manière sécurisée, et mieux que les gros machins propriétaires.

Les navigateurs web savent partager une fenêtre précise, et pas forcément l'écran complet (beaucoup trop gros pour passer par le tuyau d'Internet), chose que font rarement les applications dédiées à la visioconférence.

Techniquement, Screego établit une connexion point à point, et embarque son propre serveur STUN/TURN. Si le STUN suffit à établir la connexion, Screego ne verra pas passer le flot vidéo, gage de confidentialité.

Envoyer un flot vidéo peut permettre de décoincer une situation, mais ça mange beaucoup de bande passante, et il existe des outils spécifiques comme tmate.io, un rien vieillissant, ou upterm, plus en forme.

Vous devez vous souvenir de l'article sur ttyd, qui permet lui aussi de partager un écran, mais sans outils pour établir une connexion pair-à-pair.

ASCII

ASCII est un outil en ligne de commande, pour causer avec une personne, en partageant les webcams en ASCII art. On est clairement dans le rétro futur avec une ambiance Minitel.

C'est un hackaton d'une société qui propose de mettre en relation téléphonique des gens selon leurs affinités.

Je ne connais pas la pertinence de ce service, mais proposer du webrtc en ligne de commande sans navigateur web est une fin en soi.

Kraken

kraken est un SFU qui ne gère que l'audio. kraken.fm est une application web permettant de gérer sans aucune authentification des discussions audios.

Il y a une instance publique sur kraken.fm), qui est un bon exemple de ce que l'on peut faire de simple avec webrtc (qu'on a du mal à qualifier de simple).

Galène

Galene est un serveur de visioconférence basé sur la stack Ion. Pour l'instant en développement, il propose une application compacte et économe, simple à déployer.

Sous le capot, il propose des évolutions aux différentes bibliothèques Pion qu'il utilise, comme son propre SFU.

La suite

Le web est simple : on a d'abord lu des trucs, puis fait des trucs. Maintenant, on peut faire des trucs à plusieurs !

Quelle sera la prochaine application collaborative que vous utiliserez dans votre butineur? Quelle sera la prochaine application collaborative que vous coderez?