Partage de technologie

[Audio et Vidéo | RTSP] Explication détaillée du protocole RTSP et analyse d'exemples de capture de paquets (détaillée sans entrer dans les détails)

2024-07-08

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

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

Cet article ne peut pas être transmis sans autorisation ! ! !


Insérer la description de l'image ici

🎄一、概述

RTSP, nom complet Real Time Streaming Protocol, le protocole de streaming en temps réel, est un protocole de couche application du système de protocole TCP/IP. Il s'agit d'une norme IETF RFC soumise par l'Université de Columbia, Netscape et RealNetworks.

Le document officiel sur le protocole RTSP est le RFC2326, lien vers le document :RFC2326-Protocole de diffusion en temps réel (RTSP)

La syntaxe et le fonctionnement du protocole RTSP sont référencés. HTTP/1.1, un protocole basé sur du texte qui utilise le jeu de caractères ISO10646 et le codage UTF-8 ; le protocole de couche transport qui transporte RTSP est ;TCP, port par défaut554; S'il s'agit d'un tunneling RTSP-over-HTTP, le port TCP par défaut est 8080, généralement utilisé en conjonction avec le protocole RTP/RTCP, le protocole RTP transmet les données de flux en temps réel et le protocole RTCP termine la transmission des flux de données et ; commandes de contrôle.

Insérer la description de l'image ici

Protocole RTP : nom completReal-time Transport Protocol , le protocole de transmission en temps réel, a été annoncé par le groupe de travail sur la transmission multimédia de l'IETF en 1996 dans la RFC 1889. Le protocole RTP détaille le format de paquet standard pour la diffusion audio et vidéo sur Internet. Il est construit sur le protocole UDP.

Protocole RTCP : nom completReal-time Transport Control Protocol , Protocole de contrôle de transport en temps réel, utilisé avec RTP. RTP utilise un port UDP pair ; RTCP utilise le port suivant de RTP, qui est un port impair. RTCP et RTP fonctionnent ensemble. RTP implémente la transmission des données réelles et RTCP est responsable de l'envoi des paquets de contrôle à toutes les personnes participant à la session. Sa fonction principale est de fournir un retour d'information sur la qualité du service fourni par RTP.

La différence entre le protocole RTSP et le protocole HTTP :
RTSP est avec état et ses commandes sont toujours envoyées dans l'ordre, et une commande peut toujours devoir être envoyée avant une autre commande. HTTP est sans état Une fois que le protocole envoie une commande, la connexion est déconnectée et il n'y a aucune dépendance entre les commandes.
Le protocole rtsp utilise le port 554 et http utilise le port 80.
Les requêtes RTSP peuvent être envoyées à la fois par le serveur et par le client, tandis que les requêtes HTTP ne peuvent être envoyées que par le client.


Insérer la description de l'image ici

🎄二、RTSP 方法

