2026-06-02

Il flusso RTSP si interrompe dopo 30 secondi: Keepalive, timeout della sessione, NAT e disconnessione della fotocamera inattiva

Perché i flussi RTSP si interrompono dopo 30 secondi, 60 secondi o pochi minuti e come eseguire il debug di richieste keepalive, timeout della sessione, NAT, silenzio RTP e disconnessioni della fotocamera.

Un flusso RTSP che si avvia correttamente e si interrompe dopo 30 secondi è un problema diverso da un flusso che non si avvia mai. L'autenticazione ha funzionato. L'SDP è stato restituito. SETUP e PLAY probabilmente sono riusciti. I media potrebbero essere arrivati da un po'. Quindi la fotocamera ha chiuso la sessione, l'RTP si è interrotto, il lettore si è bloccato o la connessione è scaduta.

Ricerche come "Lo streaming RTSP si interrompe dopo 30 secondi", "Timeout keepalive RTSP", "Lo streaming della telecamera si disconnette dopo un minuto" e "Timeout sessione RTSP" in genere indicano un problema di durata della sessione. Lo streaming potrebbe richiedere richieste keepalive, la mappatura NAT potrebbe scadere, la telecamera potrebbe chiudere sessioni RTSP inattive, i media UDP potrebbero essere bloccati dopo una modifica del percorso o RTCP potrebbe rivelare la perdita dei media prima della disconnessione.

L'ispettore RTSP è utile qui perché la sequenza temporale è importante. Devi sapere cosa è successo al secondo 0, al secondo 30, al secondo 60 e nel momento esatto in cui lo streaming si è interrotto.

Perché RTSP può interrompersi dopo l'avvio

Le cause comuni includono:

Il client non invia keepalive RTSP.
La telecamera si aspetta il keepalive GET_PARAMETER.
La fotocamera attende il keepalive "OPZIONI".
Il timeout della sessione RTSP è più breve del previsto.
Lo stato NAT o firewall scade.
UDP RTP si interrompe mentre RTSP TCP rimane aperto.
La fotocamera chiude la connessione TCP dopo il silenzio dei media.
Il client ha utilizzato un URL di controllo aggregato errato.
Il firmware della fotocamera presenta un bug di pulizia della sessione.
RTCP segnala la perdita di pacchetti o il jitter prima che il flusso si blocchi.

La correzione dipende da quale livello si è interrotto per primo: controllo RTSP, supporto RTP, feedback RTCP o percorso TCP/UDP sottostante.

Intestazione e timeout della sessione RTSP

Dopo "SETUP", la fotocamera solitamente restituisce un'intestazione "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

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

Prova riproducibile per «Il flusso RTSP si interrompe dopo 30 secondi: Keepalive, timeout della sessione, NAT e disconnessione della fotocamera inattiva»

La risposta diretta è che una schermata nera o un solo codice non dimostra l’origine del guasto. Una diagnosi affidabile collega richiesta e risposta RTSP, trasporto negoziato, sessione valida e poi numeri di sequenza RTP, timestamp e segnali RTCP. Per «Il flusso RTSP si interrompe dopo 30 secondi: Keepalive, timeout della sessione, NAT e disconnessione della fotocamera inattiva» parti dal livello più vicino al sintomo visibile, ma conserva una cronologia comune per non confondere controllo, rete e decodifica.

Prima di cambiare camera, firewall o VMS, crea un test di base piccolo. Registra URL RTSP senza password, ora, percorso, trasporto richiesto, risposta del server e momento del primo pacchetto multimediale. Prova separatamente UDP e TCP interleaved quando disponibili. Non cambiare insieme percorso, credenziali e trasporto: se il secondo tentativo funziona, devi poter identificare la variabile decisiva.

Livello	Evidenza da conservare	Domanda
RTSP	metodo, stato, header, CSeq e Session	Il server ha accettato proprio questa operazione?
SDP	control, payload type, clock rate e codec	È descritta la traccia attesa?
Transport	client_port, server_port o interleaved	I due estremi usano lo stesso canale?
RTP	SSRC, sequenza, timestamp e marker	Le unità arrivano in ordine spiegabile?
RTCP	sender report, CNAME e BYE	Orologio, identità e fine sono tracciabili?
Decoder	SPS/PPS/VPS e packetization mode	Il payload ricevuto può inizializzare il decoder?

Separa «nessun media ricevuto» da «media ricevuto ma non decodificabile». Se RTP manca dopo SETUP e PLAY riusciti, verifica UDP, NAT, firewall e risposta Transport. Buchi nella sequenza provano perdita o riordinamento. Una sequenza continua senza immagine sposta l’indagine su payload type, clock rate, confini del frame e parametri H.264 o H.265. Questo confine è più utile del messaggio generico del player.

