2026-06-03

Débogage d'URL de contrôle d'agrégation RTSP : contrôle SDP :*, suivi des URL, SETUP 404 et échec de PLAY

Comment dépanner les URL de contrôle d'agrégation RTSP, les attributs de contrôle SDP :*, les chemins de contrôle au niveau de la piste, les erreurs SETUP 404, les échecs de PLAY et les bogues de construction d'URL de caméra.

Les URL de caméra RTSP échouent souvent parce que le client crée une mauvaise URL de contrôle à partir de SDP. Les utilisateurs recherchent « RTSP SETUP 404 », « Étoile de contrôle SDP », « URL de contrôle d'agrégation RTSP », « URL de piste RTSP incorrecte », « DESCRIBE fonctionne mais la configuration échoue » et « PLAY échoue après la configuration » lorsqu'une caméra renvoie SDP avec succès mais que le média ne démarre jamais.

RTSP Inspector est utile car cet échec ne concerne pas si le lecteur peut dessiner une vidéo. Il s'agit de savoir si le client RTSP a interprété correctement les attributs de « contrôle » au niveau de la session et au niveau du média.

Le symptôme commun

Une trace typique ressemble à ceci :

DESCRIBE rtsp://camera/live
200 OK
SDP contains a=control:*
SDP video media contains a=control:trackID=1
SETUP rtsp://camera/trackID=1
404 Not Found

The camera did not necessarily reject RTSP. The client may have constructed SETUP with the wrong base URL.

Session-level and media-level control

SDP can contain control attributes at different levels:

a=control:*
m=video 0 RTP/AVP 96
a=control:trackID=1
m=audio 0 RTP/AVP 97
a=control:trackID=2

Le contrôle au niveau de la session peut identifier la ressource globale utilisée pour « PLAY » et « PAUSE ». Le contrôle au niveau du support identifie chaque piste RTP utilisée pour « SETUP ».

Si un client traite chaque valeur de « contrôle » comme un chemin absolu, il peut créer des URL non valides.

URL de contrôle relatif ou absolu

Les valeurs de contrôle RTSP SDP peuvent être :

URL RTSP absolues.
Chemins relatifs.
Suivre les identifiants.
* contrôle global.
Chemins spécifiques au fournisseur.

Exemples :

a=control:rtsp://192.168.1.10/live/trackID=1
a=control:trackID=1
a=control:streamid=0
a=control:video
a=control:*

The client must combine relative track control values with the correct base URL. A tiny difference such as /live/trackID=1 vs /trackID=1 can turn a working camera into a 404 Not Found.

DESCRIBE succeeds but SETUP fails

This is one of the strongest search patterns for this article. DESCRIBE proves the camera accepted the main URL and returned SDP. SETUP failure points to transport negotiation, track URL construction, unsupported media track, or camera firmware behavior.

Evidence to collect:

Original DESCRIBE URL.
Content-Base header if present.
Content-Location header if present.
Session-level a=control.
Media-level a=control for each track.
Exact SETUP URL.
SETUP response status.
Transport header used by SETUP.

Without the SETUP URL, the diagnosis is incomplete.

Content-Base and Content-Location

Some cameras include Content-Base or Content-Location headers in the DESCRIBE response. These headers can affect how relative SDP control paths should be resolved.

Failure patterns:

Client ignores Content-Base.
Client uses the original DESCRIBE URL when camera intended a different base.
Camera returns a base URL with trailing slash differences.
Proxy rewrites the RTSP URL but not SDP.
Client normalizes away a path component needed by the camera.

These details are exactly why protocol evidence matters.

PLAY uses aggregate control

After SETUP succeeds for one or more tracks, PLAY may need to target the aggregate control URL instead of a single track URL. Some cameras accept either. Others are strict.

Search symptoms:

"RTSP SETUP works but PLAY fails"
"RTSP 460 Only Aggregate Operation Allowed"
"RTSP PLAY 404"
"RTSP track SETUP OK no video"

If PLAY targets the wrong URI, the RTP stream may never start even though SETUP returned 200 OK.

Multi-track audio and video

The bug is easier to see when both audio and video exist:

m=video ...
a=control:trackID=1
m=audio ...
a=control:trackID=2

Le client doit CONFIGURER les deux pistes avec leurs propres URL de contrôle, puis JOUER l'URL globale correcte. Si le client configure uniquement la vidéo mais que PLAY cible l'audio, ou s'il fusionne les deux pistes en une seule URL de CONFIGURATION, la caméra peut renvoyer une erreur qui ne semble pas liée.

