¿Qué es RTSP y por qué es necesario?

Los mensajeros robóticos, los drones, los automóviles no tripulados y otros logros de la ciencia y la tecnología modernas ya no parecen sacados del mundo de fantasía. Se han convertido en un fenómeno común (o casi) para nosotros. Las cámaras IP incorporadas les permiten “ver” lo que está sucediendo y nosotros podemos ver el mundo a través de sus “ojos”. Pero, ¿y si te decimos que la visión (cámaras IP) de estas criaturas de alta tecnología se basa en una tecnología que tiene más de 20 años?

¿Puedes creerlo? Siéntate y prepárate para sorprenderte.

En este artículo, te contamos cómo una tecnología de los noventas se sigue utilizando con éxito en la actualidad, porqué no hay nada mejor y porqué deberías saberlo.

Spoiler: el nombre de este veterano es RTSP.

En este texto hablaremos sobre RTSP, RTP, RTCP, cómo existen en las cámaras IP actuales que admiten HEVC (H.265), con tecnología de análisis y visión por computadora, y cómo han sobrevivido hasta el día de hoy. Entonces, ¿qué tiene de bueno y exitoso RTSP y por qué no se usa en televisión?

Tabla de contenido:

1. ¿Qué es RTSP y por qué es necesario?
2. La relación entre RTSP y HTTP RTP (RTCP)
3. Relación entre RTSP, RTP, RTCP y SDP
4. Los métodos básicos del protocolo RTSP. SIP y RTSP
5. RTSP. Era/es
6. RTSP y RTMP
7. Flussonic y RTSP

¿Qué es RTSP y por qué es necesario?

RTSP (Protocolo de transmisión en tiempo real) es un protocolo de capa de aplicación diseñado para sistemas de telecomunicaciones y entretenimiento para controlar la entrega de datos multimedia. RTSP es un protocolo de señalización, controla la sesión de transmisión de datos.

RTSP originalmente estaba destinado a ser utilizado para ofrecer televisión de entretenimiento. Y realmente lo era por el momento. Luego, un destino malvado decidió lo contrario: RTSP fue borrado de la televisión y ahora solo se puede encontrar en cámaras IP.

Los principios establecidos en el RTSP podemos observarlos en el estándar moderno WebRTC.

RTSP se puede comparar con un control remoto de TV. Se puede usar para iniciar, pausar, detener, etc. el video en el televisor, el servidor de medios. El control no es vía infrarrojos, sino vía Internet. La humanidad todavía no ha aprendido a transmitir el contenido propiamente dicho mediante el mando a distancia de la tv (aunque sean nuestros años), pero es más que suficiente para controlarlo.

Espera, entonces RTSP solo administra el contenido, pero ¿cómo se transmite el contenido en sí?

En la capa de transporte, se utiliza RTP (Protocolo en tiempo real) para transmitir el flujo en tiempo real. La función de RTSP es equivalente al control remoto de un servidor de transmisión de medios. Las cámaras IP pueden usar tanto TCP como UDP para transmitir contenido de transmisión. Sin embargo, cabe señalar que UDP no tiene ningún sentido práctico para esta tarea.

¿Por qué no UDP?

Debido a la falta de mecanismos modernos de compensación de pérdidas. Entonces, los datos simplemente se pierden en algún lugar del camino. En nuestra práctica, nos ceñimos a TCP, donde los datos y la gestión de datos coexisten en un flujo en simbiosis. Cabe señalar que todo funciona bien.

Tenemos el concepto, también tenemos el propósito en un sentido general. Pero, ¿y la práctica?

Pongamos un ejemplo: supongamos que has instalado videovigilancia en tu propiedad y tienes miedo de que te roben tu videograbadora y todos los datos que contiene, y nunca será posible ver las caras de los ladrones. ¿Qué hacer en este caso? ¿Guardarla en una caja fuerte? Puedes configurar una grabación de video directamente en la nube. Usando el protocolo RTSP, puedes enviar la información a un servicio de nube remoto. Además, si deseas visualizar remotamente el archivo desde el DVR, la comunicación con el mismo también será vía RTSP, pero sólo si el equipo tiene soporte para el protocolo RTSP.

RTSP ya no se usa para la transmisión web como tal, ha sido eclipsado y reemplazado por representantes más jóvenes de la tecnología de transmisión: HLS y DASH, dejándonos ni siquiera una oportunidad para resistir y luchar contra el cambio.

La relación entre RTSP y HTTP RTP (RTCP)

Similitudes:

• Ambos usan texto sin formato para enviar mensajes, y la sintaxis del protocolo RTSP es similar a HTTP.

• RTSP se diseñó originalmente para ser compatible con el código de análisis del protocolo HTTP escrito anteriormente.

Diferencias:

