2026-06-02

RTSP vs UDP: perché RTSP si connette ma il video è nero: RTP bloccato da firewall, NAT e VPN

Corregge l'assenza di video RTSP quando il controllo si connette ma l'RTP UDP è bloccato. Copre le regole del firewall, la porta del protocollo RTSP, l'attraversamento NAT, la perdita dell'RTP VPN, il fallback interleaved TCP e le porte di origine UDP della telecamera.

Uno dei problemi RTSP di più alta intensità è semplice da descrivere: "la telecamera si connette, ma non c'è video. In molti casi, il controllo RTSP funziona su TCP, ma i pacchetti multimediali UDP RTP non raggiungono mai il client. L'utente vede un login riuscito, SDP, forse anche "PLAY 200 OK", e quindi un timeout. Ricerche come "RTSP si connette ma nessun video", "RTP UDP bloccato firewall", "RTSP funziona su LAN non su VPN", "fotocamera RTSP NAT nessun video" e "Correzione interleaved TCP RTSP" puntano tutte a questa suddivisione del livello." RTSP non è un flusso di dati. Il canale di controllo e il canale multimediale possono utilizzare percorsi di trasporto diversi. Se il canale di controllo funziona e il percorso multimediale non funziona, un lettore potrebbe mostrare la stessa schermata nera di un errore del codec. La prova del pacchetto è diversa.

RTSP Inspector è utile perché separa il successo del controllo RTSP dalla consegna dei media RTP.

Il controllo funziona non significa che i media funzionino

Un normale flusso RTP UDP potrebbe assomigliare a:

Il client apre la connessione TCP RTSP alla porta 554 della fotocamera.
Il client invia "DESCRIBE".
La fotocamera restituisce l'SDP.
Il client invia "SETUP" con le porte client UDP.
La fotocamera restituisce le porte del server UDP.
Il client invia "PLAY".
La fotocamera invia pacchetti RTP alle porte UDP del client.

Se i passaggi da 1 a 6 hanno esito positivo e il passaggio 7 ha esito negativo, lo streaming non è un problema di accesso RTSP. È un problema del percorso multimediale.

L'intestazione del trasporto rivela la planimetria del porto

La richiesta "SETUP" può includere:

Transport: RTP/AVP;unicast;client_port=50000-50001

The camera may answer:

Transport: RTP/AVP;unicast;client_port=50000-50001;server_port=6970-6971

La fotocamera dovrebbe inviare RTP/RTCP alle porte UDP del client. I firewall devono consentire quel traffico. I dispositivi NAT devono mapparlo correttamente. Le VPN devono trasportarlo. In caso contrario, il controllo RTSP può apparire integro mentre i media sono silenziosi.

Errori comuni di firewall e NAT

Le cause comuni includono:

Il firewall consente TCP 554 ma blocca l'intervallo di porte RTP UDP.
NAT inoltra la porta RTSP ma non le porte RTP.
La fotocamera invia RTP da porte di origine impreviste.
Il client pubblicizza le porte UDP private irraggiungibili dalla fotocamera.
La VPN consente TCP ma elimina UDP.
Il firewall aziendale blocca le porte UDP elevate.
La fotocamera è dietro il doppio NAT.
I pacchetti RTP ritornano all'interfaccia sbagliata.

Il sintomo visibile è spesso "nessun video dopo la riproduzione".

Perché TCP interleaved spesso funziona

RTSP su TCP interleaved trasporta RTP e RTCP all'interno della connessione RTSP TCP. Ciò evita fori stenopeici UDP separati.

Se la modalità UDP fallisce e il TCP interleaved funziona, ciò è una prova evidente che il codec e la fotocamera probabilmente funzionano bene. Il problema è probabilmente il trasporto multimediale UDP.

Tuttavia, TCP interleaved ha i propri requisiti di analisi, inclusa la mappatura dei canali. Si tratta di una soluzione alternativa per i problemi del percorso UDP, non di una prova che ogni livello sia integro.

RTCP può aiutare a dimostrare il percorso

Se l'RTP è bloccato ma arriva l'RTCP, o viceversa, ispeziona le coppie di porte. Alcuni firewall gestiscono le due direzioni in modo diverso. I rapporti del ricevitore RTCP possono anche mostrare perdita di pacchetti e jitter se il supporto arriva parzialmente.

