How To Troubleshoot Common RTSP and RTSPS Restreaming Errors

For organizations running IP camera fleets, RTSP remains the workhorse ingest protocol. It is the foundation of ONVIF compliance, the standard most camera manufacturers ship with, and the protocol Wowza Streaming Engine has supported natively for over a decade. RTSPS, the TLS-encrypted variant, is increasingly common in deployments where compliance requirements mandate end-to-end encryption between the camera and the media server.

Most RTSP and RTSPS ingest issues fall into a small number of repeatable categories, and most resolve with the same handful of stream file properties and diagnostic steps. This blog covers:

1. The three root causes behind most RTSP and RTSPS ingest failures
2. A step-by-step diagnostic flow for problematic camera sources
3. Stream file properties that resolve the most common encoder and SDP errors
4. Advanced troubleshooting with jitter buffers and debug TS recordings

What Causes RTSP and RTSPS Restreaming Errors?

Most RTSP and RTSPS streaming errors in Wowza Streaming Engine come from one of three root causes:

1. A source encoder or camera sending malformed metadata
2. Network paths blocking the streaming packets
3. Bursty out-of-order packet delivery that breaks timecode alignment

Source encoder or camera issues

IP cameras often send non-compliant SDP files, malformed SPS/PPS data, or unrecognized track types that the server cannot parse. This happens far more often than most teams expect, especially in mixed-vendor camera deployments.

Network path issues

Another point of failure could occur between the camera and the Wowza Streaming Engine server. Firewalls, NAT translation, or routing problems can block RTP and RTCP packets from reaching the ingest port, even when the RTSP control channel connects successfully.

Bursty or out-of-order packet delivery issues

Cameras transmitting over unstable network segments produce timecode drift and packetization errors downstream. This manifests as choppy playback or stalled streams. For the underlying protocol-stack context, see our blog on RTP and RTSP frequently asked questions.

The RTSP Troubleshooting Decision Tree

Before adjusting any configuration, technical teams should work through a sequential set of diagnostic checks. Wowza recommends a four-step decision process for any failing RTSP or RTSPS ingest.

Step 1: Verify Source Playback With a Third-Party Tool

The first test is to confirm the camera URL is reachable and playable from the Wowza Streaming Engine host itself. From the same machine running Wowza Streaming Engine, attempt playback of the RTSP URL using VLC or ffplay. The ffplay command looks like this:

ffplay -rtsp_transport tcp rtsp://username:password@camera-ip:554/stream

If playback fails, the issue is upstream of the server. Common culprits include:

• Firewall rules blocking the RTSP port (TCP 554 for RTSP, TCP 322 for RTSPS)
• Incorrect credentials
• NAT translation problems
• The camera itself being unreachable.

Network engineers can run a packet trace using tcpdump or Wireshark on the Wowza Streaming Engine host to confirm whether the camera’s packets are actually arriving at the server’s network interface.

If playback succeeds in VLC or ffplay but the Wowza Streaming Engine MediaCaster still cannot ingest the stream, the camera is reachable and the network path is clean. The next step is to investigate the server’s logs.

Step 2: Check the Wowza Streaming Engine Access Logs for MediaCaster Errors

Once it is confirmed the source is reachable, the next step is to check the Wowza Streaming Engine logs for MediaCaster errors. Common error signatures include depacketizer failures, SDP parsing errors, RTP timestamp warnings, and connection state mismatches.

If no errors appear, technical teams should verify the MediaCaster connection has actually started from Wowza Streaming Engine Manager and confirm the stream URI in the .stream file matches the working URL from Step 1. For a refresher on stream file setup, see Re-stream from another source in Wowza Streaming Engine.

If errors do appear in the logs, the next step is to apply the following three diagnostic stream file properties.

How To Resolve Encoder and SDP Errors With Stream File Properties

Three .stream file properties resolve most RTSP ingest errors caused by problematic camera or encoder sources:

1. rtspFilterUnknownTracks: true/false
2. rtpIgnoreProfileLevelId: true/false
3. rtpIgnoreSPropParameterSets: true/false

rtspFilterUnknownTracks

The rtspFilterUnknownTracks property filters out tracks the server cannot parse, such as proprietary metadata channels embedded in some IP camera streams. The default value is false. Set this property to true when cameras send vendor-specific metadata tracks (ONVIF metadata extensions, telemetry channels, or analytics overlays) alongside standard audio and video. If the following error occurs while ingesting a stream that included an ONVIF SMP metadata extension:

Failed to find an appropriate depacketizer for this track (vnd.onvif.metadata)

The camera may be sending a proprietary metadata channel that Wowza Streaming Engine can not recognize. The fix is to filter out the unknown track at the ingest layer using the rtspFilterUnknownTracks property. The same pattern applies to a wide range of vendor-specific tracks that surface in mixed camera deployments.

rtpIgnoreProfileLevelId

The rtpIgnoreProfileLevelId property disables profile-level-id parsing, which the server normally extracts from SPS and PPS NAL units. The default value is false. Set this property to true when encoders report inconsistent or invalid profile level IDs in the SDP that conflict with the actual stream encoding.

rtpIgnoreSPropParameterSets

The rtpIgnoreSPropParameterSets property tells Wowza Streaming Engine to ignore the sprop-parameter-sets data in the SDP file and rely instead on the SPS and PPS packets within the live stream. The default value is false. Set this property to true for cameras and encoders that send incorrectly formatted parameter sets in their SDP advertisements.

After editing the .stream file, technical teams should disconnect and reconnect the MediaCaster instance from Wowza Streaming Engine Manager and retest playback. For the full reference of supported stream file properties, see How to specify per-stream settings in stream files.