Come si scrive una risposta citabile?

Usa tre frasi: ultima operazione riuscita, prima evidenza fallita, prossimo test che separa due cause. Esempio: «DESCRIBE, SETUP e PLAY riescono; nessun RTP arriva alle porte annunciate; una prova TCP interleaved separerà blocco UDP e percorso media errato». Non attribuire il guasto a camera o rete senza una risposta o un pacchetto che dimostri il confine.

Quali dati rendono il caso riproducibile?

Conserva OPTIONS, DESCRIBE, SETUP e PLAY, SDP, risposta Transport e Session ripulita. Per RTP annota SSRC, prima e ultima sequenza, clock rate, buchi e durata. Indica se VLC o un altro VMS funziona, ma usalo come confronto controllato, non come prova che il client riuscito interpreti correttamente ogni regola.

Quando controllare server o client?

Controlla il server se rifiuta un metodo, fornisce un control URL assente, restituisce un trasporto incompatibile o cambia SSRC o clock senza transizione. Controlla il client se riusa un nonce scaduto, perde Session, richiede UDP senza aprire le porte o tratta ogni fine NAL come fine access unit. Se il difetto è intermedio, pacchetto e tempo devono accompagnare ogni conclusione.

Come verificare il rapporto?

Ripeti da una connessione nuova e confronta le cronologie fino alla prima differenza. Rimuovi password e valori Authorization completi. Collega ogni conclusione a CSeq, sequenza o timestamp. Segui la guida RTSP correlata e usa RTSP Inspector per testare uno stream RTSP e raccogliere prove localmente, senza caricare il video su un servizio pubblico.

Risposta diretta e confine di accettazione

La risposta breve a «Il flusso RTSP si interrompe dopo 30 secondi: Keepalive, timeout della sessione, NAT e disconnessione della fotocamera inattiva» è: Perché i flussi RTSP si interrompono dopo 30 secondi, 60 secondi o pochi minuti e come eseguire il debug di richieste keepalive, timeout della sessione, NAT, silenzio RTP e disconnessioni della fotocamera. Tratta questa frase come un risultato da verificare, non come una promessa per ogni input, dispositivo, progetto o ambiente. Un risultato completo registra stato iniziale, azione esatta, output visibile e condizione che dimostra la conclusione dell’attività in RTSP Inspector.

Procedura basata sulle prove

Parti da un caso piccolo e ripetibile prima di modificare un progetto intero. Registra versione, sistema operativo, identità dell’input o dispositivo, impostazioni rilevanti e risultato atteso. Esegui un’azione deliberata, conserva la prima transizione inattesa e confrontala con un caso noto quando disponibile. Cambiare più controlli insieme nasconde quale condizione ha creato o corretto il problema.

Punto di controllo 1: Il flusso RTSP si interrompe dopo 30 secondi: Keepalive, timeout della sessione, NAT e dis

Per «Il flusso RTSP si interrompe dopo 30 secondi: Keepalive, timeout della sessione, NAT e disconnessione della fotocamera inattiva», separa una decisione del prodotto da un limite del sistema, hardware, file sorgente, permesso o processo. Conferma quale livello ha prodotto la prova prima di assegnare una causa. Così un sintomo vicino non diventa una causa radice data per certa.

Punto di controllo 2: Perché i flussi RTSP si interrompono dopo 30 secondi, 60 secondi o pochi minuti e come ese

Chiudi «Perché i flussi RTSP si interrompono dopo 30 secondi, 60 secondi o pochi minuti e come eseguire il debug di richieste keepalive, timeout della session» solo quando il risultato salvato, esportato o riaperto conserva lo stato osservato. Il feedback temporaneo dell’interfaccia è utile, ma la prova durevole è più forte. Registra ogni limite residuo per chi prosegue.

Punto di controllo 3: Perché RTSP può interrompersi dopo l'avvio

Per «Perché RTSP può interrompersi dopo l'avvio», separa una decisione del prodotto da un limite del sistema, hardware, file sorgente, permesso o processo. Conferma quale livello ha prodotto la prova prima di assegnare una causa. Così un sintomo vicino non diventa una causa radice data per certa.

Punto di controllo 4: Intestazione e timeout della sessione RTSP

Chiudi «Intestazione e timeout della sessione RTSP» solo quando il risultato salvato, esportato o riaperto conserva lo stato osservato. Il feedback temporaneo dell’interfaccia è utile, ma la prova durevole è più forte. Registra ogni limite residuo per chi prosegue.

