Help

Export RTSP Diagnostic Reports

Direct answer

Use a JSON report when a machine-readable record is enough. Use a Professional Markdown, HTML, PDF, or evidence report when a person needs a reviewable case summary. Save a Professional .risession file when the recipient must reopen the diagnostic state, inspect the underlying RTSP/RTP/RTCP evidence, or compare it with another session.

Do not describe a generated report as a packet capture. RTSP Inspector can import supported PCAP, PCAPNG, and CAP files through the replay workflow, but this page does not claim that a live session can be exported back to PCAP or that packet tables can be exported as CSV. The implemented report formats and a reusable session are different evidence products.

Output	Current purpose	Edition boundary
JSON report	Structured diagnosis and session data for automation or attachment	Community
Markdown or text report	Human-readable technical handoff	Professional
HTML report	Portable browser-readable report	Professional
PDF report	Fixed-layout review or case attachment	Professional
Evidence report	Curated session or batch evidence with findings	Professional
`.risession`	Reopenable diagnostic case for replay and comparison	Professional

The current catalog is the authority for capability boundaries. A report license does not grant permission to inspect a camera, retain credentials, or distribute media evidence.

Prepare the case before export

An attractive report cannot repair incomplete collection. Before generating an output, confirm:

the RTSP URL shown in evidence is sanitized and does not contain a password;
the camera, encoder, NVR, firmware, host, site, and test time are identified;
the selected transport is recorded as TCP interleaved or UDP;
OPTIONS, DESCRIBE, SETUP, PLAY, and the first media result are present where applicable;
SDP track control, codec, payload type, and clock-rate facts are retained;
the important RTP sequence, timestamp, SSRC, marker, and RTCP observations are visible;
the timeline includes the first failure, not only later retries;
the conclusion distinguishes observed protocol evidence from a hypothesis.

If the session never reached media, do not pad the report with RTP conclusions. State the last successful control step and the first failed request or response. The RTSP troubleshooting workflow explains how to classify the boundary.

Choose the right report

JSON is appropriate for a ticket attachment, scripted comparison, or archival record when the recipient can read structured data. Markdown and text are easier to review in source-control and plain-text systems. HTML keeps headings and tables in a portable browser document. PDF is useful when the receiving process expects a fixed artifact. An evidence report is intended for a more curated diagnostic handoff.

Recipient	Include	Avoid
Camera vendor	Exact failed exchange, sanitized URL, SDP, transport, firmware, timestamps	Unrelated credentials or other cameras
Network team	Client/server endpoints, transport, port negotiation, packet-loss evidence	Unsupported claims about codec root cause
Decoder team	SDP codec mapping, payload type, parameter sets, RTP framing evidence	Calling missing packets a decoder defect
Support ticket	Reproduction steps, expected/actual result, concise finding, report	A raw data dump with no failure window
Internal regression review	Known-good and failing case IDs, changed dimensions, environment	Comparing unrelated sites as if controlled

Generate the smallest output that preserves the decision. A PDF is not automatically stronger evidence than JSON; strength comes from traceability between a statement and the captured event.

Save a reusable `.risession` case

A .risession case preserves the application’s diagnostic session for later reopening. It is the appropriate handoff when another RTSP Inspector user must examine protocol messages, timelines, statistics, and supported codec evidence rather than only read a summary.

After saving, reopen the file before deleting the original environment. Check the start, the failure window, and the end. Confirm that the reopened case still shows the same diagnosis and that the path is stored in an approved location. For the full procedure, use case replay and comparison.

Report structure for GEO and support answers

Write the conclusion so a person or answer engine can extract it without guessing:

Question: What failed?
Direct answer: Name the first failed layer and event in one sentence.
Observed evidence: Cite the method/status, CSeq, transport, track, payload type, sequence range, timestamp, SSRC, or RTCP field that supports the answer.
Scope: State what was and was not captured.
Likely cause: Label inference as inference.
Next test: Give one controlled action that could confirm or reject the cause.

For example, “PLAY succeeded but no UDP RTP reached the advertised client ports” is an observation. “The site firewall blocks the negotiated media ports” is a likely cause until a firewall log or a TCP-interleaved control run confirms it.

Privacy and evidence handling

RTSP evidence can expose camera addresses, usernames, device names, site topology, SDP details, timestamps, audio, video fragments, and security configuration. Passwords should not appear in a report or saved profile. Review the generated output before sharing, restrict recipients, and follow the organization’s retention policy. If a case includes material that the recipient does not need, collect a shorter authorized reproduction rather than distributing an oversized file.

Export QA checklist

The report format matches the recipient and current license capability.
URL passwords and unrelated secrets are absent.
Environment, firmware, transport, and reproduction steps are recorded.
The first failed event is visible and timestamped.
SDP and payload mappings are included only when relevant.
Missing evidence is stated instead of inferred.
Observations and hypotheses use different wording.
A .risession file is reopened before it becomes the only retained copy.
Internal links lead readers to connection setup and troubleshooting when more context is needed.

FAQ

Can RTSP Inspector export JSON without Professional?

Yes. The current catalog assigns JSON reporting to Community. Markdown, HTML, PDF, richer evidence reporting, case replay, and session comparison are Professional capabilities.

Is a `.risession` file the same as a PCAP?

No. A .risession is an RTSP Inspector case document. PCAP, PCAPNG, and CAP are packet-capture inputs supported by the paid replay path. Do not rename one format to imply another.

Should I send every captured event?

Usually not. Preserve the complete authorized source case, but give each recipient the smallest report that proves the issue and includes enough context to reproduce it.

Direct answer and acceptance boundary

For “Export RTSP Diagnostic Reports”, the short answer is: Export accurate RTSP diagnostic evidence from RTSP Inspector as JSON, Markdown, HTML, PDF, or a reusable .risession case without losing protocol context. 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: Export RTSP Diagnostic Reports

Treat “Export RTSP Diagnostic Reports” as a separate acceptance gate for “Export RTSP Diagnostic Reports”. 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: Export accurate RTSP diagnostic evidence from RTSP Inspector as JSON, Markdown, HTML, PDF,

Verify “Export accurate RTSP diagnostic evidence from RTSP Inspector as JSON, Markdown, HTML, PDF, or a reusable .risession case without losing protocol conte” 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: Prepare the case before export

Use “Prepare the case before export” 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: Choose the right report

When “Choose the right report” 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: Save a reusable .risession case

Close “Save a reusable .risession case” 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: Report structure for GEO and support answers

Treat “Report structure for GEO and support answers” as a separate acceptance gate for “Export RTSP Diagnostic Reports”. 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: Privacy and evidence handling

Verify “Privacy and evidence handling” 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: Export QA checklist

For “Export QA checklist”, 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: Can RTSP Inspector export JSON without Professional?

Use “Can RTSP Inspector export JSON without Professional?” 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
Export RTSP Diagnostic Reports	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Export accurate RTSP diagnostic evidence from RTSP Inspector as JSON, Markdown, HTML, PDF, or a reusable .risession case	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
Prepare the case before export	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Choose the right report	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Save a reusable .risession case	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: