2026-06-02

RTP \"Unknown Write\" NDPI Error Fix — Dynamic Payload Type Mismatch in RTSP Streams

Fix \"unknown write\" RTP NDPI errors. Step-by-step: read the SDP rtpmap, cross-check RTP payload type byte, match codec depacketizer. H.264, H.265, AAC, ONVIF metadata.

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:

Find the RTSP DESCRIBE response.
Copy the SDP.
Find every m= media line and its payload numbers.
For each dynamic payload (96-127), find the matching a=rtpmap:<id> line.
Check the a=fmtp:<id> line for codec parameters.
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:

Capture the SDP returned by DESCRIBE.
List every m= media section.
List every dynamic payload type.
Map payload IDs with a=rtpmap.
Inspect a=fmtp for codec configuration.
Compare RTP packet payload type values to SDP.
Check whether payload IDs change between sessions.
Separate video, audio, metadata, and private tracks.
Confirm the client has a depacketizer for each required codec.
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.

Bind payload mappings to the exact SDP session

Dynamic payload types are local to the SDP session. A mapping must be discarded when the RTSP session ends, when the camera returns a new SDP, or when a new source/SSRC/profile boundary is selected. Reusing “96 means H.264” from an earlier stream is a design bug even if it happens to work in a lab.

Boundary	Mapping policy	Failure avoided
New `DESCRIBE` response	Parse every `m=`, `rtpmap`, and related `fmtp` again	Stale payload ID from old profile
New RTSP session	Scope mapping to current session identity and SDP	Cross-camera/cross-channel leakage
Track-level `SETUP`	Bind selected transport/channel to the correct media section	Mixing audio, video, or metadata packets
New SSRC after a source switch	Revalidate mapping and source context	Treating a replacement stream as old media
NVR/proxy restream	Treat downstream SDP as separate from upstream SDP	Assuming the proxy preserved payload numbers

The payload type field is only seven bits in the RTP header; it says nothing about the codec on its own. The media section, control URL, and RTSP session identify what that number means in the current capture.

Parse media sections as a complete track definition

An SDP m= line establishes a media section. The relevant a=rtpmap and a=fmtp attributes belong to that section and payload number, not automatically to every subsequent track. A robust client should handle several video/audio/metadata sections and explicitly choose the tracks it supports.

SDP element	Question to answer	Common implementation error
`m=video ... 96 97`	Which payload IDs are offered for this video track?	Taking the first dynamic ID globally
`a=rtpmap:96 H264/90000`	Which codec/clock rate does this session assign?	Treating 96 as static H.264
`a=fmtp:96 ...`	Which codec initialization/packetization settings apply?	Ignoring fmtp then calling valid payload corrupt
`a=control:`	Which RTSP URL selects this media track?	Binding RTP from a different setup channel
`m=application` or metadata mapping	Is this optional metadata rather than playable A/V?	Failing the whole session on an unsupported optional track

The SDP H.264/H.265 RTSP diagnostics guide gives the wider SDP workflow. Keep a sanitized copy of the actual SDP with the capture; guessing from a vendor model name is not a substitute.

Inspect RTP header, transport channel, and packetization together

After PLAY, record the RTP payload type, marker bit, sequence, timestamp, SSRC, and the negotiated transport/channel. For TCP interleaved RTSP, the interleaved channel identifies whether the bytes are RTP or RTCP; for UDP, ports and selected tracks matter. A packet classifier that sees only one datagram can label a valid dynamic payload “unknown” because it has no control-plane context.

Observation	What to check next
RTP PT does not appear in the selected SDP media section	Confirm correct session, track, transport, and possible proxy rewrite
PT maps to ONVIF/private metadata	Keep media playback separate from optional metadata support
PT maps to H.265, client uses H.264 depacketizer	Select the codec from current SDP rather than numeric convention
PT mapping is correct but decode fails	Inspect fmtp, packetization, parameter sets, and frame boundary
Interleaved channel carries RTCP where RTP expected	Verify channel pairing and parser framing
PT changes after a new SDP/profile	Rebuild the mapping before accepting packets

Use the RTSP TCP interleaved channel mismatch guide for channel framing and the H.264 packetization-mode guide for a mapping that is correct but still needs the right depacketizer.

Handle unsupported tracks without hiding required failures

An application can often ignore an optional metadata track and continue video/audio, but it must not silently ignore a required video track or claim playback is healthy. Make track policy explicit: supported required media, supported optional media, unsupported optional metadata, and unsupported required media.

Track policy outcome	Safe behavior
Required video mapped and supported	Set up/depacketize with its current SDP parameters
Optional audio unsupported	Preserve a warning while continuing video only if product policy allows
Optional ONVIF/private metadata unsupported	Isolate/report it without turning it into a false video failure
Required video has no `rtpmap`	Fail with SDP evidence; do not guess codec
Required codec unsupported	Explain decoder capability boundary and offer a permitted profile comparison

This distinction is especially important for an NVR or analytics workflow where metadata may be valuable but video must remain independently diagnosable. It also makes GEO-style answers more accurate: the packet classification is observed, the product policy is explicit, and the unknown vendor payload is not exaggerated into a universal stream defect.

Payload-mapping QA workflow

Capture the full sanitized DESCRIBE SDP for the active session.
Enumerate every media section and its offered dynamic payload values.
Bind rtpmap, fmtp, and control URL to the right section.
Record the transport or interleaved channel selected in SETUP.
Compare first RTP headers to that session map and retain SSRC/timestamp/sequence context.
Repeat after a reconnect or profile change; do not reuse the previous table.
Report whether the failure is missing SDP mapping, wrong track binding, unsupported codec, packetization/configuration, or optional-track policy.

QA case	Acceptance evidence
H.264 dynamic video	Current SDP/rtpmap/fmtp bind to observed PT
H.265 profile	Different mapping selects H.265 path, not numeric H.264 assumption
AAC audio	Clock rate/channels/fmtp are retained with the audio track
Metadata present	Optional/required policy is documented
Interleaved RTSP	Channel direction and RTP/RTCP pairing are verified
New session	Old mapping is invalidated and new SDP is parsed

Questions about RTP payload type mismatch errors

Is payload type 96 always H.264?

No. In the dynamic range it is only a session-local number. SDP defines whether it is H.264, H.265, AAC, metadata, or another format for that session.

Does an NDPI “unknown” label prove the camera sends invalid RTP?

No. A classifier may lack the RTSP/SDP context or support for an optional/private payload. Compare the actual RTP header to the active SDP before drawing a conclusion.

Why does the same camera use a different payload number after reconnect?

Dynamic assignments can change with profile, firmware, stream path, or new SDP generation. Parse and bind each session independently.

What can RTSP Inspector prove?

It can preserve the SDP mapping, RTSP track/transport selection, observed RTP header fields, and codec/metadata classification. It cannot certify an undocumented vendor payload as decodable without a supported specification or decoder.

The durable fix is architectural: make SDP the authority for every active RTSP session, bind packet interpretation to its media track, and give unsupported optional data an explicit policy rather than treating every unknown number as broken video.

Related guides

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