• RTSP guarda el estado. Los comandos RTSP necesitan saber en qué estado se encuentran actualmente. En otras palabras, los comandos RTSP siempre se envían en orden, cada siguiente comando viene después del anterior. RTSP no interrumpirá la conexión, sin importar en qué estado se encuentre. HTTP, por otro lado, no guarda el estado. Después de cómo, el protocolo envía un comando, la conexión se interrumpe y no hay dependencia entre los comandos.

• RTSP usa el puerto 554, mientras que HTTP usa el puerto 80.

• En comparación con RTSP, el cliente envía las solicitudes HTTP y el servidor responde. Con RTSP, tanto el cliente como el servidor pueden enviar solicitudes, lo que significa que RTSP puede ser bidireccional.

Relación entre RTSP, RTP, RTCP y SDP

Consolidemos cómo se relacionan RTSP, RTP, RTCP y SDP:

• RTP (Protocolo en tiempo real).

Un protocolo de transmisión en tiempo real. RTP proporciona marcas de tiempo, números de serie y otros métodos para garantizar el tiempo de procesamiento durante las transmisiones de datos en tiempo real.

• RTCP (Protocolo de control de transporte en tiempo real)

Un protocolo para asegurar la calidad del servicio y el control de los participantes. RTP y RTCP se usan juntos.

• RTSP (Protocolo de transmisión en tiempo real).

Un protocolo para controlar la entrega de datos.

• SDP (Protocolo de descripción de sesión).

Un protocolo para describir una sesión de transmisión de datos.

Los métodos básicos del protocolo RTSP. SIP y RTSP

Aquí también nos gustaría mencionar SIP (Session Initiation Protocol, por sus sigla en inglés) para resaltar las características de RTSP y contrastarlo con SIP.

SIP (Protocolo de inicio de sesión) es similar a RTSP visualmente, pero su lógica es muy diferente. Por ejemplo, RTSP a menudo se caracteriza por una única sesión TCP, mientras que SIP es un antipatrón.

Hagamos una comparación basada en SDP. RTSP (hoy SDP) se usa exclusivamente para describir contenido. En SIP, así como en WebRTC (que es una extensión de SIP), SDP se usa para configurar puertos y comunicación de red.

Los principales métodos RTSP se enumeran a continuación:

RTSP ¿Qué era/es?

Comencemos con un poco de historia.

RTP junto con RTCP se desarrollaron en 1996 y se fijaron en el estándar RFC 1889. SDP vio la luz en abril de 1998 en RFC 2327. RTSP también fue desarrollado en abril de 1998 por el Grupo de Trabajo de Ingeniería de Internet (IETF) y se refleja en el estándar RFC 2326. Se hizo muy popular de inmediato porque permitía reproducir video y audio directamente a través de Internet sin tener que descargar contenido a un dispositivo cliente. ¡La gente estaba encantada con la cantidad de tiempo y recursos que podía ahorrar!

RTSP proviene de redes donde los retrasos y las pérdidas de entrega son pequeños y estables, es decir, redes de área local. También es de donde provienen muchas otras soluciones.

RTSP fue concebido y desarrollado cuando la tarea de controlar la entrega al cliente se quería confiar al servidor. Así, el servidor se encargaba de toda la lógica: qué, cuándo y a quién enviar. Podemos decir que el servidor tenía que ser lo más complejo posible y el cliente, lo más simple y sin complicaciones posible. Cuando cambiamos a los protocolos HLS y DASH, la situación era todo lo contrario. El cliente ahora estaba más ornamentado y el servidor era más primitivo. Pero resultó que las funciones de control inteligente sobre la entrega del servidor RTSP no han sobrevivido hasta el día de hoy y han caído en el olvido.

Los servidores RTSP de hoy en día son en su mayoría cámaras IP que desconocen todas las capacidades RTSP que se concibieron hace décadas. Esto significa que realmente no importa si hay comentarios del cliente. Si el cliente obtiene los datos, genial, si no, bueno, eso sucede, hay problemas.

Ten en cuenta que RTSP se creó junto con la telefonía. Se basó en soluciones muy exitosas que ya existían en el mercado, pero las hemos cambiado un poco: RTP para la entrega de datos, RTCP para señalar la calidad de la entrega de datos (QoS) y SDP para la transferencia de información de contenido. Para darte una idea del éxito de estas soluciones, los mismos RTP y RTCP desarrollados hace unos 25 años ahora se utilizan de la misma forma en el estándar WeRTC, que es el estándar de facto para la comunicación en tiempo real. ¡Entonces, incluso en ese entonces, tenían todo lo que necesitaban para mantenerse a flote hasta ahora!

En un momento, RTSP fue el líder entre las tecnologías de transmisión de video y audio. Pero con el tiempo, las tecnologías basadas en HTTP que utilizan un algoritmo de tasa de bits adaptable eclipsaron a RTSP y RTMP. A pesar de esto, RTSP todavía se usa activamente en la videovigilancia hoy en día para capturar la transmisión de las cámaras IP.

