Compartir tecnología

[Audio y Vídeo | RTSP] Explicación detallada del protocolo RTSP y análisis de ejemplos de captura de paquetes (detallado sin entrar en detalles)

2024-07-08

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

😁博客主页😁:🚀https://blog.csdn.net/wkd_007🚀
🤑博客内容🤑:🍭嵌入式开发、Linux、C语言、C 、数据结构、音视频🍭
🤣本文内容🤣:🍭介绍RTSP协议 🍭
😎金句分享😎:🍭你不能选择最好的,但最好的会来选择你——泰戈尔🍭
⏰Hora de lanzamiento⏰: 2024-07-06 12:22:00

¡Este artículo no puede reenviarse sin permiso! ! !


Insertar descripción de la imagen aquí

🎄一、概述

RTSP, nombre completo Real Time Streaming ProtocolEl protocolo de transmisión en tiempo real es un protocolo de capa de aplicación en el sistema de protocolo TCP/IP. Es un estándar IETF RFC presentado por la Universidad de Columbia, Netscape y RealNetworks.

El documento oficial sobre el protocolo RTSP es RFC2326, enlace del documento:RFC2326: Protocolo de transmisión en tiempo real (RTSP)

Se hace referencia a la sintaxis y el funcionamiento del protocolo RTSP. HTTP/1.1, un protocolo basado en texto que utiliza el juego de caracteres ISO10646 y codificación UTF-8 es el protocolo de capa de transporte que transporta RTSP;TCP, puerto predeterminado554Si se trata de un túnel RTSP sobre HTTP, el puerto TCP predeterminado es 8080 y generalmente se usa junto con el protocolo RTP/RTCP. El protocolo RTP transmite datos de flujo en tiempo real y el protocolo RTCP completa la transmisión de flujos de datos; comandos de control.

Insertar descripción de la imagen aquí

Protocolo RTP: nombre completoReal-time Transport Protocol , el protocolo de transmisión en tiempo real, fue anunciado por el Grupo de Trabajo de Transmisión Multimedia del IETF en 1996 en RFC 1889. El protocolo RTP detalla el formato de paquete estándar para entregar audio y video a través de Internet. Está construido sobre el protocolo UDP.

Protocolo RTCP: nombre completoReal-time Transport Control Protocol , Protocolo de control de transporte en tiempo real, utilizado con RTP. RTP utiliza un puerto UDP par; RTCP utiliza el siguiente puerto de RTP, que es un puerto impar. RTCP y RTP trabajan juntos. RTP implementa la transmisión de datos reales y RTCP es responsable de enviar paquetes de control a todos los participantes de la sesión. Su función principal es retroalimentar la calidad del servicio brindado por RTP.

La diferencia entre el protocolo RTSP y el protocolo HTTP:
RTSP tiene estado y sus comandos siempre se envían en orden, y es posible que siempre sea necesario enviar un comando antes que otro. HTTP no tiene estado. Una vez que el protocolo envía un comando, la conexión se desconectará y no habrá dependencia entre los comandos.
El protocolo rtsp usa el puerto 554 y http usa el puerto 80.
Las solicitudes RTSP pueden ser enviadas tanto por el servidor como por el cliente, mientras que las solicitudes HTTP solo pueden ser enviadas por el cliente.


Insertar descripción de la imagen aquí

🎄二、RTSP 方法

