2026-06-02

RTSP vs UDP: Why RTSP Connects but Video Is Black — RTP Blocked by Firewall, NAT, and VPN

Fix RTSP no video when control connects but UDP RTP is blocked. Covers firewall rules, RTSP protocol port, NAT traversal, VPN RTP loss, TCP interleaved fallback, and camera UDP source ports.

One of the highest-intent RTSP problems is simple to describe: "the camera connects, but there is no video. In many cases, RTSP control works over TCP, but UDP RTP media packets never reach the client. The user sees a successful login, SDP, maybe even PLAY 200 OK, and then a timeout. Searches like "RTSP connects but no video", "RTP UDP blocked firewall", "RTSP works on LAN not over VPN", "camera RTSP NAT no video", and "RTSP TCP interleaved fix" all point to this layer split." RTSP is not one stream of data. The control channel and media channel can use different transport paths. If the control channel works and the media path fails, a player may show the same black screen as a codec failure. The packet evidence is different.

RTSP Inspector is useful because it separates RTSP control success from RTP media delivery.

Control works does not mean media works

A normal UDP RTP flow may look like:

Client opens RTSP TCP connection to camera port 554.
Client sends DESCRIBE.
Camera returns SDP.
Client sends SETUP with UDP client ports.
Camera returns UDP server ports.
Client sends PLAY.
Camera sends RTP packets to client UDP ports.

If steps 1-6 succeed and step 7 fails, the stream is not an RTSP login problem. It is a media path problem.

Transport header reveals the port plan

The SETUP request may include:

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

The camera may answer:

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

The camera should send RTP/RTCP to the client's UDP ports. Firewalls must allow that traffic. NAT devices must map it correctly. VPNs must carry it. If not, RTSP control can appear healthy while media is silent.

Common firewall and NAT failures

Common causes include:

Firewall allows TCP 554 but blocks UDP RTP port range.
NAT forwards RTSP port but not RTP ports.
Camera sends RTP from unexpected source ports.
Client advertises private UDP ports unreachable from camera.
VPN allows TCP but drops UDP.
Corporate firewall blocks high UDP ports.
Camera is behind double NAT.
RTP packets return to wrong interface.

The visible symptom is often "no video after PLAY."

Why TCP interleaved often works

RTSP over TCP interleaved carries RTP and RTCP inside the RTSP TCP connection. This avoids separate UDP pinholes.

If UDP mode fails and TCP interleaved works, that is strong evidence that the codec and camera are probably fine. The problem is likely UDP media transport.

However, TCP interleaved has its own parsing requirements, including channel mapping. It is a workaround for UDP path issues, not proof that every layer is healthy.

RTCP can help prove the path

If RTP is blocked but RTCP arrives, or vice versa, inspect port pairs. Some firewalls handle the two directions differently. RTCP receiver reports can also show packet loss and jitter if media partially arrives.

Record:

RTP packet count.
RTCP packet count.
RTP source IP and port.
RTP destination IP and port.
Sequence number gaps.
Time from PLAY to first packet.

Debug checklist

Use this workflow:

Confirm RTSP DESCRIBE, SETUP, and PLAY succeed.
Inspect Transport header and client/server UDP ports.
Check whether RTP packets arrive after PLAY.
Check whether RTCP packets arrive.
Compare LAN test vs VPN/WAN test.
Test TCP interleaved transport.
Check firewall rules for UDP RTP port range.
Check NAT port forwarding and source-port behavior.
Verify client advertised reachable UDP ports.
Do not debug codec until RTP payloads actually arrive.

Final diagnosis

When RTSP connects but UDP RTP is blocked, the camera can be perfectly reachable while media never arrives. The fix is in UDP port reachability, NAT behavior, firewall policy, VPN rules, or switching to TCP interleaved.

RTSP Inspector helps by showing the RTSP control sequence and RTP packet evidence together, so "no video" becomes a concrete transport diagnosis.

Prove which media path is missing

Start with one controlled observation window immediately after PLAY. Record the accepted Transport header rather than the requested one, because a camera or NVR can select different source ports or transport parameters. Then count RTP and RTCP separately and preserve the first packet timestamp, source, destination, and sequence number. A black video pane is a presentation symptom; those fields identify whether media ever entered the client network stack.

Evidence after `PLAY`	What it means	Most useful next check
No RTP and no RTCP	The UDP media path is completely absent or misaddressed	Client port reachability, NAT mapping, firewall policy
RTP arrives; no RTCP	Media may be present but the paired control path is filtered	Port-pair rules and camera RTCP behavior
RTCP arrives; no RTP	The path is partially open or port mapping differs	RTP port, source-port policy, track-specific transport
RTP arrives with gaps	Delivery exists; this is not a total UDP block	Sequence gaps, loss burst timing, bandwidth/policy
TCP interleaved delivers media	The camera can send media; UDP requires a path-level fix	Document the UDP tuple and compare firewall/VPN policy

Keep the actual source and destination tuples in the case report. “Allow UDP” is not a rule; a network owner needs the camera-side source behavior, client-side advertised port pair, direction, interface, and test time. The RTSP Inspector connection guide and troubleshooting workflow provide the surrounding session evidence.

Audit the NAT and firewall assumptions

RTSP port forwarding alone is frequently incomplete. A public RTSP TCP port can reach DESCRIBE and PLAY while UDP packets are still sent to a private, expired, or unforwarded address. Conversely, a client behind NAT can advertise UDP ports that the remote camera cannot reach. Check the exact deployment topology instead of applying a generic port-range rule.

