Vídeo y Televisión

Protocolos de Streaming IP
RTP , RTCP y RTSP

Francisco José de la Torre Barreiro

30 de junio de 2021
Índice

1. Resumen 3

2. Introducción 3

3. Protocolos: 3

3.1. RTP: Real-Time Transport Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.1.1. Sesión RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1.2. Paquetes RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1.3. Perfil RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2.1. Funcionalidades básicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2.2. Paquetes RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.3. RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4. Conclusión: 15

5. Referencias 16

Índice de figuras

1. Esquema pila TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Sesiones RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3. Cabecera Paquete RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4. Encapsulamiento RTP/UDP/IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

5. Paquete Sender Report (SR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

6. Paquete Receiver Report (RR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

7. Paquete Extended Reports (XR)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

8. Report Blocks de los Paquetes RTCP XR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

9. Paquete SDES One Byte-Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

10. Paquete SDES Two Byte-Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1
11. Goodbye RTCP Packets (BYE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

12. Application -Defined RTCP Packets (APP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

13. Esquema funcionamiento general RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

14. Métodos RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2
1. Resumen

A lo largo de este informe se describirá el funcionamiento del Real Time Transport Protocol (RTP) y de
sus cabeceras (Real Time Control Protocol - RTCP ) .
También se hablará más adelante sobre el Real Time Streaming Protocol ( RTSP), protocolo a nivel de
aplicación que facilita el control de flujos multimedia.

2. Introducción

La motivación principal de la creación de estos protocolos es la transmisión de datos multimedia sobre Internet
( la cual no ofrece garantías de Calidad de Servicio (QoS) ) y que inicialmente se creó para el transporte de datos
textuales . Internet , como una red que comparte datagramas no es lo mejor para tráfico a tiempo real.
Estos estándares surgen a raíz de dar cabida a esa necesidad de mejora del tráfico multimedia.

El protocolo RTP tiene 2 partes:

1) RTP : utilizado para el transporte de datos.
2) RTCP: utilizado para el transporte de la información de control.

3. Protocolos:

3.1. RTP: Real-Time Transport Protocol

Protocolo definido por el IETF (Internet Engineering Task Force) inicialmente en el RFC 1889
( Enero , 1996 ) y cuya edición en vigor es la RFC 3550 ( Julio , 2003).
El objetivo fundamental es transportar flujos multimedia sobre redes IP.
No proporciona mecanismos para garantizar las entregas ni para recuperar errores , la red subyacente será la en-
cargada de hacerlo.
A nivel de transporte suele usar el protocolo UDP , cuyas diferencias fundamentales con TCP (el otro protocolo de
transporte más utilizado) son:

TCP(Transmission Control Protocol) : orientado a conexión, fiable, secuencial y con control de flujo y conges-
tión .

UDP(User Datagram Protocol): sin conexión, sin garantías e insensible a congestión (además admite mensajes
de difusión y multidifusión).

UDP es el protocolo escogido mayoritariamente para el transporte de RTP por 2 razones fundamentalmente:
1) RTP está diseñado principalmente para la multidifusión.
2) La fiabilidad de los datos en tiempo real no es tan importante como entregarlos a tiempo.

Por estas y algunas otras razones relacionadas , RTP envía sobre UDP y emplea servicios UDP (como las compro-
baciones de checksums y el multiplexado de flujos).

3
 A continuación se muestra un esquema de la localización de RTP en la pila TCP/IP:

(a)

Figura 1: Esquema pila TCP/IP

Aunque lo más común es su uso en UDP/IP , RTP es neutral , lo que permite utilizarse en ADSL,redes de
satélite , ...
Es flexible y escalable (tiene instancias para formatos comunes como MPEG , H261 , wav ... y permite unicast y
multicast)
En los aspectos de seguridad en RFC 3711 se define el Secure Real-Time Transport Protocol (SRTP , 2004),
también flexible en el diseño pues incorpora de forma fácil nuevos algoritmos de encriptación .
SRTP emplea el AES(Advanced Encryption Standard)como mecanismo de encriptación predeterminado ,
basado en cifrado por bloques.
Con SRTP , todas las funcionalidades son opcionales y pueden ser activadas y desactivadas de forma individual , a
excepción de la funcionalidad de mensaje de autenticación que es obligatoria.
También existe el SRTCP , que proporciona las mismas características de seguridad que proporciona SRTP a RTP.

4
3.1.1. Sesión RTP