Los métodos RTSP comúnmente utilizados incluyen: OPCIONES, DESCRIBE, CONFIGURACIÓN, REPRODUCCIÓN, PAUSA, DESMONTAJE, ANUNCIAR, GET_PARAMETER y SET_PARAMETER, etc. Las instrucciones de uso detalladas son las siguientes:

  • OPTIONS : El cliente obtiene el método admitido por el servidor del servidor. No afecta el estado del servidor;
  • DESCRIBE: El cliente obtiene la descripción del objeto multimedia especificado por la URL del servidor, dondeAcceptEl campo especifica el formato de descripción;
  • SETUP : El cliente solicita al servidor que establezca una sesión y se prepare para la transmisión. La información de la solicitud incluye principalmente el protocolo de transmisión y el número de puerto del cliente;
  • PLAY : El cliente notifica activamente al servidor que comience a enviar datos utilizando el mecanismo especificado por SETUP.enRangeEl campo especifica la hora de inicio y finalización de la reproducción (el rango de transmisión en tiempo real generalmente esRange: npt=0.000-), cuando llegan múltiples solicitudes PLAY, el servidor pondrá en cola las solicitudes PLAY y las ejecutará secuencialmente, es decir, debe esperar a que se complete el primer tiempo PLAY antes de continuar procesando el segundo mensaje PLAY.
  • PAUSE : El cliente solicita que se suspenda temporalmente la transmisión de medios del servidor.capaz de pasarRangeEl parámetro se detiene en un momento específico o puede especificar una transmisión para pausar. Por ejemplo, si especifica una transmisión de audio para pausar, la reproducción será silenciosa.
  • RECORD : RECORD notifica al servidor que el cliente comenzará a grabar datos multimedia de acuerdo con la descripción anterior. entimestamp Los campos reflejan las horas de inicio y finalización (UTC). Si este campo no está presente, se utilizará la hora de inicio o finalización de la descripción del medio. Si la sesión ya ha comenzado, la grabación comienza inmediatamente.
    El servidor decide si almacenar los datos registrados enrequest-URI Siguiente u otro URI. Si el servidor no utiliza un URI de solicitud, la respuesta debe ser 201 (Creado) y contener un encabezado de Entidad y Ubicación que describa el estado de la solicitud y haga referencia al nuevo recurso.
  • TEARDOWN: El cliente solicita dejar de enviar la secuencia de URL especificada y liberar los recursos relacionados.
  • REDIRECT : Para redirigir una solicitud, el servidor notifica al cliente que debe conectarse a otra ubicación del servidor. Contiene el encabezado de Ubicación obligatorio, que indica que el cliente debe realizar una solicitud para esta URL. Puede contener el parámetro Rango, que indica cuándo entrará en vigor la redirección. Si el cliente desea continuar enviando o recibiendo medios para este URI, debe emitir una solicitud TEARDOWN para la sesión actual y una CONFIGURACIÓN para la nueva sesión en el host especificado.
  • ANNOUNCE: Cuando el cliente envía al servidor, significa enviar la descripción de la presentación o el objeto multimedia identificado por la URL de solicitud al servidor.
    Cuando el servidor lo envía al cliente, significa notificarle al cliente que actualice la información de la sesión.
  • GET_PARAMETER :Solicitud GET_PARAMETER para recuperar valores de parámetros para la representación o flujo especificado en el URI. El contenido de las respuestas y respuestas se deja a la implementación. GET_PARAMETER sin un cuerpo de entidad se puede utilizar para probar la vida ("ping") de un cliente o servidor.
  • SET_PARAMETER : Este método solicita establecer los valores de los parámetros de la demostración o la secuencia URL especificada. Las solicitudes solo deben contener un único parámetro, lo que permite al cliente decidir por qué falló una solicitud en particular. Si la solicitud contiene varios parámetros, todos los parámetros se pueden configurar correctamente y el servidor solo debe actuar en esta solicitud. El servidor debe permitir que los parámetros se establezcan en el mismo valor repetidamente, pero no cambiar el valor del parámetro. Nota: Los parámetros de transmisión de medios se deben configurar mediante el comando SETUP. Es beneficioso para los firewalls limitar los parámetros de transferencia de configuración a SETUP.

Arriba se presentan un total de 11 métodos RTSP, entre los cuales,SETUPPLAYTEARDOWN Los tres comandos son necesarios en el proceso RTSP y no son necesarios otros métodos.yANNOUNCEGET_PARAMETERSET_PARAMETERLos tres comandos se pueden enviar del cliente al servidor o del servidor al cliente. Los otros comandos se envían del cliente al servidor.


Insertar descripción de la imagen aquí

🎄三、RTSP 的 请求报文 与 响应报文

RTSP tiene dos tipos de mensajes: mensajes de solicitud y mensajes de respuesta. El mensaje de solicitud se refiere al mensaje de solicitud enviado del cliente al servidor, y el mensaje de respuesta se refiere a la respuesta del servidor al cliente.

✨3.1, mensaje de solicitud RTSP