Es importante señalar que RTSP para cámaras IP y para televisión son dos protocolos completamente diferentes. El mismo RTSP para televisión solo se puede encontrar en sistemas heredados que todavía funcionan.

Como empezamos a hablar de RTSP, debemos mencionar RTMP.

RTSP y RTMP

RTMP (Protocolo de mensajería en tiempo real) se creó como un protocolo para transferir funciones, gestión remota de códigos, una especie de protocolo RPC, como lo fue CORBA antes o ahora gRPC. RTMP era bastante complejo por derecho propio. De hecho, por grosero que parezca, RTMP está vivo solo porque los CDN comenzaron a admitirlo a tiempo. Hoy en día, casi cualquier CDN te brinda la capacidad de transmitir video a través de RTMP, pero no de reproducirlo. Hoy en día, RTMP es solo un protocolo de publicación, pero no un protocolo de reproducción, porque no tiene ventajas sobre los actuales HLS, CMAF, etc.

En los viejos tiempos, las cámaras IP vivían básicamente en el códec MPEG-4 Parte 2 y la televisión tenía todas las ventajas de MPEG-2. Y luego todos pasaron a MPEG-4 Parte 10, también conocido como H.264 o AVC. Así es, no hay necesidad de quedarse quieto, es hora de evolucionar.

Vale, se han cambiado los códecs, pero ¿qué pasa con RTSP y RTMP? ¿Que se aguanten? Bueno, no hay forma de evitarlo.

¿Recuerdas que RTSP se hizo a partir de soluciones ya exitosas: RTP, RTCP, SDP? Bueno, las cámaras IP, gracias a la flexibilidad de SDP, sin problemas ni cambios han migrado a H.264. De la misma manera, las cámaras IP se trasladaron a H.265 o HEVC.

RTMP, por otro lado, no ha podido hacer transiciones similares con tanta facilidad. Por qué, porque RTMP no tiene ese superpoder de poder agregar nuevos códecs, es decir, de expandir.

Como se dice popularmente, la supervivencia del más apto.

Flussonic y RTSP

Productos de TI, que se escribieron con prisa y no de la mejor manera, la transición de UDP a TCP fue difícil. No lograron dominar cualitativamente el modelo de programación asincrónica. En la práctica, se expresa en la traducción del socket TCP al modo ‘non-blocking’, en el que los datos pueden perderse, es decir, los intentos del software para escribir datos en el socket parecen ser en vano, porque el socket está bloqueado. Como resultado, el propio sistema operativo no acepta los datos. Resulta que el software de la cámara simplemente “desecha” los datos y, como resultado, tenemos un desastre.

¿Hay alguna manera de resolver este problema?

Claro, como conectar la cámara IP directamente al servidor con un cable. A pesar de que esta es una forma oficial de instalar cámaras (en realidad no fueron diseñadas para transmitir datos a través de Internet), en la realidad actual parece una solución ridícula y frívola.

En Flussonic hay modos para restaurar la sincronización. Por ejemplo, si la cámara china pierde sincronización y datos, en Flussonic existen mecanismos especiales para recuperar bytes de información perdidos, lo que permite resucitar el flujo de datos. ¿Cuan genial es eso?

¿Qué necesitas para comenzar a obtener video de la cámara IP en Flussonic?

Primero, la dirección IP de la cámara. En segundo lugar, solo la dirección IP de la cámara no es suficiente para obtener video de ella. Siempre necesitas especificar otra ruta. Esto no siempre se proporciona en la documentación, por lo que es posible que debas ponerte en contacto con el proveedor o el fabricante de la cámara.

Cómo se ven los enlaces RTSP:

• rtsp://hostname/path - syntax;
• rtsp://user:password@ip/path - authorization URL;
• rtsp2://hostname/path - enables audio transcoding in AAC.
• rtsp://192.168.0.100/h264 - ejemplo de un link real.

En Flussonic, entre otras cosas, puedes usar la opción tracks=1 para capturar solo la pista de video. El siguiente es un ejemplo de la configuración:

stream fake { 
    input fake://fake; 
} 
stream input_rtsp { 
    input rtsp://localhost/fake tracks=1; 
} 

Flussonic Media Server te permite recibir transmisiones a través de RTSP y muchos otros protocolos.

Puedes encontrar cómo agregar una cámara IP a Flussonic y enviar video al sitio web en la [documentación].

También puedes leer sobre estas y muchas otras características de Flussonic en la sección de documentación en nuestra página web.

Author:

Maksim Klyushkov

Flussonic Media Server Team Lead

At the forefront of Flussonic innovations: responsible for development of Flussonic Media Server, video analytics & UI services