Introducción al Protocolo de Transporte en Tiempo Real (RTP)

A continuación, se distingue qué hace y qué no hace RTP.

🔹 Funcionalidades Clave de RTP (Lo que SÍ hace)

• Añade información temporal y de control a los datos multimedia:
  • Cada paquete tiene un número de secuencia para detectar pérdidas.
  • Una marca de tiempo (timestamp) para mantener el ritmo original.
  • Un identificador del códec usado.
  • Puede incluir informes de calidad vía RTCP.
• RTP se monta encima de UDP, porque UDP es rápido y tolera pérdidas.
• RTP puede enviar datos a varios receptores a la vez (multicast), ideal para videoconferencias.

🔸 Limitaciones de RTP (Lo que NO hace)

• No asegura que los paquetes lleguen (ni en orden ni sin pérdidas).
• No gestiona la congestión ni garantiza un ancho de banda.

Filosofía de Diseño de RTP

La filosofía de diseño de RTP se basa en la flexibilidad y la descentralización:

• No hay un control central ni reglas rígidas sobre cómo reaccionar a errores: cada aplicación decide qué hacer si se pierde un paquete (ejemplo: Skype puede interpolar el audio, Zoom puede congelar la imagen).
• Se busca que RTP sea flexible (o «maleable»): cada aplicación toma de RTP lo que necesita.
• RTP no es un nivel independiente como TCP o IP: se implementa directamente dentro de la lógica de la aplicación multimedia.
• La arquitectura se adapta bien al multicast (varios receptores escuchando un mismo flujo, como una clase online).

Problema Técnico 1: Mitigación del Jitter

El primer problema técnico real que RTP intenta resolver es el Jitter.

• Jitter = variación del retardo entre paquetes.
• Solución mediante RTP:

1. Cada paquete tiene:
   • Un número de secuencia (para saber si falta alguno).
   • Una marca de tiempo (timestamp) (para reproducir en el momento exacto).

El receptor mantiene un buffer que almacena varios paquetes antes de empezar a reproducir (para compensar los retrasos).

Si un paquete llega demasiado tarde, se descarta, porque retrasaría el flujo total.

👉 En resumen: RTP ayuda a mantener la fluidez en la reproducción sin garantizar que los paquetes lleguen puntuales, sino proporcionando herramientas para reconstruir el flujo temporal y mitigar los efectos del jitter.

Problema Técnico 2: La Pérdida de Paquetes

Otro problema clave es la pérdida de paquetes.

Cuando la red está congestionada, los routers o buffers pueden descartar paquetes para liberar espacio.

• Por eso, las pérdidas se gestionan a nivel de aplicación, con diferentes estrategias:
  • Interpolar → estimar lo perdido a partir de lo anterior.
  • Rellenar con silencio o ruido blanco → para evitar huecos perceptibles.
  • Usar redundancia → enviar parte de la información duplicada o comprimida.
  • En algunos casos, pedir retransmisión puntual (por ejemplo, en streaming con algo de retraso permitido).

RTP no garantiza que no haya pérdidas, pero da la información necesaria (números de secuencia, timestamps) para que la aplicación sepa cuándo y qué se ha perdido y decida cómo reaccionar.

La Sesión RTP

• Una sesión RTP agrupa a todos los participantes que están intercambiando un tipo de flujo multimedia (por ejemplo, audio).

RTP no establece las sesiones; eso lo hace otro protocolo, como SIP (Session Initiation Protocol), que negocia qué direcciones y puertos se usarán.

• En una videollamada, puede haber dos sesiones RTP:
  • Una para audio.
  • Otra para vídeo.

Definición de una Sesión RTP

Cada sesión está definida por:

Modos de Transmisión: Unicast y Multicast

Sesión Unicast

En una sesión unicast, cada comunicación es directa entre dos equipos.