How to Fix RTSP Network and Packet Loss Issues

When the source is clean and the stream file properties do not resolve the issue, shift focus to how packets are arriving at the server.

How To Verify Network Path and Packet Delivery

A packet capture on the Wowza Streaming Engine host confirms whether packets are actually reaching the server. Tools like tcpdump on Linux or Wireshark on Windows can filter on the camera’s IP address and the relevant ports. RTSP uses TCP 554 by default, RTSPS uses TCP 322, and RTP uses dynamically-negotiated UDP ports that the RTSP SETUP exchange establishes during session initiation.

For deployments behind NAT or firewalls, RTP over UDP often fails even when the RTSP control connection succeeds. Switching the MediaCaster to RTP over TCP (interleaved mode) resolves most NAT and firewall issues at the cost of slightly higher latency.

How To Configure An RTP Jitter Buffer for Bursty Streams

When packets arrive out of order or with high jitter, the RTP jitter buffer in Wowza Streaming Engine holds incoming packets long enough to reorder them before processing. This smooths variable network delivery and reduces the timecode errors that lead to dropped frames downstream.

The jitter buffer is particularly valuable for cameras transmitting over wireless backhaul, mobile networks, or any unstable WAN segment. For the configuration steps, see Turn on jitter buffer and packet loss logging.

How To Capture Debug TS Recordings for Deeper Analysis

When a stream fails with no clear log signature, or exhibits intermittent corruption, a debug TS recording captures the raw incoming RTP stream for offline analysis. The recording captures the unprocessed transport stream, allowing engineers (or Wowza Support) to inspect the actual bytes the camera is sending. For the configuration steps, see Record incoming streams for debugging. Wowza Support requests this artifact for advanced troubleshooting cases.

How to Read Wowza RTSP Error Logs

Wowza Streaming Engine logs live in the [install-dir]/logs/ directory by default. On Linux, this is typically /usr/local/WowzaStreamingEngine/logs/. On Windows, this is typically C:\Program Files (x86)\Wowza Media Systems\Wowza Streaming Engine\logs. The two files most relevant to RTSP troubleshooting are wowzastreamingengine_access.log and wowzastreamingengine_error.log.

Verbose RTSP and RTP logging captures the additional context required to diagnose edge cases. Common error signatures include:

• MediaReaderRTP errors which indicate packet-level RTP processing failures
• RTSPSessionInfo errors which indicate problems during the RTSP SETUP or PLAY phase
• Depacketizer errors which indicate codec or track type incompatibility (the case the rtspFilterUnknownTracks property addresses)
• SDP parsing errors which indicate malformed session description data from the camera

Building Reliable Camera Ingest at Scale

Most RTSP and RTSPS ingest issues are upstream of the media server. Wowza Streaming Engine provides the configuration flexibility to compensate at the ingest layer, which is why teams managing large camera fleets consistently choose it as the connective tissue between RTSP camera infrastructure and modern delivery formats like HLS, DASH, and WebRTC.

For more detailed technical guidance, visit the Wowza Community or contact a Wowza expert to discuss specific deployment requirements.

Frequently Asked Questions

How to troubleshoot RTSP connection issues?

To troubleshoot RTSP connection issues, start by confirming the camera URL plays back using VLC or ffplay from the Wowza Streaming Engine host. If playback fails, the issue is network or camera related. If playback succeeds, the next step is checking the Wowza Streaming Engine logs for MediaCaster errors. From there, enable the three diagnostic .stream file properties: rtspFilterUnknownTracks, rtpIgnoreProfileLevelId, and rtpIgnoreSPropParameterSets.

What causes the “depacketizer not found” error in RTSP streams?

The “depacketizer not found” error occurs when the camera sends a track type that Wowza Streaming Engine does not recognize, such as a proprietary ONVIF metadata channel or vendor analytics overlay. Setting rtspFilterUnknownTracks to true in the .stream file filters these unknown tracks before processing, which resolves the depacketizer error in most cases.

What ports do RTSP and RTSPS use?

RTSP uses TCP port 554 by default. RTSPS, the TLS-encrypted variant, uses port 322. RTP media transport uses dynamically negotiated UDP ports that the RTSP SETUP exchange establishes during session initiation. Firewalls between the camera and the Wowza Streaming Engine server need to allow both the RTSP control port and the RTP UDP port range, or the MediaCaster needs to use RTP over TCP (interleaved mode) to bypass UDP entirely.

What fixes bursty or out-of-order RTSP packets?

Enabling the RTP jitter buffer in Wowza Streaming Engine smooths variable packet arrival times. The jitter buffer reorders incoming packets and reduces the timecode errors caused by unstable network delivery, which is especially valuable for cameras transmitting over wireless backhaul or mobile networks.

What is the difference between RTSP and RTSPS in Wowza Streaming Engine?

RTSPS is RTSP wrapped in TLS encryption. Both protocols use the same MediaCaster ingest workflow in Wowza Streaming Engine, but RTSPS adds TLS handshake overhead and requires valid certificate configuration on both the camera and the server. Standard RTSP sends control commands in plain text over TCP port 554, while RTSPS encrypts the control channel and defaults to TCP port 322.

Does Wowza Streaming Engine support RTSP streams from cameras with malformed SDP?

Yes. Setting rtpIgnoreSPropParameterSets to true tells Wowza Streaming Engine to rely on the SPS and PPS data in the live stream itself, rather than the SDP advertisement. This resolves most malformed SDP issues at the source. The rtpIgnoreProfileLevelId property handles a related class of issue where the SDP reports an invalid H.264 profile level ID.