RTP/RTCP - Historial de revisiones

Javiermartin jc: Texto reemplazado: «
» por «»

2019-08-22T04:13:33Z

Texto reemplazado: «<div align="justify">» por «»

Elizabeth jc en 01:09 27 nov 2013

2013-11-27T01:09:21Z

Elizabeth jc en 01:08 27 nov 2013

2013-11-27T01:08:50Z

Arian.Perez jc: Protocolo RTP y RTCP trasladada a RTP/RTCP

2011-12-05T15:42:09Z

Protocolo RTP y RTCP trasladada a RTP/RTCP

Yrosario06 en 14:52 5 dic 2011

2011-12-05T14:52:45Z

Arian.Perez jc en 14:24 5 dic 2011

2011-12-05T14:24:55Z

Yrosario06: Página creada con '{{Ficha Software |nombre= Protocolo RTP y RTCP |familia= |imagen=Protocolo_RTP.JPG‎ |tamaño= |descripción=RTP es un protocolo basado en IP que proporciona soporte para el t...'

2011-12-01T22:02:15Z

Página creada con '{{Ficha Software |nombre= Protocolo RTP y RTCP |familia= |imagen=Protocolo_RTP.JPG‎ |tamaño= |descripción=RTP es un protocolo basado en IP que proporciona soporte para el t...'

Página nueva

{{Ficha Software
|nombre= Protocolo RTP y RTCP
|familia=
|imagen=Protocolo_RTP.JPG‎
|tamaño=
|descripción=RTP es un protocolo basado en IP que proporciona soporte para el transporte de datos en tiempo real (flujos de vídeo y de audio).
|tipo=Protocolo
}}
<div align="justify">
'''Protocolo RTP: Real-time Transport Protocol (Protocolo en Tiempo Real)'''. Es una aplicación que envía contenido multimedia sobre la red en tiempo real, le debe agregar números de secuencia y marcas de tiempo a los segmentos antes de pasarlo a la capa de transporte. 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.
==Historia==
RTP fue en un principio diseñado para emisiones multicast de tráfico en tiempo real (aunque también se puede utilizar en emisiones unicast) y puede ser utilizado para el video bajo demanda y servicios interactivos tales como telefonía en Internet.
RTP ha sido diseñado para funcionar junto con el protocolo de control auxiliar [[RTCP]] para conseguir mantener la calidad en la transmisión de datos y proporcionar información sobre los participantes al iniciarse la sesión.
==Características==
El objetivo de RTP es que sea maleable y proporcionar la información requerida por una
aplicación particular y normalmente será integrada dentro de la aplicación en vez de constituir un nivel separado. La intención de RTP es que sea adaptado a través de las modificaciones y/o adiciones de las cabeceras necesarias. Dentro de sus principales características se tienen:
* Se encapsula sobre [[UDP]] ([[TCP]] no sirve para aplicaciones de tiempo real).
*Usa puertos de usuario para cada medio que se transfiere.
*Puede enviar tramas generadas por cualquier algoritmo de Codificación: [[H261]], [[MPEG-1]], [[MPEG-2]].
*Puede usarse con direcciones de destino [[unicast]] o [[multicast]].
*Identifica los orígenes del tráfico, lo que permite reencapsular agrupando tráficos a mitad de camino.
*Incorpora marcas de tiempo para cada medio:
**Para sincronización intra-flujo (eliminar [[jitter]]).
**Para sincronización inter-medios (coincidencia audio/vídeo).
*Incluye números de secuencia para detectar pérdidas dentro de un flujo.
===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.
==Protocolo RTCP==

El protocolo RTCP (Protocolo de Control RTP) se basa en la transmisión periódica de paquetes de control a todos los participantes de la sesión, utilizando el mismo mecanismo de transporte que los paquetes RTP. Utiliza un puerto distinto que RTP, por lo general se utilizan puertos consecutivos donde el par es asignado a el flujo RTP y el impar al flujo RTCP.

===Principales Funciones===

*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.
==Fuentes==
*http://www.arcesio.net/rtp/rtprtcp1.html
* Protocolos para telefonía sobre IP.
[[Category:Ciencias_informáticas_y_Telecomunicaciones]]
[[Category:Ciencias_informáticas]] [[Category:Software]]

