RTP \"Unknown Write\" NDPI Error Fix — Dynamic Payload Type Mismatch 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 or packet classifier reports unknown write, unknown RTP payload, NDPI unknown, unsupported payload type, depacketizer not found, invalid codec mapping, no decoder for payload type 96, or stream contains unknown track.

Those errors usually mean the bytes are present but the analyzer cannot map an RTP payload type to the codec and track definition from SDP. In RTSP, payload type 96 is not automatically H.264. It is a session-local dynamic ID. You have to read the SDP.

Fast answer: check SDP before blaming NDPI or the camera

If a capture says unknown write / RTP / NDPI, start here:

1. Find the RTSP DESCRIBE response.
2. Copy the SDP.
3. Find every m= media line and its payload numbers.
4. For each dynamic payload (96-127), find the matching a=rtpmap:<id> line.
5. Check the a=fmtp:<id> line for codec parameters.
6. Compare the RTP packet payload type byte with that SDP mapping.

If RTP packets use payload type 96 and SDP says a=rtpmap:96 H265/90000, an analyzer expecting H.264 will report nonsense. If SDP has a=rtpmap:96 vnd.onvif.metadata/90000, the unknown payload is not video at all; it is ONVIF metadata and should not kill playback.

This is why a generic DPI label such as NDPI unknown is not enough. DPI engines see packet bytes. They do not always have the RTSP control-plane context needed to interpret session-local dynamic payload IDs. For RTSP, the control plane and media plane have to be read together.

This is a protocol interpretation problem. RTSP Inspector 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.

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

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