Protocolo RTP

Por:

Daniel Esteban González López

Alejandro Londoño Rivera

Presentado a:

Fernando Eliecer Ávila Berrio

Asignatura:

Conmutación y Señalización

INSTITUTO TECNOLÓGICO METROPOLITANO

 DEPARTAMENTO DE ELECTRÓNICA Y TELECOMUNICACIONES

TECNOLOGÍA EN TELECOMUNICACIONES

MEDELLÍN

2019

Introducción:

A medida que las telecomunicaciones han ido evolucionando sus necesidades también y esto
ah dado origen a protocolos encaminados a aplicaciones de difusión, los protocolos de
retransmisión utilizados en el siglo pasado aún siguen siendo útiles para la transmisión de
datos al actualizar sus versiones y su funcionalidad fusionándolos con otros protocolos. RTP
tuvo un gran auge entrer 1996-2003 usado por sistemas de retransmisión de datos y siendo
primordial para la base de la industria de VOIP y para la transmisión de múltiples datos en
tiempo real.

Objetivos:

● Fomentar investigaciones para el mecanismo del protocolo RTP

● Conocer cómo funciona y como se relaciona y conecta con otros protocolos.
● Determinar la estructura del envío de paquetes de flujos, las marcas de tiempo y la
funcionalidad de este protocolo.
 PROTOCOLO RTP

Definición

define un formato de paquete estándar para el envío de audio y video sobre Internet. Es
definido en el RFC1889. Fue desarrollado por el grupo de trabajo de transporte de audio y
video y fue publicado por primera vez en 1996. RTP se utiliza ampliamente en los sistemas
de comunicación y entretenimiento que involucran medios de transmisión, tales como la
telefonía, aplicaciones de videoconferencias, servicios de televisión y web basado en
funcionalidades push-to-talk. (3cx, s.f.)

Funcion

Estos son necesarios para reconstruir el contenido en el receptor sin tener que esperar a bajar
el contenido completo (o una parte suficientemente grande). Es conveniente tener una
estructura estandarizada de paquetes que tenga campos que indiquen el tipo de codificación,
marcas de tiempo, número de secuencia y otros campos potencialmente útiles.

En el RFC 1889 se define el estándar RTP que cumple con las características mencionadas.
Puede ser utilizado para transportar formatos comunes como WAV o GSM para audio y
MPEG1 o MPEG2 para video. También permite utilizar formatos propietarios de sonido y
video.

Feedback RTCP: es el encargado de la distribución de la información de realimentación

de la calidad de los datos. Uno podría tomar acciones para mejorar el rendimiento de la
aplicación con esta información, por ejemplo cambiar la codificación, para disminuir la tasa
de bits.
Identificación: es necesario tener un identificador persistente a nivel de capa de transporte

para las fuentes RTP. Este identificador se llama Nombre Canónico. Dado que el SSRC
puede cambiar debido a un conflicto o debido a el reinicio del programa, los receptores
utilizan el nombre canónico para mantener una lista de los participantes de la sesión. También
se utiliza para agrupar distintos streams de un participante, por ejemplo para sincronizar
audio con video.

Control de Participantes: las funciones anteriores obligan a los participantes de la sesión a

enviar periódicamente paquetes RTCP, la tasa de envío de esos paquetes tiene que ser
controlada para permitir acceso a mas participantes. Dado que los participantes envían los
paquetes de control a todos los demás participantes, cada uno observa localmente el número
de participantes y calcula a partir de este número la tasa de envío de paquetes de control.

Cabecera de los paquetes

Cada paquete RTCP empieza con una parte fija que es similar a los paquetes de datos RTP,
seguido por elementos estructurados que pueden ser de longitud variable de acuerdo con el
tipo de paquete.Para cumplir las funciones de este protocolo se imponen las siguientes
condiciones:

Las estadísticas de recepción (en SR o RR) deben ser enviadas tan a menudo como lo

permita el ancho de banda para maximizar la resolución de las estadísticas.

 Los nuevos receptores deben recibir el CNAME de una fuente tan pronto como sea

posible para identificar la fuente.

 El número de tipos de paquetes deben aparecer en el primer paquete para determinar

su tratamiento.

 El intervalo de transmisión de paquetes RTCP debe ser calculado de forma que se

permita tener sesiones que vayan desde pocos participantes a miles. Para ello, en cada
sesión se asume que el tráfico de datos está sujeto a un límite denominado “ancho de
banda de sesión” que se divide entre los participantes. Este ancho de banda debe ser
reservado y limitado por la red. El parámetro de ancho de banda de sesión debe ser
 proporcionado por la aplicación de control de sesión. A partir de este valor y en
función del número de participantes se calcula el intervalo con una formula empírica.

Componentes del protocolo

Cabecera de los paquetes

Los primeros 12 octetos (es decir, los campos V, P, X, CC, M, PT, sequence number,
timestamp y SSRC) siempre están presentes, en tanto que los identificadores de "fuentes
contribuyentes" (nodos que generan información al mismo tiempo para, supongamos, una
videoconferencia) son utilizados sólo en ciertas circunstancias. Después del header "básico"
puede tenerse extensiones opcionales para el header (Extension header).