• Cada participante envía su flujo RTP (audio) y RTCP (control) a cada uno de los otros.
• Esto significa que cada par de equipos mantiene una conexión punto a punto, como si fueran tres llamadas individuales.
• En una llamada de voz entre tres personas sin multicast, cada una envía dos flujos de audio: uno a cada interlocutor.
• Esto consume más ancho de banda, pero garantiza compatibilidad, porque el unicast es universal (todos los routers lo soportan).

Sesión Multicast (Alternativa Eficiente)

La alternativa más eficiente es el multicast.

• En vez de enviar un flujo a cada participante, todos los participantes se unen a una misma dirección multicast (224.10.10.15).
• Cada flujo RTP que se envía a esa dirección es recibido por todos los miembros del grupo.
• Esto reduce drásticamente el tráfico, ya que cada fuente envía solo una copia de su flujo.

Ejemplo Práctico: Conferencia de Audio Multicast

Aquí se muestra un ejemplo real de cómo funciona RTP en una conferencia de audio.

1. Los cuatro usuarios (A, B, C y D) forman parte de una misma sesión multicast.
   • Dirección multicast: 224.10.10.15
   • Puertos: RTP = 5004, RTCP = 5005.
2. Cada usuario:
   • Muestrea su voz (por ejemplo, 8.000 veces por segundo en PCM).
   • Comprime los datos (para reducir el tamaño).
   • Encapsula los fragmentos de audio dentro de paquetes RTP.
   • Envía esos paquetes a la dirección multicast, donde todos los demás los reciben.

En la cabecera de cada paquete RTP vienen:

• El tipo de codificación (para saber qué códec usar al reproducir).
• Un número de secuencia, que permite detectar pérdidas.
• Una marca de tiempo (timestamp), que permite mantener el ritmo del habla.

Gestión de Audio y Vídeo Simultáneos

A continuación, se explica cómo RTP maneja audio y vídeo al mismo tiempo.

🔹 Dos Sesiones RTP Independientes

En una videoconferencia RTP siempre hay al menos dos flujos RTP paralelos (uno de audio y otro de vídeo), cada uno con su propio par de puertos y su propio grupo multicast.

Por qué dos sesiones separadas:

• El ritmo y el ancho de banda del audio y del vídeo son distintos.
• Mantenerlos separados permite que cada uno tenga su propio reloj, frecuencia y control de calidad (RTCP).
• RTCP ayuda a sincronizarlos en el receptor.

Ejemplo de configuración:

• Una sesión de audio
  • IP: 224.10.10.15
  • RTP: 5004
  • RTCP: 5005
• Otra sesión de vídeo
  • IP: 224.10.10.20
  • RTP: 5014
  • RTCP: 5015

Cada tipo de medio (audio y vídeo) tiene su propia sesión RTP, aunque ambas pertenecen a la misma conferencia multimedia.

Sincronización de Audio y Vídeo con RTCP

A continuación, se detalla cómo se sincronizan el audio y el vídeo en el receptor.

🔹 Flujos Recibidos:

Cada equipo recibe:

• Un flujo RTP de audio (IP: 224.10.10.15).
• Un flujo RTP de vídeo (IP: 224.10.10.20).

Ambos llegan por separado, pero deben reproducirse al mismo tiempo para mantener la sincronía entre la voz y los labios del hablante.

🔸 Sincronización con RTCP:

• RTP no puede sincronizarse solo, porque los relojes locales de cada flujo (audio y vídeo) son distintos.
• Para resolverlo, los paquetes RTCP (el protocolo complementario de control) transportan información de tiempo absoluta (basada en NTP, Network Time Protocol).
• El receptor usa esa información para alinear las marcas de tiempo RTP de ambos flujos y reproducirlos sincronizados.

Estructura del Paquete RTP

Esta sección muestra cómo está formado un paquete RTP.

📦 Estructura de un paquete en la red:

[Física] → [IP] → [UDP] → [RTP] → [Datos (Payload)]

• IP y UDP se encargan de llevar el paquete hasta su destino.
• RTP añade información específica para los datos en tiempo real (sincronización, numeración, identificación…).
• Payload es el contenido: audio, vídeo o lo que se esté transmitiendo.

