2026-06-02

Session RTSP 454 introuvable : pourquoi l'installation ou la lecture échoue après le démarrage d'une connexion de caméra

Comment dépanner les erreurs RTSP 454 Session Not Found dans les caméras IP, les NVR, ffmpeg, VLC, SETUP, PLAY, les ID de session, keepalive et les sessions RTSP obsolètes.

« 454 Session Not Found » est l'une des erreurs RTSP qui déroute les utilisateurs car la caméra est clairement accessible. La connexion TCP s'est ouverte. L'URL peut avoir répondu à « OPTIONS » ou même à « DESCRIBE ». L'authentification a peut-être fonctionné. Ensuite, SETUP, PLAY, keepalive ou une requête ultérieure échoue avec 454 Session Not Found.

Les utilisateurs recherchent « Session RTSP 454 introuvable », « Échec de la méthode ffmpeg PLAY 454 », « Caméra VLC RTSP 454 » et « Session de caméra introuvable RTSP » lorsqu'un flux n'échoue pas à la première étape. Cette erreur signifie généralement que le serveur RTSP ne reconnaît pas l'ID de session utilisé par le client, que la session a expiré, que le client a envoyé une demande avant qu'une session n'existe ou que le chemin du flux/l'URL de contrôle a provoqué un état incompatible.

L'inspecteur RTSP est utile car « 454 » n'est pas un problème de décodeur vidéo. Il s'agit d'une preuve d'état de session RTSP.

Que signifie 454 Session non trouvée

Après RTSP SETUP, la caméra renvoie un en-tête Session :

RTSP/1.0 200 OK
Session: 12345678;timeout=60

Later requests should use that session:

PLAY rtsp://192.168.1.50/stream1 RTSP/1.0
Session: 12345678

Si la caméra ne reconnaît pas « 12345678 », elle peut renvoyer :

RTSP/1.0 454 Session Not Found

That can happen because the client used the wrong Session ID, the camera expired it, the camera restarted internally, a proxy lost state, or the request URI does not match the session context.

Common causes

High-probability causes include:

PLAY sent without a successful SETUP.
Client reused a stale Session ID after reconnect.
Camera timed out the session because keepalive was missing.
SETUP succeeded for one track but PLAY used a different aggregate URL.
NVR session state was cleared while the client kept the old session.
Camera returned a Session header with parameters and the client parsed it incorrectly.
Multiple clients exceeded camera session capacity.
Firmware bug after encoder restart or profile switch.
RTSP proxy or relay did not preserve session affinity.

The error is about server-side state, not necessarily wrong credentials.

Session header parsing problems

Some Session headers include parameters:

Session: 12345678;timeout=60

L'identifiant de session est « 12345678 » ; timeout=60 est un paramètre. Si un client envoie la valeur entière de manière incorrecte ou supprime la mauvaise partie, la caméra peut rejeter les demandes ultérieures.

Un bon diagnostic doit conserver exactement ce que la caméra a renvoyé et exactement ce que le client a envoyé plus tard.

Configuration des pistes et lecture globale

Pour les flux multipistes, le client peut envoyer des requêtes « SETUP » distinctes pour les pistes vidéo et audio. Ensuite, il peut envoyer un agrégat « PLAY ».

Le SDP peut contenir :

a=control:*
a=control:trackID=1
a=control:trackID=2

If the client chooses the wrong control URL, the camera may create session state for one resource and reject playback on another. This can look like a session error even when authentication and SDP are correct.

Session timeout and keepalive

If 454 appears after 30, 60, or 120 seconds, inspect keepalive. The camera may expire the session if the client does not send OPTIONS or GET_PARAMETER before timeout.

Important questions:

What timeout did the camera advertise?
Did the client send keepalive?
Did keepalive include the correct Session header?
Did the camera return 200 OK?
Did 454 happen immediately after a missed keepalive interval?

If the timing matches the timeout, this is a session lifetime problem.

Reconnect logic can create stale sessions

Some applications reconnect quickly after network loss. If the app keeps old session state after reconnect, it may send requests using a Session ID from the previous TCP connection. Many cameras treat that as invalid.

The correct behavior is usually to run a fresh RTSP sequence:

OPTIONS
DESCRIBE
SETUP
PLAY

Do not assume the camera remembers an old Session ID after a reconnect.

Debug checklist

Use this process:

