Help

RTSP Stream Troubleshooting Guide

Direct answer

Find the last successful layer and the first failed event. Check network reachability before RTSP status codes, RTSP control before RTP media, RTP transport before codec behavior, and captured evidence before application inference. This order prevents a missing UDP path from being called a decoder defect or a wrong stream path from being called packet loss.

Start with one controlled TCP-interleaved run using the connection workflow. Record the sanitized URL, device, firmware, host, network path, credentials source, transport, timeout, exact test time, and expected result.

Last success	First failure	Primary boundary
No socket	Refused, reset, timeout, DNS error	Address, route, listener, VPN, firewall
TCP connected	OPTIONS/DESCRIBE error	URL, authentication, server policy
DESCRIBE 200	Invalid SDP or wrong control URL	SDP and resource resolution
SETUP accepted	PLAY error	Session, range, server state
PLAY accepted	No RTP/RTCP	TCP channels or UDP media path
RTP arrives	Gaps, reordering, wrong mapping	Network, payload, stream state
Complete media arrives	Decode or display failure	Codec/application after evidence review

Layer 1: host and RTSP listener

Confirm the destination is the intended camera, encoder, NVR, proxy, or media server. An ICMP ping can fail even when RTSP works, so treat it as one signal rather than proof. Test the exact RTSP host and port from the same workstation and network path used by RTSP Inspector.

Connection refused usually means the host responded but no service accepted that port. Timeout can mean filtering, routing, VPN, wrong address, or an unresponsive server. Reset can indicate server policy, resource limits, TLS/plain-protocol mismatch, or a middlebox.

Do not continue to codec analysis when the TCP listener was never reached.

Layer 2: URL and authentication

The RTSP path is vendor and profile specific. A working web page or ONVIF operation does not prove the RTSP resource. A DESCRIBE 404 can be the wrong path; a later SETUP 404 can instead be a broken aggregate or track control URL.

Evidence	Check
400 Bad Request	Request target, escaping, required headers, server syntax
401 Unauthorized	Basic/Digest challenge, realm, nonce, credentials, retry
403 Forbidden	Account permission, stream policy, source limits
404 Not Found	DESCRIBE resource or resolved track control
500/503	Server state, resource exhaustion, reproducibility
HTML or JSON body	Wrong service, management endpoint, or proxy response

RTSP Inspector supports credential fields and handles supported Basic and Digest retries. Inspect the full challenge/retry sequence, not only the first 401. Passwords and Authorization values should never appear in exported notes.

Layer 3: DESCRIBE and SDP

A successful DESCRIBE should provide usable SDP. Review:

m= media sections and their payload types;
a=rtpmap codec and clock-rate mappings;
a=fmtp parameters and codec configuration;
aggregate and media-level a=control values;
Content-Base or Content-Location used to resolve controls;
duplicate, missing, malformed, or contradictory attributes.

If SDP says payload type 96 is H.264 but arriving RTP uses another dynamic payload without a matching map, the diagnosis is a mapping inconsistency. It is not yet proof that packet transport failed.

Layer 4: SETUP transport

TCP interleaved SETUP should return accepted transport and channel information. The server may assign different interleaved channels from those requested; inspect the response and subsequent frames. UDP SETUP should return a coherent client/server port relationship and the client must be reachable on its negotiated ports.

Symptom	Evidence to inspect	Controlled next test
461 Unsupported Transport	Requested and returned Transport headers	Switch transport only
454 Session Not Found	Session header creation and propagation	Trace SETUP to PLAY
SETUP 200, no UDP	Client/server ports, local bind, NAT, firewall	Repeat over TCP
SETUP 200, no TCP media	Interleaved channels and incoming frames	Verify server channel use
One track works	Each media control and SETUP result	Isolate failing track

UDP is a Professional advanced-network capability. A disabled UDP control is not a server error.

Layer 5: PLAY, Range, and session lifetime

Trace the Session header from SETUP into PLAY and later keepalive or TEARDOWN requests. Inspect Range handling when recorded or live playback position matters. A server can accept SETUP and then reject PLAY because the session expired, the aggregate control is wrong, the requested range is unsupported, or resources are exhausted.

If a stream stops after a repeatable interval, look for the advertised session timeout, the presence and result of keepalive requests, RTCP BYE, TEARDOWN, TCP closure, and the last RTP packet. The interval alone does not prove a missing keepalive.

Layer 6: RTP and RTCP

Once media arrives, compare packet facts with SDP:

payload type and codec mapping;
sequence continuity, wraparound, duplicates, loss, and reordering;
timestamp progression and declared clock rate;
SSRC stability and changes;
marker-bit behavior at access-unit boundaries;
RTCP sender/receiver reports, jitter, loss, CNAME, and BYE;
truncation or retention limits in the captured evidence.

A sequence gap indicates missing sequence numbers in the observation; it does not by itself identify Wi-Fi, switch, server, kernel, VPN, or application as the loss location. RTCP reports represent the reporting endpoint’s perspective and need the correct SSRC and time context.

Layer 7: H.264 and H.265 evidence

Community includes supported H.264 inspection. H.265 inspection is a Professional capability. Check codec mapping before interpreting NAL structure. For H.264, inspect SPS/PPS availability, single NAL units, aggregation, FU-A start/middle/end continuity, IDR access, and marker behavior.

Black video can result from missing parameter sets, loss before an IDR, payload mismatch, damaged fragmentation, unsupported stream details, or a downstream renderer. If transport evidence is incomplete, do not jump directly to the decoder.

Known-good comparison

Use a baseline only when it is comparable. Prefer the same device, path, credentials, transport, host, and network, changing one firmware or configuration variable. Save and reopen Professional .risession cases and follow replay and comparison.

Comparison highlights diagnosis, video, network, and protocol differences. It narrows the search; it does not automatically prove causation.

Escalation package

Give the receiving team:

one-sentence direct answer naming the first failed boundary;
sanitized environment and reproduction steps;
exact observed event and timestamp;
relevant SDP, transport, RTP, RTCP, or codec fields;
known-good comparison when controlled;
limitations such as truncation, encryption, missing direction, or unsupported codec;
one next test that can confirm the leading explanation.

Use diagnostic report export for implemented JSON, Markdown, HTML, PDF, evidence, and .risession handoff paths. Do not promise a PCAP export that the report workflow does not implement.

Troubleshooting QA

The exact host, port, path, and test time are recorded.
Passwords are absent from the retained URL and report.
TCP control is separated from UDP media reachability.
The last success and first failure are named.
SDP controls are resolved before SETUP conclusions.
RTP payload and clock values are checked against SDP.
Missing packets are not assigned to a cause without supporting evidence.
Codec conclusions follow transport validation.
License-locked features are not described as protocol failures.
The next test changes one variable.

FAQ

Why does PLAY return 200 but the screen remains empty?

First determine whether RTP arrived. If not, investigate the negotiated TCP channels or UDP media path. If RTP arrived, verify payload mapping, sequence continuity, timestamps, parameter sets, and supported codec evidence before blaming rendering.

Should I try UDP before TCP?

Use TCP first to prove the URL, authentication, control path, and media availability with fewer network variables. Test Professional UDP separately when the deployment requires it.

Does a different result from another player prove an RTSP Inspector bug?

No. It is useful evidence, but compare URL, transport, authentication, user agent, control resolution, keepalive, and test time before deciding which behavior differs.

Direct answer and acceptance boundary

For “RTSP Stream Troubleshooting Guide”, the short answer is: Troubleshoot RTSP connection, authentication, SDP, SETUP, PLAY, RTP, RTCP, packet loss, and codec evidence in the correct diagnostic order. Treat that statement as a result to verify, not as a promise that every input, device, project, or environment behaves identically. A complete result records the starting state, the exact action, the visible output, and the condition that proves the task is finished in RTSP Inspector.

Evidence-first operating procedure

Work from a small, repeatable case before changing a full project. Record the application version, operating system, input or device identity, relevant settings, and the expected result. Perform one deliberate action, preserve the first unexpected transition, and compare it with a known-good run whenever one is available. Changing several controls at once may hide which condition fixed or created the problem.

Checkpoint 1: RTSP Stream Troubleshooting Guide

Treat “RTSP Stream Troubleshooting Guide” as a separate acceptance gate for “RTSP Stream Troubleshooting Guide”. Record its initial state before acting, then capture the first visible change and the final state. If the result differs from the page’s stated outcome, return to the last confirmed checkpoint instead of continuing with assumptions.

Checkpoint 2: Troubleshoot RTSP connection, authentication, SDP, SETUP, PLAY, RTP, RTCP, packet loss, an

Verify “Troubleshoot RTSP connection, authentication, SDP, SETUP, PLAY, RTP, RTCP, packet loss, and codec evidence in the correct diagnostic order.” with the smallest representative input. Keep unrelated settings unchanged, repeat the same action once, and note whether the result is stable after reopening or reconnecting. A screenshot alone is weaker than a record that includes the input, setting, action, output, and time.

Checkpoint 3: Direct answer

For “Direct answer”, distinguish a product decision from an operating-system, hardware, source-file, permission, or workflow boundary. Confirm which layer supplied the evidence before assigning a cause. This prevents a nearby symptom from being reported as a proven root cause.

Checkpoint 4: Layer 1: host and RTSP listener

Use “Layer 1: host and RTSP listener” to define a pass/fail statement that another operator can repeat. Include what should be present, what must be absent, and what recovery action is safe if the check fails. Keep the original project or capture unchanged until the repaired copy has passed the same check.

Checkpoint 5: Layer 2: URL and authentication

When “Layer 2: URL and authentication” is ambiguous, compare one known-good case with one failing case under matching conditions. Mark the first meaningful difference rather than listing every later symptom. That first boundary usually produces a clearer support request and a safer next experiment.

Checkpoint 6: Layer 3: DESCRIBE and SDP

Close “Layer 3: DESCRIBE and SDP” only after the saved, exported, or reopened result still matches the observed state. Temporary UI feedback is useful, but durable evidence is stronger. Record any limitation that remains so the next reader does not interpret an incomplete path as a successful one.

Checkpoint 7: Layer 4: SETUP transport

Treat “Layer 4: SETUP transport” as a separate acceptance gate for “RTSP Stream Troubleshooting Guide”. Record its initial state before acting, then capture the first visible change and the final state. If the result differs from the page’s stated outcome, return to the last confirmed checkpoint instead of continuing with assumptions.

Checkpoint 8: Layer 5: PLAY, Range, and session lifetime

Verify “Layer 5: PLAY, Range, and session lifetime” with the smallest representative input. Keep unrelated settings unchanged, repeat the same action once, and note whether the result is stable after reopening or reconnecting. A screenshot alone is weaker than a record that includes the input, setting, action, output, and time.

Checkpoint 9: Layer 6: RTP and RTCP

For “Layer 6: RTP and RTCP”, distinguish a product decision from an operating-system, hardware, source-file, permission, or workflow boundary. Confirm which layer supplied the evidence before assigning a cause. This prevents a nearby symptom from being reported as a proven root cause.

Checkpoint 10: Layer 7: H.264 and H.265 evidence

Use “Layer 7: H.264 and H.265 evidence” to define a pass/fail statement that another operator can repeat. Include what should be present, what must be absent, and what recovery action is safe if the check fails. Keep the original project or capture unchanged until the repaired copy has passed the same check.

Acceptance matrix

Checkpoint	Evidence to retain	Pass condition
RTSP Stream Troubleshooting Guide	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Troubleshoot RTSP connection, authentication, SDP, SETUP, PLAY, RTP, RTCP, packet loss, and codec evidence in the correc	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Direct answer	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Layer 1: host and RTSP listener	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Layer 2: URL and authentication	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Layer 3: DESCRIBE and SDP	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome

Failure isolation, recovery, and handoff

If a check fails, stop at the first failed boundary. Preserve the source, project, session, or capture; duplicate it before destructive editing; and change one variable per experiment. Repeating a broad workflow after several simultaneous changes may produce a different result without explaining why.

Separate absence of evidence from evidence of absence. A blank view may mean the wrong input, scope, filter, permission, device, time range, or project state rather than “nothing happened.” Verify the acquisition or import path before interpreting a decoder, editor, report, or export.

Before handoff, reopen the durable artifact and inspect its beginning, the decision point, and its end. Record version, platform, relevant configuration, expected behavior, observed behavior, and the smallest reproduction. Remove or redact sensitive material and confirm the recipient is authorized to receive it.

Questions and answers

What is the fastest reliable way to start?

Use the smallest representative case, write down the expected result, and change one variable. Confirm the basic path before adding filters, effects, edits, automation, or a larger source. This creates a baseline that can be compared after every later decision.

What evidence should be saved?

Keep the input identity, application version, platform, relevant settings, exact action, first unexpected transition, and final output. If the workflow creates a project, session, report, or export, close and reopen it before treating it as durable evidence.

When should the procedure be repeated?

Repeat it after an application, operating-system, driver, firmware, model, source, or workflow change that can alter the result. Preserve the earlier accepted case so the comparison uses the same acceptance boundary rather than memory.

When is the task ready for handoff?

It is ready when another authorized person can identify the input, repeat the action, see the same result, understand any remaining limitation, and open the saved artifact without relying on undocumented local state.

Related guides

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