1. Introduction

Le RFC 3264 [RFC3264] définit un échange en deux phases de messages SDP (Session Description Protocol) [RFC4566] aux fins de l'établissement de sessions multimédias. Ce mécanisme d'offre/réponse est utilisé par des protocoles tels que le protocole SIP (Session Initiation Protocol) [RFC3261].

Les protocoles utilisant l'offre/réponse sont difficiles à faire fonctionner à travers des traducteurs d'adresses réseau (NAT). Parce que leur but est d'établir un flux de paquets multimédias, ils ont tendance à transporter les adresses IP et les ports des sources et des destinations multimédias dans leurs messages, ce qui est connu pour être problématique à travers un NAT [RFC3235]. Les protocoles cherchent également à créer un flux multimédia directement entre les participants, de sorte qu'il n'y ait pas d'intermédiaire de couche application entre eux. Cela est fait pour réduire la latence multimédia, diminuer la perte de paquets et réduire les coûts opérationnels de déploiement de l'application. Cependant, cela est difficile à accomplir à travers un NAT. Un traitement complet des raisons de cela dépasse la portée de cette spécification.

De nombreuses solutions ont été définies pour permettre à ces protocoles de fonctionner à travers un NAT. Celles-ci incluent les passerelles de couche application (ALG), le protocole de contrôle de Middlebox [RFC3303], la spécification originale STUN (Simple Traversal of UDP Through NAT) [RFC3489], et l'IP spécifique au domaine [RFC3102] [RFC3103] ainsi que les extensions de description de session nécessaires pour les faire fonctionner, telles que l'attribut SDP (Session Description Protocol) [RFC4566] pour le protocole de contrôle en temps réel (RTCP) [RFC3605]. Malheureusement, ces techniques ont toutes des avantages et des inconvénients qui rendent chacune optimale dans certaines topologies de réseau, mais un mauvais choix dans d'autres. Le résultat est que les administrateurs et les implémenteurs font des hypothèses sur les topologies des réseaux dans lesquels leurs solutions seront déployées. Cela introduit de la complexité et de la fragilité dans le système. Ce qui est nécessaire est une solution unique suffisamment flexible pour bien fonctionner dans toutes les situations.

Cette spécification définit l'établissement de connectivité interactive (ICE) comme une technique pour la traversée de NAT pour les flux multimédias basés sur UDP (bien que ICE puisse être étendu pour gérer d'autres protocoles de transport, tels que TCP [ICE-TCP]) établis par le modèle d'offre/réponse. ICE est une extension du modèle d'offre/réponse, et fonctionne en incluant une multiplicité d'adresses IP et de ports dans les offres et réponses SDP, qui sont ensuite testés pour la connectivité par des vérifications de connectivité pair-à-pair. Les adresses IP et les ports inclus dans le SDP et les vérifications de connectivité sont effectués en utilisant la spécification STUN révisée [RFC5389], maintenant renommée Session Traversal Utilities for NAT. Le nouveau nom et la nouvelle spécification reflètent son nouveau rôle en tant qu'outil utilisé avec d'autres techniques de traversée de NAT (à savoir ICE) plutôt que comme une solution de traversée de NAT autonome, comme l'était la spécification STUN originale. ICE utilise également TURN (Traversal Using Relays around NAT) [RFC5766], une extension de STUN. Parce que ICE échange une multiplicité d'adresses IP et de ports pour chaque flux multimédia, il permet également la sélection d'adresses pour les hôtes multi-homed et double pile, et pour cette raison, il rend obsolètes les RFC 4091 [RFC4091] et [RFC4092].