Documentazione:

Conteggio dei pacchetti RTP.
Conteggio pacchetti RTCP.
IP e porta di origine RTP.
IP e porta di destinazione RTP.
Lacune nei numeri di sequenza.
Tempo da "PLAY" al primo pacchetto.

Elenco di controllo del debug

Utilizza questo flusso di lavoro:

Conferma che RTSP "DESCRIBE", "SETUP" e "PLAY" hanno avuto esito positivo.
Ispeziona l'intestazione "Transport" e le porte UDP client/server.
Controlla se i pacchetti RTP arrivano dopo "PLAY".
Controlla se arrivano i pacchetti RTCP.
Confronta il test LAN con il test VPN/WAN.
Testare il trasporto interlacciato TCP.
Controlla le regole del firewall per l'intervallo di porte UDP RTP.
Controlla il port forwarding NAT e il comportamento della porta di origine.
Verificare le porte UDP raggiungibili pubblicizzate dal client.
Non eseguire il debug del codec finché non arrivano effettivamente i payload RTP.

Diagnosi finale

Quando RTSP si connette ma UDP RTP è bloccato, la fotocamera può essere perfettamente raggiungibile mentre i contenuti multimediali non arrivano mai. La soluzione riguarda la raggiungibilità delle porte UDP, il comportamento NAT, la politica del firewall, le regole VPN o il passaggio a TCP interleaved.

RTSP Inspector aiuta mostrando insieme la sequenza di controllo RTSP e l'evidenza dei pacchetti RTP, quindi "nessun video" diventa una diagnosi di trasporto concreta.

Prova riproducibile per «RTSP vs UDP: perché RTSP si connette ma il video è nero: RTP bloccato da firewall, NAT e VPN»

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 «RTSP vs UDP: perché RTSP si connette ma il video è nero: RTP bloccato da firewall, NAT e VPN» 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 «RTSP vs UDP: perché RTSP si connette ma il video è nero: RTP bloccato da firewall, NAT e VPN» è: Corregge l'assenza di video RTSP quando il controllo si connette ma l'RTP UDP è bloccato. Copre le regole del firewall, la porta del protocollo RTSP, l'attraversamento NAT, la perdita dell'RTP VPN, il fallback interleaved TCP e le porte di origine UDP della telecamera. 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: RTSP vs UDP: perché RTSP si connette ma il video è nero: RTP bloccato da firewall, NAT e V

Per «RTSP vs UDP: perché RTSP si connette ma il video è nero: RTP bloccato da firewall, NAT e VPN», 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: Corregge l'assenza di video RTSP quando il controllo si connette ma l'RTP UDP è bloccato.

Chiudi «Corregge l'assenza di video RTSP quando il controllo si connette ma l'RTP UDP è bloccato. Copre le regole del firewall, la porta del protocollo 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 3: Il controllo funziona non significa che i media funzionino

Per «Il controllo funziona non significa che i media funzionino», 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: L'intestazione del trasporto rivela la planimetria del porto

Chiudi «L'intestazione del trasporto rivela la planimetria del porto» 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: Errori comuni di firewall e NAT

Per «Errori comuni di firewall e NAT», 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: Perché TCP interleaved spesso funziona

Chiudi «Perché TCP interleaved spesso funziona» 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: RTCP può aiutare a dimostrare il percorso

Per «RTCP può aiutare a dimostrare il percorso», 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: Elenco di controllo del debug

Chiudi «Elenco di controllo del debug» 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: Diagnosi finale

Per «Diagnosi finale», 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: Prova riproducibile per «RTSP vs UDP: perché RTSP si connette ma il video è nero: RTP bloc

Chiudi «Prova riproducibile per «RTSP vs UDP: perché RTSP si connette ma il video è nero: RTP bloccato da firewall, NAT e VPN»» 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
RTSP vs UDP: perché RTSP si connette ma il video è nero: RTP bloccato da firewall, NAT e VPN	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
Corregge l'assenza di video RTSP quando il controllo si connette ma l'RTP UDP è bloccato. Copre le regole del firewall,	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
Il controllo funziona non significa che i media funzionino	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
L'intestazione del trasporto rivela la planimetria del porto	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
Errori comuni di firewall e NAT	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
Perché TCP interleaved spesso funziona	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: