2026-06-02

RTSP over TCP Interleaved Channel Mismatch: Fixing RTP/RTCP Channel Mapping and No Video Problems

How to diagnose RTSP over TCP interleaved channel mismatch, RTP and RTCP channel mapping, Transport headers, interleaved=0-1, no video, and camera media parsing failures.

RTSP over TCP may complete DESCRIBE, SETUP, and PLAY and deliver $-framed bytes, yet the client shows no video because it parses RTP and RTCP on the wrong interleaved channels. Compare each interleaved=0-1 assignment in the Transport response with the channel byte, frame length, payload type, and SSRC of arriving data. This can prove an RTP/RTCP channel-map mismatch or malformed interleaved frame; it cannot show how a player's proprietary parser recovers from the inconsistency.

RTSP Inspector is useful here because the important evidence is in the Transport header and the $-framed interleaved data on the RTSP TCP connection.

What interleaved transport means

With UDP transport, RTSP control uses TCP and RTP/RTCP media uses separate UDP ports. With TCP interleaved transport, media packets are embedded inside the RTSP TCP connection.

The SETUP response may contain:

Transport: RTP/AVP/TCP;unicast;interleaved=0-1

That means RTP and RTCP for that track should be carried on interleaved channels 0 and 1. Interleaved frames use a $ marker, a channel byte, a length, and then the RTP or RTCP packet.

If the client maps channels incorrectly, it may parse RTP as RTCP, audio as video, or metadata as media.

Multiple tracks create more mappings

A camera with video and audio may return separate SETUP responses:

Video Transport: RTP/AVP/TCP;unicast;interleaved=0-1
Audio Transport: RTP/AVP/TCP;unicast;interleaved=2-3

Now the client must map:

Channel 0: video RTP
Channel 1: video RTCP
Channel 2: audio RTP
Channel 3: audio RTCP

If audio and video setup order changes, hardcoded assumptions break. If a metadata track is added, channel assignments can shift again.

Common symptoms

Interleaved channel problems look like:

RTSP session reaches PLAY but video stays black.
RTP bytes arrive but payload parser rejects them.
RTCP Sender Reports are parsed as media.
Audio packets are sent to video depacketizer.
Sequence numbers look impossible.
Payload type does not match SDP for that track.
Client reports "invalid RTP packet" or "unknown interleaved channel."

The network may be fine. The camera may be sending media. The client is just reading the wrong channel mapping.

Transport header is the authority

Do not infer channel mapping from track order alone. Use the Transport header returned by the camera for each SETUP.

For each track, preserve:

Track control URL.
Transport mode.
Interleaved channel pair.
Payload type from SDP.
Media type from SDP.

Then compare incoming interleaved frames to that mapping.

Camera and proxy quirks

Some cameras behave inconsistently:

They ignore requested interleaved channel numbers and assign their own.
They return interleaved=0-1 for multiple tracks.
They send RTCP on unexpected channels.
They omit RTCP.
A proxy rewrites Transport but does not rewrite media frames.

These are exactly the cases where a player-only test hides too much. The raw RTSP and interleaved frame evidence matters.

Checklist for interleaved channel debugging

Use this workflow:

Capture SDP from DESCRIBE.
Identify every media track.
Capture every SETUP request and response.
Record Transport headers and interleaved= values.
Map channel numbers to track and RTP/RTCP role.
Inspect incoming $ frames and channel bytes.
Compare RTP payload types against SDP for that track.
Check whether RTCP appears on the expected odd channel.
Check whether channel mappings change after reconnect.
Test UDP only after the TCP interleaved mapping is understood.

Final diagnosis

RTSP over TCP interleaved problems are not always network problems. If media arrives but no video appears, inspect channel mapping. The Transport header defines which interleaved channel carries each RTP and RTCP stream.

RTSP Inspector helps by exposing both RTSP control and interleaved media framing, so "RTSP connects but no video" can be diagnosed as a channel mapping issue instead of a codec or firewall guess.

Decode the `$` frame before calling it RTP

An interleaved frame has four parts: the dollar marker, one channel byte, a two-byte big-endian length, and exactly that many following bytes. The channel byte is transport routing information; it is not an RTP payload type, stream index, or UDP port. Treating it as any of those is a common client bug. A malformed length can be just as destructive as a wrong map because it moves the parser boundary and makes the next RTSP response or media frame appear corrupt.

Frame check	Expected observation	Failure interpretation
Marker	`$` begins an interleaved unit on the RTSP TCP connection	Bytes may be RTSP text, a parser offset, or a non-interleaved transport path
Channel byte	Matches one pair returned for a specific `SETUP`	Client/proxy may be routing the frame to the wrong track
Length	Matches the bytes that follow before the next framing boundary	A bad length can desynchronize every later frame
RTP version/payload type	Valid only after the channel identifies the expected RTP track	Correct channel does not prove codec or SDP compatibility
RTCP packet type	Appears on the assigned RTCP channel when present	Missing RTCP is a camera behavior observation, not proof of broken RTP

Write the map down as an explicit table in the case rather than relying on array position in code. For a video/audio camera, a useful row reads: “trackID=1, H.264 video, RTP payload type 96, interleaved=0-1, channel 0 RTP, channel 1 RTCP.” That sentence can be checked against every arriving frame and survives a reconnect where setup order changes.

Build the map from SDP and every SETUP response

SDP tells you which media tracks and payload types exist; SETUP tells you the transport channels actually assigned for the selected session. Neither source replaces the other. A camera can advertise multiple video, audio, metadata, or application tracks in SDP, and it can assign channels in an order the client did not request. Some endpoints include an aggregate control URL while individual tracks have their own control values, so preserve the exact request URL too.

Evidence source	What to record	Why it matters
`DESCRIBE` SDP	Media type, `m=` payload types, `a=control`, codec mapping	Defines which RTP payload should be valid for the track
SETUP request	Requested transport and requested channel pair	Shows what the client asked for
SETUP response	Returned transport, session ID, assigned pair	Authoritative channel assignment for that setup
PLAY response	Range/scale/session confirmation when present	Establishes the transition into media delivery
`$` frames	Channel, length, first RTP/RTCP bytes, arrival order	Tests whether returned assignments match actual traffic

The RTSP aggregate control URL and SETUP 404 guide is useful when the wrong track control URL prevents a valid map from being created. The RTP dynamic payload type and SDP guide is the next check when the channel is correct but the payload type is not valid for that track.

Separate channel mismatch from similar no-video failures

An RTSP session can reach PLAY and still show a black video pane for several reasons. Do not jump to a channel mismatch merely because media uses TCP. The following comparisons narrow the claim.

Observed pattern	Most useful next interpretation
No `$` frames after successful `PLAY`	Check keepalive, server media start, firewall/proxy behavior, and session state before channel parsing
`$` frames all use a channel absent from SETUP responses	Strong evidence of server/proxy/client mapping disagreement
Channel matches, but RTP payload type is unexpected for SDP	Track or SDP/payload mapping issue rather than interleaved-channel issue alone
Channel matches and RTP is valid, but decoder has no picture	Inspect codec configuration, SPS/PPS, keyframe availability, and application decoding
RTCP arrives on an even/RTP channel	Preserve exact frames; do not assume odd/even convention is enough without the returned pair
Reconnect changes pair allocation and only then fails	Client has probably hardcoded a prior session’s channel layout

For video that starts and then stops, compare the RTSP keepalive and 30-second stop workflow. For a channel-correct RTP stream that is undecodable, use the H.264 SPS/PPS missing diagnostics. These are different failure boundaries and should not be merged into one “no video” conclusion.

Reproduce safely with a two-track test

Use a camera or permitted test stream with at least video and audio if available. Capture one session after a clean connection, then change only one variable. Avoid testing against a production recorder by opening many unnecessary sessions; connection limits can create a separate 503 or timeout symptom.

Save the SDP and enumerate its tracks.
Record the SETUP request and response for each track in order.
Create a mapping table from returned channel pair to media role.
Start PLAY and annotate the first frames seen on every channel.
Reconnect and repeat without assuming the same allocation.
Repeat with a single track, then with both tracks, if the server supports both.
If a proxy is in the path, capture on both sides only where authorized and compare whether it rewrites control and media consistently.

QA case	Expected result
One video track over TCP	One returned RTP/RTCP channel pair and frames that match it
Video plus audio	Distinct pairs or explicitly documented sharing; no hardcoded track order
Reconnect	New returned assignments become the active map
TCP-to-UDP change	Transport-specific data path changes without reusing TCP channel state
Unknown channel frame	Logged as an evidence event, not silently decoded as a default track

Questions about RTSP TCP interleaved channels

Are RTP always even and RTCP always odd channels?

Pairs are commonly allocated that way, but the authoritative evidence is the interleaved= value returned for that track. A robust client parses the returned pair and does not rely on an even/odd convention or the order of SDP media sections.

Can a camera ignore the requested `interleaved=0-1` pair?

It may return a different supported pair. The client should use the pair in the response for the active session. If the server returns overlapping pairs for distinct tracks, preserve the exact response and frame evidence; that is a concrete interoperability defect to investigate.

Does seeing `$` frames prove the stream is healthy?

No. It proves framed bytes arrived on the RTSP TCP connection. You still need to validate channel ownership, declared length, RTP/RTCP syntax, payload type, timestamp/sequence behavior, and decoder requirements.

What belongs in an escalation report?

Include SDP, each SETUP request/response, session ID as permitted, the mapping table, representative frame headers, first mismatch timestamp, and whether a reconnect changes allocation. Do not include credentials or unrestricted camera URLs in a shareable report.

RTSP TCP interleaved debugging is reliable when every media frame is interpreted through the channel pair the server actually returned. That transforms “RTSP connects but no video” into a narrow, testable transport-map finding.

Parser regression checks for client teams

Run parser tests with captured, sanitized fixtures rather than only a familiar camera. Include a single video track, video plus audio, a server that returns different channels from the requested pair, a reconnect with new assignments, and a deliberately unknown channel. Assert that the client stores mappings per RTSP session and per track, validates the declared frame length before reading payload, and reports an unknown channel without routing it to a default decoder.

Regression	Correct behavior
Returned pair differs from requested pair	Replace the request assumption with the response mapping
Second track is added	Allocate a distinct map from its own SETUP response
TCP connection is reopened	Discard old channel state before processing new frames
Frame length is incomplete	Wait or fail safely; do not consume the next RTSP message as media
Unexpected channel appears	Retain a bounded evidence record and surface a transport-map diagnostic

This test set catches the hardcoded-array bugs that often work against one single-track camera and fail only after an audio track, proxy, or reconnect changes the channel order.

Can a proxy create a channel mismatch after SETUP succeeds?

Yes. A proxy that relays or rewrites RTSP control must keep the returned transport mapping consistent with the media frames it forwards. Capture the request/response and frame headers at the authorized observation point. If the upstream pair differs from downstream behavior, report that boundary precisely instead of blaming the camera or player without evidence.

Should a client guess the media role from packet contents?

No. RTP and RTCP parsing can validate a frame after the transport map selects the track, but guessing a role from payload bytes hides routing defects and can misclassify metadata or malformed traffic. Keep channel mapping, SDP payload mapping, and RTP parsing as separate checks.

Related guides

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