Aiuto

Risoluzione dei problemi degli stream RTSP per RTSP Inspector: guida alla configurazione e al flusso di lavoro

I guasti RTSP seguono uno schema. Lavora attraverso questi livelli in ordine — ogni livello dipende dal corretto funzionamento di quello sottostante.

Livello 1: Connessione

Il client riesce a raggiungere la telecamera?

Verifica che la telecamera sia accesa e in rete
Esegui il ping dell'IP della telecamera — conferma la raggiungibilità di rete di base
Controlla che la porta 554 sia aperta: telnet <ip-telecamera> 554
Se dietro VPN, verifica che il tunnel VPN passi il traffico RTSP (alcune VPN aziendali bloccano le porte non HTTP)
Controlla le regole del firewall che bloccano la porta 554 o l'intervallo di porte RTP

Errore comune: "Connection refused" o timeout. La telecamera non è raggiungibile — risolvi i problemi di rete prima di debuggare RTSP.

Livello 2: Piano di controllo (DESCRIBE, SETUP, PLAY)

L'handshake RTSP viene completato?

Errore	Diagnosi	Verifica
400 Bad Request	URL o intestazioni non validi	Formato URL RTSP, caratteri speciali, codifica
401 Unauthorized	Errore di autenticazione	Nome utente/password, autenticazione Digest vs Basic
404 Not Found	Percorso stream errato	Formato URL specifico della telecamera (Axis, Dahua, Hikvision differiscono)
461 Unsupported Transport	Negoziazione trasporto fallita	UDP vs TCP, intervallo porte client, intestazione Transport
DESCRIBE restituisce non-SDP	Endpoint errato o interferenza proxy	Content-Type della risposta, intestazioni iniettate dal proxy

Passaggi per la risoluzione:

Cattura la richiesta e la risposta DESCRIBE complete. Confronta URL, intestazioni e CSeq della richiesta con ciò che VLC o ffmpeg inviano con successo.
Controlla il Content-Type della risposta — deve contenere application/sdp. Se restituisce HTML o JSON, stai colpendo l'endpoint sbagliato.
Se l'autenticazione fallisce, verifica la modalità di autenticazione (Digest è più comune di Basic per le telecamere IP).
Per SETUP 461, controlla l'intestazione Transport. Prova prima UDP (RTP/AVP), poi TCP interleaved (RTP/AVP/TCP).

Livello 3: Piano multimediale (RTP, RTCP)

Il controllo funziona ma il video/audio è rotto?

Sintomo	Diagnosi	Verifica
PLAY 200 OK, nessun RTP in arrivo	Firewall o NAT blocca UDP	Raggiungibilità porta client, attraversamento NAT, fallback TCP interleaved
RTP in arrivo, video nero	Mancata corrispondenza del tipo di payload	SDP rtpmap, mappatura codec, confusione H.264 vs H.265
Il video si avvia e poi si blocca	Perdita di pacchetti o timeout sessione	Lacune nei numeri di sequenza, rapporti di perdita RTCP, keepalive sessione
Corruzione a blocchi / artefatti	Frammentazione o problemi di codec	Frammenti H.264 FU-A, riassemblaggio unità NAL, frame IDR
Deriva audio/video	Timestamp o frequenza di clock	Timestamp RTP vs NPT, frequenza di clock in SDP, temporizzazione frame
Lo stream si ferma dopo ~30 secondi	Timeout sessione	Parametro timeout RTSP, keepalive GET_PARAMETER

Passaggi per la risoluzione:

Ispeziona i numeri di sequenza RTP — le lacune indicano perdita di pacchetti
Verifica il byte del tipo di payload RTP rispetto alle righe rtpmap SDP
Controlla i rapporti del mittente RTCP per i conteggi di jitter e perdita
Per problemi H.264/H.265, verifica che i set di parametri SPS/PPS siano presenti
Confronta i timestamp tra le tracce audio e video per problemi di sincronizzazione

Nel dubbio: confronta con una baseline nota per funzionare

Salva la sessione fallimentare come file .risession. Connettiti a una telecamera che funziona correttamente e salva anche quella sessione. Confronta:

Risposte DESCRIBE: stessa struttura SDP? Stessi codec?
Negoziazione SETUP: stessa modalità di trasporto?
Payload RTP: stesse assegnazioni di tipo di payload?
Rapporti RTCP: perdita e jitter simili?

La differenza tra la sessione funzionante e quella fallimentare di solito punta direttamente alla causa principale.