RTP añade una pequeña cabecera (12 bytes mínimos) con metadatos que permiten mantener el flujo ordenado y sincronizado.

RTP no es rígido: su diseño es extensible mediante perfiles.

🔹 Perfiles RTP

Un perfil define cómo se adapta RTP a un tipo concreto de aplicación o medio.

🔸 Por qué se usan perfiles:

• No todas las aplicaciones tienen las mismas necesidades.
  • En vídeo: el bit M puede marcar el final de una trama.
  • En voz: puede marcar un cambio de hablante.
• Los perfiles permiten que RTP sea modular y personalizable.

👉 En resumen: La cabecera básica de RTP (RFC 3550) es el esqueleto, y los perfiles (como RFC 3551) son las adaptaciones específicas para cada tipo de uso.

Relays RTP: Mezcladores y Traductores

Un relay RTP es un nodo intermedio (como un servidor) entre los emisores y receptores.

🔹 Qué hace un relay:

• Recibe paquetes RTP de varios emisores.
• Los procesa, transforma o combina.
• Los vuelve a enviar a otros destinos.

🔸 Dos Tipos Principales de Relays:

1. Mezclador (Mixer):
   • Combina varios flujos en uno solo.
   • Crea un nuevo flujo RTP con su propio SSRC.
   • Inserta en la cabecera los CSRCs (identificadores de las fuentes que ha mezclado).
   • Puede modificar timestamps (p. ej., al sincronizar voces).

   🔹 Ventaja del Mezclador:

   Los clientes receptores no tienen que procesar ni mezclar varios audios, lo que reduce la carga y el tráfico.

   🔹 Inconveniente del Mezclador:

   Pierden información individual (ya no saben quién dijo cada cosa, a menos que el mezclador lo indique de otra forma).

   Aquí se ilustra un caso más complejo: mezcladores en cascada.

   🔹 Situación:

   • En redes grandes (por ejemplo, videoconferencias internacionales), puede haber varios mezcladores conectados entre sí.

   

2. Traductor (Translator):

   El traductor (translator) es otro tipo de relay, pero no mezcla flujos, sino que los adapta o transforma.

   🔸 Funciones posibles:

   • Convertir formatos: Pasar de un códec pesado (por ejemplo, H.264) a otro más ligero (como VP8), para adaptarse al receptor.
   • Reducir calidad: Bajar resolución o tasa de bits si el receptor tiene poca red.
   • Cambiar direcciones: Reenviar paquetes de una red a otra (por ejemplo, unicast ↔ multicast).
   • Atravesar firewalls: Encapsular RTP dentro de otro protocolo (VPN, túnel seguro…).

Diferencia clave con el mezclador:

• El traductor mantiene el mismo SSRC (porque el flujo sigue siendo del mismo origen).
• El mezclador crea un SSRC nuevo (porque genera un flujo nuevo).

RTP y la Congestión de Red

A continuación, se explica cómo RTP afronta la congestión de red.

🔹 Por qué es diferente:

• RTP transporta datos en tiempo real (voz, vídeo).
• No puede reducir el ritmo drásticamente ni retransmitir paquetes, como hace TCP.
• Por tanto, sus mecanismos deben ser más suaves y adaptativos.

🔸 Dos Estrategias Principales:

1. Prevención por ingeniería:
   • Usar redes dedicadas o sobredimensionadas, donde la congestión es mínima (por ejemplo, dentro de una empresa).
2. Adaptación dinámica:
   • Usar la información que llega a través de RTCP (los reportes de recepción):
     • Si los reportes indican pérdidas o jitter altos, la aplicación puede:
       • Reducir la resolución del vídeo.
       • Bajar el bitrate.
       • Enviar menos frames por segundo.

👉 Resumen: El control de congestión en RTP no lo hace el protocolo directamente, sino la aplicación mediante los datos que recibe de RTCP.

