Le protocole ICE

La RFC 5245 d’avril 2010 décrit le protocole ICE, qui :
- s’appuie sur les protocoles STUN et TURN
- peut être mis en œuvre dans le cadre d’une signalisation SIP.

Il s’agit ici de décrire comment chacun des postes destinés à communiquer entre eux :
- découvre, chacun en ce qui le concerne, les adresses IP et les ports utilisables pour leur envoyer les flux constituant cette communication,
- en informe l’autre poste,
- et comment s’effectuent les choix finaux, en cas de possibilités a priori multiples.

On est ici dans le contexte d’une invitation à communiquer envoyée par le poste A au poste B, invitation transportée dans le cas présent par le protocole SIP.

Remarque : dans la suite de ce billet, sauf précision – par exemple “adresse IP” -, le terme “adresse” recouvre ici non seulement l’adresse IP, mais aussi le port de communication.

Première étape : le rassemblement des adresses candidates.

C’est le poste à l’initiative de l’invitation à communiquer qui procède le premier à ce rassemblement :
- pour chacune de ses interfaces (connexion filaire à son réseau local, Wi-Fi, VPN, etc.), ce poste recense ses adresses IP locales,
- pour chacune de ces adresses IP locales, il choisit 2 ports (un pour le protocole RTP et un autre pour le protocole RTCP) pour chacun des flux de communication constituant la communication à venir : par exemple, deux flux s’il s’agit de communiquer à la fois en audio et en vidéo;
- ces différents couples adresse IP / port de communication constituent autant ” d’adresses candidates “;
- en utilisant les services d’un serveur STUN – et éventuellement aussi TURN -, le poste A associe à chacune de ces adresses candidates une adresse réflexive, et éventuellement une adresse relayée (voir le billet).
Puis le poste A attribue des “priorités” à ces adresses candidates, selon plusieurs critères, notamment :
- l’interface de l’adresse candidate,
- le fait que cette adresse soit relayée ou non.

L’ensemble est alors encodé selon le protocole SDP, et transmis au poste B, transporté par l’invitation SIP dans le cas présent.

Lors de la réception de cette invitation, le poste B rassemble lui aussi ses adresses candidates, leur attribue ses priorités, encode le tout selon le protocole SDP, et retourne cette information au poste A. Ce retour est transporté par la réponse du poste B à l’invitation venant du poste A (protocole SIP).

Seconde étape : les tests de connectivité et le choix des connexions.

Chaque poste est alors en possession de ces deux listes d’adresses candidates.
Ensuite :
- chaque poste forme une liste de “paires candidates”, en combinant chaque adresse candidate de sa liste avec chaque adresse candidate de l’autre liste. Chacune de ces paires pourrait donc représenter un trajet possible pour un flux de la communication envisagée.
- chaque poste attribue ensuite à chacune de ces paires un attribut “priorité”, selon lequel il trie cette liste de paires. Cet attribut résulte de la combinaison des attributs de même nom qui avaient été accolés à chacune des adresses candidates rassemblées à l’étape précédente.
A ce stade, les deux postes sont en possession de la même liste triée de paires candidates.

Puis un des deux postes, qui a le rôle de “contrôleur” (“Ice-Controlling”), teste chacune de ces paires par l’envoi d’une requête STUN à l’autre poste. Il est alors normal que certaines de ces requêtes échouent – par exemple au niveau de leur réponse – car certaines de ces paires ne tiennent évidemment pas compte de la présence des routeurs, ou de NAT au comportement restrictif.
En cas de succès, l’autre poste teste aussi cette connexion.
A l’issue de ces tests, les paires nécessaires à la communication envisagée sont choisies par le poste “Ice-Controlling”.

Le plus souvent, celui des postes qui joue ce rôle d’Ice-Controlling est le poste appelant, qui aura envoyé l’invitation à communiquer.

Dans le cas présent, l’échange initial des listes d’adresse candidates a fait l’objet d’un transport par le protocole SIP.
Mais ce protocole ICE est en fait indépendant de SIP, et peut être utilisé avec d’autres systèmes de signalisation.

Par ailleurs, la RFC 5245 aborde évidemment de nombreux points complémentaires, notamment pour pouvoir gérer des situations réelles plus complexes. Par exemple, l’utilisateur appelé peut avoir décroché son téléphone (ou effectué une opération similaire sur son logiciel) avant que tous les tests de connectivité ICE aient été menés à bien entre les deux postes, et que les connexions nécessaires à cette communication aient été choisies.

 

 

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