Le webRTC est un outil dédié à la communication en temps réel. Actuellement implémenté dans presque tous les navigateurs, Il rend possible d’établir une conversation entre plusieurs clients en quelques lignes de code JavaScript.

I. Introduction

Le WebRTC est une API Javascript de communication en temps réel, permettant les échanges directs entre plusieurs navigateurs (voix vidéo et data).

Ce standard de la W3C et de l’IETF dont les premières ébauches sont apparues courant 2011 est soutenu par google, Mozilla et Opera.

Il existe actuellement une solution concurrente développée par Windows : CU-RTC-WEB

http://html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web.htm

http://lists.w3.org/Archives/Public/public-webrtc/2012Oct/att-0076/realtime-media.html

(Les solutions précédentes exploitaient des plugins propriétaires (exemple : flash) et n’étaient pas standardisées)

 

WebRTC est déjà implémenté (à des stades différents) dans plusieurs navigateurs, ainsi que dans android et IOS.

 

Etat le 25 avril 2017 :

 

Le WebRTC s’appuie sur d’autres normes tel STUN, ICE, TURN, DTLS, SRTP et d’autres normes issues du projet libjingle. Le canal de communication repose sur de l’UDP.

Le schéma ci-dessous illustre bien l’empilement protocolaire exploité:

II. Les 3 APIs

Les APIs implémentées par WebRTC répondent à 3 grands axes.

– acquérir les flux audio et vidéo

– transmettre les flux audio et vidéo

– transmettre des données arbitraires

 

1. PeerConnection :

Représente la connexion entre les deux terminaux (repose sur UDP). Cette connexion est établie à l’aide d’un canal de signalement laissé au choix de l’utilisateur (websocket ..) sur la quelle sont transmises des données issues du Protocol SDP, permettant d’obtenir les informations local sur la connexion. (/ ! \ SDP est en cours de remplacement au sein de la norme WebRTC par le protocole JSEP)

Pour assurer la connexion à travers les NAT, l’api Peerconnexion utilise les protocoles STUN, ICE et TURN.

Des flux de données et médias peuvent être multiplexé sur cette connexion, ces flux partagent donc les mêmes paquets de niveaux transport et donc partagent le même numéro de port. Ainsi l’octet de l’entête UDP indiquant la nature du contenu de la trame permet d’identifier s’il s’agit d’une trame STUN (0 ou 1), SRTP (20 à 63) ou DTLS (128 à 191).

 

2. DataStream :

L’api Data channel permet de transmettre des données génériques entre les terminaux (texte, image …). Elles sont transmises à l’aide du protocole SCTP lui-même reposant sur DTLS afin d’assurer la confidentialité et l’authenticité des paquets.

L’Api permet la gestion de plusieurs flux de données de manière bidirectionnelle, ainsi que des priorités.

 

3. MediaStream:

L’api MediaStream représente un flux de donné audio ou vidéo (local ou distant). L’accès à un flux local (WebCam, Micro) se fait grâce à l’API getusermedia.

Les flux sont transportés à l’aide du protocole SRTP implémentant une version sécurisé du protocole RTP. Il est à noté qu’un flux média exploite également DTLS pour la gestion des clés SRTP.

 

III. Codec audio et vidéo

 

La norme requière (au minimum) les codecs audio suivant : PCMA/PCMU correspondant au G711 respectivement alaw et ulaw, Telephone Event (RCF4733), Opus (RCF 6716).

Firefox permet déjà la communication avec H.264, les autres browsers affirment vouloir implémenter ce codec bientôt,  sans pour autant se fixer de date.

Les codecs vidéo ne sont pas encore définis. Les critères auxquels le codec doit répondre sont :

– support de fps compris entre 10 et 30

– support d’une résolution min 320 x 240 pixels

 

On peut facilement vérifier les codecs implémenté dans différents navigateurs en analysant le SDP généré (à l’aide de testSdp.htm présent dans src/webrtc/sdp-exemple par exemple. Note : le résultat se trouve dans la console javascript, pour une mise en forme plus lisible on peut utiliser le script sdp.sh présent dans le répertoire)

IV. Protocoles exploités par le WebRTC

1. Signalement

SDP :

Pour créer une connexion l’API peerconnexion exploite le protocole SDP. (Session Description Protocol). Il permet de décrire la session multimédia en cours d’établissement.

Voici la signification des champs :

Session description

v=  (protocol version number, currently only 0)

o=  (originator and session identifier : username, id, version number, network address)

s=  (session name : mandatory with at least one UTF-8-encoded character)

i=* (session title or short information)

u=* (URI of description)

e=* (zero or more email address with optional name of contacts)

p=* (zero or more phone number with optional name of contacts)

c=* (connection information—not required if included in all media)

b=* (zero or more bandwidth information lines)    One or more Time descriptions (« t= » and « r= » lines; see below)

z=* (time zone adjustments)

k=* (encryption key)

a=* (zero or more session attribute lines)    Zero or more Media descriptions (each one starting by an « m= » line; see below)Time description (mandatory)

t=  (time the session is active)    r=* (zero or more repeat times)Media description (if present)    m=  (media name and transport address)

i=* (media title or information field)

c=* (connection information — optional if included at session level)

b=* (zero or more bandwidth information lines)

k=* (encryption key)

a=* (zero or more media attribute lines — overriding the Session attribute lines)

 

Cette trame est généralement encapsulée dans du JSON. Le SDP est amené à disparaitre au profit du JSEP.

 