RTCP: RTP Control Protocol

🎯 Idea General

RTCP acompaña a RTP.

Mientras RTP transporta los datos multimedia (audio, vídeo…), RTCP envía paquetes de control periódicos entre todos los participantes.

🔧 ¿Para qué sirve RTCP?

1. Monitorear la calidad de la transmisión:
   • Los receptores envían informes con:
     • Cuántos paquetes han recibido correctamente.
     • Cuántos se han perdido.
     • Cuánto jitter o variación de retardo hay.
   • Esto permite detectar congestión o problemas de red y adaptar la calidad.
2. Identificar las fuentes (CNAME):
   • Cada participante tiene un nombre canónico (CNAME) textual, para poder asociar varios flujos del mismo usuario (ejemplo: su audio y su vídeo).
3. Controlar la tasa de RTCP:
   • Evita saturar la red con mensajes de control. (RTCP debe usar menos del 5% del ancho de banda total de la sesión).
4. Control de sesión mínimo:
   • Permite saber cuántos usuarios hay.
   • Detectar quién abandona la sesión (BYE).
   • Mantener coherencia entre participantes.

Envío de Paquetes RTCP

En la práctica, RTCP no envía un paquete individual por cada tipo, sino que agrupa varios en un único paquete compuesto.

🧩 Reglas de Composición:

1. Siempre debe incluir un SR (Sender Report) o RR (Receiver Report).
   • Si no hay tráfico (por ejemplo, aún no se ha enviado nada), se manda igualmente, pero con todos los valores a 0.
2. Puede incluir varios RR adicionales si hay más de 31 fuentes a reportar.
3. Siempre debe incluir un SDES, con al menos un CNAME.
4. Otros tipos (APP, BYE, etc.) pueden añadirse después.
   • El BYE debe ir al final, indicando salida de la sesión (opcionalmente con texto explicativo, como «user left the call»).

📦 Ejemplo de orden de un paquete compuesto:

[SR] + [RR opcionales] + [SDES] + [APP] + [BYE]

💬 Así se optimiza la comunicación: menos cabeceras, menos ancho de banda y control sincronizado.

Frecuencia de Envío de RTCP

RTCP no puede enviarse continuamente, porque ocuparía demasiado ancho de banda.

📉 Reglas Básicas:

• No enviar demasiado a menudo, ya que podría robar ancho de banda al flujo RTP (el de datos reales).
• No enviar muy poco, porque entonces no se detectan a tiempo las pérdidas o retrasos.

⚙️ Según el RFC 3550:

• Se usa un algoritmo adaptativo para ajustar la frecuencia.
• Se garantiza que RTCP usa menos del 5 % del tráfico total de la sesión.
• La frecuencia se ajusta según:
  • Número de participantes (a más usuarios, menos frecuencia por cada uno).
  • Ancho de banda disponible.

🕓 Detalles:

• Los intervalos de envío se aleatorizan (no todos mandan a la vez → evita acoples).
• El mínimo intervalo recomendado entre paquetes es de 5 segundos.

🧠 En resumen: RTCP se comporta como un sistema de control distribuido y autorregulado. Cada nodo sabe cuánto puede enviar, calcula su turno y lo hace sin saturar la red.

Detalle de la Cabecera RTP

La cabecera RTP contiene:

Identificadores de Fuente

Estos identificadores sirven para saber quién genera cada flujo de datos.

Campos de Control General

Campos de Ordenación y Sincronización

Estos campos sirven para identificar y ordenar los paquetes multimedia.

• Si llegan los paquetes con secuencia 101, 102, 104 → el receptor deduce que el 103 se perdió.
• Si el códec es PCM, el campo «Payload Type» tendrá valor 0 (según la tabla de RFC 3551).

El número de secuencia no se reinicia en cada conversación, sino que empieza en un número aleatorio para evitar confusiones entre flujos antiguos y nuevos.

El Campo Timestamp (Marca de Tiempo)

