Résumé

  • Avec rport, un client SIP demande que la réponse soit renvoyée au couple adresse-port réellement vu par le serveur. La réception prouve le passage de cette réponse dans la liaison NAT encore active, rien de plus durable.
  • Le couple observé, la liaison NAT, le flux, l’inscription, la transaction, le dialogue et le résultat utilisateur ont des durées et des autorités différentes. Les fondre dans un seul état « joignable » détruit la cause des pannes futures.

Une réponse arrive. Le tableau d’exploitation passe au vert. Quelques minutes plus tard, une nouvelle requête destinée au même utilisateur se perd. La tentation est d’accuser une mesure incohérente : si le terminal a reçu la réponse, pourquoi ne serait-il plus joignable ?

Parce que les deux paquets ne posaient pas la même question.

La réponse empruntait une ouverture créée à l’instant par une requête sortante. Le paquet ultérieur exigeait encore une liaison valide, le bon proxy d’accès, le bon membre de cluster et une décision d’inscription capable de retrouver ce chemin. La RFC 3581, publiée en août 2003 sur la filière Standards Track, résout le premier problème. Elle consacre une part remarquable de son texte à empêcher qu’on lui attribue le second.

Une destination composée de deux vérités

Dans SIP sur UDP, la règle initiale de retour était hybride. L’adresse IP venait de la source observée du datagramme ; le port venait du composant sent-by du Via supérieur. Cette combinaison permettait à un serveur d’annoncer un point d’écoute commun. Derrière un NAT, elle pouvait juxtaposer l’adresse publique traduite et un port privé devenu inutilisable.

Le client ajoute alors rport sans valeur. Cette absence est un choix d’autorité : il ne prétend pas connaître son port public, il demande au destinataire de noter ce qu’il voit. Le serveur inscrit le port source dans rport et l’adresse source dans received, même lorsque celle-ci correspond à sent-by.

Pour un transport monodiffusion non fiable, en l’absence de maddr, la réponse part vers received:rport. Elle doit aussi partir de l’adresse et du port du serveur qui ont reçu la requête. Un NAT symétrique peut conditionner la liaison à l’ensemble des deux extrémités ; l’interface sortante du serveur fait donc partie de la preuve.

Le mécanisme ne dit pas « croire l’en-tête ». Il dit : utiliser l’observation du fil pour la réponse de cette transaction. Tout élargissement doit être prouvé séparément.

Le couple observé expire avec son contexte

Prenons un Via annonçant 10.1.1.1:4540 et un proxy voyant 192.0.2.1:9988. Le second couple est une bonne destination de retour à cet instant. Il n’est pas le nom du terminal, le titulaire de l’Address-of-Record, un identifiant d’instance ni un bail sur le port public.

La chaîne comporte au moins trois faits. Le rport vide prouve que l’expéditeur a demandé l’extension. Le rport numérique prouve qu’un serveur a consigné son observation. Seule une réception côté client prouve que la réponse a achevé le trajet. Même cette réception ne dit ni combien de temps la liaison survivra, ni si un autre serveur pourra l’utiliser.

Un reçu exploitable doit associer branche, Call-ID, CSeq, Via avant et après modification, couple source sur le fil, instance du proxy, interface d’entrée, interface de sortie, statut de réponse et preuve côté client. Une ligne reachable=true enlève le sujet, la durée et le trajet de l’affirmation.

L’interface concrète résiste mal à l’abstraction du cluster

Un proxy multiréseau ou multiport doit se souvenir du point exact de réception. Un proxy avec état le conserve pendant la transaction. Un proxy sans état peut encoder l’adresse et le port nécessaires dans le Via qu’il ajoute, puis les récupérer lorsque la réponse revient.

« Sans état » ne signifie donc pas « sans provenance ». La provenance voyage dans le message plutôt que dans la mémoire locale. Si l’observabilité ne garde que le nom logique du service, elle ne peut plus démontrer que la réponse est partie du même socket.

Cette différence devient critique derrière un répartiteur. Le nœud qui a vu le paquet sortant peut être le seul dont les paquets entrants correspondent à la liaison du NAT symétrique. Un basculement peut être sain pour le service global et fatal pour ce trajet précis. Santé du cluster, santé du proxy et santé de la transaction sont trois états.

Un succès n’est pas un bail de liaison

La RFC 3581 exige que la liaison NAT subsiste pendant la transaction. Les transactions autres qu’INVITE étaient réputées assez courtes par rapport aux délais UDP courants de l’époque. Un INVITE peut attendre sa réponse finale sans borne pratique. Le texte recommande donc de poursuivre les retransmissions, même après une réponse provisoire, afin de rafraîchir la liaison.

