Resumen
- El número de secuencia de RTP sigue los paquetes enviados; su marca de tiempo sitúa audio o vídeo en un reloj propio del formato. Ninguno demuestra por sí solo la hora absoluta de envío o recepción.
- Los flujos se llevan a una referencia común mediante informes RTCP que emparejan, de manera periódica, un valor RTP con otro en formato NTP. La correspondencia es la prueba que permite sincronizar.
El nombre del campo parece inequívoco, pero no lo es. En RFC 3550, la marca de tiempo de 32 bits refleja el instante de muestreo del primer octeto del medio. Si el emisor produce paquetes a intervalos regulares, debe usar el reloj nominal de muestreo, no consultar el reloj del sistema en el momento de transmitir.
RTP nació como trabajo colectivo de Henning Schulzrinne, Stephen Casner, Ron Frederick y Van Jacobson. RFC 1889 apareció en 1996 y RFC 3550 lo sustituyó en 2003. La Information Sciences Institute describe a Casner como líder del desarrollo y la normalización del protocolo. Esa responsabilidad es el hilo biográfico del artículo; no convierte un estándar de cuatro autores y una comunidad de trabajo en una invención individual.
El silencio también ocupa tiempo
Para audio de ritmo fijo, un bloque de 160 periodos de muestreo aumenta la marca en 160. El aumento ocurre aunque el bloque no se envíe porque solo contiene silencio. La ausencia de un paquete no elimina ese tramo de la experiencia que el receptor deberá reproducir.
El número de secuencia cuenta otra cosa. Sus 16 bits avanzan una unidad por cada paquete de datos enviado y permiten detectar huecos o recomponer el orden. Tanto su inicio como el de la marca temporal son aleatorios. Ninguno comienza necesariamente en cero ni funciona como número global de una llamada.
Una imagen de vídeo puede requerir varios paquetes. Todos reciben números de secuencia sucesivos, pero pueden compartir la misma marca porque pertenecen al mismo fotograma. También puede ocurrir lo contrario de lo que espera una gráfica ingenua: ciertos codificadores transmiten datos en orden distinto del orden de muestreo, por lo que las secuencias siguen subiendo mientras las marcas de tiempo consecutivas no lo hacen.
Así, dos síntomas aparentes dejan de ser pruebas. Una marca repetida no demuestra duplicación. Una marca que retrocede no demuestra que la red haya reordenado los paquetes. Para interpretar el rastro hay que conservar qué eje se está mirando: salida de paquetes o posición del medio.
La frecuencia del contador temporal depende del formato de carga. Convertirlo en segundos exige conocer esa frecuencia. Atribuirlo a un origen exige conservar el SSRC. Situarlo junto a otro flujo exige un puente adicional. Un entero desnudo pierde las tres cosas.
Los contadores de audio y vídeo no hablan el mismo idioma
Dos fuentes pueden capturar el mismo instante y producir valores RTP sin parecido. El audio y el vídeo suelen tener ritmos distintos y desplazamientos iniciales aleatorios e independientes. RFC 3550 dice expresamente que comparar de forma directa sus marcas no sirve para sincronizarlos.
La decisión ahorra una obligación innecesaria en cada paquete. Dentro de un flujo, el reloj del medio basta para ordenar la reproducción y calcular la variación de llegada frente al ritmo de muestreo. No hace falta incrustar una fecha civil absoluta en todos los datos ni exigir que todo emisor ejecute NTP.
Cuando sí hace falta alinear flujos aparece RTCP. Un Sender Report incluye una marca en formato NTP y una marca RTP que corresponden al mismo instante. Ese par define cómo proyectar el contador local sobre una referencia. Cada medio lleva su propio par y el receptor los relaciona a través de la referencia compartida.
El informe es poco frecuente frente al caudal de datos. El par no viaja en cada paquete RTP. Entre informes, la relación se extiende con la frecuencia conocida del contador. La marca RTP calculada para el informe normalmente no coincide con la de un paquete adyacente. Buscar esa igualdad como requisito sería confundir el instante del informe con el instante de una muestra.
La etiqueta NTP tampoco concede exactitud. RFC 3550 permite usar un reloj relativo común del sistema cuando no hay hora absoluta, y permite cero cuando el emisor no dispone ni de hora civil ni de tiempo transcurrido. El formato da una representación. El origen, la sincronización y la incertidumbre siguen siendo hechos aparte.
RFC 7273 volvió a precisar que el par NTP/RTP de un informe define un mapeo. Para reproducir a la vez dos fuentes, sus referencias deben estar alineadas por algún medio. El paquete de control conserva la relación; no fabrica la confianza en el reloj de referencia.
Un protocolo nacido de reconstruir continuidad
La carrera de Casner ayuda a leer esa arquitectura. La ISI relata sus primeros trabajos de voz por paquetes en ARPANET, donde una señal continua debía comprimirse, fragmentarse y reconstruirse con un ancho de banda mínimo. Después desarrolló vídeo por paquetes, participó en el MBONE y condujo la normalización de RTP. El memorial institucional enlaza RTP con Network Voice Protocol y Packet Video Protocol.
El problema nunca fue pegar una hora vistosa en cada paquete. Era suministrar las evidencias mínimas para que la aplicación recompusiera un medio continuo sobre una red que podía perder, retrasar o alterar el orden de llegada. Por eso RTP identifica tipo de carga y fuente, lleva secuencia y tiempo del medio, y añade informes de control.
El estándar no reserva recursos ni garantiza calidad de servicio. Su marco deja esas decisiones fuera. Incluso la revisión de 2003 conservó los formatos de paquete; su cambio principal fue mejorar el temporizador escalable de RTCP cuando muchos participantes entraban a una sesión. No se amplió el significado de la marca: se refinó la economía de los informes.
La captura debe guardar la relación, no solo el número
Un sistema de observabilidad útil archiva SSRC, tipo de carga, frecuencia de reloj, secuencia, marca RTP, hora de captura y los pares RTP/NTP cercanos. También registra si la referencia era absoluta, relativa o nula cuando esa información está disponible.
Con esos datos, cada indicio conserva sus límites. Un hueco de secuencia puede señalar pérdida. Una discontinuidad temporal puede acompañar un reinicio, un salto de presentación o un cambio de formato. Un informe demasiado antiguo aumenta la incertidumbre del mapeo. La deriva entre dos líneas ya proyectadas sobre la misma referencia puede revelar un problema real de sincronización.
Sin ellos, la herramienta llena huecos con supuestos. Divide toda marca por 90.000 aunque no sea el reloj aplicable; ordena por tiempo de muestreo lo que necesitaba ordenar por transmisión; compara dos desplazamientos aleatorios; presenta un valor con forma NTP como UTC confirmado.
La aportación que conserva el diseño de Casner es una disciplina de significado. Si un campo ofrece una prueba acotada, no hay que ensancharla por comodidad. Hay que guardar el recibo que permite conectar ese hecho con otro.
Fuentes
- RFC Editor — RFC 1889: RTP: A Transport Protocol for Real-Time Applications
- RFC Editor — RFC 3550: RTP: A Transport Protocol for Real-Time Applications
- RFC Editor — RFC 7273: RTP Clock Source Signalling
- RFC Editor — RFC 8088: How to Write an RTP Payload Format
- USC Information Sciences Institute — Premio IEEE 2020: Stephen Casner y Eve Schooler
- USC Information Sciences Institute — Informe anual de 2022
- IETF Datatracker — Stephen L. Casner
- 50.º aniversario de USC/ISI — Pioneers
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