@@ Línea 1: / Línea 1: @@
-<div align="justify">
 {{Ficha Software
 |nombre= Protocolo RTP y RTCP

@@ Línea 56: / Línea 56: @@
 ==Protocolo RTCP==
 El protocolo RTCP (Protocolo de Control RTP) se basa en la transmisión periódica de paquetes de control a todos los participantes de la sesión, utilizando el mismo mecanismo de transporte que los paquetes RTP. Utiliza un puerto distinto que RTP, por lo general se utilizan puertos consecutivos donde el par es asignado a el flujo RTP y el impar al flujo RTCP.
 ===Principales Funciones===
 * Feedback RTCP: es el encargado de la distribución de la información de realimentación
@@ Línea 75: / Línea 72: @@
 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
@@ Línea 88: / Línea 84: @@
 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

@@ Línea 1: / Línea 1: @@
 {{Ficha Software
 |nombre= Protocolo RTP y RTCP
 |familia=
-|imagen=Protocolo_RTP.JPG‎
+|imagen=Image_thumb1.png
 |tamaño=
 |descripción=RTP es un protocolo basado en IP que proporciona soporte para el transporte de datos en tiempo real (flujos de vídeo y de audio).
 |tipo=Protocolo
 }}
-<div align="justify">
+'''Protocolo RTP y RTCP''': Real-time Transport Protocol (Protocolo en Tiempo Real) es una aplicación que envía contenido multimedia sobre la red en tiempo real, le debe agregar números de secuencia y marcas de tiempo a los segmentos antes de pasarlo a la capa de transporte.
-'''Protocolo RTP: Real-time Transport Protocol (Protocolo en Tiempo Real)'''. Es una aplicación que envía contenido multimedia sobre la red en tiempo real, le debe agregar números de secuencia y marcas de tiempo a los segmentos antes de pasarlo a la capa de transporte. 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.
+==Utilidad==
 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.
 ==Historia==
 RTP fue en un principio diseñado para emisiones multicast de tráfico en tiempo real (aunque también se puede utilizar en emisiones unicast) y puede ser utilizado para el video bajo demanda y servicios interactivos tales como telefonía en Internet.
-RTP ha sido diseñado para funcionar junto con el protocolo de control auxiliar [[RTCP]] para conseguir mantener la calidad en la transmisión de datos y proporcionar información sobre los participantes al iniciarse la sesión.
+RTP fue en un principio diseñado para emisiones multicast de tráfico en tiempo real (aunque también se puede utilizar en emisiones unicast) y puede ser utilizado para el video bajo demanda y servicios interactivos tales como telefonía en [[Internet]].
 ==Características==
 El objetivo de RTP es que sea maleable y proporcionar la información requerida por una
 aplicación particular y normalmente será integrada dentro de la aplicación en vez de constituir un nivel separado. La intención de RTP es que sea adaptado a través de las modificaciones y/o adiciones de las cabeceras necesarias. Dentro de sus principales características se tienen:
 * Se encapsula sobre [[UDP]] ([[TCP]] no sirve para aplicaciones de tiempo real).
-*Usa puertos de usuario para cada medio que se transfiere.
+* Usa puertos de usuario para cada medio que se transfiere.
-*Puede enviar tramas generadas por cualquier algoritmo de Codificación: [[H261]], [[MPEG-1]], [[MPEG-2]].
+* Puede enviar tramas generadas por cualquier algoritmo de Codificación: [[H261]], [[MPEG-1]], [[MPEG-2]].
-*Puede usarse con direcciones de destino [[unicast]] o [[multicast]].
+* Puede usarse con direcciones de destino [[unicast]] o [[multicast]].
-*Identifica los orígenes del tráfico, lo que permite reencapsular agrupando tráficos a mitad de camino.
+* Identifica los orígenes del tráfico, lo que permite reencapsular agrupando tráficos a mitad de camino.
-*Incorpora marcas de tiempo para cada medio:
+* Incorpora marcas de tiempo para cada medio:
-**Para sincronización intra-flujo (eliminar [[jitter]]).
+** Para sincronización intra-flujo (eliminar [[jitter]]).
-**Para sincronización inter-medios (coincidencia audio/vídeo).
+** Para sincronización inter-medios (coincidencia audio/vídeo).
-*Incluye números de secuencia para detectar pérdidas dentro de un flujo.
+* Incluye números de secuencia para detectar pérdidas dentro de un flujo.
 ===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.
+* 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.
+* 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.
+* 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.
+* 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.
+* 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.
+* 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.
+* 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.
+* 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.
+* 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.
+* CSRC, 32 bits: esta información es introducida por los mezcladores para indicar que han contribuido a modificar la información.
 ==Protocolo RTCP==
 El protocolo RTCP (Protocolo de Control RTP) se basa en la transmisión periódica de paquetes de control a todos los participantes de la sesión, utilizando el mismo mecanismo de transporte que los paquetes RTP. Utiliza un puerto distinto que RTP, por lo general se utilizan puertos consecutivos donde el par es asignado a el flujo RTP y el impar al flujo RTCP.
 ===Principales Funciones===
-*Feedback RTCP: es el encargado de la distribución de la información de realimentación
+* 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
+* 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
@@ Línea 62: / Línea 81: @@
 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
@@ Línea 77: / Línea 99: @@
 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.
 ==Fuentes==
-*http://www.arcesio.net/rtp/rtprtcp1.html
+* [http://www.arcesio.net/rtp/rtprtcp1.html]
 * Protocolos para telefonía sobre IP.
-[[Category:Ciencias_informáticas_y_Telecomunicaciones]]
-[[Category:Ciencias_informáticas]] [[Category:Software]]
+[[Category:Telecomunicaciones]] [[Category:Protocolos]]