RTSP Connects but UDP RTP Is Blocked: Firewall, NAT, Port Range, and TCP Interleaved Fixes

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.

RtspInspector 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:

1. Client opens RTSP TCP connection to camera port 554.
2. Client sends DESCRIBE.
3. Camera returns SDP.
4. Client sends SETUP with UDP client ports.
5. Camera returns UDP server ports.
6. Client sends PLAY.
7. 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:

1. Confirm RTSP DESCRIBE, SETUP, and PLAY succeed.
2. Inspect Transport header and client/server UDP ports.
3. Check whether RTP packets arrive after PLAY.
4. Check whether RTCP packets arrive.
5. Compare LAN test vs VPN/WAN test.
6. Test TCP interleaved transport.
7. Check firewall rules for UDP RTP port range.
8. Check NAT port forwarding and source-port behavior.
9. Verify client advertised reachable UDP ports.
10. 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.

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