Mon blog

Ce court RFC normalise un nouveau plan d'URI, stun:, qui sera utilisé pour la configuration des clients STUN, un protocole de traversée des obstacles comme les routeurs NAT.

C'est le travail sur WebRTC qui a ravivé l'intérêt pour ce nouveau modèle d'URI (envisagé depuis longtemps mais jamais normalisé). WebRTC (RFC 8825) est un mécanisme de communication directe entre navigateurs Web. Souvent, les logiciels WebRTC vont devoir passer à travers des environnements hostiles comme des routeurs NAT. Une des techniques fréquemment utilisées pour aider ce passage est STUN, normalisé dans le RFC 8489, qui permet à un client STUN, en se connectant à un serveur STUN (en général installé par un fournisseur de services, par exemple SIP), d'apprendre son adresse IP extérieure et aussi d'autres caractéristiques utiles du NAT traversé.

Mais, pour cela, il faut que le client soit configuré avec les coordonnées d'un serveur STUN. Actuellement, cela se fait d'une manière spécifique à chaque client. D'où l'idée d'avoir un mécanisme simple de désignation du serveur STUN, un URI comme stun:example.net. Il n'y aura plus qu'à le copier/coller à l'endroit indiqué. Cela simplifiera la configuration et la documentation.

La section 3 fournit la syntaxe exacte. Il y a deux plans d'URI, stun: et stuns:, le second servant aux connexions sécurisées avec TLS. Ils sont notés dans le registre IANA des plans (après une discussion sur la liste d'examen des nouveaux plans). Un numéro de port est possible comme par exemple stuns:provider.example:8888. S'il est absent, le port par défaut est 3478 pour stun: et 5349 pour stuns:. Rappelez-vous que le nom du serveur, lui, sera déduit du nom de domaine indiqué dans l'URI par une recherche SRV (section 9 du RFC 5389).

Aujourd'hui, ces URI stun: sont utilisés dans des normes W3C comme celle de WebRTC. Ils sont acceptés par :

• libjingle, une bibliothèque utilisée par Chrome et qui met en oeuvre les normes XMPP XEP-166 et XEP-167,
• et Firefox depuis la version 21 (voir le source).