Le NAT, l'ennemi.
Le SIP a été pensé en 1999 pour un Internet symétrique. Vingt-cinq ans plus tard, presque tous les UA vivent derrière une box. Voici comment ils s'en sortent quand même.
Les types de NAT.
Tous les NAT ne se valent pas. Quatre comportements existent, par ordre de gentillesse :
| Type | Comportement | STUN ? |
|---|---|---|
| Full cone | Une fois sortie, n'importe qui peut rentrer sur le même port. | Oui.Le plus permissif. Rare. |
| Restricted cone | Seules les IP externes déjà contactées peuvent rentrer. | Oui. |
| Port-restricted cone | Même IP et même port que celui contacté. | Oui, avec ICE. |
| Symmetric | Le port externe change pour chaque destination. | Non. TURN obligatoire. |
Les box ISP modernes (Freebox, Livebox, etc.) sont typiquement port-restricted. Les firewalls d'entreprise sérieux sont presque toujours symétriques. C'est pourquoi STUN marche à la maison et pas au bureau.
STUN.
Session Traversal Utilities for NAT — RFC 5389. Le UA pose une question simple à un serveur tiers : quelle est mon adresse publique vue de toi ? Le serveur répond, le UA réécrit ses en-têtes Contact et Via en conséquence.
# Trois étapes
1. UA → stun.linphone.org : Binding Request (UDP)
2. stun.linphone.org → UA : "tu sors avec 81.2.3.4:54812"
3. UA réécrit Contact: <sip:alice@81.2.3.4:54812>
Léger, gratuit, sans état côté serveur. Marche pour 80 % des configurations résidentielles. Échec garanti sur les NAT symétriques.
TURN.
Traversal Using Relays around NAT — RFC 8656. Quand le P2P est impossible, on relaie. Le UA envoie son RTP à un serveur TURN public, qui le transmet à l'autre UA. Coûteux en bande passante, imparable en couverture.
Sans TURN (RTP P2P) :
Alice ←──────── RTP ────────→ Bob
Avec TURN :
Alice ←─ RTP ─→ turn.x.com ←─ RTP ─→ Bob
Tout le trafic vocal passe par le serveur de relais. C'est pour ça que les opérateurs facturent ce service : 1 Mbit/s par appel en double sens, multiplié par mille utilisateurs simultanés, ça finit par coûter.
ICE.
Interactive Connectivity Establishment — RFC 8445. La stratégie qui essaie tout, dans l'ordre du moins cher au plus cher. Voici sa procédure :
Collecte des candidats
Chaque UA recense ses adresses possibles : locale (host), publique (via STUN, server-reflexive), relayée (via TURN, relayed).
Échange via SDP
Les candidats sont sérialisés en SDP, transmis dans l'INVITE et le 200 OK. Chaque UA connaît tous les candidats de l'autre.
a=candidate: dans le SDP.Vérifications par paires
Les UA s'envoient des ping STUN sur chaque paire de candidats possibles. La paire qui répond la première et la mieux gagne.
Nomination du gagnant
Le RTP passe désormais par cette paire. Si elle tombe pendant l'appel, ICE peut renégocier vers une autre paire.
Le SBC.
Session Border Controller. Un proxy SIP musclé placé en bordure du réseau opérateur. Il réécrit les en-têtes SIP au vol pour cacher la topologie interne, relaie le RTP, applique des règles de débit, déchiffre/rechiffre. C'est l'équivalent VoIP d'un firewall applicatif.
Côté entreprise, un SBC peut aussi servir à traduire entre dialectes SIP. Tel opérateur attend du Contact avec rport, tel autre veut une auth P-Asserted-Identity. Le SBC normalise tout ça.
Internet ───► SBC opérateur ───► Cœur de réseau opérateur
réécrit Via, Contact, SDP
relaie RTP (force le passage)
applique ACL, débit, transcodage
« Le NAT n'est pas un bug du SIP. C'est un trauma de jeunesse de l'Internet. Tout le reste est de la thérapie. » — note de chevet
Suivant : Les codecs audio →