Transmisión en vivo RTSP







Frank Wang  |  Ingeniero de software







RESUMEN: con la rápida evolución de la industria de las cámaras IP, casi todas las cámaras de vigilancia IP admiten la transmisión de video del Protocolo de transmisión en tiempo real (RTSP), lo que significa que el usuario puede operar un reproductor multimedia para ver vistas en vivo desde cualquier lugar. RTSP proporciona una forma para que los usuarios controlen el video y el audio. El Protocolo de transporte en tiempo real (RTSP) en realidad no proporciona la transferencia de señales de video y señales de audio; controla cómo se entregan los paquetes.



I. Introducción

RTSP es un protocolo de control de red que está diseñado para ver una transmisión en vivo y controlar las sesiones de medios entre los puntos finales. La transmisión de datos de transmisión en sí no es una tarea de RTSP. En cambio, RTSP usa una combinación de transmisión confiable sobre TCP (usado para control) y entrega de mejores esfuerzos sobre UDP (usado para contenido) para transmitir contenido a los usuarios. La mayoría de los servidores RTSP utilizan el Protocolo de transporte en tiempo real (RTP) junto con el Protocolo de control en tiempo real (RTCP) para la entrega de flujo de medios.



II - Análisis del paquete de red

Consideremos una interacción en la que el cliente y el servidor utilizarán una combinación de RTSP basado en TCP y RTP y RTCP basados en UDP para entregar una transmisión de video.


Capturamos el tráfico de red entre nuestra cámara IP y el lado del cliente mediante Wireshark. Los parámetros del escenario experimental se muestran en la siguiente tabla.

A. RTSP

RTSP es un protocolo utilizado para transferir datos multimedia en tiempo real (por ejemplo, audio y video) entre un servidor y un cliente. Es un protocolo de transmisión; esto significa que RTSP intenta facilitar escenarios en los que los datos multimedia se transfieren y procesan simultáneamente (es decir, se muestra video y se reproduce audio).

El servidor necesita mantener un estado de sesión para poder correlacionar las solicitudes RTSP con una secuencia. Las transiciones de estado se muestran en la figura 1.



Figura 1: Diagrama de transición de la máquina de estado del servidor RTSP.






Las solicitudes básicas de RTSP se describen a continuación:

1. Opciones

El cliente establecerá una conexión TCP al puerto 554 del servidor. Una solicitud de OPCIONES devuelve los tipos de solicitud que aceptará el servidor.






2. Describe

Una solicitud DESCRIBE incluye una URL RTSP y el tipo de datos de respuesta que se pueden manejar. Esta respuesta incluye la descripción de la presentación, normalmente en formato de Protocolo de descripción de sesión (SDP).






3. Configuración

La solicitud SETUP especifica cómo se debe transportar un único flujo de medios. La solicitud contiene la URL del flujo de medios y un especificador de transporte.

especificador de transporte. Este especificador normalmente incluye un puerto local para recibir datos RTP (audio o video) y otro para datos RTCP (metainformación). La respuesta del servidor generalmente confirma los parámetros elegidos y completa las partes que faltan, como los puertos elegidos por el servidor. track1 (audio):






- El puerto RTP del cliente es 59842, el puerto RTCP del cliente es 59843
- El puerto RTP del servidor es 6970, el puerto RTCP del servidor es 6971

track2 (video):






- El puerto RTP del cliente es 59844, el puerto RTCP del cliente es 59845
- El puerto RTP del servidor es 6972, el puerto RTCP del servidor es 6973

4. Jugar

Una solicitud de REPRODUCCIÓN hará que se reproduzcan una o todas las transmisiones de medios.






5. Desmontaje

Se utiliza una solicitud TEARDOWN para terminar la sesión. Detiene todos los flujos de medios y libera todos los datos relacionados con la sesión en el servidor.






B. RTP

RTP está diseñado para transportar datos de audio y video codificados. RTP agrega un encabezado a cada paquete, que luego se pasa al UDP para su posterior procesamiento.

RTP también proporciona una función de sellado de tiempo que permite sincronizar varios flujos de la misma fuente. Cada forma de carga útil (es decir, video y audio) tiene una forma específica de ser mapeada en RTP.

Cada fuente inserta marcas de tiempo en los encabezados de los paquetes salientes que pueden ser procesados por el receptor para recuperar la señal de reloj de la transmisión que se necesita para reproducir correctamente clips de video y audio.

Como puede verse en la Fig. 2, una trama completa puede identificarse como una secuencia de paquetes que terminan con un paquete que tiene el bit marcador RTP establecido.



Figura 2: Paquetes RTP de video y audio.





Para los paquetes de voz, el bit marcador indica el comienzo de una ráfaga de conversación. Los inicios de las ráfagas de voz son buenas oportunidades para ajustar el retardo de reproducción en el receptor para compensar las diferencias entre las velocidades de reloj del emisor y el receptor, así como los cambios en la fluctuación del retardo de la red.

C. RTCP

RTCP es un mecanismo bidireccional basado en UDP que permite al cliente comunicar información de calidad de flujo al servidor. Esta conexión siempre usa el siguiente puerto UDP incremental del puerto de origen RTP. La figura 3 muestra cómo los tres protocolos funcionan juntos en nuestro escenario experimental.



Figura 3: Los tres principales protocolos de aplicación utilizados en la transmisión en tiempo real.





III - Conclusión

El RTSP proporciona un medio para que el usuario controle el video y el audio. RTSP en realidad no proporciona el transporte de señales de video y señales de audio; en cambio, permite que el usuario controle estas señales. Al igual que un despachador para un servicio de entrega, RTSP en realidad no entrega paquetes; controla cuándo y cómo se entregan los paquetes mediante otros protocolos, como RTP.



Referencias

1. M. Syme y P. Goldie, Optimización del rendimiento de la red con conmutación de contenido: Equilibrio de carga de servidor, firewall y caché: Equilibrio de carga de servidor, firewall y caché, Prentice Hall, 2003.



Descargar PDF>





Ver todos los artículos técnicos>