Les méthodes RTSP couramment utilisées incluent : OPTIONS, DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN, ANNOUNCE, GET_PARAMETER et SET_PARAMETER, etc. Les instructions d'utilisation détaillées sont les suivantes :

  • OPTIONS : Le client obtient du serveur la méthode prise en charge par le serveur. Cela n'affecte pas l'état du serveur ;
  • DESCRIBE: Le client obtient du serveur la description de l'objet média spécifié par l'URL, oùAcceptLe champ spécifie le format de description ;
  • SETUP : Le client demande au serveur d'établir une session et de préparer la transmission. Les informations de la demande comprennent principalement le protocole de transmission et le numéro de port du client ;
  • PLAY : Le client informe activement le serveur de commencer à envoyer des données en utilisant le mécanisme spécifié par SETUP.dansRangeLe champ précise l'heure de début et de fin de lecture (la plage du flux en temps réel est généralementRange: npt=0.000-), lorsque plusieurs requêtes PLAY arrivent, le serveur mettra les requêtes PLAY en file d'attente et les exécutera séquentiellement, c'est-à-dire qu'il devra attendre la fin du premier temps PLAY avant de continuer à traiter le deuxième message PLAY.
  • PAUSE : Le client demande que le streaming multimédia du serveur soit temporairement suspendu.capable de passerRangeLe paramètre s'arrête à un instant spécifié, ou vous pouvez spécifier un flux à mettre en pause. Par exemple, si vous spécifiez un flux audio à mettre en pause, la lecture sera silencieuse.
  • RECORD : RECORD informe le serveur que le client va commencer à enregistrer les données multimédias selon la description précédente. danstimestamp Les champs reflètent les heures de début et de fin (UTC). Si ce champ n'est pas présent, l'heure de début ou de fin de la description du média sera utilisée. Si la session a déjà commencé, l'enregistrement démarre immédiatement.
    Le serveur décide s'il doit stocker les données enregistrées dansrequest-URI Suivant ou un autre URI. Si le serveur n'utilise pas d'URI de demande, la réponse doit être 201 (Créé) et contenir un en-tête Entité et Emplacement décrivant l'état de la demande et faisant référence à la nouvelle ressource.
  • TEARDOWN : le client demande d'arrêter d'envoyer le flux d'URL spécifié et de libérer les ressources associées.
  • REDIRECT : Pour rediriger une requête, le serveur informe le client qu'il doit se connecter à un autre emplacement de serveur. Il contient l'en-tête obligatoire Location, qui indique que le client doit faire une demande pour cette URL. Il peut contenir le paramètre Range, indiquant quand la redirection prendra effet. Si le client souhaite continuer à envoyer ou à recevoir des médias pour cet URI, il doit émettre une demande TEARDOWN pour la session en cours et une demande SETUP pour la nouvelle session sur l'hôte spécifié.
  • ANNOUNCE: Lorsque le client envoie au serveur, cela signifie soumettre la description de la présentation ou l'objet média identifié par l'URL de la requête au serveur.
    Lorsque le serveur l'envoie au client, cela signifie demander au client de mettre à jour les informations de session.
  • GET_PARAMETER :GET_PARAMETER requête pour récupérer les valeurs des paramètres pour la représentation ou le flux spécifié dans l'URI. Le contenu des réponses et des réponses est laissé à la mise en œuvre. GET_PARAMETER sans corps d'entité peut être utilisé pour tester l'activité (« ping ») d'un client ou d'un serveur.
  • SET_PARAMETER : Cette méthode demande de définir les valeurs des paramètres du flux spécifié par la démo ou l'URL. Les requêtes ne doivent contenir qu'un seul paramètre, permettant au client de décider pourquoi une requête particulière a échoué. Si la requête contient plusieurs paramètres, tous les paramètres peuvent être définis avec succès et le serveur ne doit agir que sur cette requête. Le serveur doit permettre que les paramètres soient définis à plusieurs reprises sur la même valeur, mais ne doit pas modifier la valeur du paramètre. Remarque : Les paramètres de diffusion multimédia doivent être définis à l'aide de la commande SETUP. Il est avantageux pour les pare-feu de limiter les paramètres de transfert de configuration à SETUP.

Au total, 11 méthodes RTSP sont présentées ci-dessus, parmi lesquelles :SETUPPLAYTEARDOWN Les trois commandes sont nécessaires dans le processus RTSP et les autres méthodes ne sont pas nécessaires.etANNOUNCEGET_PARAMETERSET_PARAMETERLes trois commandes peuvent être envoyées du client au serveur ou du serveur au client. Les autres commandes sont envoyées du client au serveur.


Insérer la description de l'image ici

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

RTSP a deux types de messages : les messages de demande et les messages de réponse. Le message de demande fait référence au message de demande envoyé du client au serveur et le message de réponse fait référence à la réponse du serveur au client.

✨3.1, message de demande RTSP

