Résumé

  • RFC 3605 a créé l'attribut média a=rtcp parce qu'un NAT peut attribuer à RTP et RTCP des ports non consécutifs, voire des adresses différentes. L'attribut indique une destination; il ne prouve pas que le chemin fonctionne.
  • Une exploitation fiable distingue description acceptée, mode négocié, socket ouvert, mappage observé, paquet émis, paquet reçu, rapport validé et décision de qualité. Le média peut circuler pendant que la boucle de contrôle reste muette.

Le premier symptôme est trompeur: les participants s'entendent. Les compteurs RTP progressent. La fiche de session contient bien une ligne a=rtcp. Pourtant aucun rapport de réception ne rejoint l'outil de supervision. Si l'équipe se contente du son, elle conclut que la session est saine. Si elle se contente du SDP, elle conclut que le contrôle est configuré. Dans les deux cas, elle transforme une indication locale en preuve d'un trajet qu'elle n'a pas observé.

RFC 3605, publié sur la Standards Track en octobre 2003, répondait à un problème délimité. SDP décrivait un port de base pour le média et les applications déduisaient les ports auxiliaires. Pour RTP, la convention plaçait RTCP sur le numéro impair immédiatement supérieur. La traduction de ports rendait cette arithmétique fragile: ordre et parité pouvaient disparaître. Avec un pool d'adresses, le NAT pouvait même exposer RTP et RTCP sous deux adresses publiques différentes.

La correction fut explicite: a=rtcp: porte un numéro de port et, si nécessaire, un type de réseau, un type d'adresse et une adresse de connexion. L'attribut appartient au niveau média; il ne doit pas être placé au niveau session. Grâce à lui, le correspondant n'est plus obligé d'inventer le port traduit en ajoutant un.

Mais «documenté» ne signifie pas «en service». La ligne peut provenir d'un générateur correct alors qu'aucun processus n'écoute. Elle peut être authentique alors que le pare-feu bloque les datagrammes. Elle peut contenir le mappage exact observé une minute plus tôt alors que l'état NAT a expiré. Elle peut être acceptée par le parseur mais ignorée par l'implémentation chargée d'émettre RTCP.

Ce dernier cas est inscrit dans le choix de conception. RFC 3605 a préféré un attribut à une modification de la ligne média. Une application ancienne qui ne comprend pas l'attribut l'ignore. Elle peut continuer à recevoir les paquets RTP et ne jamais envoyer RTCP au port indiqué. La compatibilité produit donc une dégradation partielle volontaire: le contenu peut survivre tandis que son canal de retour disparaît.

Une interface qui ne montre qu'un statut «appel établi» masque cette asymétrie. Elle confond au moins trois réalités: média entrant, contrôle sortant et rapport exploitable. Le premier ne prouve pas le deuxième; le deuxième ne prouve pas le troisième. Une période de son convenable ne démontre pas non plus que les mesures nécessaires à l'adaptation, au diagnostic ou à la synchronisation seront disponibles lorsque la situation se dégrade.

La découverte de l'adresse externe ajoute une autre limite. Le RFC décrit une procédure STUN: ouvrir les deux ports UDP, envoyer un message depuis chacun vers un serveur, puis récupérer les coordonnées externes vues par ce serveur. Le texte avertit aussitôt que la méthode suppose un NAT réutilisant la même traduction vers le futur correspondant SDP. Tous les équipements déployés n'offrent pas cette propriété.

Une réponse STUN est donc une observation datée, faite depuis un point précis. Elle ne promet pas le même mappage pour un autre destinataire. Elle ne réserve pas l'état dans le temps. Elle ne prouve pas qu'un retour empruntera le trajet inverse. Le dossier d'exploitation doit conserver le serveur observateur, l'heure, le tuple interne, le tuple externe, le pair visé et le délai entre observation et usage.

Il faut ensuite séparer émission et réception. Un compteur d'envoi atteste au mieux que l'application a remis des octets à la pile locale. Une capture sur l'interface émettrice ajoute un point de passage. Une capture en bordure distante établit l'arrivée à cette bordure. Le parseur RTCP doit encore associer le paquet à la bonne session et accepter sa structure. Sans ces étapes, «RTCP envoyé» reste une phrase trop grande pour son reçu.

Le rapport lui-même possède une portée limitée. RFC 3550 fait de RTCP un mécanisme de retour sur la réception, d'identification des participants, de synchronisation et de contrôle. Un rapport décrit des sources et un intervalle. Il ne certifie pas l'identité humaine du participant, l'exhaustivité de l'observation, la qualité ressentie dans les deux sens ou l'issue commerciale de la communication.

L'absence est encore plus difficile à interpréter. Elle peut venir d'un attribut inconnu, d'un port adjacent utilisé par erreur, d'un mappage périmé, d'un filtre, d'un ordonnancement RTCP qui n'a pas encore produit de rapport, d'un manque d'état de source ou d'une panne de collecte. Déclarer automatiquement «perte réseau» fabrique de faux diagnostics. Déclarer automatiquement «zéro défaut» fabrique une zone aveugle.

Les évolutions ultérieures n'autorisent pas davantage la compression. RFC 5761 permet de multiplexer RTP et RTCP sur un seul port. RFC 8859 classe rtcp comme attribut de transport dans son analyse du multiplexage, et le registre IANA continue de le référencer. Le mode à un port et le mode à ports séparés sont des résultats de négociation. Ils ne doivent pas être reconstruits après coup à partir d'une valeur par défaut.

RFC 5389 a aussi recentré STUN: c'est un outil, pas une solution complète de traversée NAT. Cette modestie est un principe d'audit. Chaque mécanisme fournit une pièce de preuve dans son périmètre. L'intégrité de la signalisation protège le contenu de la déclaration; elle ne rend pas le port joignable. L'ouverture du socket prouve un état local; elle ne traverse pas le réseau. L'arrivée d'un paquet ne prouve pas son ingestion dans l'analytique.

Une chaîne probante doit donc garder les transitions. Empreinte du SDP source; résultat du parseur; mode RTP/RTCP retenu; socket et processus propriétaire; observation du mappage avec heure et témoin; tuple annoncé; vérification d'intégrité; premier paquet sortant; première arrivée distante; premier paquet RTCP valide; premier rapport; intervalle couvert; règle d'analyse déclenchée; décision prise.

Cette granularité empêche un raccourci dangereux: prendre le silence de la base de données pour une mesure égale à zéro. Aucun rapport enregistré ne signifie pas que le réseau n'a perdu aucun paquet. Cela signifie seulement que le système de preuve n'a pas produit de rapport disponible, pour une cause encore ouverte.

RFC 3605 a rendu dicible une destination que le NAT avait dissociée du média. C'était une pièce minimale et utile de coordination. Le code en fonctionnement doit encore créer le socket, maintenir le mappage, livrer les paquets et conserver les reçus. La norme donne le langage; l'opérateur répond du trajet réel.