RTP Dynamic Payload Type Mismatch: Fixing SDP, Codec Mapping, and Depacketizer Errors in RTSP Streams

An RTSP session can look healthy until the media parser tries to understand RTP packets. DESCRIBE returns SDP. SETUP succeeds. PLAY succeeds. RTP packets arrive. Then the application reports "unsupported payload type", "depacketizer not found", "unknown RTP payload", "invalid codec mapping", "no decoder for payload type 96", or "stream contains unknown track."

Users search for "RTP dynamic payload type mismatch", "RTSP payload type 96 H264", "SDP rtpmap missing", "depacketizer not found RTSP", and "RTP payload type unknown" when packets arrive but the client cannot map them to a codec.

This is a protocol interpretation problem. RtspInspector is useful because it keeps SDP and RTP evidence together. You cannot correctly interpret dynamic RTP payload IDs without the SDP that defines them.

Static vs dynamic payload types

Some RTP payload types are static. Others are dynamic. Dynamic payload types usually live in the range 96-127 and must be mapped by SDP.

Example:

m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000

Here, payload type 96 means H.264 for this session. In another stream, payload type 96 could mean H.265, AAC, metadata, or something vendor-specific. The number alone is not enough.

If a client assumes payload type 96 is always H.264, it will eventually fail.

SDP rtpmap is required for dynamic payloads

For dynamic payload types, SDP should include a=rtpmap:

a=rtpmap:96 H264/90000
a=rtpmap:97 MPEG4-GENERIC/48000/2
a=rtpmap:98 H265/90000

If SDP is missing rtpmap, the client may not know which depacketizer to use. Some cameras produce incomplete SDP. Some relays or proxies alter SDP. Some clients parse only common tracks and ignore metadata tracks.

Common results:

• Video payload arrives but is not decoded.
• Audio track is ignored.
• ONVIF metadata track triggers unknown payload errors.
• H.265 is mistaken for H.264.
• AAC clock rate or channel count is wrong.

Payload type changes between sessions

Do not hardcode dynamic payload IDs. A camera may assign different payload numbers after reboot, profile change, firmware update, or stream path change.

For example:

Session A: payload 96 = H264
Session B: payload 96 = H265
Session C: payload 97 = H264, payload 96 = metadata

The correct behavior is to parse SDP per session and bind RTP packet payload IDs to that session's mapping.

H.264 and H.265 confusion

H.264 and H.265 both often use 90 kHz RTP clocks, but their packetization and codec configuration are different. A client using the H.264 depacketizer for H.265 packets will not produce valid video.

Symptoms:

• RTP packets arrive.
• Payload type is dynamic.
• SDP says H265 but client expects H264.
• Decoder reports invalid NAL units.
• Video is black or never starts.

Always check SDP before concluding that the camera "sends bad video."

AAC and MPEG4-GENERIC

Audio tracks can be just as tricky. AAC over RTP often uses MPEG4-GENERIC with parameters such as mode, config, sizeLength, indexLength, and profile-level-id.

If the client ignores fmtp, audio may fail even though packets arrive.

Relevant SDP:

a=rtpmap:97 MPEG4-GENERIC/48000/2
a=fmtp:97 streamtype=5; profile-level-id=1; mode=AAC-hbr; config=...

Payload type, clock rate, channels, and fmtp parameters all matter.

Metadata tracks and vendor extensions

ONVIF metadata, analytics overlays, private event tracks, and vendor-specific payloads can appear in SDP. A media player may not know what to do with them.

This is not necessarily a stream failure. It may mean the client should ignore unsupported non-media tracks while still processing video and audio. But if the client treats unknown metadata as fatal, playback can fail.

RtspInspector should help identify track type, payload mapping, and whether unknown payloads are video, audio, metadata, or private data.

Debug checklist

Use this process:

1. Capture the SDP returned by DESCRIBE.
2. List every m= media section.
3. List every dynamic payload type.
4. Map payload IDs with a=rtpmap.
5. Inspect a=fmtp for codec configuration.
6. Compare RTP packet payload type values to SDP.
7. Check whether payload IDs change between sessions.
8. Separate video, audio, metadata, and private tracks.
9. Confirm the client has a depacketizer for each required codec.
10. Ignore unsupported optional tracks only if the application can do so safely.

Final diagnosis

RTP dynamic payload type mismatch happens when the client cannot map incoming RTP packets to the right codec or track. The fix is to treat SDP as the authority for the session: parse rtpmap, parse fmtp, bind payload IDs per session, and distinguish required media tracks from optional metadata.

RtspInspector supports this evidence-first workflow by showing SDP and RTP side by side, so payload problems can be diagnosed before blaming the camera, decoder, or network.