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, interleaved rtp, rtp channel mismatch, rtcp channel, rtsp transport header, no video, rtsp diagnostics

RTSP over TCP interleaved transport is often used when UDP RTP is blocked by firewalls, NAT, VPNs, or cloud relay paths. It can make a camera stream work through networks where UDP would fail. But it introduces another class of problems: interleaved channel mismatch. The RTSP session connects. DESCRIBE returns SDP. SETUP succeeds. PLAY succeeds. Media bytes arrive on the TCP connection. Then the client shows no video, no audio, unknown RTP channel, malformed interleaved frame, or RTCP packets parsed as RTP.

Users search for "RTSP over TCP interleaved no video", "RTP interleaved channel mismatch", "RTSP interleaved 0-1", "RTSP TCP channel mapping", and "RTP over RTSP parsing error" when the control channel works but media parsing fails.

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

  1. Capture SDP from DESCRIBE.
  2. Identify every media track.
  3. Capture every SETUP request and response.
  4. Record Transport headers and interleaved= values.
  5. Map channel numbers to track and RTP/RTCP role.
  6. Inspect incoming $ frames and channel bytes.
  7. Compare RTP payload types against SDP for that track.
  8. Check whether RTCP appears on the expected odd channel.
  9. Check whether channel mappings change after reconnect.
  10. 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.

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