Ispettore RTSP logo Ispettore RTSP Diagnostica video RTSP

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.

rtsp udp bloccato, firewall rtp, rtsp niente video, fotocamera rtsp nazionale, intervallo di porte udp, tcp interlacciato, diagnostica rtsp

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:

  1. Il client apre la connessione TCP RTSP alla porta 554 della fotocamera.
  2. Il client invia "DESCRIBE".
  3. La fotocamera restituisce l'SDP.
  4. Il client invia "SETUP" con le porte client UDP.
  5. La fotocamera restituisce le porte del server UDP.
  6. Il client invia "PLAY".
  7. 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:

  1. Conferma che RTSP "DESCRIBE", "SETUP" e "PLAY" hanno avuto esito positivo.
  2. Ispeziona l'intestazione "Transport" e le porte UDP client/server.
  3. Controlla se i pacchetti RTP arrivano dopo "PLAY".
  4. Controlla se arrivano i pacchetti RTCP.
  5. Confronta il test LAN con il test VPN/WAN.
  6. Testare il trasporto interlacciato TCP.
  7. Controlla le regole del firewall per l'intervallo di porte UDP RTP.
  8. Controlla il port forwarding NAT e il comportamento della porta di origine.
  9. Verificare le porte UDP raggiungibili pubblicizzate dal client.
  10. 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.

Flussi di lavoro correlati