Punto di controllo 5: OPTIONS vs GETPARAMETER keepalive

Per «OPTIONS vs GETPARAMETER keepalive», separa una decisione del prodotto da un limite del sistema, hardware, file sorgente, permesso o processo. Conferma quale livello ha prodotto la prova prima di assegnare una causa. Così un sintomo vicino non diventa una causa radice data per certa.

Punto di controllo 6: Aggregate control URL problems

Chiudi «Aggregate control URL problems» solo quando il risultato salvato, esportato o riaperto conserva lo stato osservato. Il feedback temporaneo dell’interfaccia è utile, ma la prova durevole è più forte. Registra ogni limite residuo per chi prosegue.

Punto di controllo 7: NAT and firewall idle timeout

Per «NAT and firewall idle timeout», separa una decisione del prodotto da un limite del sistema, hardware, file sorgente, permesso o processo. Conferma quale livello ha prodotto la prova prima di assegnare una causa. Così un sintomo vicino non diventa una causa radice data per certa.

Punto di controllo 8: Camera idle disconnects

Chiudi «Camera idle disconnects» solo quando il risultato salvato, esportato o riaperto conserva lo stato osservato. Il feedback temporaneo dell’interfaccia è utile, ma la prova durevole è più forte. Registra ogni limite residuo per chi prosegue.

Punto di controllo 9: RTP silence vs RTSP disconnect

Per «RTP silence vs RTSP disconnect», separa una decisione del prodotto da un limite del sistema, hardware, file sorgente, permesso o processo. Conferma quale livello ha prodotto la prova prima di assegnare una causa. Così un sintomo vicino non diventa una causa radice data per certa.

Punto di controllo 10: Checklist for streams that stop after 30 seconds

Chiudi «Checklist for streams that stop after 30 seconds» solo quando il risultato salvato, esportato o riaperto conserva lo stato osservato. Il feedback temporaneo dell’interfaccia è utile, ma la prova durevole è più forte. Registra ogni limite residuo per chi prosegue.

Matrice di accettazione

Punto	Prova da conservare	Criterio di superamento
Il flusso RTSP si interrompe dopo 30 secondi: Keepalive, timeout della sessione, NAT e disconnessione della fotocamera i	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
Perché i flussi RTSP si interrompono dopo 30 secondi, 60 secondi o pochi minuti e come eseguire il debug di richieste ke	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
Perché RTSP può interrompersi dopo l'avvio	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
Intestazione e timeout della sessione RTSP	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
OPTIONS vs GETPARAMETER keepalive	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
Aggregate control URL problems	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato

Isolamento, ripristino e consegna

Fermati al primo confine che fallisce. Conserva sorgente, progetto, sessione o cattura, crea una copia prima di modifiche distruttive e cambia una variabile per esperimento. Ripetere un flusso ampio dopo più cambiamenti può dare un esito diverso senza spiegarlo.

Separa assenza di prove da prova di assenza. Una vista vuota può indicare input, ambito, filtro, permesso, dispositivo, intervallo o stato errato. Verifica acquisizione o importazione prima di interpretare decoder, editor, report o esportazione.

Prima della consegna, riapri l’artefatto e controlla inizio, punto decisionale e fine. Registra versione, piattaforma, configurazione, attesa, osservazione e riproduzione minima. Rimuovi o oscura dati sensibili e verifica l’autorizzazione del destinatario.

Domande e risposte

Qual è il modo affidabile più rapido per iniziare?

Usa il più piccolo caso rappresentativo, scrivi il risultato atteso e cambia una variabile. Conferma il percorso base prima di aggiungere filtri, effetti, modifiche, automazione o una sorgente maggiore.

Quali prove vanno salvate?

Conserva identità dell’input, versione, piattaforma, impostazioni, azione esatta, prima transizione inattesa e output finale. Chiudi e riapri progetto, sessione, report o export prima di considerarli durevoli.

Quando va ripetuta la procedura?

Ripetila dopo cambiamenti rilevanti ad applicazione, sistema, driver, firmware, modello, sorgente o workflow. Conserva il caso accettato precedente come riferimento non modificato.

Quando il risultato è pronto per la consegna?

Quando un’altra persona autorizzata identifica l’input, ripete l’azione, vede lo stesso risultato, comprende i limiti e apre l’artefatto senza stato locale non documentato.

Guide correlate

Queste pagine nella stessa lingua coprono le fasi vicine senza cambiare il proprietario canonico dell’argomento: