2. Overview of ICE (Aperçu d'ICE)
Dans un déploiement ICE typique, il y a deux points de terminaison (agents ICE, ICE agents) qui souhaitent communiquer. Notez qu'ICE n'est pas destiné à la traversée de NAT pour le protocole de signalisation (signaling protocol), qui est supposé être fourni via un autre mécanisme. ICE suppose que les agents sont capables d'établir une connexion de signalisation entre eux.
Initialement, les agents ignorent leurs propres topologies. En particulier, les agents peuvent ou non être derrière des NAT (ou plusieurs niveaux de NAT). ICE permet aux agents de découvrir suffisamment d'informations sur leurs topologies pour potentiellement trouver un ou plusieurs chemins par lesquels ils peuvent établir une session de données.
La figure 1 montre un déploiement ICE typique. Les agents sont étiquetés L et R. L et R sont tous deux derrière leurs propres NAT respectifs, bien qu'ils puissent ne pas en être conscients. Le type de NAT et ses propriétés sont également inconnus. L et R sont capables de s'engager dans un processus d'échange de candidats (candidate exchange), dont le but est de configurer une session de données entre L et R. Typiquement, cet échange se produira via un serveur de signalisation (par exemple, un proxy SIP).
En plus des agents, d'un serveur de signalisation et des NAT, ICE est généralement utilisé en concert avec des serveurs STUN ou TURN dans le réseau. Chaque agent peut avoir son propre serveur STUN ou TURN, ou ils peuvent être identiques.
+---------+
+--------+ |Signaling| +--------+
| STUN | |Server | | STUN |
| Server | +---------+ | Server |
+--------+ / \ +--------+
/ \
/ \
/ <- Signaling -> \
/ \
+--------+ +--------+
| NAT | | NAT |
+--------+ +--------+
/ \
/ \
+-------+ +-------+
| Agent | | Agent |
| L | | R |
+-------+ +-------+
Figure 1 : Scénario de déploiement ICE
L'idée de base derrière ICE est la suivante : chaque agent dispose d'une variété d'adresses de transport candidates (candidate transport addresses) (combinaison d'adresse IP et de port pour un protocole de transport particulier, qui est toujours UDP dans cette spécification) qu'il pourrait utiliser pour communiquer avec l'autre agent. Celles-ci peuvent inclure :
- Une adresse de transport sur une interface réseau directement connectée
- Une adresse de transport traduite du côté public d'un NAT (une "adresse réflexive de serveur (server-reflexive address)")
- Une adresse de transport allouée à partir d'un serveur TURN (une "adresse relayée (relayed address)")
Potentiellement, n'importe quelle adresse de transport candidate de L peut être utilisée pour communiquer avec n'importe quelle adresse de transport candidate de R. En pratique, cependant, de nombreuses combinaisons ne fonctionneront pas. Par exemple, si L et R sont tous deux derrière des NAT, leurs adresses d'interface directement connectées sont peu susceptibles de pouvoir communiquer directement (c'est pourquoi ICE est nécessaire, après tout !). Le but d'ICE est de découvrir quelles paires d'adresses fonctionneront. La manière dont ICE le fait est d'essayer systématiquement toutes les paires possibles (dans un ordre soigneusement trié) jusqu'à ce qu'il en trouve une ou plusieurs qui fonctionnent.
2.1. Gathering Candidates (Collecte de candidats)
Pour exécuter ICE, un agent ICE identifie et collecte un ou plusieurs candidats d'adresse. Un candidat a une adresse de transport -- une combinaison d'adresse IP et de port pour un protocole de transport particulier (avec seulement UDP spécifié ici). Il existe différents types de candidats ; certains sont dérivés d'interfaces réseau physiques ou logiques, et d'autres sont découvrables via STUN et TURN.
La première catégorie de candidats sont ceux avec une adresse de transport obtenue directement à partir d'une interface locale. Un tel candidat est appelé un "candidat hôte (host candidate)". L'interface locale pourrait être Ethernet ou Wi-Fi, ou elle pourrait être obtenue via un mécanisme de tunnel, tel qu'un réseau privé virtuel (Virtual Private Network, VPN) ou IP mobile (Mobile IP, MIP). Dans tous les cas, une telle interface réseau apparaît à l'agent comme une interface locale à partir de laquelle des ports (et donc des candidats) peuvent être alloués.
Ensuite, l'agent utilise STUN ou TURN pour obtenir des candidats supplémentaires. Ceux-ci se déclinent en deux types : des adresses traduites du côté public d'un NAT (candidats réflexifs de serveur, server-reflexive candidates) et des adresses sur des serveurs TURN (candidats relayés, relayed candidates). Lorsque des serveurs TURN sont utilisés, les deux types de candidats sont obtenus à partir du serveur TURN. Si seuls des serveurs STUN sont utilisés, seuls les candidats réflexifs de serveur sont obtenus à partir d'eux.
2.2. Connectivity Checks (Vérifications de connectivité)
Une fois que L a collecté tous ses candidats, il les classe par priorité décroissante et les envoie à R via le canal de signalisation. Lorsque R reçoit les candidats de L, il effectue le même processus de collecte et répond avec sa propre liste de candidats. À la fin de ce processus, chaque agent ICE dispose d'une liste complète de ses propres candidats et de ceux de son pair. Il les apparie, ce qui donne des paires de candidats. Pour voir quelles paires fonctionnent, chaque agent planifie une série de vérifications de connectivité.
Le principe de base des vérifications de connectivité est simple :
- Trier les paires de candidats par ordre de priorité.
- Envoyer des vérifications sur chaque paire de candidats par ordre de priorité.
- Accuser réception des vérifications reçues de l'autre agent.
2.3. Nominating Candidate Pairs and Concluding ICE (Nomination de paires de candidats et conclusion d'ICE)
ICE attribue à l'un des agents ICE le rôle d'agent contrôlant (controlling agent), et à l'autre le rôle d'agent contrôlé (controlled agent). Pour chaque composant d'un flux de données, l'agent contrôlant désigne une paire valide (de la liste valide) à utiliser pour les données.
2.4. ICE Restart (Redémarrage ICE)
Une fois ICE terminé, il peut être redémarré à tout moment pour un ou tous les flux de données par l'un ou l'autre agent ICE. Cela se fait en envoyant des informations de candidat mises à jour indiquant un redémarrage.
2.5. Lite Implementations (Implémentations Lite)
Certains agents ICE seront toujours connectés à l'Internet public et auront une adresse IP publique à laquelle ils peuvent recevoir des paquets de n'importe quel correspondant. Pour faciliter la prise en charge d'ICE par ces appareils, ICE définit un type spécial d'implémentation appelé "lite" (par opposition à l'implémentation complète normale). Les agents Lite n'utilisent que des candidats hôtes et ne génèrent pas de vérifications de connectivité ni n'exécutent de machines d'état, bien qu'ils doivent pouvoir répondre aux vérifications de connectivité.