Le message de requête RTSP se compose de trois parties : la ligne de requête, l'en-tête de la requête et le corps de la requête. Parmi eux, la ligne de requête est obligatoire, tandis que l'en-tête et le corps de la requête sont facultatifs en fonction de la situation spécifique.
Insérer la description de l'image ici

  • Ligne de requête : La ligne de requête est constituée d'une méthode, d'un URI de requête et d'une version de protocole séparés par des espaces et précédés de CRLF (c'est-à-dire :rn)Finition.
    方法 : C'est la méthode RTSP introduite ci-dessus. Y compris OPTIONS, DESCRIPTION, CONFIGURATION, LECTURE, PAUSE, DÉMONTAGE, etc.
    请求URI: Identifie la ressource multimédia à exploiter, généralement au format rtsp://example.com/path/to/stream.
    协议版本: Indique la version du protocole RTSP suivie par la requête, généralementRTSP/1.0ouRTSP/2.0
    Voici un exemple de ligne de requête complète :
    OPTIONS rtsp://192.168.3.225:554/wbc RTSP/1.0
    
  • En-tête de requête : l'en-tête de requête contient des informations supplémentaires, telles que : CSeq (numéro de séquence utilisé pour identifier la requête), Session ID (identifiant de session), Transport (protocole de transport), etc. Chaque champ d'en-tête se compose d'un nom de champ, de deux points et d'une valeur de champ, et chaque champ d'en-tête est séparé par CRLF.
    Voici un exemple d’en-tête de requête complet :
    CSeq: 2
    User-Agent: LibVLC/3.0.19 (LIVE555 Streaming Media v2016.11.28)
    
  • Corps de la requête : le corps de la requête est utilisé pour transmettre des données supplémentaires. Le contenu spécifique du corps de la requête dépend de la méthode RTSP utilisée dans la ligne de requête. Remarque : Après l'en-tête de la demande, une ligne vide (CRLF) doit être insérée pour distinguer l'en-tête de la demande du corps de la demande. La plupart des messages de requête n'ont pas de corps de requête.

✨3.2, message de réponse RTSP

