Faire sonner un téléphone dans un navigateur, sans installer le moindre logiciel, c’est la promesse de WebRTC. Pour qu’un client web puisse s’enregistrer sur Asterisk et passer des appels, le serveur doit parler le langage exact qu’attendent les navigateurs : une signalisation sur WebSocket sécurisé, un média chiffré en DTLS-SRTP, et la traversée de réseau par ICE. Ce tutoriel configure Asterisk de zéro pour servir des clients WebRTC, en expliquant chaque réglage plutôt qu’en le copiant aveuglément. À la fin, votre serveur sera prêt à accueillir les softphones navigateur que les tutoriels suivants construiront.
Prérequis
- Un serveur Asterisk récent (version 18 ou, idéalement, la branche 22 LTS) déjà installé et fonctionnel.
- Un certificat TLS valide pour le nom de domaine du serveur (indispensable : les navigateurs refusent le micro sans HTTPS reconnu).
- Un accès SSH avec droits root pour éditer les fichiers de configuration.
- Des notions de la pile PJSIP d’Asterisk (extensions, transports).
- Niveau : avancé. Temps estimé : 45 minutes.
Les trois exigences propres à WebRTC
Avant d’éditer le moindre fichier, il faut comprendre pourquoi la configuration WebRTC diffère d’une configuration SIP classique. Trois contraintes sont imposées par les navigateurs et ne sont pas négociables. La première est le transport par WebSocket sécurisé (WSS) : un navigateur ne peut pas ouvrir un socket SIP brut sur le port 5060, il passe obligatoirement par un WebSocket. La deuxième est le chiffrement du média en DTLS-SRTP : la voix doit être chiffrée, sans exception. La troisième est la traversée de réseau par ICE, assistée de serveurs STUN et TURN, pour franchir les pare-feu et le NAT. Asterisk sait gérer ces trois exigences ; tout l’enjeu est de les activer correctement.
DTLS-SRTP : pourquoi ce chiffrement précis
En SIP classique, on peut sécuriser le média avec SRTP en échangeant les clés de chiffrement dans la signalisation (une méthode appelée SDES). WebRTC refuse cette approche : il impose DTLS-SRTP, où les deux extrémités négocient les clés directement dans le canal média, par une poignée de main chiffrée, indépendamment de la signalisation. L’avantage est de taille : même si quelqu’un interceptait la signalisation, il n’obtiendrait pas les clés du média. C’est ce qui rend WebRTC chiffré par conception, sans configuration optionnelle possible. Sur Asterisk, c’est exactement ce que l’option media_encryption=dtls active, et c’est l’une des raisons pour lesquelles un endpoint WebRTC ne peut pas se contenter d’une configuration SIP ordinaire.
Cette poignée de main DTLS s’appuie sur des certificats. C’est pourquoi la configuration prévoit soit la génération automatique d’un certificat dédié, soit l’usage de certificats existants. La vérification par empreinte (dtls_verify=fingerprint) garantit que les deux parties sont bien celles attendues : l’empreinte du certificat est annoncée dans la signalisation SDP, puis vérifiée lors de la poignée de main média. Comprendre ce mécanisme aide à diagnostiquer les échecs : un appel qui se connecte puis se coupe immédiatement, sans audio, trahit souvent un problème de négociation DTLS — certificat absent, horloge système déréglée, ou empreinte qui ne correspond pas.
ICE, STUN et TURN : franchir les réseaux
La deuxième particularité de WebRTC est sa manière de trouver un chemin pour le média entre deux participants qui ne sont presque jamais sur le même réseau. Un navigateur derrière une box ignore sa propre adresse publique et ne peut pas, par défaut, recevoir de connexion entrante. Le mécanisme ICE (Interactive Connectivity Establishment) résout ce casse-tête en testant méthodiquement tous les chemins possibles entre les deux extrémités.
ICE s’appuie sur deux types de serveurs auxiliaires. Un serveur STUN répond à une question simple : « quelle est mon adresse publique vue de l’extérieur ? » Cette information suffit souvent à établir une connexion directe entre les deux participants. Mais quand les réseaux sont trop restrictifs — pare-feu d’entreprise strict, NAT symétrique — aucune connexion directe n’est possible. C’est là qu’intervient un serveur TURN, qui relaie l’intégralité du média entre les deux parties, au prix d’un peu de latence et de bande passante. L’option ice_support=yes activée par webrtc=yes indique à Asterisk de participer à ce processus de découverte de chemin. Retenez ce principe : STUN aide à se trouver, TURN sert de relais en dernier recours. C’est exactement pour cette raison que le tutoriel dédié à coturn est incontournable avant toute mise en production sérieuse.
Étape 1 — Vérifier les modules nécessaires
Asterisk est modulaire : les fonctions WebRTC reposent sur des modules qui doivent être présents et chargés. Avant de configurer quoi que ce soit, vérifions qu’ils sont disponibles. Ouvrez la console Asterisk et interrogez l’état des modules clés.
asterisk -rx "module show like websocket"
asterisk -rx "module show like res_srtp"
Ces commandes listent les modules dont le nom contient « websocket » et le module de chiffrement SRTP. Vous devez voir res_http_websocket, res_pjsip_transport_websocket et res_srtp à l’état chargé (« Running »). Le module res_crypto est également requis pour la gestion des certificats. Si l’un manque, c’est qu’il n’a pas été compilé ou activé : il faut alors l’installer ou le charger avant de poursuivre, car sans eux aucun appel WebRTC ne fonctionnera.
Étape 2 — Activer le serveur web pour le WebSocket sécurisé
Le WebSocket sécurisé s’appuie sur le serveur HTTP intégré à Asterisk. Il faut l’activer et lui fournir le certificat TLS qui chiffrera la connexion. Éditez le fichier /etc/asterisk/http.conf avec la configuration suivante.
[general]
enabled=yes
bindaddr=0.0.0.0
bindport=8088
tlsenable=yes
tlsbindaddr=0.0.0.0:8089
tlscertfile=/etc/asterisk/keys/asterisk.crt
tlsprivatekey=/etc/asterisk/keys/asterisk.key
La ligne enabled=yes active le serveur web ; bindport=8088 est le port WebSocket non chiffré (à éviter en production) et tlsbindaddr=0.0.0.0:8089 définit le port du WebSocket sécurisé, celui qu’utiliseront vos clients. Les deux dernières lignes pointent vers votre certificat et sa clé privée. Adaptez ces chemins à l’emplacement réel de vos fichiers. Après sauvegarde, le serveur web d’Asterisk écoutera en WSS sur le port 8089 — c’est par là que transitera toute la signalisation des navigateurs.
Étape 3 — Déclarer le transport WSS dans PJSIP
Asterisk sait maintenant servir un WebSocket sécurisé, mais la pile PJSIP doit être informée qu’elle peut l’utiliser comme transport SIP. On ajoute donc un transport de type WSS dans /etc/asterisk/pjsip.conf.
[transport-wss]
type=transport
protocol=wss
bind=0.0.0.0
Ce bloc déclare un transport nommé transport-wss qui accepte le protocole wss sur toutes les interfaces. Il n’y a pas de port à préciser ici : le transport WSS s’appuie sur le serveur HTTP configuré à l’étape précédente, donc sur le port 8089. Ce transport sera référencé par les endpoints WebRTC que nous créons juste après. C’est le pont entre le serveur web et la logique d’appel d’Asterisk.
Étape 4 — Créer un endpoint WebRTC
Voici le cœur de la configuration. Un endpoint WebRTC se compose, comme tout endpoint PJSIP, de trois objets liés : un AOR (où joindre le client), une authentification (identifiants), et l’endpoint lui-même (les paramètres d’appel). La nouveauté tient à une seule option magique, webrtc=yes, qui active d’un coup tous les réglages exigés par les navigateurs.
[webrtc_client]
type=aor
max_contacts=5
remove_existing=yes
[webrtc_client]
type=auth
auth_type=userpass
username=webrtc_client
password=un_mot_de_passe_robuste
[webrtc_client]
type=endpoint
aors=webrtc_client
auth=webrtc_client
dtls_auto_generate_cert=yes
webrtc=yes
context=default
disallow=all
allow=opus,ulaw
Décortiquons. L’AOR autorise jusqu’à cinq contacts simultanés pour ce client. L’authentification définit un identifiant et un mot de passe — choisissez ce dernier long et aléatoire, jamais identique au nom d’utilisateur. L’endpoint relie le tout, génère automatiquement un certificat DTLS grâce à dtls_auto_generate_cert=yes, et n’autorise que les codecs Opus et u-law (Opus étant le codec natif de WebRTC). Mais l’essentiel est webrtc=yes.
Cette unique option est un raccourci qui active automatiquement, en coulisses, l’ensemble des réglages que WebRTC impose : le profil média sécurisé use_avpf=yes, le chiffrement media_encryption=dtls, la vérification dtls_verify=fingerprint, le mode dtls_setup=actpass, la traversée réseau ice_support=yes, ainsi que media_use_received_transport=yes et rtcp_mux=yes. Sans ce raccourci, il faudrait écrire ces sept lignes une à une et le moindre oubli casserait les appels. C’est pourquoi webrtc=yes est la pierre angulaire d’une configuration WebRTC propre sur Asterisk moderne.
Étape 5 — Recharger et vérifier la configuration
Les fichiers sont édités, mais Asterisk ne les a pas encore relus. Rechargez les modules concernés depuis la console, puis vérifiez que le transport et l’endpoint sont bien pris en compte.
asterisk -rx "module reload res_pjsip.so"
asterisk -rx "pjsip show transports"
asterisk -rx "pjsip show endpoint webrtc_client"
La première commande recharge la configuration PJSIP. La deuxième doit faire apparaître le transport transport-wss avec le protocole WSS. La troisième affiche le détail de l’endpoint que vous venez de créer, où vous pouvez confirmer que les options dérivées de webrtc=yes sont bien activées (chiffrement DTLS, support ICE, AVPF). Si une erreur de syntaxe s’était glissée dans les fichiers, le rechargement l’aurait signalée dans les messages de la console : lisez-les attentivement.
Étape 6 — Confirmer la connexion WebSocket
Reste à s’assurer que le serveur web accepte bien les connexions WebSocket sécurisées. Le statut du serveur HTTP d’Asterisk le confirme.
asterisk -rx "http show status"
La sortie indique les adresses et ports d’écoute. Vous devez y voir le serveur actif et le port TLS 8089 en écoute, ce qui prouve que le WebSocket sécurisé est opérationnel. À ce stade, le serveur est prêt : un client WebRTC qui pointe vers wss://votre-domaine:8089/ws avec les identifiants de l’endpoint pourra s’enregistrer. La construction de ce client est l’objet des tutoriels dédiés à JsSIP et SIP.js.
Ne pas oublier le serveur TURN
Votre serveur accepte désormais les clients WebRTC, mais un piège attend en production : les appels entre utilisateurs situés derrière des réseaux différents peuvent échouer faute de chemin média direct. C’est le rôle d’un serveur TURN, qui relaie le média quand la connexion directe est impossible. Sans lui, les appels fonctionnent en réseau local de test mais échouent dès que les box et pare-feu s’en mêlent. Le déploiement de ce maillon est traité dans le tutoriel déployer un serveur TURN coturn pour WebRTC, à mettre en place avant toute exposition réelle.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| Le client ne s’enregistre pas | Module WebSocket manquant ou WSS non actif | Vérifier les modules et http show status (port 8089) |
| Navigateur refuse le microphone | Certificat TLS invalide ou auto-signé | Installer un certificat reconnu pour le domaine |
| Appel établi sans audio | Média bloqué, pas de serveur TURN | Déployer coturn et vérifier la traversée NAT |
| « webrtc » ignoré | Version d’Asterisk trop ancienne | Utiliser Asterisk 18 ou 22 ; l’option date d’Asterisk 16 |
| Erreur de rechargement PJSIP | Faute de syntaxe dans pjsip.conf | Lire le message d’erreur de la console et corriger |
Tutoriels associés
- Construire le client : softphone navigateur avec JsSIP et Asterisk.
- Approche typée : client SIP WebRTC avec SIP.js.
- Indispensable en production : déployer un serveur TURN coturn.
Pour aller plus loin
- Retour au guide : Téléphonie IP avancée : 3CX, Issabel et softphones WebRTC.
- Documentation officielle : configurer Asterisk pour les clients WebRTC.
Questions fréquentes
Pourquoi un certificat TLS est-il obligatoire ?
Les navigateurs n’autorisent l’accès au microphone que sur une page servie en HTTPS valide, et le WebSocket sécurisé exige lui-même un certificat. Un certificat auto-signé provoque un refus côté navigateur ; il faut un certificat reconnu par une autorité.
Que fait exactement l’option webrtc=yes ?
Elle active en une fois tous les réglages qu’imposent les navigateurs : profil AVPF, chiffrement DTLS du média, vérification par empreinte, support ICE, multiplexage RTCP et usage du transport reçu. C’est un raccourci qui évite sept lignes de configuration et autant de risques d’erreur.
Faut-il absolument un serveur TURN ?
Pour des tests en réseau local, non. Mais dès que des utilisateurs se trouvent derrière des réseaux différents, oui : sans TURN, le média ne trouve pas toujours de chemin direct et les appels échouent silencieusement.
WebRTC fonctionne-t-il avec FreePBX ou Issabel ?
Oui, puisqu’ils reposent sur Asterisk. Leur interface graphique propose souvent une case « activer WebRTC » sur l’extension, qui applique les mêmes réglages que ceux décrits ici à la main.
Quel port mon client doit-il viser ?
Le WebSocket sécurisé écoute sur le port 8089 par chemin /ws, soit une URL de la forme wss://votre-domaine:8089/ws. Ce port doit être ouvert dans le pare-feu et le certificat doit correspondre au nom de domaine utilisé, faute de quoi la connexion sécurisée échoue avant même l’enregistrement.