Boundary	Question to verify	Evidence that answers it
Camera/NVR egress	Which source ports and source IP does the media use?	Returned `Transport`, packet capture near the sender
Client ingress	Are the advertised client RTP/RTCP ports reachable?	Capture on client interface and firewall decision log
NAT mapping	Does mapping survive until media begins and stay bound to the right interface?	NAT state, test timing, LAN versus WAN comparison
VPN tunnel	Does the tunnel carry the UDP packets both directions?	Endpoint captures, tunnel counters, same-session TCP comparison
Stateful firewall	Are RTP and RTCP permitted as the negotiated pair?	Rule/order evidence and observed accepts/drops

Do not publish broad, permanent port exposure merely to make one test work. Work with the network owner to permit the exact required flow, retain the proof, and retest with the same URL and camera profile. If a corporate or VPN policy prohibits UDP, TCP interleaving can be the selected transport only after its latency and capacity trade-offs have been evaluated.

Use TCP interleaving as a discriminating test

When UDP RTP is absent, request TCP interleaving for the same track. If the RTSP response accepts interleaved=a-b and media frames arrive on the existing TCP session, the camera's media encoder and selected track are much less likely to be the first problem. That comparison should be recorded alongside the failed UDP request; it is not a reason to discard the UDP evidence.

Comparison outcome	Bounded conclusion
UDP absent; interleaved media arrives	Investigate UDP routing, NAT, firewall, or VPN policy first
Both transports have no media	Recheck selected track, camera resource state, and control transcript
UDP packets arrive; interleaved fails	Inspect channel mapping and TCP-session parsing
UDP works on LAN only	The camera is healthy; inspect the WAN/VPN boundary

Use TCP interleaved channel mismatch guidance when framed media arrives but does not map to the expected track. If the symptom includes a delay or missing control response instead of a black stream, compare it with the RTSP timeout: UDP vs TCP interleaved guide.

FAQ: RTSP connects but UDP RTP is blocked

Why does `PLAY 200 OK` not prove that video can arrive?

PLAY confirms the control request was accepted. UDP RTP normally travels separately from that TCP control connection, so the camera can accept playback while a firewall, NAT device, or VPN blocks the media packets.

Is opening TCP 554 enough for an RTSP camera over the internet?

Not when the chosen transport uses UDP RTP/RTCP. The camera and client must be able to exchange the negotiated media flow as well. Confirm the exact tuple in a controlled capture rather than assuming a fixed range fits every device.

Is TCP interleaved always preferable?

No. It often avoids separate UDP pinholes, but it can change latency and failure behavior. Treat it as a diagnostic comparison and choose it deliberately for the deployment.

What a network escalation should contain

Provide the RTSP URL with secrets removed, observation time, client network, camera/NVR address, accepted transport response, requested and returned ports, RTP/RTCP counts, packet tuples, LAN/VPN comparison, and TCP-interleaved result. Add the first and last control response so the network team can see that the case is “RTSP connects but no video,” not a failed login or unsupported codec. For adjacent symptoms, see RTSP connects but no video and RTP sequence-number loss analysis, then open RTSP Inspector with the retained evidence.

How do you accept a firewall or NAT correction?

Reproduce with one camera profile and record DESCRIBE, each SETUP, the accepted Transport response, client/server RTP and RTCP endpoints, source/destination tuples visible at the capture point, PLAY response, first media packet, and time to first decodable frame. Keep UDP and TCP-interleaved runs separate but otherwise identical.

Test boundary	Evidence	Pass condition
RTSP control	TCP connect and DESCRIBE/SETUP/PLAY status	Authentication and session setup advance normally
UDP negotiation	Requested/returned ports or multicast details	Client and server agree on the media path
Packet arrival	RTP/RTCP tuples, counts, timestamps	Expected media reaches the intended observation point
NAT/firewall policy	Authorized rule/log or second capture point	The responsible boundary is proven, not guessed
Interleaved control	Same URL/profile over TCP	Comparison narrows transport without changing codec/profile
Recovery	Rule rollback/reapply or fresh session	Result survives a new session and timeout state

A host capture that sees no RTP proves absence only at that host. To name a firewall, NAT, VPN, or router, pair it with an authoritative policy log, counter, or capture on another side. Watch for source-port rewriting, address-family differences, symmetric return policy, short NAT lifetime, and a camera advertising an unreachable private address.

Acceptance requires repeated fresh sessions long enough to cross the original failure interval, with both RTP and RTCP behavior documented. Preserve the result in an RTSP Inspector report and use RTSP timeout transport analysis if media starts and later stops.

Validate direction, lifetime, and multiple tracks

Test video and audio separately when SDP exposes both. Each track can negotiate different ports, server sources, multicast groups, or interleaved channels. Video success does not prove the audio return path, and an ignored audio SETUP can look like a general playback issue in some clients.

Keep the session running beyond the suspected NAT or firewall idle lifetime while preserving RTSP keepalives and RTCP. If packets stop, record the last packet in each direction, the last control message, mapping/policy log where authorized, and whether a fresh SETUP restores traffic. Do not raise arbitrary keepalive frequency until the owner of the expiring state is identified.

Repeat from LAN, VPN, and the affected routed network only when each path is explicitly labeled. Address/port translation and capture location must be shown in the report. Acceptance means the production path—not merely a direct LAN control—carries all required media for the documented duration and reconnects cleanly after session teardown.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: