Resumen

  • El SSRC reunía los paquetes de un espacio de secuencia y tiempo, pero solo debía ser único dentro de una sesión RTP y podía cambiar.
  • Si un origen encontraba su propio SSRC en otro emisor, enviaba RTCP BYE para la cifra antigua, elegía otra al azar y verificaba que estuviera libre.
  • Una dirección distinta no distinguía por sí sola entre colisión, bucle, nueva asignación NAT, reinicio de traductor o movilidad; el CNAME aportaba contexto, no autenticación.

El adiós pertenecía al identificador

La palabra BYE parece definitiva. En la reparación de una colisión SSRC tenía un alcance más estrecho. El origen decía que una cifra dejaba de representar su espacio de sincronización; no afirmaba que la cámara, el micrófono o la aplicación hubieran abandonado la sesión para siempre.

El diseño viene de RFC 1889. Cada origen de sincronización llevaba un SSRC de 32 bits. Bajo esa clave, el receptor agrupaba secuencias, marcas de tiempo y estado de reproducción. La cifra se elegía al azar y aspiraba a ser única en una sesión RTP, sin depender de la dirección de red.

Así se evitó una autoridad central que asignara números antes de iniciar una conferencia. La contrapartida era explícita: dos fuentes podían acertar la misma cifra y toda implementación debía saber salir del conflicto.

La probabilidad no era una política de recuperación

RFC 3550 calculó el riesgo para explicar su escala. Mil fuentes que comienzan juntas producen una probabilidad aproximada de colisión de 10^-4; una nueva fuente que se une a mil valores ya únicos afronta alrededor de 2×10^-7. No son estadísticas de uso real.

La aleatoriedad exige trabajo. Una IP local puede repetirse detrás de varios dominios privados o en varias fuentes del mismo equipo. Un generador sin semilla adecuada puede entregar la misma serie a procesos que arrancan juntos. Escuchar antes del primer envío permite descartar un candidato que ya circula.

La norma no reemplazó el mecanismo por confianza matemática. Mantuvo ambas cosas: reducir el riesgo y preparar la reparación.

Retirar, volver a sortear y comprobar

Cuando un origen descubre que otro usa su SSRC, debe enviar RTCP BYE por el valor viejo. Después genera un nuevo candidato aleatorio y lo consulta en la tabla local de fuentes. Si ya está ocupado, repite el proceso.

El flujo puede continuar con el sustituto. RFC 7656 formalizó esta semántica años después: un flujo RTP tiene un solo SSRC en un momento concreto, pero puede cambiar de SSRC con el tiempo; una colisión justifica el cambio.

Por eso el SSRC no puede servir sin más como identidad de usuario. Una grabación que lo usa como clave permanente inventará dos participantes. Un sistema que interpreta BYE como expulsión puede cerrar una cuenta cuando el protocolo solo cerró un espacio de secuencia.

El receptor elegía tráfico, no al dueño del número

Si el conflicto ocurre entre dos terceros, el receptor puede conservar los paquetes de uno y descartar los del otro cuando las direcciones de transporte o los CNAME permiten diferenciarlos. Los dos orígenes deben resolver el choque.

La fuente vista primero suele conservar continuidad mientras llega BYE o vence el estado. Esa regla evita mezclar paquetes, pero no adjudica la cifra. El receptor no dispone de un registro de propiedad.

La tabla conserva por separado la primera dirección RTP y la primera dirección RTCP porque sus puertos UDP pueden ser distintos. Si un traductor oculta las direcciones originales, dos descripciones RTCP con un SSRC común y CNAME diferentes todavía pueden revelar el problema.

El mismo síntoma podía ser un paquete que regresaba

Un bucle también devuelve el mismo SSRC desde otra dirección. El primer paquete conflictivo no dice si hay dos fuentes o una sola reflexión.

RFC 3550 mantiene una lista temporal de direcciones conflictivas. Ante el propio SSRC, el participante cambia de cifra una vez y anota el camino. Si la misma reflexión persiste, la ignora. Volver a renombrarse por cada vuelta causaría una tormenta de BYE y dejaría que el bucle controlara al emisor.

Los mezcladores y traductores deben romper bucles. Sin embargo, RFC 7667 limita la visibilidad: el detector necesita que SSRC y CSRC sobrevivan correctamente. Las sesiones independientes y algunas topologías de conmutación rompen el espacio común, por lo que otra capa debe reconciliar el camino.

Cambiar de dirección no siempre significaba cambiar de fuente

La revisión de 2003 hizo opcional elegir otro SSRC al cambiar de dirección de transporte. Una aplicación móvil puede mantener legítimamente el mismo flujo mientras se mueve. El receptor puede aceptar la nueva dirección con una protección contra alternancias falsas.

Un traductor reiniciado que cambia de puerto puede hacer que todos los SSRC reenviados parezcan bucles. RFC 5135 muestra otro caso: si una asignación NAT cambia IP o puerto y conserva el SSRC, otros miembros ejecutan detección de colisión. El resultado puede contaminar diagnósticos y búferes de fluctuación.

La dirección es una prueba necesaria, no un veredicto sobre intención.

El CNAME preservaba una continuidad distinta

RFC 7022 explica que el SSRC puede cambiar tras colisión o reinicio mientras el CNAME RTCP permanece para asociar un endpoint y sincronizar flujos relacionados. Una aplicación puede mantenerlo entre sesiones para monitorización o renovarlo por sesión para reducir la correlación.

El CNAME tampoco certifica al hablante. Los participantes lo eligen y pueden imitar un valor ajeno. Sirve como vínculo operativo, no como credencial.

La señalización moderna no reserva todos los números. RFC 8834 mantiene obligatoria en WebRTC la asignación aleatoria y la resolución de RFC 3550. Dos extremos pueden estrenar el mismo valor antes de confirmar sus mensajes de señalización, y funciones como la retransmisión incorporan SSRC adicionales no anunciados previamente.

Fuentes y límites

RFC 1889 documenta el origen; RFC 3550, el algoritmo vigente. RFC 5135 acota NAT, RFC 7022 el CNAME, RFC 7656 la continuidad del flujo, RFC 7667 las topologías y RFC 8834 WebRTC. Ninguno demuestra frecuencia actual, cumplimiento de un producto, identidad humana, autenticidad del contenido ni éxito de reproducción.