Résumé

  • Le SSRC regroupait les paquets d'un même espace de temps et de séquence, mais il ne constituait qu'un identifiant aléatoire dans une session RTP.
  • Quand une source découvrait son propre SSRC chez une autre, elle envoyait RTCP BYE pour l'ancienne valeur, choisissait un candidat libre et poursuivait le flux.
  • Une adresse différente pouvait signaler une collision, une boucle, un changement de NAT, un redémarrage de relais ou une mobilité ; le CNAME ajoutait de la continuité sans authentifier un propriétaire.

Le récepteur devait d'abord protéger une histoire cohérente

Dans RTP, le SSRC n'est pas un simple champ décoratif. Le récepteur l'utilise pour réunir les numéros de séquence, les horodatages, les statistiques RTCP et l'état de lecture d'une source de synchronisation. Deux origines sous la même valeur peuvent donc mêler des rythmes et des pertes qui n'ont jamais appartenu au même flux.

RFC 1889, publié en 1996, avait choisi un espace de 32 bits indépendant de l'adresse réseau. Cette indépendance convenait aux conférences multicast, aux mélangeurs et aux traducteurs. Elle évitait un registre central, mais obligeait chaque émetteur à tirer une valeur aléatoire censée être unique dans la session RTP concernée.

La faible probabilité n'était pas une garantie. Dès la première norme, la résolution de collision faisait partie du fonctionnement obligatoire.

Le hasard avait une discipline

RFC 3550 donne deux ordres de grandeur. Pour mille sources démarrant ensemble, son modèle estime à environ 10^-4 la probabilité qu'au moins deux choisissent la même valeur. Une nouvelle source face à mille valeurs déjà distinctes rencontre environ 2×10^-7. Ces nombres décrivent le modèle mathématique, pas des incidents observés.

Une adresse IP locale ne suffit pas : plusieurs espaces privés peuvent se rencontrer derrière un traducteur, et plusieurs sources vivent sur le même hôte. Un générateur pseudo-aléatoire mal initialisé peut reproduire la même suite lors de démarrages simultanés. Une source prudente écoute la session avant son premier envoi et recommence son tirage si la valeur existe déjà.

Le protocole n'a donc pas cherché le nombre parfait. Il a combiné une bonne allocation avec une procédure de sortie.

BYE fermait un nom, pas nécessairement la conversation

Lorsqu'une source voit qu'une autre utilise son propre SSRC, elle doit émettre un paquet RTCP BYE pour l'ancien identifiant, puis choisir une nouvelle valeur aléatoire. Avant de l'adopter, elle consulte sa table des sources ; une valeur déjà présente impose un nouveau tirage.

L'ambiguïté du mot « goodbye » est essentielle. La source physique ou logique peut rester active. C'est son ancien espace de synchronisation qui prend fin. RFC 7656 résume cette continuité : un flux RTP possède un seul SSRC à un instant donné, mais ce SSRC peut changer, notamment après une collision.

Un lecteur qui confond le numéro avec une personne verra un faux départ et une fausse arrivée. Un enregistreur qui utilise le SSRC comme clé éternelle séparera une seule intervention en deux biographies. Le protocole, lui, n'accorde jamais cette permanence au champ.

Le premier chemin pouvait être conservé sans devenir propriétaire

Un récepteur peut aussi découvrir la collision de deux autres sources. RFC 3550 l'autorise à conserver les paquets de l'une et à rejeter ceux de l'autre quand leurs adresses de transport ou leurs CNAME diffèrent. Les émetteurs sont censés régler eux-mêmes la collision.

Cette préférence est opérationnelle. Le premier paquet admis obtient souvent la continuité temporaire, mais pas un titre de propriété. Après le BYE ou l'expiration d'état, le résultat peut changer.

La table nécessaire dépasse le couple SSRC-valeur. RTP et RTCP peuvent partir de ports UDP différents ; l'algorithme mémorise donc séparément leur première adresse de transport. Au-delà d'un mélangeur, deux chunks SDES utilisant le même SSRC avec des CNAME distincts peuvent révéler ce que l'adresse commune masquait.

Une collision et une boucle présentaient la même silhouette

Le même SSRC reçu d'une autre adresse peut être un second émetteur ou le retour d'un paquet à travers une boucle. La première observation ne tranche pas.

RTP conserve alors une liste temporaire des adresses conflictuelles. Si le conflit touche le SSRC local, la source change une fois de numéro et enregistre l'adresse. Si le même retour continue, elle l'ignore au lieu d'envoyer une succession de BYE et de se renommer sans fin. Cette mémoire borne la réaction.

Les mélangeurs et traducteurs doivent casser les boucles qu'ils peuvent créer. Mais RFC 7667 montre que la détection dépend d'un espace SSRC/CSRC correctement préservé. Des sessions indépendantes dos à dos et certaines topologies de commutation détruisent cette visibilité ; une couche supérieure doit alors reprendre l'autorité.

Le réseau pouvait fabriquer un faux conflit

RFC 3550 a assoupli la règle de 1996 sur le changement d'adresse. Dans une application mobile, le même flux peut légitimement poursuivre sous le même SSRC depuis une nouvelle adresse ; le récepteur peut accepter ce déplacement tout en empêchant des bascules répétées entre deux prétendants.

Un traducteur redémarré peut changer de port UDP et faire paraître bouclées toutes les sources qu'il relaie. RFC 5135 ajoute le NAT : une nouvelle association d'adresse ou de port avec le même SSRC déclenche la détection de collision et peut perturber les diagnostics ou la mémoire tampon de gigue.

« Collision SSRC » nomme donc un symptôme protocolaire. Il ne prouve ni attaque, ni duplication volontaire, ni identité du composant fautif.

Le CNAME gardait une autre forme de continuité

RFC 7022 distingue clairement les deux axes. Le SSRC peut changer après collision ou redémarrage ; le CNAME RTCP reste suffisamment stable pour associer un endpoint et les flux qui doivent être synchronisés. Une application peut choisir une persistance longue pour le suivi ou un CNAME par session pour limiter la corrélation.

Cette stabilité n'est pas une authentification. Un participant choisit son CNAME et peut imiter celui d'un autre. Le champ aide à rapprocher des observations ; il ne certifie pas un utilisateur, une entreprise ou un droit de parole.

Même un système signalé conserve le problème. RFC 8834 exige des endpoints WebRTC qu'ils prennent en charge l'allocation aléatoire et la résolution RFC 3550. Deux pairs peuvent employer une nouvelle valeur avant l'accusé de signalisation, et des fonctions auxiliaires comme la retransmission introduisent parfois des SSRC non annoncés.

Sources et limites

L'origine historique se trouve dans RFC 1889 et l'algorithme mûr dans RFC 3550. Les effets du NAT sont décrits par RFC 5135, le CNAME par RFC 7022, la terminologie des flux par RFC 7656, les topologies par RFC 7667 et WebRTC par RFC 8834. Ces textes ne mesurent pas les collisions actuelles, ne valident aucun produit et ne prouvent pas l'identité réelle derrière un flux.