Los datos multimedia en RTP se dividen en transmisiones de diferentes flujos de datos , cada uno de ellos usando
una sesión RTP.
La transmisión de datos en una sesión RTP será unidireccional (emisor-receptor), pero en cada una de ellas habrá
una comunicación bidireccional a través de RTCP (el cual se explicará más adelante) y también una sincronización
Inter-Flujo.
Para la correcta recepción de los flujos , estos serán numerados para , por ejemplo en vídeo , ser reproducidos en el
orden oportuno.
En cuanto a los puertos que utilizan en las sesiones , la comunicación RTP se suele hacer a través de un puerto con
número par y la RTCP a través del impar consecutivo.

(a)

Figura 2: Sesiones RTP

5
3.1.2. Paquetes RTP

La estructura estándar de un paquete RTP incluye ,aparte de otro tipo de información:

Payload Type:de qué tipo son los datos del streaming y a que flujo pertenencen.
Numeración de paquetes:para ordenar los datos y también detectar pérdidas.
Timestamps:para compensar la fluctuación del retardode la red al entregar paquetes.
Las cabeceras de los paquetes RTP siguen el siguiente formato :

(a)

Figura 3: Cabecera Paquete RTP

Campos de la cabecera del paquete RTP: (en orden de aparición)

-Bits V(2bits): versión RTP , actualmente la 2.
-Bits de relleno(1bit): su activación indica byte/s adicionales al final de la carga útil.
-Bit de extensión(1bit): si se activa la cabecera irá seguida por una cabecera de extensión.
-Contador de CSRC (4bits): número de ids SSRC después de la cabecera .
-Bit M (1bit): para señalizar eventos de importancia como el primer paquete de un determinado flujo.
-Payload type(7bits): indica el formato de carga útil RTP (p.e. : 31 –>H.261 , 34–>H.263, 3 –>GSM, ...)
-Número de secuencia (2bytes): identifica cada paquete RTP, se va incrementando en una unidad.
-Timestamp(4 bytes): indica el instante de muestreo del primer octeto del paquete RTP.
-SSRC: id de la fuente.
-Lista CSRC: lista de 16 items con 4 bytes cada uno que identifican las fuentes que contribuyen en la carga útil del
paquete RTP.

En la siguiente figura se muestra el encapsulamiento RTP , una vez creada la cabecera RTP , sobre UDP e
IPv4:

(a)

Figura 4: Encapsulamiento RTP/UDP/IPv4

6
3.1.3. Perfil RTP

Desde el principio , el diseño RTP se vio condicionado en que debía transportar una gran cantidad de formatos
multimedia y que se pudiesen añadir nuevos formatos.
Para ello , RTP está diseñado sobre el principio de application level flaming , para ser fácilmente modificable.
Las necesidades específicas de cada aplicación se indican mediante los perfiles y formatos de carga útil.
En el perfil se especifica el formato de RTP para una aplicación en concreto. Por ejemplo:
-RFC 3640, RTP Payload Format for Transport of MPEG-4 Elementary Streams. https://datatracker.ietf.
org/doc/rfc3640/
-RFC 6184 , RTP Payload Format for Transport of H.264 Video.https://datatracker.ietf.org/doc/html/
rfc6184

3.2. RTCP

El RTCP (RTP Control Protocol) está definido, como RTP, en el RFC 1889 y RFC 3550 .
Se emplea para enviar datos de control entre emisor y receptor de una secuencia RTP.
RTP basa su funcionamiento en la transmisión periódica de paquetes de control a todos los participantes dentro de
la sesión , al puerto inmediatamente siguiente al que se manda los paquetes RTP.

3.2.1. Funcionalidades básicas

1. Informe de la calidad de distribución : a través de los informes de control RTCP.

2. Identificación de cada fuente RTCP : el CNAME (Canonical Name).Normalmente se utiliza en RTP un id

de fuente (SSRC) que se obtiene de forma aleatoria y que puede cambiar al reiniciar las aplicaciones.
El CNAME asocia múltiples flujos de datos que provengan del mismo participante de sesiones RTP relacionadas.

3. Control de ancho de banda: el objetivo es evitar la congestión .

Se recomienda que el ancho de banda utilizado por RTCP sea <= 5 % del total.
Del ancho de banda asignado para RTCP el 25 % se reserva para fuentes y 75 % para receptores (del 5 % , 1,25 %
fuentes y 3,75 % receptores).
También se recomienda que el período de envío de paquetes RTCP mínimo sea de 5 segundos.

4.Transporte de información para el control de la sesión: para identificar a los usuarios.

7
3.2.2. Paquetes RTCP