Cette recommandation révèle ce que rport ne transporte pas : une date d’expiration. Une réponse provisoire réussie ne signe pas de bail. Le silence, un redémarrage du NAT, une modification de politique ou un basculement du proxy peuvent supprimer le chemin sans toucher à l’identité SIP.

Le document citait la découverte de durée de liaison de la RFC 3489 tout en la qualifiant de peu fiable. La RFC 5389 a ensuite rendu la RFC 3489 obsolète, puis la RFC 8489 a remplacé la RFC 5389. Les estimations de 2003 ne sont pas des mesures actuelles. Ce qui reste valable est la discipline : conserver le dernier trafic observé, la cadence de retransmission, la fenêtre mesurée et son incertitude.

Une adresse apprise n’est pas un itinéraire acquis

La paire received+rport révèle au client son couple public tel que le serveur le voit. Il pourrait réinscrire ce couple dans Contact, ou l’utiliser dans Record-Route, afin d’attirer des requêtes futures. La RFC 3581 classe cet usage comme une auto-correction unilatérale d’adresse, UNSAF, et en décrit les fragilités.

Il faut rafraîchir la liaison beaucoup plus souvent qu’une inscription ordinaire. Avec un NAT symétrique, le couple peut accepter uniquement les paquets du serveur initial. Un autre membre de la même grappe lit la même inscription mais ne passe pas. Si REGISTER a été reçu par un proxy avant le registrar, les requêtes futures doivent repasser par ce proxy ; le mécanisme Path de la RFC 3327 porte cette exigence.

Le seul nombre de port ne contient ni le pair distant autorisé, ni l’échéance, ni le proxy responsable, ni l’affinité de grappe. Copier l’observation dans un carnet d’adresses rend ces conditions invisibles.

La stratégie de sortie de la RFC 3581 demandait une solution où le client puisse exiger l’usage de la connexion ou du flux qu’il a ouvert, où les grappes soient traitées explicitement et où le rafraîchissement n’impose pas une charge excessive. La RFC 5626 a ensuite défini SIP Outbound : l’inscription peut viser des flux initiés par le client, plusieurs flux peuvent coexister, des keepalives entretiennent la liaison et détectent une panne. La RFC 6314 recommande cette approche dans ses pratiques de traversée NAT.

Les mécanismes ultérieurs gardent leurs limites. La RFC 6223 distingue le maintien en vie de la réutilisation de connexion. La RFC 5923 traite les requêtes inverses sur transport connecté. La RFC 5627 définit un GRUU stable pour une instance d’agent. Un pong ne prouve pas le choix d’inscription ; un jeton de flux n’est pas une autorisation ; une URI stable ne prouve ni média ni réponse humaine.

L’intégrité protège les octets, pas la portée de l’affirmation

L’adresse et le port source peuvent être sensibles. La RFC 3581 évoque SIP sur TLS pour protéger la signalisation. Sur TCP/TLS, rport fournit surtout l’information observée ; le retour ne dépend pas de sa mécanique UDP.

Un intermédiaire peut supprimer rport et empêcher un client derrière NAT de recevoir sa réponse. La protection d’intégrité peut empêcher cette modification. Elle ne prouve pas qui contrôle le couple traduit et ne prolonge pas la liaison. L’enregistrement du paramètre par l’IANA coordonne une syntaxe ; il ne certifie ni implémentation, ni état actif, ni livraison.

Il faut donc des autorités séparées : authentification pour l’identité, observation réseau pour le couple de transaction, provenance du socket pour la réponse, Path ou flux pour le futur, état du registrar pour la sélection, Route set pour le dialogue, puis reçus propres à la sonnerie, à la réponse, au média et à l’application.

Périmètre de preuve

Cet Article ne désigne aucun opérateur, PBX, fournisseur SIP, terminal, proxy, registrar, fabricant de NAT, cluster, abonné, appel, incident ou résultat média. La filière Standards Track ne prouve aucun taux de déploiement.

La RFC 3261 fournit la base Via et transactionnelle ; la RFC 3327, Path ; la RFC 3424, le cadre UNSAF. La RFC 3489 reste un contexte historique, tandis que les RFC 5389 et 8489 marquent l’évolution de STUN. Les RFC 5626, 6314, 5923, 6223 et 5627 séparent Outbound, pratiques NAT, réutilisation, keepalive et URI stable. Le registre IANA ne remplace pas la preuve en fonctionnement.

Les essais de Heng Lu sur Running-Code Primacy et Minimum Initial Specification sont des angles éditoriaux déclarés. Ils invitent à vérifier le chemin réellement exécuté et à limiter la règle commune au minimum interopérable. Ils ne témoignent ni de l’intention des auteurs de la RFC ni d’un déploiement.

La conclusion tient en une phrase rigoureuse : une réponse a trouvé un port à un moment donné. Ce reçu est précieux, à condition de ne pas le vendre comme l’itinéraire de demain.

Sources