Protocolo Rtp 2i6if

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. RT: 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 RT, la tasa de envío de esos paquetes tiene que ser controlada para permitir 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 RT 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 RT 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 RT. El paquete RT 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 RT. Se definen varios tipos de paquete RT, para transportar una amplia variedad de información de control. A continuación, se muestran los cinco tipos más comunes de paquetes RT. Tipos de paquetes RT 

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 RT, 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 RT, 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 RT el protocolo RTP no tendría a la información de los clientes, tiempo de conexión ni ningún beneficio que ofrece RT

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/RT#Utilidad Matango, F. (s.f.). SERVIREFERENCIAS. Obtenido de http://www.servervoip.com/blog/protocolo-de-control-de-transporte-en-tiempo-realrt/