El mensaje de solicitud RTSP consta de tres partes: línea de solicitud, encabezado de solicitud y cuerpo de solicitud. Entre ellos, la línea de solicitud es obligatoria, mientras que el encabezado y el cuerpo de la solicitud son opcionales según la situación específica.
Insertar descripción de la imagen aquí

  • Línea de solicitud: la línea de solicitud consta de un método, un URI de solicitud y una versión del protocolo separados por espacios y precedidos por CRLF (es decir:rn)Finalizar.
    方法 : Es el método RTSP presentado anteriormente. Incluyendo OPCIONES, DESCRIBIR, CONFIGURACIÓN, REPRODUCCIÓN, PAUSA, DESMONTAJE, etc.
    请求URI: Identifica el recurso multimedia que se utilizará, normalmente en el formato rtsp://example.com/path/to/stream.
    协议版本: Indica la versión del protocolo RTSP que sigue la solicitud, generalmenteRTSP/1.0oRTSP/2.0
    A continuación se muestra un ejemplo de una línea de solicitud completa:
    OPTIONS rtsp://192.168.3.225:554/wbc RTSP/1.0
    
  • Encabezado de la solicitud: el encabezado de la solicitud contiene información adicional, como: CSeq (número de secuencia utilizado para identificar la solicitud), ID de sesión (identificador de sesión), Transporte (protocolo de transporte), etc. Cada campo de encabezado consta de un nombre de campo, dos puntos y un valor de campo, y cada campo de encabezado está separado por CRLF.
    A continuación se muestra un ejemplo de un encabezado de solicitud completo:
    CSeq: 2
    User-Agent: LibVLC/3.0.19 (LIVE555 Streaming Media v2016.11.28)
    
  • Cuerpo de la solicitud: el cuerpo de la solicitud se utiliza para transmitir datos adicionales. El contenido específico del cuerpo de la solicitud depende del método RTSP utilizado en la línea de solicitud. Nota: Después del encabezado de la solicitud, se debe insertar una línea en blanco (CRLF) para distinguir el encabezado de la solicitud del cuerpo de la solicitud. La mayoría de los mensajes de solicitud no tienen cuerpo de solicitud.

✨3.2, mensaje de respuesta RTSP

El mensaje de solicitud RTSP consta de tres partes: línea de estado, encabezado de respuesta y cuerpo de respuesta. Entre ellos, la línea de estado es obligatoria, mientras que el encabezado y el cuerpo de la respuesta son opcionales según la situación específica.
Insertar descripción de la imagen aquí

  • Línea de estado: la línea de estado contiene una versión del protocolo, un código de estado y un texto de estado, separados por espacios y terminados en CRLF (es decir, "rn").
    协议版本: Indica la versión del protocolo RTSP que sigue la respuesta, generalmente RTSP/1.0 o RTSP/2.0.
    状态码 : Tres dígitos, como: 200, 401, 500, etc., utilizados para indicar el resultado del procesamiento de la solicitud. El primer dígito representa la categoría de respuesta: 2xx indica éxito, 4xx indica error del cliente y 5xx indica error del servidor.
    状态文本: Una breve descripción de texto que explica el significado específico del código de estado correspondiente, como por ejemplo: OK, No autorizado, etc.
    A continuación se muestra una línea de respuesta de ejemplo:
    RTSP/1.0 200 OK
    
  • Encabezado de respuesta: el encabezado de respuesta contiene información similar al encabezado de la solicitud, como: CSeq (número de secuencia utilizado para identificar la solicitud), ID de sesión (identificador de sesión), Transporte (protocolo de transporte), etc. El formato de cada campo del encabezado de respuesta es el mismo que el del encabezado de la solicitud, por lo que no entraremos en detalles aquí.
    CSeq: 2
    Date: Wed, Feb 04 1970 03:25:10 GMT
    Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER
    
  • Cuerpo de respuesta: algunas respuestas RTSP (como DESCRIBE) pueden contener un cuerpo de respuesta para transmitir datos adicionales.Nota: Después del encabezado de respuesta, se debe insertar una línea en blanco (CRLF) paraDistinguir entre encabezados de respuesta y cuerpo de respuesta
    A continuación se muestra un ejemplo de un cuerpo de respuesta completo.
    v=0
    o=- 8913478 1 IN IP4 192.168.3.91
    s=LIVE555 Streaming Media v2016.07.19
    i=1080
    t=0 0
    a=tool:LIVE555 Streaming Media v2016.07.19
    a=type:broadcast
    a=control:*
    a=range:npt=0-
    a=x-qt-text-nam:LIVE555 Streaming Media v2016.07.19
    a=x-qt-text-inf:1080
    m=video 0 RTP/AVP 96
    c=IN IP4 0.0.0.0
    b=AS:5000
    a=rtpmap:96 H264/90000
    a=fmtp:96 packetization-mode=1;profile-level-id=64002A;sprop-parameter-sets=Z2QAKq2EAQwgCGEAQwgCGEAQwgCEO1A8ARPyoA==,aO48sA==
    a=control:track1
    m=audio 0 RTP/AVP 97
    c=IN IP4 0.0.0.0
    b=AS:768
    a=rtpmap:97 PCMA/48000/2
    a=control:track2
    

Insertar descripción de la imagen aquí

🎄四、RTSP 报文的常用字段

El encabezado de respuesta del mensaje RTSP contendrá algunos campos. Los siguientes son algunos campos de uso común:

  • Aceptar : Se utiliza para especificar el tipo de estructura de datos de entidad que el cliente informa al servidor que acepte. Por ejemplo: Aceptar: aplicación/sdp, luego el servidor devuelve el tipo de estructura de datos de su entidad a través del campo Tipo de contenido;
  • Accept-Encoding: utilizado por el cliente para notificar al servidor los formatos de compresión de datos que puede aceptar, por ejemplo: Accept-Encoding: gzip, compress, br. Luego, el servidor notificará al cliente su elección a través del campo Content-Encoding. .
  • Accept-Language: utilizado por el cliente para notificar al servidor los idiomas que puede entender y su aceptación, por ejemplo: Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q =0.7, *; q=0.5, después de lo cual el servidor notificará al cliente su elección a través del campo Contenido-Idioma
  • Autorización: el encabezado de la solicitud del cliente contiene las credenciales utilizadas por el servidor para autenticar el agente de usuario.
  • Ancho de banda: se utiliza para describir el valor del ancho de banda disponible para el cliente. Por ejemplo: Ancho de banda: 4000
  • Tamaño de bloque: el cliente envía este campo al servidor de medios para solicitar un tamaño de paquete de medios específico del servidor; el servidor es libre de utilizar tamaños de bloque más pequeños que los solicitados. Este tamaño de paquete no incluye encabezados de bajo nivel como IP, UDP o RTP.
  • CSeq : Especifica el número de secuencia de la respuesta de la solicitud RTSP. Cada solicitud RTSP debe contener un valor CSeq único para que el servidor pueda identificar y procesar correctamente la solicitud. Este número de secuencia se incrementa con los mensajes de solicitud. La respuesta del servidor debe tener un valor CSeq que indique a qué solicitud responder.
  • Control de caché: implemente el mecanismo de almacenamiento en caché especificando instrucciones.Las directivas de almacenamiento en caché son unidireccionales, lo que significa que las directivas establecidas en la solicitud no necesariamente se incluyen en la respuesta.
  • Conferencia: notifique al servidor que el ID de conferencia de la misma sesión RTSP no debe cambiarse
  • Conexión: este campo determina si la conexión de red se cerrará después de que se complete la transacción actual. Si el valor es "mantener vivo", la conexión de red es persistente y no se cerrará, por lo que las solicitudes al mismo servidor pueden continuar completándose en la conexión o Conexión: cerrar.
  • Largancia de contenido : Este campo indica la longitud del contenido después del doble CRLF que sigue al último encabezado del protocolo RTSP.Por ejemplo, en la respuesta del servidor DESCRIBIR, especifique la longitud de la información sdp
  • Tipo de contenido: Le dice al cliente el tipo de contenido real devuelto.
  • Fecha : proporciona la fecha y hora en que el servidor generó la respuesta, lo que ayuda al cliente a determinar la actualidad de la respuesta o realizar la sincronización horaria. El formato del campo Fecha cumple con RFC 1123, por ejemplo: sábado, 6 de abril de 2024 11:15:00 GMT.
  • Agente de usuario: este campo se utiliza para permitir que el par del protocolo de red identifique el tipo de aplicación, el sistema operativo, el desarrollador de software y el número de versión del software del agente de usuario que inició la solicitud.
  • Expires: Especifica el tiempo de vencimiento.
  • Sonó: Se utiliza para especificar un rango de tiempo; puede utilizar SMPTE, NTP o unidad de tiempo de reloj.
  • Sesión :El campo de encabezado de sesión identifica una sesión RTSP. El ID de sesión lo determina el servidor enSETUPSeleccionado en la respuesta, una vez que el cliente obtenga el ID de sesión, incluirá el ID de sesión en futuros mensajes de solicitud de operación para la sesión. Por ejemplo: Sesión: 4581E0AE tiempo de espera = 65.
  • Transporte : El campo del encabezado de Transporte contiene una lista de opciones de transporte aceptables para el cliente, incluido el protocolo de transporte, el puerto de dirección, TTL, etc. El servidor también devuelve la opción específica realmente seleccionada a través de este campo de encabezado. Por ejemplo: Transporte: RTP/AVP/TCPunicast;destino=192.168.31.222;fuente=192.168.31.222;interleaved=0-1

