2026-06-02

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

How to diagnose RTSP camera streams where ONVIF discovery, control traffic, or multicast setup works but RTP media never arrives.

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 RTSP Inspector Fits

RTSP Inspector 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.

Separate discovery, control, membership, and media evidence

A camera can be visible in an ONVIF tool, answer an RTSP URL, and still fail to deliver a single RTP packet to the client. Each observation belongs to a different protocol boundary. Treating them as one “camera reachability” result wastes time because the owner may be the camera profile, the receiver host, the switch, the VLAN gateway, the firewall, or the NVR path.

Observation	What it proves	What it does not prove
ONVIF discovery reply	Discovery traffic reached a listener	RTSP control or RTP media can traverse the chosen path
TCP connection to RTSP port	A listener accepted a control connection	UDP ports, multicast forwarding, or a valid track setup
Successful DESCRIBE	The server returned session description	The receiver joined a media group or receives packets
Successful SETUP and PLAY	RTSP negotiation reached media-start stage	RTP reaches the capture interface or can be decoded
RTP at camera-side capture	Camera emits media at that point	The client VLAN or NVR receives the same group
TCP interleaved playback works	Session and encoded media can travel over the RTSP connection	Multicast or UDP network policy is correct

Use that distinction in a case report. “Discovery works” is useful evidence, but it should never close an investigation whose actual complaint is “no media arrives after PLAY.”

Read the SDP and Transport headers before changing network equipment

Start with the actual session description and SETUP exchange. SDP tells the client about tracks and may expose a multicast address, port, control URI, payload type, and codec clock rate. The SETUP Transport header shows what the client requested and what the server accepted. A network team can act on concrete group, port, VLAN, and receiver details; it cannot act on “the player is black.”

Evidence field	Why it matters
SDP media address and port	Identifies whether the session advertises multicast or unicast media
Track control URL	Shows which media track is actually being set up
Requested Transport header	Records UDP, multicast, or TCP-interleaved intent
Accepted Transport response	Shows server ports, interleaved channels, or negotiated mode
Receiver interface and VLAN	Connects the case to the correct network segment
RTP SSRC and payload type	Confirms whether packets at the capture point match this session
RTCP packets	Provides an additional signal about media-path symmetry and timing
Test timestamp	Lets the network team correlate switch or firewall events

If the result is a 461 error rather than a successful SETUP, solve the negotiation boundary first with the RTSP 461 unsupported transport guide. No multicast switch change can repair a mode the server refused to negotiate.

Multicast has receiver and network responsibilities

Multicast is not a server sending a packet to a vague “network.” The receiver must join the group on the intended interface, and the local network must forward the group to that interface. IGMP snooping can reduce unnecessary flooding, but it can also expose configuration problems when a querier is absent, membership is learned on the wrong VLAN, or a downstream port is not eligible for the group. Routed multicast between VLANs adds another boundary; a discovery multicast on one segment is not proof that a different RTP group is routed to another.

A practical triage order is:

Confirm the camera profile and SDP actually request multicast rather than assuming it.
Record the multicast group, port, receiving interface, client VLAN, and test time.
Capture beside the client to establish whether RTP arrives at all.
Capture or inspect at a closer network point only after identifying the exact test window.
Compare one controlled unicast or TCP-interleaved session with the same camera and track.
Check group membership, snooping/querier state, VLAN policy, ACLs, and multicast-routing policy with the network owner.
Re-run the same request and retain the before/after packet evidence.

Multicast pattern	Most likely boundary	Next test
SDP advertises a group; no RTP at client	Membership, switch forwarding, VLAN, or ACL	Verify client interface/group and capture at receiver
RTP exists on camera-side port but not client VLAN	Network forwarding path	Check IGMP, VLAN membership, and routed multicast policy
Unicast works; multicast fails	Multicast-specific network configuration	Keep codec settings unchanged and escalate group/path evidence
Multicast works for one receiver but not another	Receiver interface, host firewall, or local switch port	Compare membership and VLAN context
RTP arrives but video still fails	Media/depacketization rather than reachability	Inspect payload, timestamps, loss, and codec readiness