Los paquetes RTCP deben enviarse en paquetes compuestos que se encapsulan sobre UDP y que contienen al
menos 2 paquetes RTCP individuales , de los cuales el primero es un SR o un RR. Los paquetes RTCP se envían
cada 5 segundos aproximadamente.
Los tipos de paquetes empleados en RTCP son 6 :

1. Paquete Sender Report (SR): envío periódico a los participantes activos para información de transmi-
sión (y recepción si son receptores también) para todos los paquetes durante la sesión.
El SR tiene la siguiente estructura:

(a)

Figura 5: Paquete Sender Report (SR)

Este paquete se divide en 4 partes: cabecera (header) , bloque de información de fuente (sender info) , bloque
de información de receptor (report block 1 y report block 2) y , si fuera necesario , extensiones específicas de perfil
(profile specific extensions).
Por orden de aparición las partes de la cabecera o header son :
-Bits V (2 bits) : indican la versión de RTP ( la 2 actualmente)
-Bit de relleno (1 bit): su activación indica byte/s adicionales al final de la carga útil.
-Report Count (5 bits) : número de bloques de informe de recepción en el paquete SR.
-Packet Type (1 byte): indica el tipo de paquete , p.e. el 200 .
-Length/longitud (2 bytes): longitud del paquete en palabras de 32 bits menos una , con cabecera y relleno.
-SSRC(4 bytes): id de la fuente .

8
 Por orden de aparición las partes del bloque de información de fuente son:
-NTP timestamp (8bytes): indica el instante de tiempo en el cual fue enviado el paquete, respecto a una referencia
de tiempo global.
-RTP timestamp (4bytes) : instante de tiempo en el cual fue enviado el paquete, respecto al tiempo local.
- Sender’s Packet Count (4bytes): número de paquetes enviados por la fuente desde que se inició la sesión.
-Sender’s Octet Count(4bytes):número de bytes de datos enviados en paquetes RTP desde que la fuente inició el
envío de datos.

Por orden de aparición las partes del bloque de información de receptor son:

-SSRC (4bytes): id de la fuente a la que se refieren los datos del informe de recepción.
-Fraction Lost (1byte): fracción de paquetes RTP ( de cada 255) que se perdieron desde que se envió el informe.
-Número de paquetes perdidos acumulado (3bytes): número total de paquetes perdidos desde el inicio de recepción.
- EHSN(Extended Highest Sequence) (4bytes): los 2 bytes más significativos indican el número de ciclos de contador
de secuencia que han pasados y los otros 2 el número de secuencia más alto recibido en paquetes RTP de la fuente
con el id indicado .
-Inter-arrival Jitter (4bytes): estimación del tiempo entre llegadas de los paquetes de datos RTP.
-Last SR Timestamp(4bytes): contiene los 32 bits centrales de los 64 del NTP timestamp recibido como parte del
paquete RTCP SR más reciente de la fuente con id indicada.
-Delay Since Last SR(4bytes): retardo desde que se recibió el último paquete RTCP SR de la fuente indicada y el
instante de envío de este paquete de informe.

Por último están las extensiones específicas del perfil RTP: cada perfil RTP debe definir extensiones espe-
cíficas siempre y cuando haya una información de fuente que deba ser enviada de forma regular.

9
 2.Paquete Receiver Report (RR):se envían periódicamente a los participantes pasivos (las que no envían
paquetes RTP) para informar sobre QoS.
La estructura del paquete RR es:

(a)

Figura 6: Paquete Receiver Report (RR)

De forma análoga a los paquetes SR, un paquete RR contiene :

-Un header / cabecera
-Bloques de informes de receptor.
-Extensiones específicas del perfil , si fueran necesarias.

3.Paquete Extended Reports (XR): el objetivo principal es transportar información adicional que comple-
mente los datos de los paquetes SR y RR.
Se definen en el RFC 3611 de 2003.
Su estructura es la siguiente:

(a)

Figura 7: Paquete Extended Reports (XR))

10
 El apartado de report blocks tiene la siguiente forma :

(a)

Figura 8: Report Blocks de los Paquetes RTCP XR

4.Paquete de Descripción de fuente (SDES,source description): contiene información sobre la fuente

transmisora como el CNAME.

(a)

Figura 9: Paquete SDES One Byte-Format

(a)

Figura 10: Paquete SDES Two Byte-Format

5.Paquete BYE:indica la finalización de un participante en una sesión RTP. Algunas veces y opcionalmente
dando una razón para abandonar la sesión.

(a)

