WebRTC Partie 1 : Comment ça marche ?
Voilà le deuxième article de la série WebRTC qui va principalement traiter de l’approche de WebRTC. Pour la suite de l’article (et les prochains aussi), je vais prendre, comme base, une mise en relation entre deux clients, donc une structure 1:1. De plus, au moment où je rédige cet article, WebRTC est fonctionnel, mais il manque beaucoup de fonctionnalités décrites dans la RFC de l’IETF (Internet Engineering Task Force), tels que :
- Le multi-pair
- L’enregistrement de vidéo
- Le support du protocole TURN à la dernière norme (que nous décrirons dans un prochain article)
- L’envoie de données autres que vidéo ou audio (Datagram)
Des fonctionnalités clés de communication encore absentes, restreignent l’utilisation de cette technologie à la démonstration pour l’instant. Néanmoins, cela ne va pas nous empêcher de parler de la technologie et de pouvoir l’utiliser pour le développement d’une application de type visioconférence.
Alors comment ça marche tout ça pour mettre en relation deux clients ? Et bien, le tout suit des étapes logiques qui sont quasi-similaires à un appel avec une application SIP.
Voici, donc un schéma qui représente l’établissement d’une connexion entre deux clients :
— : Numéro de phase
— : Phases
— : Protocoles
- Les utilisateurs s’identifient auprès d’un Fournisseur d’identité (Identity Provider cf ci-après)
- Lors de la connexion les utilisateurs se présentent au serveur TURN/STUN (Traversal Using Relay NAT/Session Traversal Utilities for NAT) pour la traversée des NAT
- La phase de signaling débute avec l’envoie d’un message SDP stipulant une offre (OFFER)
- L’autre client répond avec un message SDP contenant une réponse (ANSWER)
- Finalement, le premier utilisateur accuse de la réception de cette réponse et envoie un dernier message SDP (OK)
- Enfin, la connexion en pair à pair peut s’établir et les médias sont échangés.
Les messages SDP sont faits à partir d’un blob (Binary Large OBject) généré, pour le moment, par ROAP (RTCWeb Offer/Answer Protocol) afin de générer l’état de la machine dans la partie signalling. Le fait que ROAP soit intégré dans la navigateur pose des soucis au niveau du développement de certains types d’applications. Par exemple, des applications, compatibles SIP, qui empêchent l’envoie de la mise à jour de l’état de la machine après l’envoie de l’offre initiale. C’est ici qu’intervient la nouvelle norme JSEP qui devraient être intégrée d’ici sous peu.
L’échange des médias se fait bien de manière décentralisée et ne passe pas par de serveur intermédiaire, sauf dans le cas où la connexion direct entre les intervenants ne peut se faire. Dans ce cas on utilise un serveur TURN comme passerelle de paquets UDP. Nous verrons plus en détail comment marche un serveur TURN dans un prochain article.
Les recommandations de l’IETF ont notamment prévu qu’un appel devra s’effectuer avec la vérification de l’identité des personnes à l’aide d’un Identity Provider, étape 1. Par exemple, avant de déclarer la méthode peerconnection, le navigateur irait « demander » à un service (BrowserID, Federated Google Login, Facebook Connect, OAuth, OpenID,WebFinger) l’authenticité de l’utilisateur A pour que l’utilisateur B s’attende bien à recevoir un appel de A :
Globalement, pour les habitués de la VoIP, il n’y pas trop de changement par rapport au procédé utilisé dans les appels SIP. On remarque aussi que la procédure se libère totalement du navigateur, quel qu’il soit, et qu’il suffit que les navigateurs partagent l’API JavaScript qui comporte les méthodes WebRTC pour une compatibilité complète. La génération des blobs SDP reste la dernière abstraction à atteindre qui se fera avec l’introduction de JSEP.
L’établissement de la connexion entre les pairs est simple et met en jeu plusieurs notions que nous allons explorer lors des prochains articles qui auront un aspect plus technique. J’insiste sur le fait que chacune des notions présentées ici peut complètement changer du jour au lendemain, du fait de l’évolution constante de la technologie.