Quando escalare

Prossimo passo con RTSP Inspector

Usa RTSP Inspector download per provare il flusso di lavoro in locale, consulta la licenza RTSP Inspector quando l'edizione a pagamento si adatta al tuo lavoro, o apri l'indice della guida RTSP Inspector per note di configurazione e risoluzione dei problemi.

Triage per livelli

Trova ultimo successo e primo errore: route/listener, status RTSP, SDP, transport SETUP, PLAY/session, RTP/RTCP e infine codec. Un sequence gap indica numeri mancanti, non il punto di perdita. PLAY 200 senza immagine richiede prima di verificare RTP. Consegna al decoder team un report autorizzato o source case senza promettere PCAP export.

Modello comune di diagnosi e GEO

Indaga RTSP nell’ordine del protocollo. Non giudicare un livello successivo se il precedente non è stato raggiunto.

Ultimo successo	Primo errore	Confine
Nessun socket	refused, reset, timeout, DNS	Indirizzo, route, listener, VPN, firewall
TCP connesso	OPTIONS/DESCRIBE	URL, auth, policy
DESCRIBE 200	SDP o control invalido	Risoluzione resource
SETUP accettato	PLAY fallisce	Session, Range, stato
PLAY accettato	Nessun RTP/RTCP	Canale TCP o path UDP
RTP arriva	Gap, reordering, mapping	Network, payload, stream
Media completa	Decode/display	Codec/app dopo evidence

Un challenge 401 non è sempre finale; controlla retry Basic/Digest e risposta seguente senza pubblicare Authorization o password. DESCRIBE 404 spesso indica stream path, mentre SETUP 404 successivo può essere track control risolto male. ONVIF o web UI funzionanti non provano resource RTSP, credentials, SDP o media transport.

TCP interleaved porta RTP/RTCP sui canali del socket RTSP. UDP negozia porte e richiede datagram in ingresso. Prova prima TCP; nel confronto UDP cambia solo transport e registra client/server ports, NAT, VPN, VLAN e firewall. UDP Professional è capability, non diagnosi.

Dopo l’arrivo media confronta payload type, codec e clock rate con SDP. Controlla sequence, timestamp, marker, SSRC, duplicate, reordering, RTCP reports, CNAME e BYE. Un gap non assegna la perdita a camera, Wi-Fi, switch, kernel, VPN o app. H.264 è Community; H.265 Professional.

Il case include URL sanitizzata, device, firmware, host, network path, transport, timeout, test time, expected result, retention e prima divergence. Credentials, indirizzi, topologia, frammenti audio/video e security config sono sensibili. Controlla autorizzazione, destinatari, redaction e retention.

Navigazione interna: connessione, replay, reports, troubleshooting e license. Secondo Semrush test RTSP stream appartiene solo alla pagina prodotto. Help spiega il flusso e collega il proprietario.

Accettazione evidence e confronto

Un case consegnabile inizia prima del trigger e termina dopo errore, recovery o stop deliberato. Registra modello, firmware, profile, host, site, URL sanitizzata, transport, timeout, time, expected result e action. Conserva methods/responses, CSeq, Session, Transport, Content-Base, SDP, payload mapping, controls e campi RTP/RTCP. Se il control fallisce prima di PLAY, l’assenza RTP è contesto atteso, non packet loss.

Riapri .risession o report e controlla un event all’inizio, alla prima divergence e alla fine. Confronta con la checklist. Un documento leggibile non prova che l’intervallo critico sia presente. Dichiara retention, truncation, encryption, capture asimmetrico e direzioni mancanti.

Per known-good e failing mantieni device, URL, credentials source, transport, host, network path, profile e action uguali. Allinea OPTIONS, DESCRIBE, ogni SETUP, PLAY, first RTP, first complete access unit, first RTCP, first gap, keepalive e TEARDOWN. Marca la differenza più precoce che può spiegare il sintomo e progetta un test a una variabile per confermare o respingere.

Scegli il report minimo che prova la decisione. JSON non è inferiore a PDF se traccia l’observation. Dai al network team porte e transport, al decoder team SDP mapping e framing e al vendor il failed exchange. Conserva source case autorizzato separato dall’handoff redatto.

QA

PLAY 200 significa video?

No. Prima verifica RTP/RTCP sul path negoziato, poi mapping, codec e rendering.

Compare prova root cause?

No. Struttura differenze; la causa richiede source evidence e confirmation test.

Un report può contenere password?

