Mi informacion de contacto
Correo[email protected]
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! ! !
RTSP, nombre completo Real Time Streaming Protocol
El 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 predeterminado554
Si 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.
Protocolo RTP: nombre completo
Real-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 completo
Real-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.
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, dondeAccept
El 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.enRange
El 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 pasarRange
El 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.request-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.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,SETUP
、PLAY
、TEARDOWN
Los tres comandos son necesarios en el proceso RTSP y no son necesarios otros métodos.yANNOUNCE
、GET_PARAMETER
、SET_PARAMETER
Los tres comandos se pueden enviar del cliente al servidor o del servidor al cliente. Los otros comandos se envían del cliente al servidor.
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.
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.
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.0
oRTSP/2.0
。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)
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.
协议版本
: 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.RTSP/1.0 200 OK
CSeq: 2
Date: Wed, Feb 04 1970 03:25:10 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER
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
El encabezado de respuesta del mensaje RTSP contendrá algunos campos. Los siguientes son algunos campos de uso común:
SETUP
Seleccionado 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.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íaOPTIONS
Método, respuesta del servidor;
2. El cliente envíaDESCRIBE
Método, respuesta del servidor;
3. El cliente envíaSETUP
Método, respuesta del servidor;
2. El cliente envíaPLAY
Método, respuesta del servidor;
2. El cliente envíaTEARDOWN
Método, respuesta del servidor;
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.
Obtenga métodos disponibles del servidor:
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, utiliceDate
especificar la fecha,Public
Especifica el método proporcionado.
Obtener del servidorrtsp://192.168.3.225:554/wbc
una descripción del objeto multimedia, dondeAccept
El campo especifica el formato de descripción:
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,Accept
El 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, utiliceDate
especificar la fecha,Content-Type
Indica que el tipo de contenido es SDP,Content-Length
Especifique 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.
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;
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,Transport
El 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, utiliceDate
especificar la fecha,Transport
Especifique 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),Session
Especifique 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/TCP
Indica 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-1
Representa 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
El cliente notifica activamente al servidor que comience a enviar datos utilizando el mecanismo especificado por SETUP.
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,Session
El campo especifica el ID de la sesión.Range
El 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;Date
especificar fecha;Range
El campo especifica la hora de inicio y finalización de la reproducción;Session
El campo especifica el ID de la sesión;RTP-Info
El 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.
El cliente solicita dejar de enviar la secuencia de URL especificada y liberar los recursos relacionados.
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,Session
El campo especifica el ID de la sesión.
El servidor responderá a esta solicitud utilizando CSeq
Indique a qué solicitud se está respondiendo;Date
Especifique la fecha.
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:
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 error | frase de razon | método de respuesta |
---|---|---|
100 | Continuar | Todo |
200 | Éxito | Todo |
201 | Creado | REGISTRO |
250 | Poco espacio de almacenamiento | REGISTRO |
300 | Múltiples opciones | Todo |
301 | Movido permanentemente | Todo |
302 | Mudado temporalmente | Todo |
303 | Ver otros | Todo |
305 | Usa proxy | Todo |
400 | Solicitud incorrecta | Todo |
401 | No autorizado | Todo |
402 | pago requerido | Todo |
403 | Prohibido | Todo |
404 | Extraviado | Todo |
405 | Método no permitido | Todo |
406 | Inaceptable | Todo |
407 | Se requiere autenticación proxy | Todo |
408 | Pide tiempo fuera | Todo |
410 | Desaparecido | Todo |
411 | Longitud requerida | Todo |
412 | Precondición fallida DESCRIBIR | CONFIGURACIÓN |
413 | La entidad de solicitud es demasiado grande | Todo |
414 | La URL de solicitud es demasiado larga | Todo |
415 | Tipo de medio no compatible | Todo |
451 | Parametro invalido | CONFIGURACIÓN |
452 | Identificador de conferencia ilegal | CONFIGURACIÓN |
453 | No hay suficiente ancho de banda | CONFIGURACIÓN |
454 | Sesión no encontrada | Todo |
455 | Método no válido en este estado | Todo |
456 | Campo de encabezado no válido | Todo |
457 | Rango inválido | JUGAR |
458 | El parámetro es de solo lectura | ESTABLECER_PARÁMETRO |
459 | Operación agregada no permitida | Todo |
460 | Solo se permiten operaciones agregadas | Todo |
461 | Transporte sin soporte | Todo |
462 | Destino inalcanzable | Todo |
500 | Error Interno del Servidor | Todo |
501 | No se ha implementado | Todo |
502 | Puerta de enlace defectuosa | Todo |
503 | Servicio No Disponible | Todo |
504 | Tiempo de espera de la puerta de enlace | Todo |
505 | Versión RTSP no compatible | Todo |
551 | Opción no compatible | Todo |
如果文章有帮助的话,点赞👍、收藏⭐,支持一波,谢谢 😁😁😁
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