WebRTC et les NAT

WebRTC ("Web Real-Time Communication") réunit plusieurs avancées significatives en vue de permettre des communications audio et vidéo, de poste à poste, en utilisant des versions récentes de certains navigateurs web :
- une API ("Application Programming Interface") Javascript est en cours de développement,
- divers navigateurs web implémentent cette interface, et des systèmes WebRTC commencent à être utilisés.
Tous les ordinateurs, tablettes, smartphones, sont équipés d’un navigateur web. WebRTC permettra donc de telles communications sans avoir besoin, comme c’est le cas actuellement, d’installer un logiciel supplémentaire dédié à cet effet.

Dans les projets WebRTC, les programmeurs accordent évidemment une attention particulière à cette API Javascript, d’autant que toutes les versions utilisables des navigateurs web n’utilisent pas encore exactement la même syntaxe pour certaines fonctions de cette API…

Cela étant, la mise en place d’un système de communication WebRTC demande aussi une réflexion plus générale, notamment pour choisir les solutions aux problèmes suivants :
- comment joindre son correspondant pour lui proposer une communication WebRTC ?
- comment s’accorder sur divers aspects techniques de cette communications (codecs audio et vidéo, notamment) ?
- comment faire pour que ces différents échanges préliminaires, ainsi que la communication WebRTC elle-même, arrivent à passer à travers les routeurs placés entre les postes devant communiquer ?

On reconnaît ici divers problèmes déjà rencontrés dans de multiples systèmes de communication audio et vidéo sur internet, indépendamment des logiciels utilisés par les utilisateurs sur leurs postes. On constate notamment la nécessité d’un système de signalisation pour permettre de débuter une telle communication.
En ce qui concerne les routeurs – et les NAT qu’ils mettent en œuvre -, on retrouve aussi avec WebRTC les mêmes problèmes à résoudre que dans divers autres systèmes existant déjà :
- les messages de signalisation doivent pouvoir traverser ces NAT,
- la communication elle-même, aussi.

Les différents documents décrivant le fonctionnement de WebRTC laissent libre le choix du dispositif de signalisation. Ce choix – et éventuellement son adaptation nécessaire – est donc largement indépendant des nouveautés apportées par cette technologie WebRTC, et il dépend plutôt de l’environnement considéré. Ainsi, pour prendre deux exemples parmi d’autres, on utilisera sans doute des systèmes de signalisation différents :
- pour ajouter des communications WebRTC à une infrastructure existante de téléphonie sur IP, où les utilisateurs ont déjà des identifiants, et sont déjà ainsi joignables,
- pour ajouter un service WebRTC à un site Web, sur lequel les utilisateurs s’identifient déjà pour y effectuer diverses sessions.

 

Dans ce cadre de réflexion, ce groupe de billets rappelle un certain nombre de concepts concernant les communications (audio, vidéo) de point à point, et examine plus particulièrement les principaux problèmes posés par l’existence de routeurs placés entre les postes devant communiquer.
Ce groupe de billets :
- n’a pas pour ambition d’être exhaustif en matière de systèmes de signalisation,
- ne vise pas non plus à identifier et résoudre tous les problèmes posés par les différents types de routeurs et dispositifs analogues,
- et, bien sûr, ne cherche nullement à fournir de solutions "clés en main" pour tel ou tel projet WebRTC.

Toutefois, le rappel des principaux protocoles et méthodes utilisés dans ce domaine ne peut qu’aider à peut-être clarifier certains problèmes, et à reformuler correctement des questions auxquels un responsable informatique devra répondre.

Les billets suivants concernent donc :
- les principaux types de NAT mises en œuvre par les routeurs, et les problèmes qu’elles peuvent poser,
- l’exemple de la signalisation SIP, et la prise en compte des NAT par ce protocole,
- le protocole SDP et les NAT,
- le recours aux protocoles STUN et TURN, et plus généralement la méthode ICE

Par ailleurs, il existe une RFC qui reprend et résume les différentes solutions décrites dans ce groupe de billets. Il s’agit de la RFC 6314 de juillet 2011, qui s’appuie sur plusieurs RFC antérieures.
- la RFC 5626 pour l’entretien des connexions SIP initiées par les postes d’utilisateurs,
- la RFC 3581, pour que la réponse à une invitation à communiquer puisse parvenir au poste à l’origine de cette invitation.
Concernant la communication elle-même :
- la RFC 4961 pour les protocoles RTP et RTPC "symétriques",
- la RFC 4566 pour la version actuelle du protocole SDP,
- la RFC 5245 pour le protocole ICE.

 

 

WebRTC et les NAT
Les NAT dynamiques et les NAT statiques
La signalisation SIP et les NAT
Le protocole SDP
Les protocoles STUN et TURN
Le protocole ICE