Je vous donne au passage ce petit exemple qui permet de modifier le SDP à la volé, pour forcer l’utilisation d’un codec:

https://github.com/rmanibus/webrtc-examples

 

2. Transport de données

RTP (Pour info):

RTP est un protocole destiné à transmettre sur de l’IP tout type de donnée ayant une contrainte de temps réel. Le principal service fourni par RTP est la numérotation des paquets ainsi que l’ajout de timestamp pour permettre de reconstituer correctement l’information

 

figure: Header RTP

SRTP :

Le SRTP correspond à une version sécurisée du RTP.


figure: Header SRTP

 

Voici la signification des champs :

V version du protocole (V=2) sur 2 bit

P Padding, sur 1 bit, vaut 1 si le dernier paquet contient un champ de bourrage

X extension sur 1 bit, vaut 1 si l’en-tête est suivie d’un paquet d’extension

CC sur 4 bits, nombre de CSRC qui suivent l’entête (CSRC count)

M Marker sur 1 bit, son interprétation est définie par un profil d’application (profile)

PT  sur 7 bits, identifie le type du payload (audio, vidéo, image, texte, html, etc.)

Séquence number sur 16 bits, sa valeur initiale est aléatoire et il s’incrémente de 1 à chaque paquet envoyé, il peut servir à détecter des paquets perdus

timestamp sur 32 bits, reflète l’instant où le premier octet du paquet RTP a été échantillonné.

SSRC sur 32 bits, valeur choisie de manière aléatoire par l’application qui identifie de manière unique la source.

Le champ CSRC : 32 bits, identifie les sources contribuant.

SCTP :

Le protocole SCTP est employé par l’API dataStream. Il est utilisé pour échanger des données n’étant pas de la vidéo ou du son.


figure: Header SCTP


figure: Trame SCTP

3. Sécurité

DTLS :

Littéralement Datagram Transport Layer Security.

Le protocole DTLS est basé sur le protocole TLS et fournit des garanties de sécurité similaires.

4. Network Adress Translation

STUN :

Littéralement Simple Traversal of UDP through NATs

Ce protocole permet d’obtenir son adresse IP publique. Il s’agit d’un serveur léger consommant peut de ressources. Les données ne passent pas par le serveur.

Entête STUN :

Le champ Type codé sur 16 bit se découpe en plusieurs sous champ :Les deux premiers bits sont à 0 pour se différencier des autres protocoles.

La classe sur 2 bits (00 Requête, 01 Indication, 10 Réponse avec succès, 11 Réponse avec erreur)

La méthode sur 12 bits

Magic Cookie est un champ à valeur fixe

Transaction ID est choisie de manière aléatoire par le client (le serveur répète la valeur dans sa réponse).

 

ICE :

Littéralement Interactive Connectivity Establishment, il s’agit d’un framework dont l’objectif est de trouver le meilleur chemin pour chaque communication.

 

TURN :

Litteralement Traversal Using Relays around NAT, ce protocole fourni une alternative cloud si la communication directe entre les terminaux n’est pas possible. Les données sont ainsi transmises au serveur qui relaye l’information.

 

Serveur google (STUN/TURN): stun.l.google.com:19302

V Sources

Ce qui est implémenté:
http://iswebrtcreadyyet.com/

Wiki:
https://fr.wikipedia.org/wiki/WebRTC

Site du projet:
http://www.webrtc.org/

Slides sur le WebRTC:
http://io13webrtc.appspot.com

Draft IETF WebRTC:
https://tools.ietf.org/wg/rtcweb/

Draft W3C WebRTC:
http://w3c.github.io/webrtc-pc/

Doc SRTP:
https://tools.ietf.org/html/rfc3711

Doc SCTP:
https://tools.ietf.org/html/rfc4960

Doc SDP:
https://tools.ietf.org/html/rfc4566

Wiki SDP:
https://en.wikipedia.org/wiki/Session_Description_Protocol

 

VI. Bibliothèques (C/C++)

 

Opus, libopus :
Pour encoder et décoder des trames OPUS, utile pour réaliser une Gateway.
http://www.opus-codec.org/docs/opus_api-1.1.0.pdf

Jingle, Libjingle :
https://developers.google.com/talk/libjingle/developer_guide

SCTP:
http://simplestcodings.blogspot.fr/2010/08/sctp-server-client-implementation-in-c.html

SDP:
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-gstsdpmessage.html

RTP/SRTP:
http://gstreamer.freedesktop.org/
ou libsrtp
https://github.com/cisco/libsrtp
ou ffmpeg
https://www.ffmpeg.org/

TLS/DTLS:
http://tinydtls.sourceforge.net/
http://wolfssl.com
http://www.gnutls.org/
https://www.openssl.org/

UDP:
[tuto from Scratch] http://broux.developpez.com/articles/c/sockets/
Cependant la SDL et Qt permettent de créer très facilement des connexions UDP

VII. Projets divers:

http://www.openwebrtc.io/
[MCU] https://janus.conf.meetecho.com/
[MCU] http://www.kurento.org/
[TUTO] http://www.html5rocks.com/fr/tutorials/webrtc/basics/
[MCU] http://sourceforge.net/projects/mcumediaserver/ (support H.264 ?)
https://wiki.asterisk.org/wiki/display/AST/Asterisk+WebRTC+Support
http://phono.com/
https://github.com/EricssonResearch/openwebrtc/
[H.264] http://webrtcbook.com/sdp-h264.html