Finalmente el header es seguido por los datos (payload) que transporta RTP y su formato es
definido por la aplicación. El diseño del header de RTP busca llevar sólo aquellos campos
que son necesarios para diversos tipos de aplicaciones.

 V (versión), 2 bits: los primeros dos bits identifican la versión del protocolo.
 P (padding), 1 bit: el siguiente bit identifica el padding. Informa que los datos de RTP
llevan un "relleno" para completar un bloque de cierto tamaño. El último byte en el
mensaje UDP dice de qué tamaño es el padding.
 X (extensión), 1 bit: indica si a continuación viene una cabecera de extensión.
 CC (CSRC count), 4 bits: número de indentificadores CSRC que siguen a la cabercera
fija.
 M (marker), 1 bit: está indicada para señalar elementos especiales como salirse de los
límites.
 PT (payload type), 7 bits: formato de la información que se transporta para que lo
interprete la aplicación.
 Número de secuencia, 16 bits: se incrementa en uno por cada paquete que se envía y sirve
para que el receptor detecte pérdidas de paquetes.
 Timestamp, 32 bits: tiempo en el que se muestra el primer octeto de los datos
transmitidos en el paquete.
 SSRC, 32 bits: identifica la fuente del paquete.
 CSRC, 32 bits: esta información es introducida por los mezcladores para indicar que
han contribuido a modificar la información. (inder.ho, 9)

Protocolos en los que se apoya

Protocolo rtpc

Es un protocolo fundamentado en la transmisión periódica de paquetes de control a todos los

integrantes en una sesión. Utiliza el mismo mecanismo de transmisión que los paquetes de
datos RTP. El protocolo subyacente, en este caso el UDP, se encarga de multiplexar los
paquetes de datos RTP y los paquetes de control RTCP. El paquete RTCP sólo contiene la
información necesaria para el control de transporte y no transporta ningún contenido.

Está compuesto por un encabezamiento de conjunto, similar al de los paquetes RTP que
transportan el contenido, seguido de otros elementos que dependen del tipo de paquete RTCP.
Se definen varios tipos de paquete RTCP, para transportar una amplia variedad de
información de control. A continuación, se muestran los cinco tipos más comunes de
paquetes RTCP.

Tipos de paquetes RTCP

 SR (Informe de emisor) Conjunto de estadísticas de transmisión y recepción que

proviene de participantes que son emisores activos.
 RR (Informe del receptor) Conjunto de estadísticas que proviene de participantes
que sólo son receptores.
 SDES (Descripción de fuente) Los paquetes de descripción de fuente están
compuestos de varios elementos, incluido el CNAME. Constituyen la «tarjeta de
visita» de la fuente.
 BYE (Mensaje de fin) Indica que se termina una sesión.
 APP Funciones específicas (Matango, s.f.)de una determinada aplicación.

Los destinatarios de los paquetes RTP devuelven información sobre de la calidad de

recepción, utilizando diferentes formas de paquetes RTCP, según si ellos mismos son
emisores de contenido o no. Los dos tipos, SR y RR, contienen ninguno, uno o varios bloques
de informe de receptor, previstos para la sincronización de las fuentes de las cuales el receptor
ha recibido un paquete de contenido RTP desde el último informe.

La evaluación de la calidad de recepción no es sólo útil para el emisor, sino también para el
receptor y cualquier supervisor de red que pudiera existir. El emisor puede modificar su
transmisión de acuerdo con la información recibida; el receptor puede inferir si las
dificultades de recepción que observa son de origen local, regional o más amplio. El
supervisor recibirá solamente los paquetes RTCP, con lo cual podrá evaluar la calidad de
funcionamiento de la red. (Matango, s.f.)

Conclusiones:

 El protocolo RTP es un excelente protocolo al momento de enviar archivos

multimedia por medio de UDP hacia el receptor, pero su gran problema es que no
tiene servicio de QOS y no se tiene un orden preciso de la calidad del paquete ni el
tiempo de llegada.
 RTP se apoya por medio de otros protocolos como UDP que a su vez se apoya de
IPV4-IPV6 para el transporte de datos, para una comunicación más óptima debería
tener sus propios sistemas de transporte de flujos.
 Sin RTCP el protocolo RTP no tendría acceso a la información de los clientes, tiempo
de conexión ni ningún beneficio que ofrece RTCP

Referencias
3cx. (s.f.). 3cx. Obtenido de https://www.3cx.es/voip-sip/rtp/
inder.ho, A. (2010 de JUN de 9). ECURED. Obtenido de
https://www.ecured.cu/RTP/RTCP#Utilidad
Matango, F. (s.f.). SERVIREFERENCIAS. Obtenido de
http://www.servervoip.com/blog/protocolo-de-control-de-transporte-en-tiempo-real-
rtcp/