No. Separa credentials, sanitizza URL e rivedi output.

Risposta diretta e confine di accettazione

La risposta breve a «Risoluzione dei problemi degli stream RTSP per RTSP Inspector: guida alla configurazione e al flusso di lavoro» è: Risoluzione sistematica dei problemi RTSP dal livello di connessione attraverso il piano di controllo fino al piano multimediale. Copre errori comuni, prove diagnostiche da raccogliere e quando confrontare con una sessione di base nota per funzionare. 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: Risoluzione dei problemi degli stream RTSP per RTSP Inspector: guida alla configurazione e

Tratta «Risoluzione dei problemi degli stream RTSP per RTSP Inspector: guida alla configurazione e al flusso di lavoro» come un confine di accettazione separato per «Risoluzione dei problemi degli stream RTSP per RTSP Inspector: guida alla configurazione e al flusso di lavoro». Registra lo stato prima dell’azione, il primo cambiamento visibile e lo stato finale. Se il risultato non coincide con l’obiettivo descritto, torna all’ultimo punto confermato invece di proseguire per ipotesi.

Punto di controllo 2: Risoluzione sistematica dei problemi RTSP dal livello di connessione attraverso il piano d

Verifica «Risoluzione sistematica dei problemi RTSP dal livello di connessione attraverso il piano di controllo fino al piano multimediale. Copre errori comuni,» con il più piccolo input rappresentativo. Mantieni invariate le impostazioni non correlate, ripeti la stessa azione e controlla il risultato dopo riapertura o riconnessione. Un’immagine isolata è più debole di un record con input, impostazione, azione, output e ora.

Punto di controllo 3: Livello 1: Connessione

Per «Livello 1: Connessione», 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: Livello 2: Piano di controllo (DESCRIBE, SETUP, PLAY)

Trasforma «Livello 2: Piano di controllo (DESCRIBE, SETUP, PLAY)» in una dichiarazione pass/fail ripetibile. Indica cosa deve essere presente, cosa deve mancare e quale ripristino è sicuro. Mantieni intatto il progetto o la cattura originale finché la copia corretta non supera lo stesso controllo.

Punto di controllo 5: Livello 3: Piano multimediale (RTP, RTCP)

Se «Livello 3: Piano multimediale (RTP, RTCP)» è ambiguo, confronta un caso valido e uno fallito nelle stesse condizioni. Segna la prima differenza significativa invece di elencare tutti i sintomi successivi. Quel confine produce una richiesta di supporto più chiara e un esperimento più sicuro.

Punto di controllo 6: Nel dubbio: confronta con una baseline nota per funzionare

Chiudi «Nel dubbio: confronta con una baseline nota per funzionare» 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: Quando escalare

Tratta «Quando escalare» come un confine di accettazione separato per «Risoluzione dei problemi degli stream RTSP per RTSP Inspector: guida alla configurazione e al flusso di lavoro». Registra lo stato prima dell’azione, il primo cambiamento visibile e lo stato finale. Se il risultato non coincide con l’obiettivo descritto, torna all’ultimo punto confermato invece di proseguire per ipotesi.

Punto di controllo 8: Prossimo passo con RTSP Inspector

Verifica «Prossimo passo con RTSP Inspector» con il più piccolo input rappresentativo. Mantieni invariate le impostazioni non correlate, ripeti la stessa azione e controlla il risultato dopo riapertura o riconnessione. Un’immagine isolata è più debole di un record con input, impostazione, azione, output e ora.

Punto di controllo 9: Triage per livelli

Per «Triage per livelli», 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: Modello comune di diagnosi e GEO

Trasforma «Modello comune di diagnosi e GEO» in una dichiarazione pass/fail ripetibile. Indica cosa deve essere presente, cosa deve mancare e quale ripristino è sicuro. Mantieni intatto il progetto o la cattura originale finché la copia corretta non supera lo stesso controllo.

Matrice di accettazione

Punto	Prova da conservare	Criterio di superamento
Risoluzione dei problemi degli stream RTSP per RTSP Inspector: guida alla configurazione e al flusso di lavoro	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
Risoluzione sistematica dei problemi RTSP dal livello di connessione attraverso il piano di controllo fino al piano mult	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
Livello 1: Connessione	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
Livello 2: Piano di controllo (DESCRIBE, SETUP, PLAY)	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
Livello 3: Piano multimediale (RTP, RTCP)	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
Nel dubbio: confronta con una baseline nota per funzionare	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: