Help

Replay and Compare RTSP Sessions

Direct answer

Save a Professional .risession case after the failure window is complete, reopen it to prove the evidence survived, then compare a controlled failing session with a known-good session. RTSP Inspector compares structured diagnosis, video, network, and protocol dimensions; it does not make every changed value a root cause. The first meaningful divergence is the lead that deserves a controlled confirmation test.

Session replay, case storage, and session comparison are Professional capabilities in the current catalog. Community still provides the core live RTSP, RTP, RTCP, H.264, and JSON diagnostic path. Upgrade boundaries must not be confused with connection, URL, firewall, or codec failures.

Create a defensible case

Start with connection setup and collect one deliberate scenario. Record the camera or server model, firmware, host, network path, exact sanitized RTSP URL, transport, credentials source, timeout, expected result, and action that triggers the problem.

Preserve the evidence that actually exists:

RTSP methods, responses, CSeq, Session, Transport, Content-Base, and control URLs;
SDP media sections, codecs, payload types, clock rates, parameters, and track controls;
RTP sequence, timestamp, marker, SSRC, payload, loss, duplicate, and reordering observations;
RTCP sender/receiver evidence when present;
supported codec structure and diagnostic timeline;
start, failure, recovery, and stop state.

If the control plane failed before PLAY, the absence of RTP is expected context, not packet loss. If retention limits truncated raw events or packet samples, state that limitation before saving.

Save and verify `.risession`

Use the Reports case workflow to save the current session. Choose a filename that identifies the environment and case without putting a password or unnecessary customer detail in the name. Keep the source case in an approved folder.

Before calling it preserved:

stop the live analysis at a deliberate boundary;
save the .risession;
open the saved file through the replay source action;
confirm the sanitized request and transport;
inspect one event near the start, the key failure, and the end;
verify SDP, timeline, RTP/RTCP statistics, and diagnostics as applicable;
keep the original until the reopened copy passes review.

A successfully opened file proves readability, not diagnostic completeness. Compare the reopened case with the collection checklist and document any missing interval.

Import a packet capture

The Professional replay path can open supported PCAP, PCAPNG, and CAP inputs. Packet capture replay depends on the capture containing recognizable RTSP control or RTP/RTCP traffic and enough network context for the analyzers. Encryption, unsupported link types, truncation, asymmetric capture, or missing setup traffic can limit interpretation.

Replay source	Best use	Important limit
`.risession`	Reopen an RTSP Inspector diagnostic case	Preserves application evidence, not a generic packet capture
PCAP/PCAPNG/CAP	Analyze an existing network capture	Results depend on capture scope and supported decoding
Live connection	Reproduce current server behavior	Environment may change and credentials are required

Do not say RTSP Inspector exported a PCAP when it opened one. Use diagnostic report export for the implemented output formats.

Build a known-good baseline

A baseline should differ from the failing case in as few controlled variables as possible. The strongest pair uses the same camera, stream path, host, network path, transport, credentials, profile, and action, changing only one firmware, configuration, or time window.

Variable	Known-good	Failing	Comparable?
Device and firmware	Record exact identity	Record exact identity	Explain every difference
RTSP URL and track	Sanitized canonical path	Same intended path	Required for path claims
Transport	TCP or UDP	Same mode	Otherwise classify transport separately
Network path	Same VLAN/VPN/firewall route	Same where possible	Required for loss comparison
Test action and duration	Documented	Repeated	Required for timing claims
Retention/truncation	Record limits	Match limits	Prevent false absence claims

Two unrelated working cameras are weak baselines because SDP, payload mapping, control URLs, and server policy can legitimately differ.

Run and interpret comparison

Open both sessions so each has a session ID. In the Compare workspace, place the candidate on one side and the baseline on the other, then run comparison. The structured result reports whether the diagnosis, video, network, and protocol summaries changed.

Use the result as navigation:

Protocol changed: inspect status, CSeq, Session, Transport, SDP, and resolved controls.
Network changed: inspect arrival, loss, reordering, duplication, jitter, SSRC, and timing.
Video changed: inspect codec mapping, parameter sets, packetization, and decode readiness.
Diagnosis changed: trace the verdict back to the source observations.

“Changed” does not mean “broken,” and “unchanged” does not prove equality of every packet. Read the supporting evidence and identify the earliest divergence that can explain the user-visible symptom.

First-divergence method

Align the cases by semantic event rather than wall-clock timestamp: OPTIONS, DESCRIBE, each SETUP, PLAY, first RTP, first complete access unit, first RTCP report, first gap, keepalive, and TEARDOWN. Then ask what changed first.

For example, a different SDP payload type before any RTP packet is more useful than thousands of later payload differences. A successful UDP SETUP followed by no arriving packets points to a different layer than a SETUP 461. A shared freeze after the same sequence gap weakens the claim that only the decoder changed.

Case QA checklist

The case was reopened before the live environment was dismantled.
Passwords are absent from filenames, saved profiles, and report text.
Baseline and failing case differ in documented variables only.
Transport and capture scope match or differences are explicitly classified.
Comparison uses two distinct valid session IDs.
The first divergence is tied to a protocol field or measured event.
Correlation is not presented as confirmed root cause.
Truncation, encryption, and missing traffic are disclosed.
The next test can confirm or reject the leading explanation.

FAQ

Does replay reconnect to the camera?

No. Opening a .risession or packet-capture source reviews retained evidence. Start a separate live analysis when current camera behavior must be tested.

Does comparison prove the root cause?

No. It structures differences across major diagnostic dimensions. A root-cause claim still needs source evidence and, ideally, a controlled confirmation test.

Can Community open saved sessions?

No. The current catalog assigns session replay and comparison to Professional. Community remains usable for live core analysis and JSON output.

Direct answer and acceptance boundary

For “Replay and Compare RTSP Sessions”, the short answer is: Save, reopen, replay, and compare RTSP Inspector .risession cases while preserving a defensible known-good and failing evidence trail. 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: Replay and Compare RTSP Sessions

Treat “Replay and Compare RTSP Sessions” as a separate acceptance gate for “Replay and Compare RTSP Sessions”. 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: Save, reopen, replay, and compare RTSP Inspector .risession cases while preserving a defen

Verify “Save, reopen, replay, and compare RTSP Inspector .risession cases while preserving a defensible known-good and failing evidence trail.” 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: Create a defensible case

Use “Create a defensible case” 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: Save and verify .risession

When “Save and verify .risession” 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: Import a packet capture

Close “Import a packet capture” 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: Build a known-good baseline

Treat “Build a known-good baseline” as a separate acceptance gate for “Replay and Compare RTSP Sessions”. 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: Run and interpret comparison

Verify “Run and interpret comparison” 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: First-divergence method

For “First-divergence method”, 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: Case QA checklist

Use “Case QA checklist” 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
Replay and Compare RTSP Sessions	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Save, reopen, replay, and compare RTSP Inspector .risession cases while preserving a defensible known-good and failing e	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
Create a defensible case	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Save and verify .risession	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Import a packet capture	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: