RTSP Aggregate Control URL Debugging: SDP control:*, Track URLs, SETUP 404, and PLAY Fails

RTSP camera URLs often fail because the client builds the wrong control URL from SDP. Users search for "RTSP SETUP 404", "SDP control star", "RTSP aggregate control URL", "RTSP track URL wrong", "DESCRIBE works but SETUP fails", and "PLAY fails after SETUP" when a camera returns SDP successfully but media never starts.

RTSP Inspector is useful because this failure is not about whether the player can draw video. It is about whether the RTSP client interpreted the session-level and media-level control attributes correctly.

The common symptom

A typical trace looks like this:

DESCRIBE rtsp://camera/live
200 OK
SDP contains a=control:*
SDP video media contains a=control:trackID=1
SETUP rtsp://camera/trackID=1
404 Not Found

The camera did not necessarily reject RTSP. The client may have constructed SETUP with the wrong base URL.

Session-level and media-level control

SDP can contain control attributes at different levels:

a=control:*
m=video 0 RTP/AVP 96
a=control:trackID=1
m=audio 0 RTP/AVP 97
a=control:trackID=2

The session-level control may identify the aggregate resource used for PLAY and PAUSE. The media-level control identifies each RTP track used for SETUP.

If a client treats every control value as an absolute path, it can create invalid URLs.

Relative vs absolute control URLs

RTSP SDP control values may be:

• Absolute RTSP URLs.
• Relative paths.
• Track identifiers.
• * aggregate control.
• Vendor-specific paths.

Examples:

a=control:rtsp://192.168.1.10/live/trackID=1
a=control:trackID=1
a=control:streamid=0
a=control:video
a=control:*

The client must combine relative track control values with the correct base URL. A tiny difference such as /live/trackID=1 vs /trackID=1 can turn a working camera into a 404 Not Found.

DESCRIBE succeeds but SETUP fails

This is one of the strongest search patterns for this article. DESCRIBE proves the camera accepted the main URL and returned SDP. SETUP failure points to transport negotiation, track URL construction, unsupported media track, or camera firmware behavior.

Evidence to collect:

• Original DESCRIBE URL.
• Content-Base header if present.
• Content-Location header if present.
• Session-level a=control.
• Media-level a=control for each track.
• Exact SETUP URL.
• SETUP response status.
• Transport header used by SETUP.

Without the SETUP URL, the diagnosis is incomplete.

Content-Base and Content-Location

Some cameras include Content-Base or Content-Location headers in the DESCRIBE response. These headers can affect how relative SDP control paths should be resolved.

Failure patterns:

• Client ignores Content-Base.
• Client uses the original DESCRIBE URL when camera intended a different base.
• Camera returns a base URL with trailing slash differences.
• Proxy rewrites the RTSP URL but not SDP.
• Client normalizes away a path component needed by the camera.

These details are exactly why protocol evidence matters.

PLAY uses aggregate control

After SETUP succeeds for one or more tracks, PLAY may need to target the aggregate control URL instead of a single track URL. Some cameras accept either. Others are strict.

Search symptoms:

• "RTSP SETUP works but PLAY fails"
• "RTSP 460 Only Aggregate Operation Allowed"
• "RTSP PLAY 404"
• "RTSP track SETUP OK no video"

If PLAY targets the wrong URI, the RTP stream may never start even though SETUP returned 200 OK.

Multi-track audio and video

The bug is easier to see when both audio and video exist:

m=video ...
a=control:trackID=1
m=audio ...
a=control:trackID=2

The client must SETUP both tracks with their own control URLs, then PLAY the correct aggregate URL. If the client only sets up video but PLAY targets audio, or if it merges both tracks into one SETUP URL, the camera may return an error that looks unrelated.

ONVIF profile URL vs RTSP track URL

ONVIF can report stream URIs that differ from the final SDP track URLs. A stream URI from ONVIF may be valid for DESCRIBE but not directly valid for every SETUP request.

That creates the common support phrase: "ONVIF works but RTSP URL fails." The next diagnostic step is to inspect the SDP and derived SETUP URLs, not to keep generating new ONVIF URLs.

Debug checklist

Use this workflow:

1. Capture DESCRIBE response.
2. Save Content-Base and Content-Location.
3. Extract session-level a=control.
4. Extract each media-level a=control.
5. Build expected SETUP URL manually.
6. Compare it with the client SETUP URL.
7. Check whether SETUP fails with 404, 461, or 500.
8. Confirm whether PLAY targets aggregate or track URL.
9. Check multi-track audio/video behavior.
10. Preserve the exact RTSP request lines for vendor support.

Final diagnosis

RTSP aggregate control bugs hide inside SDP interpretation. A camera can accept DESCRIBE and still reject SETUP or PLAY if the client builds the wrong track or aggregate control URL.

RTSP Inspector helps expose the SDP control attributes, Content-Base headers, SETUP URLs, and PLAY target so engineers can prove whether the issue is URL construction, camera strictness, proxy rewriting, or client-side SDP handling.