UDP failure is not automatically a multicast failure

Unicast RTP over UDP can fail for a different reason: a firewall permits TCP 554 but blocks client or server UDP ports, a NAT mapping expires, an endpoint captures on the wrong interface, or the server sends media to a port pair different from the client's assumption. Multicast troubleshooting and UDP troubleshooting overlap, but they must not be merged into an untestable guess.

Compare the same track through a deliberate transport change. If TCP interleaved succeeds while UDP does not, the server, RTSP URL, session description, and encoded media have passed a useful comparison. The remaining focus is the UDP media path. The UDP/RTP firewall and NAT guide covers that path; the TCP interleaved channel guide is useful when the comparison itself fails.

Capture a bounded incident window

Capture just before the RTSP request, through DESCRIBE, SETUP, PLAY, and several seconds of expected media. A huge packet file with no stated request time is hard to correlate with switch or firewall logs. A bounded window lets a reviewer map control intent to data-plane result.

Capture checkpoint	Expected evidence	Diagnostic value
Before SETUP	TCP session and current client address/interface	Establishes the receiver path
DESCRIBE	SDP tracks, addresses, ports, payload mapping	Defines the session the client will request
SETUP	Requested and accepted Transport values	Separates negotiation from delivery
PLAY	Server acknowledgement and stream start time	Defines when media should begin
First RTP/RTCP	SSRC, ports, payload type, arrival direction	Proves or disproves data-plane arrival
Comparison transport	Same track over unicast or TCP interleaved	Isolates multicast/UDP-specific conditions

RTSP Inspector is an evidence tool, not a camera player. Its useful result is a report that says, for example, “PLAY succeeded at this time, SDP advertised this group and port, no matching RTP reached the selected receiver interface, while TCP interleaved did.” That is actionable for the correct owner without claiming the exact switch configuration is known.

FAQ: multicast and UDP camera media

Why does ONVIF discovery work if multicast RTP does not?

Discovery and RTP media can use different multicast addresses, ports, VLAN paths, membership state, and policy. A discovery response only proves the discovery exchange reached its listener. Capture the session's actual SDP group and the receiver-side RTP result before drawing a media conclusion.

Should I disable IGMP snooping to test the problem?

Do not make a broad network change merely to see whether video appears. First capture a controlled test and consult the network owner with group, VLAN, receiver, and time evidence. A change may increase flooding or hide the real membership problem without proving a durable fix.

Is TCP interleaved always the best permanent workaround?

No. It is a valuable comparison transport because it keeps RTP inside the RTSP TCP connection. The right permanent mode depends on camera capability, NVR design, latency, capacity, firewall policy, and the environment. Use the comparison to identify the failed boundary, not to mandate one transport for every camera.

What if RTP arrives but there is still no picture?

Then the reachability question is answered, but media interpretation remains. Check payload type, RTP sequence gaps, timestamp behavior, H.264/H.265 SDP mapping, and keyframe availability. Start with RTSP connects but no video and preserve the packet window around the first failed decode symptom.

What should a multicast acceptance record contain?

Record the SDP multicast destination, media port, TTL, interface selected by the receiver, IGMP join and leave timing, first observed RTP packet, sequence continuity, timestamp progression, payload type, and whether RTCP is expected. Capture on the receiving host and, when possible, at the nearest switch observation point. This separates “the camera sent multicast” from “this VLAN delivered it to this receiver.”

Repeat with the same profile on a known-working port and avoid changing transport, camera profile, and switch configuration together. A useful conclusion identifies whether the failure occurs before group membership, inside multicast forwarding, at the host interface, or after RTP arrival in codec readiness. Preserve the sanitized SDP and the RTSP troubleshooting workflow with both packet windows.

Related guides

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