Le message de demande RTSP se compose de trois parties : la ligne d'état, l'en-tête de réponse et le corps de la réponse. Parmi eux, la ligne d'état est obligatoire, tandis que l'en-tête de réponse et le corps de la réponse sont facultatifs en fonction de la situation spécifique.
Insérer la description de l'image ici

  • Ligne d'état : La ligne d'état contient une version du protocole, un code d'état et un texte d'état, séparés par des espaces et terminés par CRLF (c'est-à-dire : "rn").
    协议版本: Indique la version du protocole RTSP suivie par la réponse, généralement RTSP/1.0 ou RTSP/2.0.
    状态码 : Trois chiffres, tels que : 200, 401, 500, etc., utilisés pour indiquer le résultat du traitement de la demande. Le premier chiffre représente la catégorie de réponse : 2xx indique un succès, 4xx indique une erreur client et 5xx indique une erreur serveur.
    状态文本: Une brève description textuelle expliquant la signification spécifique du code d'état correspondant, tel que : OK, Non autorisé, etc.
    Voici un exemple de ligne de réponse :
    RTSP/1.0 200 OK
    
  • En-tête de réponse : L'en-tête de réponse contient des informations similaires à l'en-tête de demande, telles que : CSeq (numéro de séquence utilisé pour identifier la demande), Session ID (identifiant de session), Transport (protocole de transport), etc. Le format de chaque champ d’en-tête de réponse est le même que celui de l’en-tête de requête, nous n’entrerons donc pas dans les détails ici.
    CSeq: 2
    Date: Wed, Feb 04 1970 03:25:10 GMT
    Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER
    
  • Corps de réponse : certaines réponses RTSP (telles que DESCRIBE) peuvent contenir un corps de réponse pour transmettre des données supplémentaires.Remarque : Après l'en-tête de réponse, une ligne vierge (CRLF) doit être insérée pourDistinguer les en-têtes de réponse et le corps de la réponse
    Vous trouverez ci-dessous un exemple de corps de réponse complet.
    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
    

Insérer la description de l'image ici

🎄四、RTSP 报文的常用字段

L'en-tête de réponse du message RTSP contiendra certains champs. Voici quelques champs couramment utilisés :

  • Accepter : Utilisé pour spécifier le type de structure de données d'entité que le client demande au serveur d'accepter. Par exemple : Acceptez : application/sdp, puis le serveur renvoie son type de structure de données d'entité via le champ Content-Type ;
  • Accept-Encoding : Utilisé par le client pour notifier au serveur les formats de compression de données qu'il peut accepter, par exemple : Accept-Encoding : gzip, compress, br Le serveur notifiera ensuite au client son choix via le champ Content-Encoding. .
  • Accept-Language : utilisé par le client pour notifier au serveur les langues qu'il peut comprendre et son acceptation, par exemple : Accept-Language : fr-CH, fr;q=0.9, en;q=0.8, de;q =0,7, *; q=0,5, après quoi le serveur notifiera au client son choix via le champ Content-Language
  • Autorisation : l'en-tête de la demande du client contient les informations d'identification utilisées par le serveur pour authentifier l'agent utilisateur.
  • Bande passante : utilisée pour décrire la valeur de la bande passante disponible pour le client. Par exemple : Bande passante : 4 000
  • Taille de bloc : ce champ est envoyé par le client au serveur multimédia pour demander une taille de paquet multimédia spécifique au serveur, le serveur est libre d'utiliser des tailles de bloc plus petites que celles demandées. Cette taille de paquet n'inclut pas les en-têtes de bas niveau tels que IP, UDP ou RTP
  • CSeq : Spécifie le numéro de séquence de la réponse à la demande RTSP. Chaque demande RTSP doit contenir une valeur CSeq unique afin que le serveur puisse identifier et traiter correctement la demande. Ce numéro de séquence est incrémenté avec les messages de requête. La réponse du serveur doit avoir une valeur CSeq indiquant à quelle requête répondre.
  • Cache-Control : implémentez le mécanisme de mise en cache en spécifiant des instructions.Les directives de mise en cache sont à sens unique, ce qui signifie que les directives définies dans la requête ne sont pas nécessairement incluses dans la réponse.
  • Conférence : avertissez le serveur que l'ID de conférence de la même session RTSP ne doit pas être modifié.
  • Connexion : ce champ détermine si la connexion réseau sera fermée une fois la transaction en cours terminée. Si la valeur est « keep-alive », la connexion réseau est persistante et ne sera pas fermée, de sorte que les requêtes adressées au même serveur peuvent continuer à être complétées sur la connexion ou Connexion : fermer.
  • Contenu-Longueur : Ce champ indique la longueur du contenu après le double CRLF suivant le dernier en-tête du protocole RTSP.Par exemple, dans la réponse du serveur DESCRIBE, spécifiez la longueur des informations sdp
  • Type de contenu : indique au client le type de contenu du contenu réel renvoyé
  • Date : Fournit la date et l'heure auxquelles le serveur a généré la réponse, ce qui aide le client à déterminer la fraîcheur de la réponse ou à effectuer la synchronisation de l'heure. Le format du champ Date est conforme à la RFC 1123, par exemple : samedi 6 avril 2024 11:15:00 GMT.
  • Agent utilisateur: Ce champ est utilisé pour permettre à l'homologue du protocole réseau d'identifier le type d'application, le système d'exploitation, le développeur du logiciel et le numéro de version du logiciel de l'agent utilisateur qui a initié la demande.
  • Expire : spécifie le délai d'expiration
  • A sonné: Utilisé pour spécifier une plage horaire, vous pouvez utiliser SMPTE, NTP ou l'unité de temps d'horloge.
  • Session :Le champ d'en-tête Session identifie une session RTSP. L'ID de session est déterminé par le serveur dansSETUPSélectionné dans la réponse, une fois que le client aura obtenu l'ID de session, il inclura l'ID de session dans les futurs messages de demande d'opération pour la session. Par exemple : Session : 4581E0AE timeout=65 ;
  • Transport : Le champ d'en-tête Transport contient une liste d'options de transport acceptables pour le client, notamment le protocole de transport, le port d'adresse, le TTL, etc. Le serveur renvoie également l'option spécifique réellement sélectionnée via ce champ d'en-tête. Par exemple : Transport : RTP/AVP/TCPunicast;destination=192.168.31.222;source=192.168.31.222;interleaved=0-1

Insérer la description de l'image ici

🎄五、RTSP 流程抓包解析

Utilisez Wireshark pour capturer les paquets réseau des médias de streaming RTSP. Vous pouvez voir que le processus général est le suivant :
1. Le client envoieOPTIONSMéthode, réponse du serveur ;
2. Le client envoieDESCRIBEMéthode, réponse du serveur ;
3. Le client envoieSETUPMéthode, réponse du serveur ;
2. Le client envoiePLAYMéthode, réponse du serveur ;
2. Le client envoieTEARDOWNMéthode, réponse du serveur ;
Insérer la description de l'image ici
Le paquet de flux complet est le suivant :

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

Ce qui suit analysera chaque méthode RTSP et réponse utilisée dans le message précédent.

✨5.1, méthode OPTION

Obtenez les méthodes disponibles sur le serveur :
Insérer la description de l'image ici
Le client envoie la méthode OPTIONS et utiliseCSeq Pour spécifier le numéro de séquence de la demande, utilisezUser-Agent identifier son propre agent;
Le serveur répondra à la demande en utilisantCSeq Pour indiquer à quelle demande on répond, utilisezDatepréciser la date,PublicSpécifie la méthode fournie.


✨5.2, méthode DESCRIBE

Obtenir du serveurrtsp://192.168.3.225:554/wbcune description de l'objet multimédia, oùAcceptLe champ précise le format de description :

Insérer la description de l'image ici
Le client envoie la méthode DESCRIBE et utiliseCSeq Pour spécifier le numéro de séquence de la demande, utilisezUser-Agent identifiez votre mandataire,AcceptLe champ spécifie le format de description comme SDP ;

Le serveur répondra à cette requête en utilisant CSeq Pour indiquer à quelle demande on répond, utilisezDatepréciser la date,Content-TypeIndique que le type de contenu est SDP,Content-LengthSpécifiez la longueur du contenu.

Avis
1. Pour certains nécessitant un nom d'utilisateur et un mot de passe, le serveur traitera la méthode DESCRIBE pour l'authentification. Si les informations d'authentification d'autorisation ne sont pas transmises ou si l'authentification échoue, le serveur renvoie une réponse avec le numéro d'erreur 401. Lorsque le client reçoit la réponse 401, il doit générer une autorisation basée sur les informations d'authentification de l'utilisateur connues et envoyer à nouveau une description. Si l'authentification réussit, le serveur renvoie les informations de réponse portant SDP.
2. Les informations SDP renvoyées par le serveur seront analysées dans un article ultérieur.


✨5.3, méthode SETUP

Le client demande au serveur d'établir une session et de préparer la transmission. Les informations de la demande comprennent principalement le protocole de transmission et le numéro de port du client ;

Insérer la description de l'image ici
Le client envoie la méthode SETUP et utiliseCSeq Pour spécifier le numéro de séquence de la demande, utilisezUser-Agent identifiez votre mandataire,TransportLe champ spécifie le protocole de transmission RTP/AVP et le port acceptables (ici le port RTP est 55320 et le port RTCP est 55321) ;

Le serveur répondra à cette requête en utilisant CSeq Pour indiquer à quelle demande on répond, utilisezDatepréciser la date,TransportSpécifiez le protocole de transport RTP/AVP, l'adresse de destination, l'adresse source, le port client (RTP est 55320, RTCP est 55321), le port du serveur (RTP est 6970, RTCP est 6971),SessionSpécifiez l'ID de session.

Avis
Dans cet exemple, RTP est transmis via le protocole UDP. Parfois, RTP sera transmis via TCP, puis.Transport Les champs varient. Cela pourrait être le suivant :

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

RTP/AVP/TCPIndique que le flux RTP est transmis via TCP. Lorsque cette valeur apparaît, le message n'a pas le champ client_port ;
interleaved=0-1Représente streamid, identifiant RTP streamid=0 ; RTCP streamid=1 ;
Lorsque le flux de code est transmis via TCP, il partage une liaison TCP avec RTSP, il n'a donc pas besoin d'établir une nouvelle connexion. Afin de distinguer les protocoles RTP, RTCP et RTSP, un identifiant d'en-tête doit être ajouté. Le champ d'en-tête est utilisé ici, et le tcphead est une section de quatre mots, le format est le suivant :

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

magic number: 1 octet, fixé à0x24, est un personnage$, indiquant que les données transmises ne sont pas le protocole rtsp ;
channel number: 1 octet, ID de canal, identifiant le type de flux, qui est le streamid mentionné précédemment ;
embedded data length : 2 octets, indiquant la longueur du flux
data: Indique les données du paquet RTP/RTCP


✨5.4, méthode PLAY

Le client informe activement le serveur de commencer à envoyer des données en utilisant le mécanisme spécifié par SETUP.

Insérer la description de l'image ici
Le client envoie la méthode PLAY et utiliseCSeq Pour spécifier le numéro de séquence de la demande, utilisezUser-Agent identifiez votre mandataire,Sessionle champ spécifie l'ID de session,RangeLe champ spécifie l'heure de début et de fin de la lecture.

Le serveur répondra à cette requête en utilisant CSeq Indiquez à quelle demande il est répondu ;Datepréciser la date ;RangeLe champ spécifie l'heure de début et de fin de la lecture ;SessionLe champ spécifie l'ID de session ;RTP-InfoLe champ décrit les informations RTP du flux de code à envoyer, telles que la séquence et l'heure rtp du premier paquet RTP. Le client peut démultiplexer en fonction de ce champ.


✨5.5, méthode TEARDOWN

Le client demande d'arrêter d'envoyer le flux d'URL spécifié et de libérer les ressources associées.
Insérer la description de l'image ici
Le client envoie la méthode TEARDOWN et utiliseCSeq Pour spécifier le numéro de séquence de la demande, utilisezUser-Agent identifiez votre mandataire,SessionLe champ spécifie l'ID de session.

Le serveur répondra à cette requête en utilisant CSeq Indiquez à quelle demande il est répondu ;DatePrécisez la date.


Insérer la description de l'image ici

🎄六、RTSP 响应错误码

Le contenu de la réponse de RTSP contient généralement un code de réponse entier à 3 chiffres et une phrase de raison. Le but de la phrase est de donner une brève description textuelle du code d'état. Le client n'a pas besoin de vérifier ou d'afficher la phrase de raison. Selon la différence entre le premier chiffre du code de réponse, il peut être divisé en cinq catégories suivantes :

  • 1xx : Astuce - la demande a été reçue et est en cours de traitement
  • 2xx : Succès - la demande a été traitée avec succès
  • 3xx : Redirection – des mesures supplémentaires doivent être prises pour terminer la demande
  • 4xx : Erreur client - La demande contenait des paramètres ou une syntaxe incorrects et la demande n'a pas pu être satisfaite.
  • 5xx : Erreur du serveur – Le serveur n'a pas pu répondre à la demande correcte du client

Bien entendu, les codes d'erreur RTSP et les méthodes RTSP sont étroitement liés. Certaines erreurs ne peuvent être déclenchées que dans des méthodes spécifiques. Les informations détaillées sur les codes d'erreur sont les suivantes :

code d'erreurphrase de raisonméthode de réponse
100ContinuerTous
200SuccèsTous
201CrééENREGISTRER
250Manque d'espace de stockageENREGISTRER
300Choix multiplesTous
301Déménagé définitivementTous
302Déplacé temporairementTous
303Voir AutreTous
305Utiliser un proxyTous
400Mauvaise demandeTous
401Non autoriséTous
402Paiement RequisTous
403InterditTous
404Pas trouvéTous
405Méthode Non AutoriséeTous
406Pas acceptableTous
407Authentification proxy requiseTous
408Délai d'expiration de la demandeTous
410DisparuTous
411Longueur requiseTous
412Échec de la condition préalable DÉCRIREINSTALLATION
413Entité de demande trop grandeTous
414URI de requête trop longueTous
415Type de média non pris en chargeTous
451Paramètre invalideINSTALLATION
452Identifiant de conférence illégalINSTALLATION
453Pas assez de bande passanteINSTALLATION
454Session non trouvéeTous
455Méthode non valide dans cet étatTous
456Champ d'en-tête non valideTous
457Plage non valideJOUER
458Le paramètre est en lecture seuleSET_PARAMETER
459Opération d'agrégation non autoriséeTous
460Seules les opérations d'agrégation sont autoriséesTous
461Transport non pris en chargeTous
462Destination inaccessibleTous
500Erreur interne du serveurTous
501Pas mis en œuvreTous
502Mauvaise passerelleTous
503service non disponibleTous
504Délai d'expiration de la passerelleTous
505Version RTSP non prise en chargeTous
551Option non prise en chargeTous

Insérer la description de l'image ici
如果文章有帮助的话,点赞👍、收藏⭐,支持一波,谢谢 😁😁😁

faire référence à:
Protocole de streaming en temps réel – RTSP [explication détaillée]
Maîtrisez les demandes et les réponses RTSP à partir de zéro 1
Explication détaillée du protocole multimédia de streaming RTSP