El timestamp (marca de tiempo) es uno de los campos más importantes de RTP.

Sirve para reproducir el flujo en su ritmo original.

🔹 Cómo funciona:

• Cada paquete RTP lleva un timestamp que indica cuándo se generó el primer dato del paquete.
• No mide tiempo real (como un reloj), sino tiempo relativo dentro del flujo multimedia.

🔸 Ejemplo en audio PCM:

• Si el códec es PCM (8000 muestras por segundo):
  • Paquete 1: timestamp = 0
  • Paquete 2: timestamp = 160 muestras (porque contiene 20 ms → 0.02 s × 8000 muestras/s = 160)
  • Paquete 3: timestamp = 320
• Así el receptor puede reproducir los datos a intervalos regulares aunque los paquetes lleguen con retrasos o desorden.

🔸 Usos adicionales:

• Permite sincronizar distintos flujos (audio y vídeo).
• Se usa en el cálculo del jitter, para medir variaciones de retardo.

💡 Clave: Solo importan las diferencias entre timestamps, no el valor inicial (que es aleatorio).

Tipos de Paquetes RTCP

🔸 Los SR y RR son los más importantes, porque contienen los parámetros de calidad (pérdidas, retardo, sincronización).

Receiver Report (RR)

Este paquete lo envía un receptor (que no emite datos RTP o lo hace esporádicamente).

Campos de la Cabecera RTCP RR

Bloque de Reporte de Recepción

Cada bloque corresponde a una fuente RTP distinta que el receptor está monitorizando.

Contiene:

👉 Estos datos permiten calcular tasa de pérdida, rendimiento y calidad de red.

RTCP y Jitter

🧩 Qué es el Jitter

Es la variación del retardo entre la llegada de los paquetes RTP.

• Afecta directamente a la calidad de audio/vídeo.

🧮 Cómo se calcula

• S(i): timestamp del envío (en la fuente).
• R(i): instante de llegada (en el receptor).
• D(i): diferencia de retardo entre paquetes consecutivos.

• Si no hay variación, ( D(i) = 0 ).
• Luego, se calcula una media exponencial:

🔸 Un alto jitter indica congestión transitoria → si no se corrige, se pierden paquetes o hay saltos en la reproducción.

RTCP y Round Trip Time (RTT)

Sirve para calcular el tiempo de ida y vuelta (RTT) entre dos nodos (fuente j y receptor k).

1. j envía un Sender Report (SR) con una marca de tiempo absoluta (NTP).
2. k, al recibirlo, espera un poco y envía un Receiver Report (RR) que incluye:
   • LSR (Last Sender Report): timestamp del SR recibido.
   • DLSR (Delay since Last SR): tiempo desde que lo recibió hasta que envió su RR.
3. Cuando j recibe ese RR, puede calcular:

🔹 Esto da una medida del retardo de ida y vuelta, útil para diagnosticar congestión o latencia.

RTCP Sender Report (SR)

El SR (Sender Report) lo envían las fuentes que están transmitiendo paquetes RTP.

RTCP SDES (Source Description)

SDES (Source Description) es un tipo de paquete RTCP que identifica quién es cada fuente RTP.

Mientras los paquetes RTP llevan solo identificadores numéricos (SSRC, CSRC), el SDES traduce esos números a información humana legible: nombres, correos, herramientas, etc.

• V=2: versión de RTCP.
• P: padding si hay bytes de relleno.
• SC: «Source Count», número de fuentes descritas.
• Tipo = 202: identifica que es un paquete SDES.
• Longitud: tamaño total del paquete.

Luego, para cada fuente (SSRC o CSRC), vienen una serie de SDES Items, que son las etiquetas con la información textual (nombre, email, etc.).

👉 En resumen: SDES vincula el número SSRC con datos del usuario o la aplicación que los está generando.

Tipos de Ítems SDES

Cada ítem SDES tiene esta estructura:

🔢 Tipos Definidos (según RFC 3550)