URL du profil ONVIF vs URL de la piste RTSP

ONVIF peut signaler les URI de flux qui diffèrent des URL de piste SDP finales. Un URI de flux provenant d'ONVIF peut être valide pour DESCRIBE mais pas directement valide pour chaque requête SETUP.

Cela crée la phrase de support courante : « ONVIF fonctionne mais l'URL RTSP échoue. » L'étape de diagnostic suivante consiste à inspecter les URL SDP et SETUP dérivées, et non à continuer à générer de nouvelles URL ONVIF.

Liste de contrôle de débogage

Utilisez ce flux de travail :

Capturez la réponse DÉCRIRE.
Enregistrez Content-Base et Content-Location.
Extrayez a=control au niveau de la session.
Extrayez chaque a=control au niveau du média.
Créez manuellement l'URL de configuration attendue.
Comparez-le avec l'URL de configuration du client.
Vérifiez si SETUP échoue avec 404, 461 ou 500.
Confirmez si PLAY cible l'URL globale ou le suivi.
Vérifiez le comportement audio/vidéo multipiste.
Conservez les lignes de demande RTSP exactes pour le support du fournisseur.

Diagnostic final

Les bogues de contrôle d’agrégat RTSP se cachent dans l’interprétation SDP. Une caméra peut accepter DESCRIBE et rejeter toujours SETUP ou PLAY si le client crée une mauvaise URL de piste ou de contrôle d'agrégat.

RTSP Inspector permet d'exposer les attributs de contrôle SDP, les en-têtes Content-Base, les URL SETUP et la cible PLAY afin que les ingénieurs puissent prouver si le problème concerne la construction de l'URL, la rigueur de la caméra, la réécriture du proxy ou la gestion SDP côté client.

Preuve reproductible pour « Débogage d'URL de contrôle d'agrégation RTSP : contrôle SDP :*, suivi des URL, SETUP 404 et échec de PLAY »

La réponse directe est qu’un écran noir ou un code isolé ne prouve pas l’origine d’une panne de caméra. Un diagnostic fiable relie requête et réponse RTSP, transport négocié, session valide, puis numéros de séquence RTP, horodatages et éléments RTCP. Pour « Débogage d'URL de contrôle d'agrégation RTSP : contrôle SDP :*, suivi des URL, SETUP 404 et échec de PLAY », partez de la couche la plus proche du symptôme, tout en conservant une chronologie unique afin de ne pas confondre contrôle, réseau et décodage.

Avant de modifier caméra, pare-feu ou VMS, établissez un test de référence. Notez l’URL RTSP sans mot de passe, l’heure, le chemin, le transport demandé, la réponse du serveur et l’arrivée du premier paquet média. Testez séparément UDP et TCP interleaved si l’équipement les propose. Ne changez pas à la fois chemin, identifiants et transport : un second essai réussi ne dirait pas quelle variable a corrigé l’écart.

Couche	Preuve à conserver	Question de décision
RTSP	méthode, statut, en-têtes, CSeq et Session	Le serveur accepte-t-il précisément l’opération ?
SDP	control, payload type, clock rate et codec	La piste décrite est-elle celle attendue ?
Transport	client_port, server_port ou interleaved	Les deux extrémités utilisent-elles le même canal ?
RTP	SSRC, séquence, timestamp et marker	Les unités arrivent-elles dans un ordre explicable ?
RTCP	sender report, CNAME et BYE	Horloge, identité et fin sont-elles traçables ?
Décodeur	SPS/PPS/VPS et packetization mode	Le payload reçu permet-il l’initialisation ?

Séparez « aucun média reçu » de « média reçu mais indécodable ». L’absence de RTP après SETUP et PLAY réussis dirige vers UDP, NAT, pare-feu ou une réponse Transport différente de l’offre. Des trous de séquence prouvent perte ou réordonnancement. Une séquence continue sans image déplace l’enquête vers payload type, fréquence d’horloge, limites d’image et paramètres H.264 ou H.265. Cette frontière est plus utile qu’un message générique du lecteur.

Comment rédiger une réponse directement réutilisable ?

Écrivez trois phrases : dernière opération réussie, première preuve en échec, prochain test discriminant. Exemple : « DESCRIBE, SETUP et PLAY réussissent ; aucun RTP n’arrive aux ports annoncés ; un essai TCP interleaved séparera blocage UDP et mauvais chemin média. » N’accusez ni caméra ni réseau sans réponse ou paquet qui matérialise cette limite.