Find the first 454 Session Not Found.
Identify which RTSP method received it.
Locate the SETUP response that created the session.
Compare the Session ID returned by camera with the Session ID sent by client.
Check whether the Session header included parameters.
Check whether keepalive occurred before timeout.
Check whether RTSP TCP reconnected before 454.
Compare track control URLs and aggregate control URL.
Check whether multiple clients are opening the same camera stream.
Test direct camera vs NVR/proxy path.

Final diagnosis

RTSP 454 Session Not Found means the RTSP server rejected the client's session state. The root cause may be stale Session ID, missing keepalive, wrong control URL, expired session, proxy state loss, or camera firmware behavior. The fix starts with the RTSP method sequence and Session header evidence.

RTSP Inspector helps expose that sequence so the problem can be diagnosed at the RTSP state-machine layer instead of being mistaken for a codec, player, or generic network issue.

Preuve reproductible pour « Session RTSP 454 introuvable : pourquoi l'installation ou la lecture échoue après le démarrage d'une connexion de caméra »

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 « Session RTSP 454 introuvable : pourquoi l'installation ou la lecture échoue après le démarrage d'une connexion de caméra », 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.

De l’observation au verdict par couche

Pour « Session RTSP 454 introuvable : pourquoi l'installation ou la lecture échoue après le démarrage d'une connexion de caméra », écrivez d’abord l’observation puis son interprétation. Une observation peut être retrouvée dans la capture : statut RTSP lié à CSeq, valeur SDP, réponse Transport, trou de séquence, changement de SSRC ou différence entre RTP timestamp et RTCP sender report. « Le serveur est lent » ou « le codec est incompatible » reste une hypothèse tant qu’un élément précis ne la rend pas plus probable que les autres.

Découpez le parcours en frontières. TCP doit s’ouvrir, puis OPTIONS ou DESCRIBE être accepté. Le SDP doit décrire une piste exploitable, son control URL, payload type et clock rate. SETUP exige une réponse Transport compatible et PLAY une Session valide. Viennent ensuite arrivée RTP, ordre, temps et préparation du décodeur. Arrêtez-vous à la première frontière sans preuve de réussite ; une donnée ultérieure ne doit pas masquer une lacune antérieure.

Gardez source et intervalle constants pendant les comparaisons. UDP et TCP interleaved utilisent le même chemin et les mêmes identifiants. Main stream et sub stream gardent client et transport. Pour VLC face à un VMS, consignez méthodes, en-têtes et URL réels. Une différence de control URL, Authorization, Session ou keepalive explique parfois davantage que le nom de l’application.

Matrice d’exclusion

Commencez par deux hypothèses. Sans média, UDP peut être bloqué ou le serveur peut envoyer vers d’autres ports. TCP interleaved teste la première ; comparer offre et réponse Transport, adresses et ports teste la seconde. Pour une image corrompue, les séquences RTP séparent perte et initialisation incomplète, tandis que SPS/PPS/VPS avant la première image teste les paramètres codec.

Pour chaque hypothèse, notez une preuve favorable et une preuve qui pourrait la réfuter. Une affirmation qu’aucun paquet ne peut contredire est trop large. « Le NAT supprime UDP » est réfuté par RTP au port client. « Les paramètres H.264 manquent » est réfuté par SPS et PPS valides avant IDR. Le rapport reste ainsi ordonné plutôt qu’une liste de possibilités.

Interpréter le temps sans surconclure

RTSP CSeq ordonne les transactions, RTP sequence les paquets, RTP timestamp le temps d’échantillonnage, et l’horloge de capture l’arrivée au point observé. Ne les confondez pas. Une arrivée irrégulière ne prouve pas une dérive ; un saut timestamp ne prouve pas une perte sans séquence. Les RTCP sender reports relient les horloges RTP audio et vidéo à une référence commune.

Dossier de recette

Fermez l’enquête lorsque la correction se répète sur une connexion neuve avec un changement documenté. Le rapport indique entrées, dernière frontière réussie, première preuve en échec, modification, résultat et tests ouverts. Joignez un court extrait de transcription ou des statistiques ciblées. Masquez les secrets, mais gardez CSeq, Session nettoyée, SSRC et plage temporelle.

La procédure de dépannage RTSP reconstruit le parcours ; les rapports RTSP Inspector transmettent la frontière prouvée aux équipes caméra, réseau ou VMS.