RTSP Multicast and UDP Camera Streams: Why Discovery Works but Media Does Not Arrive

Camera networks often mix unicast RTSP, multicast RTP, ONVIF discovery, VLANs, PoE switches, firewalls, and NVRs. The symptom can be confusing: the camera is discovered, the RTSP URL is valid, DESCRIBE returns SDP, but media packets never arrive.

This is a classic protocol boundary. Discovery is not media. RTSP control is not RTP delivery. Multicast reachability is not the same as unicast reachability.

ONVIF Discovery Is a Different UDP Conversation

ONVIF discovery typically uses UDP multicast on a discovery address and port. If discovery succeeds, it proves that at least one multicast-style control path worked for discovery. It does not prove that RTP multicast groups are allowed, joined, routed, or forwarded.

Common mistakes:

• assuming ONVIF discovery proves RTP media path
• testing from a different VLAN than the NVR
• allowing TCP 554 but blocking UDP media ports
• blocking multicast group traffic at the switch
• forgetting IGMP snooping or querier behavior
• testing direct camera URL while NVR uses a different path

The report should name the traffic type: discovery, RTSP control, RTP media, or RTCP feedback.

Multicast Requires Group Membership

For multicast RTP, the receiver must join the multicast group. Switches and routers may need IGMP behavior to forward traffic correctly. If multicast is disabled, filtered, or misconfigured, RTSP control may still work while media never arrives.

Useful evidence:

• SDP declares multicast address or unicast transport
• SETUP transport header confirms requested mode
• receiver interface and VLAN
• multicast group address
• whether RTP packets reach the capture point
• whether RTCP appears
• whether unicast mode behaves differently

If unicast RTP works and multicast does not, the problem is probably network multicast configuration, not H.264.

UDP Media Can Be Blocked While TCP Control Works

Firewalls often allow TCP 554 or 8554 but block UDP ports. NAT can also break UDP media. This creates a common pattern:

• TCP connection succeeds
• DESCRIBE succeeds
• SETUP succeeds
• PLAY succeeds
• no RTP arrives

Switching to TCP interleaved is a useful comparison. If TCP interleaved works, the RTSP server and codec are likely functional. The UDP media path needs attention.

What to Capture

For multicast and UDP cases, capture:

• RTSP request and response headers
• SDP media address and track info
• transport header from SETUP
• client and server ports
• multicast group
• RTP packet arrival or absence
• RTCP packet arrival or absence
• same test over TCP interleaved

This evidence helps the network team fix routing, firewall, or multicast forwarding instead of asking the camera vendor to change codec settings.

Where RtspInspector Fits

RtspInspector is built for protocol evidence, not visual guessing. In multicast and UDP cases, its value is showing where the stream stopped:

• discovery worked but RTSP failed
• RTSP worked but RTP never arrived
• UDP failed but TCP interleaved worked
• multicast group was declared but no packets reached the client
• RTP arrived but codec readiness failed

Those are different failures. A player window cannot reliably tell them apart. A protocol report can.