Insertar descripción de la imagen aquí

🎄五、RTSP 流程抓包解析

Utilice Wireshark para capturar los paquetes de red de los medios de transmisión RTSP. Puede ver que el proceso general es el siguiente:
1. El cliente envíaOPTIONSMétodo, respuesta del servidor;
2. El cliente envíaDESCRIBEMétodo, respuesta del servidor;
3. El cliente envíaSETUPMétodo, respuesta del servidor;
2. El cliente envíaPLAYMétodo, respuesta del servidor;
2. El cliente envíaTEARDOWNMétodo, respuesta del servidor;
Insertar descripción de la imagen aquí
El paquete de flujo completo es el siguiente:

OPTIONS rtsp://192.168.3.225:554/wbc RTSP/1.0
CSeq: 2
User-Agent: LibVLC/3.0.19 (LIVE555 Streaming Media v2016.11.28)

RTSP/1.0 200 OK
CSeq: 2
Date: Wed, Jul 03 2024 14:42:11 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER

DESCRIBE rtsp://192.168.3.225:554/wbc RTSP/1.0
CSeq: 3
User-Agent: LibVLC/3.0.19 (LIVE555 Streaming Media v2016.11.28)
Accept: application/sdp

RTSP/1.0 200 OK
CSeq: 3
Date: Wed, Jul 03 2024 14:42:11 GMT
Content-Base: rtsp://192.168.3.225/wbc/
Content-Type: application/sdp
Content-Length: 472

v=0
o=- 1720014950032000 1 IN IP4 192.168.3.225
s=LIVE555 Streaming Media v2016.07.19
i=wbc
t=0 0
a=tool:LIVE555 Streaming Media v2016.07.19
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:LIVE555 Streaming Media v2016.07.19
a=x-qt-text-inf:wbc
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:5000
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=640029;sprop-parameter-sets=Z2QAKawsaoHgCJ WbgoCCgQ=,aO4xshs=
a=control:track1
SETUP rtsp://192.168.3.225/wbc/track1 RTSP/1.0
CSeq: 4
User-Agent: LibVLC/3.0.19 (LIVE555 Streaming Media v2016.11.28)
Transport: RTP/AVP;unicast;client_port=55320-55321

RTSP/1.0 200 OK
CSeq: 4
Date: Wed, Jul 03 2024 14:42:11 GMT
Transport: RTP/AVP;unicast;destination=192.168.2.180;source=192.168.3.225;client_port=55320-55321;server_port=6970-6971
Session: 4581E0AE;timeout=65

PLAY rtsp://192.168.3.225/wbc/ RTSP/1.0
CSeq: 5
User-Agent: LibVLC/3.0.19 (LIVE555 Streaming Media v2016.11.28)
Session: 4581E0AE
Range: npt=0.000-

RTSP/1.0 200 OK
CSeq: 5
Date: Wed, Jul 03 2024 14:42:11 GMT
Range: npt=0.000-
Session: 4581E0AE
RTP-Info: url=rtsp://192.168.3.225/wbc/track1;seq=7880;rtptime=3548171463

TEARDOWN rtsp://192.168.3.225/wbc/ RTSP/1.0
CSeq: 6
User-Agent: LibVLC/3.0.19 (LIVE555 Streaming Media v2016.11.28)
Session: 4581E0AE

RTSP/1.0 200 OK
CSeq: 6
Date: Wed, Jul 03 2024 14:42:19 GMT

A continuación se analizará cada método RTSP y respuesta utilizados en el mensaje anterior.

✨5.1, método OPCIÓN

Obtenga métodos disponibles del servidor:
Insertar descripción de la imagen aquí
El cliente envía el método OPCIONES y utilizaCSeq Para especificar el número de secuencia de la solicitud, utiliceUser-Agent identificar al propio agente;
El servidor responderá a la solicitud utilizandoCSeq Para indicar a qué solicitud se está respondiendo, utiliceDateespecificar la fecha,PublicEspecifica el método proporcionado.


✨5.2, método DESCRIBIR

Obtener del servidorrtsp://192.168.3.225:554/wbcuna descripción del objeto multimedia, dondeAcceptEl campo especifica el formato de descripción:

Insertar descripción de la imagen aquí
El cliente envía el método DESCRIBE y utilizaCSeq Para especificar el número de secuencia de la solicitud, utiliceUser-Agent identificar a su agente,AcceptEl campo especifica el formato de descripción como SDP;

El servidor responderá a esta solicitud utilizando CSeq Para indicar a qué solicitud se está respondiendo, utiliceDateespecificar la fecha,Content-TypeIndica que el tipo de contenido es SDP,Content-LengthEspecifique la longitud del contenido.

Aviso
1. Para algunos que requieren un nombre de usuario y contraseña, el servidor procesará el método DESCRIBE para la autenticación. Si la información de autenticación de autorización no se transporta, o la autenticación falla, el servidor devolverá una respuesta con el número de error 401. Cuando el cliente recibe la respuesta 401, necesita generar una autorización basada en la información de autenticación del usuario conocida y enviar la descripción nuevamente. Si la autenticación es exitosa, el servidor devuelve información de respuesta que contiene SDP.
2. La información SDP devuelta por el servidor se analizará en un artículo posterior.


✨5.3, método de CONFIGURACIÓN

El cliente solicita al servidor que establezca una sesión y se prepare para la transmisión. La información de la solicitud incluye principalmente el protocolo de transmisión y el número de puerto del cliente;

Insertar descripción de la imagen aquí
El cliente envía el método SETUP y utilizaCSeq Para especificar el número de secuencia de la solicitud, utiliceUser-Agent identificar a su agente,TransportEl campo especifica el protocolo de transmisión aceptable RTP/AVP y el puerto (aquí el puerto RTP es 55320 y el puerto RTCP es 55321);

El servidor responderá a esta solicitud utilizando CSeq Para indicar a qué solicitud se está respondiendo, utiliceDateespecificar la fecha,TransportEspecifique el protocolo de transporte RTP/AVP, la dirección de destino, la dirección de origen, el puerto del cliente (RTP es 55320, RTCP es 55321), el puerto del servidor (RTP es 6970, RTCP es 6971),SessionEspecifique el ID de la sesión.

Aviso
En este ejemplo, RTP se transmite a través del protocolo UDP. A veces, RTP se transmite a través de TCP y luego.Transport Los campos variarán. Podría ser el siguiente:

客户端请求:Transport: RTP/AVP/TCP;unicast;interleaved=0-1
服务器响应:Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=24e4e500;mode="play"

RTP/AVP/TCPIndica que el flujo RTP se transmite a través de TCP. Cuando aparece este valor, el mensaje no tiene el campo client_port;
interleaved=0-1Representa streamid, identificando RTP streamid=0; RTCP streamid=1;
Cuando el flujo de código se transmite a través de TCP, comparte un enlace TCP con RTSP, por lo que no es necesario establecer una nueva conexión. Para distinguir los protocolos RTP, RTCP y RTSP, es necesario agregar un identificador de encabezado TCPHEAD. Aquí se utiliza el campo de encabezado, y el tcphead es una sección de cuatro palabras, el formato es el siguiente:

| magic number | channel number | embedded data length | data |

magic number: 1 byte, fijado en0x24, es un personaje$, indica que los datos que se transmiten no son el protocolo rtsp;
channel number: 1 byte, ID de canal, que identifica el tipo de flujo, que es el ID de flujo mencionado anteriormente;
embedded data length : 2 bytes, que indica la longitud del flujo
data: Indica datos de paquetes RTP/RTCP


✨5.4, método JUGAR

El cliente notifica activamente al servidor que comience a enviar datos utilizando el mecanismo especificado por SETUP.