Figura 11: Goodbye RTCP Packets (BYE)

11
 6.Paquete de APP:paquete específico para una aplicación en concreto. Una vez un paquete RTP APP funciona
correctamente , debe ser registrado con el IANA (Internet Assigned Numberrs Authority) como un tipo de paquete
original.

(a)

Figura 12: Application -Defined RTCP Packets (APP)

12
3.3. RTSP

RTP está diseñado para el transporte de media , pero no provee de todas las funcionalidades . De proveer estas
funciones se encarga el protocolo RTSP (Real Time Streaming Protocol).
RTSP está definido en la norma RFC-2326 de 1998. Se describe como un mando a distancia a través de la red para
servidores multimedia.
Como RTSP no está orientado a conexión , el servidor mantiene una sesión asociada a un identificador .
Normalmente se implementa sobre TCP (por lo que es independiente al flujo de datos), con puerto por defecto el
554 ( también se puede usar UDP para latencias bajas).
El protocolo es similar a HTTP, también basado en texto . Difiere ,entre otras cosas , en los nuevos métodos que
emplea para establecimiento y control de una o más sesiones multimedia y del protocolo de transporte .
Permite también el control de la reproducción mediante operaciones VCR-like (play , stop , ...)
Antes de que se inicie una sesión RTSP , el cliente obtiene información sobre el tipo de media con el que va a
trabajar ("Descripción de la Presentación") .
Para ilustrar el funcionamiento de RTSP se ve de manera ilustrativa en las siguientes figuras:

(a)

Figura 13: Esquema funcionamiento general RTSP

13
 Como se observa en la figura , RTSP es independiente del flujo de media como se dijo anteriormente .El Brow-
ser/Navegador y el Player/Reproductor es lo que se entiende como Cliente , mientras que el Web Server/Servidor
Web y el Media Server/Servidor de Media es lo que se conoce como Servidor.
La comunicación para el protocolo RTSP se realiza mediante métodos definidos de los cuales , unos obligatorios y
otros optativos, los más habituales son:

(a)

Figura 14: Métodos RTSP

14
4. Conclusión:

RTP , que nació del esfuerzo académico e impulsado por el IEFT , se ha convertido actualmente en una de las
principales alternativas para el transporte de media a través de Internet y , junto con el RTCP , nos proporciona
monitoreo de Calidad de Servicio (QoS) .
Pese a estas ventajas , el principal problema es el ancho de banda y el empaquetamiento IP/RTP/UDP.
También se han visto las herramientas proporcionadas por el protocolo RTSP , el cual complementa los anteriores
y que se envía separado del flujo de datos .
La mejora de los equipos permite el manejo de las operaciones necesarias en RTP para el procesamiento de multi-
media con mucha mayor facilidad.
Inicialmente se comenzó para multidifusión (pero también hay casos de unidifusión).
De los documentos RFC (Request for Comments , publicaciones del grupo de trabajo de ingeniería de internet que
regulan protocolos de internet ) las referentes a RTP son 7 :

-RFC 1889: año 1996,obsoleto

-RFC 1890: año 1996,obsoleto

-RFC 3550: año 2003, standard 64

-RFC 3551: año 2003,standard 65

-RFC 3711: año 2004,proposed standard

-RFC 3984: año 2005,obsoleto

-RFC 6184: año 2011, proposed standard

15
5. Referencias

1.https://en.wikipedia.org/wiki/Real-time_Transport_Protocol

2.https://tools.ietf.org/html/rfc1889

3.https://tools.ietf.org/html/rfc3550

4.https://www.dit.upm.es/~david/TAR/trabajos/2001/07-RTP-RTCP-RTSP-William-Diaz.pdf

5.https://en.wikipedia.org/wiki/Real_Time_Streaming_Protocol

6.https://books.google.es/books?id=5fms2DW7mMUC&pg=PA42

7.J.F. Kurose, K.W. Ross, Computer networking: a top-down approach featuring the Internet

8. Apuntes Redes de Ordenadores , Grado Ingeniería Telecomunicaciones - Universidade de Vigo

9.https://datatracker.ietf.org/doc/html/rfc3611

10. https://datatracker.ietf.org/doc/html/rfc7941

11. https://repositorio.utb.edu.co/bitstream/handle/20.500.12585/1137/0035902.pdf?isAllowed=y&sequence=
1

12. https://datatracker.ietf.org/doc/html/rfc6184

13. https://datatracker.ietf.org/doc/rfc3640/

14. https://datatracker.ietf.org/doc/html/rfc7826

16