Quelles données rendent le cas reproductible ?

Conservez OPTIONS, DESCRIBE, SETUP et PLAY, le SDP, la réponse Transport et l’identifiant Session nettoyé. Pour RTP, relevez SSRC, première et dernière séquence, clock rate, nombre de trous et durée. Mentionnez le résultat dans VLC ou un autre VMS comme test différentiel, pas comme preuve que le client qui fonctionne respecte toutes les frontières.

Quand tester le serveur ou le client ?

Examinez le serveur s’il refuse une méthode, fournit une URL control absente, renvoie un transport incompatible ou change SSRC ou horloge sans transition. Examinez le client s’il réutilise un nonce expiré, perd Session, demande UDP sans ouvrir les ports ou assimile chaque fin de NAL à une fin d’access unit. Entre les deux, paquet et heure doivent accompagner chaque conclusion.

Comment valider le rapport ?

Recommencez avec une connexion neuve et comparez les chronologies jusqu’à la première divergence. Retirez mots de passe et valeurs Authorization complètes. Reliez chaque conclusion à CSeq, séquence ou timestamp. La documentation RTSP associée couvre les étapes voisines ; RTSP Inspector permet de tester un flux RTSP et de collecter localement les preuves sans téléverser la vidéo vers un service public.

Réponse directe et limite d’acceptation

La réponse courte à « Débogage d'URL de contrôle d'agrégation RTSP : contrôle SDP :, suivi des URL, SETUP 404 et échec de PLAY » est la suivante : Comment dépanner les URL de contrôle d'agrégation RTSP, les attributs de contrôle SDP :, les chemins de contrôle au niveau de la piste, les erreurs SETUP 404, les échecs de PLAY et les bogues de construction d'URL de caméra. Considérez cette phrase comme un résultat à vérifier, et non comme une promesse valable pour toute entrée, tout appareil, tout projet ou tout environnement. Un résultat complet consigne l’état initial, l’action exacte, la sortie visible et la condition qui prouve la fin de la tâche dans RTSP Inspector.

Procédure fondée sur les preuves

Commencez par un cas petit et répétable avant de modifier un projet complet. Notez version de l’application, système, identité de l’entrée ou de l’appareil, réglages pertinents et résultat attendu. Exécutez une action volontaire, conservez la première transition inattendue et comparez-la à un cas nominal si possible. Plusieurs changements simultanés masquent la condition qui a créé ou corrigé le problème.

Point de contrôle 1 : Débogage d'URL de contrôle d'agrégation RTSP : contrôle SDP :, suivi des URL, SETUP 404 et

Si « Débogage d'URL de contrôle d'agrégation RTSP : contrôle SDP :*, suivi des URL, SETUP 404 et échec de PLAY » est ambigu, comparez un cas nominal et un cas défaillant dans des conditions identiques. Marquez la première différence utile au lieu de lister tous les symptômes suivants. Cette limite produit généralement une demande d’assistance plus claire.

Point de contrôle 2 : Comment dépanner les URL de contrôle d'agrégation RTSP, les attributs de contrôle SDP :, l

Vérifiez « Comment dépanner les URL de contrôle d'agrégation RTSP, les attributs de contrôle SDP :*, les chemins de contrôle au niveau de la piste, les erreurs S » avec la plus petite entrée représentative. Gardez les réglages indépendants inchangés, répétez la même action et contrôlez le résultat après réouverture ou reconnexion. Une image seule est moins forte qu’un relevé comprenant entrée, réglage, action, sortie et heure.

Point de contrôle 3 : Le symptôme commun

Si « Le symptôme commun » est ambigu, comparez un cas nominal et un cas défaillant dans des conditions identiques. Marquez la première différence utile au lieu de lister tous les symptômes suivants. Cette limite produit généralement une demande d’assistance plus claire.

Point de contrôle 4 : Session-level and media-level control

Vérifiez « Session-level and media-level control » avec la plus petite entrée représentative. Gardez les réglages indépendants inchangés, répétez la même action et contrôlez le résultat après réouverture ou reconnexion. Une image seule est moins forte qu’un relevé comprenant entrée, réglage, action, sortie et heure.

Point de contrôle 5 : URL de contrôle relatif ou absolu

