2026-06-02

Le flux RTSP s'arrête après 30 secondes : Keepalive, Session Timeout, NAT et caméra inactive déconnexions

Pourquoi les flux RTSP s'arrêtent après 30 secondes, 60 secondes ou quelques minutes, et comment déboguer les requêtes keepalive, l'expiration de session, le NAT, le silence RTP et les déconnexions de caméra.

Un flux RTSP qui démarre avec succès puis s'arrête après 30 secondes est un problème différent d'un flux qui ne démarre jamais. L'authentification a fonctionné. SDP a été renvoyé. SETUP et PLAY ont probablement réussi. Les médias sont peut-être arrivés depuis un certain temps. Ensuite, la caméra a fermé la session, RTP s'est arrêté, le lecteur s'est figé ou la connexion a expiré.

Les recherches telles que « Le flux RTSP s'arrête après 30 secondes », « Délai d'expiration RTSP keepalive », « Le flux de la caméra se déconnecte après une minute » et « Délai d'expiration de la session RTSP » indiquent généralement un problème de durée de vie de la session. Le flux peut nécessiter des requêtes keepalive, le mappage NAT peut expirer, la caméra peut fermer des sessions RTSP inactives, le média UDP peut être bloqué après un changement de chemin ou RTCP peut révéler une perte de média avant la déconnexion.

RTSP Inspector est utile ici car la chronologie est importante. Vous devez savoir ce qui s'est passé à la seconde 0, à la seconde 30, à la seconde 60 et au moment exact où le flux s'est arrêté.

Pourquoi RTSP peut s'arrêter après avoir démarré

Les causes courantes incluent :

Le client n'envoie pas de keepalive RTSP.
La caméra attend le maintien de GET_PARAMETER.
La caméra s'attend à ce que « OPTIONS » soit maintenue en vie.
Le délai d'expiration de la session RTSP est plus court que prévu.
L'état du NAT ou du pare-feu expire.
UDP RTP s'arrête tandis que RTSP TCP reste ouvert.
La caméra ferme la connexion TCP après le silence des médias.
Le client a utilisé une mauvaise URL de contrôle d’agrégation.
Le micrologiciel de la caméra présente un bug de nettoyage de session.
RTCP signale la perte ou la gigue des paquets avant que le flux ne se fige.

Le correctif dépend de la couche arrêtée en premier : contrôle RTSP, média RTP, retour RTCP ou chemin TCP/UDP sous-jacent.

En-tête et délai d'expiration de la session RTSP

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

RTSP/1.0 200 OK
Session: 12345678;timeout=60
Transport: RTP/AVP/TCP;unicast;interleaved=0-1

OPTIONS vs GET_PARAMETER keepalive

Two common keepalive methods are:

OPTIONS rtsp://camera/stream RTSP/1.0
Session: 12345678

et:

GET_PARAMETER rtsp://camera/stream RTSP/1.0
Session: 12345678

When debugging, check:

Aggregate control URL problems

This can create subtle behavior:

NAT and firewall idle timeout

Symptoms:

Camera idle disconnects

Look for:

RTP silence vs RTSP disconnect

Checklist for streams that stop after 30 seconds

Use this process:

A useful report includes:

Final diagnosis

Preuve reproductible pour « Le flux RTSP s'arrête après 30 secondes : Keepalive, Session Timeout, NAT et caméra inactive déconnexions »

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 « Le flux RTSP s'arrête après 30 secondes : Keepalive, Session Timeout, NAT et caméra inactive déconnexions », 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 « Le flux RTSP s'arrête après 30 secondes : Keepalive, Session Timeout, NAT et caméra inactive déconnexions », é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.

Journal de modification et test de non-régression

Transformez la correction en journal reproductible : ancienne et nouvelle valeur, emplacement du réglage, heure de reconnexion et effet attendu sur les paquets. Avec TCP interleaved, « l’image apparaît » ne suffit pas ; le média ne doit plus dépendre de ports UDP séparés et doit utiliser les canaux négociés. Si le control URL change, SETUP emploie le nouveau chemin et PLAY comme keepalive conservent la même Session.

Lorsque cela reste sûr, réalisez un contrôle négatif. Rétablissez l’ancienne valeur dans un environnement de test ou comparez une capture antérieure avec les mêmes entrées. La même frontière doit échouer. Ce contrôle évite d’attribuer la réussite à un redémarrage, un cache ou une modification réseau non documentée. Sur une caméra de production, préférez une preuve historique et ne recréez pas volontairement la panne.

Laissez la connexion vivre au-delà des délais keepalive et Session. Surveillez OPTIONS ou GET_PARAMETER ainsi que la cohérence CSeq et Session. Pour RTP, comparez perte, doublons et réordonnancement sur des fenêtres égales. Pour le codec, ouvrez une connexion neuve et observez le premier IDR ; un décodeur déjà initialisé peut masquer des paramètres absents au démarrage.

Limitez la portée : « main stream TCP validé dix minutes avec ce client » vaut mieux que « RTSP réparé ». Précisez piste, transport, codec, client et durée. Audio, sub stream ou reconnexion après coupure restent ouverts s’ils ne sont pas testés.

Séparez faits et recommandation. Les faits sont réponses, paquets et mesures ; la recommandation propose une action caméra, pare-feu ou client. Une autre équipe doit pouvoir accepter les faits même si elle choisit un autre remède. Terminez par responsable, action suivante et condition de clôture, avec un intervalle court transmis via le guide des rapports RTSP.