Insertar descripción de la imagen aquí
El cliente envía el método PLAY y utilizaCSeq Para especificar el número de secuencia de la solicitud, utiliceUser-Agent identificar a su agente,SessionEl campo especifica el ID de la sesión.RangeEl campo especifica la hora de inicio y finalización de la reproducción.

El servidor responderá a esta solicitud utilizando CSeq Indique a qué solicitud se está respondiendo;Dateespecificar fecha;RangeEl campo especifica la hora de inicio y finalización de la reproducción;SessionEl campo especifica el ID de la sesión;RTP-InfoEl campo describe la información RTP del flujo de código que se enviará, como la secuencia y el tiempo de rtp del primer paquete RTP. El cliente puede demultiplexar según este campo.


✨5.5, método DE DESMONTAJE

El cliente solicita dejar de enviar la secuencia de URL especificada y liberar los recursos relacionados.
Insertar descripción de la imagen aquí
El cliente envía el método TEARDOWN y utilizaCSeq Para especificar el número de secuencia de la solicitud, utiliceUser-Agent identificar a su agente,SessionEl campo especifica el ID de la sesión.

El servidor responderá a esta solicitud utilizando CSeq Indique a qué solicitud se está respondiendo;DateEspecifique la fecha.


Insertar descripción de la imagen aquí

🎄六、RTSP 响应错误码

El contenido de la respuesta de RTSP generalmente contiene un código de respuesta entero de 3 dígitos y una frase de motivo. El propósito de la frase es brindar una breve descripción de texto del código de estado. El cliente no necesita verificar ni mostrar la frase de motivo. Según la diferencia entre el primer dígito del código de respuesta, se puede dividir en las siguientes cinco categorías:

  • 1xx: Consejo: la solicitud se recibió y se está procesando
  • 2xx: Éxito: la solicitud se procesó correctamente
  • 3xx: Redirección: se deben tomar medidas adicionales para completar la solicitud
  • 4xx: Error del cliente: la solicitud contenía parámetros o sintaxis incorrectos y no se pudo cumplir.
  • 5xx: Error del servidor: el servidor no pudo cumplir con la solicitud correcta del cliente

Por supuesto, los códigos de error RTSP y los métodos RTSP están fuertemente relacionados. Es posible que algunos errores solo se activen en métodos específicos. La información detallada del código de error es la siguiente:

código de errorfrase de razonmétodo de respuesta
100ContinuarTodo
200ÉxitoTodo
201CreadoREGISTRO
250Poco espacio de almacenamientoREGISTRO
300Múltiples opcionesTodo
301Movido permanentementeTodo
302Mudado temporalmenteTodo
303Ver otrosTodo
305Usa proxyTodo
400Solicitud incorrectaTodo
401No autorizadoTodo
402pago requeridoTodo
403ProhibidoTodo
404ExtraviadoTodo
405Método no permitidoTodo
406InaceptableTodo
407Se requiere autenticación proxyTodo
408Pide tiempo fueraTodo
410DesaparecidoTodo
411Longitud requeridaTodo
412Precondición fallida DESCRIBIRCONFIGURACIÓN
413La entidad de solicitud es demasiado grandeTodo
414La URL de solicitud es demasiado largaTodo
415Tipo de medio no compatibleTodo
451Parametro invalidoCONFIGURACIÓN
452Identificador de conferencia ilegalCONFIGURACIÓN
453No hay suficiente ancho de bandaCONFIGURACIÓN
454Sesión no encontradaTodo
455Método no válido en este estadoTodo
456Campo de encabezado no válidoTodo
457Rango inválidoJUGAR
458El parámetro es de solo lecturaESTABLECER_PARÁMETRO
459Operación agregada no permitidaTodo
460Solo se permiten operaciones agregadasTodo
461Transporte sin soporteTodo
462Destino inalcanzableTodo
500Error Interno del ServidorTodo
501No se ha implementadoTodo
502Puerta de enlace defectuosaTodo
503Servicio No DisponibleTodo
504Tiempo de espera de la puerta de enlaceTodo
505Versión RTSP no compatibleTodo
551Opción no compatibleTodo

Insertar descripción de la imagen aquí
如果文章有帮助的话,点赞👍、收藏⭐,支持一波,谢谢 😁😁😁

Referirse a:
Protocolo de transmisión en tiempo real: RTSP [explicación detallada]
Dominar solicitudes y respuestas RTSP desde cero 1
Explicación detallada del protocolo de transmisión de medios RTSP