Si « URL de contrôle relatif ou absolu » est ambigu, comparez un cas nominal et un cas défaillant dans des conditions identiques. Marquez la première différence utile au lieu de lister tous les symptômes suivants. Cette limite produit généralement une demande d’assistance plus claire.

Point de contrôle 6 : DESCRIBE succeeds but SETUP fails

Vérifiez « DESCRIBE succeeds but SETUP fails » avec la plus petite entrée représentative. Gardez les réglages indépendants inchangés, répétez la même action et contrôlez le résultat après réouverture ou reconnexion. Une image seule est moins forte qu’un relevé comprenant entrée, réglage, action, sortie et heure.

Point de contrôle 7 : Content-Base and Content-Location

Si « Content-Base and Content-Location » est ambigu, comparez un cas nominal et un cas défaillant dans des conditions identiques. Marquez la première différence utile au lieu de lister tous les symptômes suivants. Cette limite produit généralement une demande d’assistance plus claire.

Point de contrôle 8 : PLAY uses aggregate control

Vérifiez « PLAY uses aggregate control » avec la plus petite entrée représentative. Gardez les réglages indépendants inchangés, répétez la même action et contrôlez le résultat après réouverture ou reconnexion. Une image seule est moins forte qu’un relevé comprenant entrée, réglage, action, sortie et heure.

Point de contrôle 9 : Multi-track audio and video

Si « Multi-track audio and video » est ambigu, comparez un cas nominal et un cas défaillant dans des conditions identiques. Marquez la première différence utile au lieu de lister tous les symptômes suivants. Cette limite produit généralement une demande d’assistance plus claire.

Point de contrôle 10 : URL du profil ONVIF vs URL de la piste RTSP

Vérifiez « URL du profil ONVIF vs URL de la piste RTSP » avec la plus petite entrée représentative. Gardez les réglages indépendants inchangés, répétez la même action et contrôlez le résultat après réouverture ou reconnexion. Une image seule est moins forte qu’un relevé comprenant entrée, réglage, action, sortie et heure.

Matrice d’acceptation

Point	Preuve à conserver	Critère de réussite
Débogage d'URL de contrôle d'agrégation RTSP : contrôle SDP :, suivi des URL, SETUP 404 et échec de PLAY	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Comment dépanner les URL de contrôle d'agrégation RTSP, les attributs de contrôle SDP :, les chemins de contrôle au nive	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Le symptôme commun	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Session-level and media-level control	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
URL de contrôle relatif ou absolu	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
DESCRIBE succeeds but SETUP fails	État initial, une action et état obtenu	Une seconde personne reproduit le résultat

Isolation, reprise et transmission

Arrêtez-vous à la première limite en échec. Conservez source, projet, session ou capture, dupliquez avant toute modification destructive et changez une variable par essai. Rejouer un flux entier après plusieurs changements peut modifier le résultat sans expliquer pourquoi.

Distinguez absence de preuve et preuve d’absence. Une vue vide peut signaler mauvaise entrée, portée, filtre, permission, appareil, période ou état du projet. Vérifiez acquisition ou import avant d’interpréter décodeur, éditeur, rapport ou export.

Avant transmission, rouvrez l’artefact durable et inspectez début, point de décision et fin. Notez version, plateforme, configuration, attente, observation et reproduction minimale. Retirez ou masquez les données sensibles et confirmez l’autorisation du destinataire.

Questions et réponses

Quelle est la manière fiable la plus rapide de commencer ?

Utilisez le plus petit cas représentatif, écrivez le résultat attendu et ne changez qu’une variable. Validez le parcours de base avant d’ajouter filtres, effets, modifications, automatisation ou grande source.

Quelles preuves faut-il conserver ?

Gardez identité de l’entrée, version, plateforme, réglages, action exacte, première transition inattendue et sortie finale. Fermez puis rouvrez projet, session, rapport ou export avant de le considérer durable.

Quand faut-il répéter la procédure ?

Répétez-la après un changement pertinent d’application, système, pilote, firmware, modèle, source ou processus. Conservez le cas accepté précédent comme référence non modifiée.

Quand le résultat est-il transmissible ?

Lorsqu’une seconde personne autorisée identifie l’entrée, répète l’action, obtient le même résultat, comprend les limites et ouvre l’artefact sans état local non documenté.

Guides associés

Ces pages dans la même langue couvrent les étapes voisines sans changer le propriétaire canonique du sujet :