Feature: ONVIF Debug Tab — raw SOAP request/response inspector with reusable templates

[kumaakh]

Summary

Add a Debug tab to ODM (similar to the ONVIF Device Test Tool's debug/trace tab) that lets field engineers send raw SOAP requests to a connected camera and inspect the XML response — without needing an external tool.

Motivation

In the field, diagnosing non-compliant or broken camera ONVIF implementations requires being able to send arbitrary SOAP calls and see raw responses. Currently this requires switching to external tools (ONVIF TT, SoapUI), losing the context of the connected session. Having this directly in ODM — with the authenticated session already established — is a significant productivity and diagnostic tool.

ONVIF TT is not a public domain tool. When new ONVIF versions ship, ODM should be able to test and exercise new features without waiting for ONVIF TT access. This debug tab fills that gap permanently.

Proposed Behaviour

• Service selector — dropdown listing all services discovered for the connected camera (Device, Media, Media2, PTZ, Imaging, Events, etc.) with their resolved xAddr shown
• Request editor — XML text area pre-populated with a SOAP envelope for the selected operation; user can edit freely before sending
• Send button — fires the raw SOAP request using the current session's auth (WS-Security UsernameToken) and connection settings
• Response pane — displays the raw XML response with syntax highlighting; shows HTTP status, headers, and round-trip time
• Template library — built-in common request templates per service (GetProfiles, GetStreamUri, GetCapabilities, GetSystemDateAndTime, GetServices, etc.) that the user can load as a starting point; user-defined templates saved and recalled locally

WSDL-driven message generation (key architectural idea)

Rather than hand-coding request templates per operation, the debug panel should use the camera's own WSDL files to drive both message construction and dynamic form generation:

1. Fetch WSDL from the camera first — query the camera's service endpoints for their WSDL (?wsdl). Many ONVIF cameras serve their WSDL files directly. Use these as the authoritative source for that camera's supported operations and message schemas.

2. Fall back to bundled ONVIF WSDL specs — if the camera doesn't serve WSDL files (or they're incomplete), fall back to the ONVIF WSDL spec files bundled with ODM at build time (latest ONVIF release included in the build).

3. Generate request messages from WSDL — parse the WSDL at runtime to generate well-formed SOAP envelope templates automatically for each operation. No hand-coding of templates needed.

4. Dynamic input forms — parse the WSDL's embedded XSD type definitions to generate input forms dynamically for each operation's parameters (profile token, encoder config token, stream type, etc.).

5. ONVIF version agnostic — because messages are generated from WSDL, the debug tab automatically supports any ONVIF version without code changes. When a new ONVIF version ships, update the bundled WSDL files and the tab gains full support immediately.

.NET building blocks (no external dependency needed)

All the required capability exists natively in the .NET Framework — no Java tools or third-party SOAP frameworks needed:

• System.Web.Services.Description.ServiceDescription — parses WSDL into a typed object model; enumerates ports, bindings, operations, and message parts
• System.Xml.Schema.XmlSchema — walks XSD type definitions embedded in the WSDL to determine field types, constraints, and cardinality for dynamic form generation
• System.ServiceModel.Description.MetadataExchangeClient — fetches and parses WSDL/MEX metadata directly from a service endpoint at runtime
• System.ServiceModel.Description.WsdlImporter — converts fetched metadata into WCF contract descriptions, enabling runtime inspection of operations and their input/output types
• HttpClient with manual WS-Security header — for the debug send path; simpler and more transparent than going through the WCF channel factory

For dynamic WPF form generation from XSD types, evaluate Forge.Forms (WPF-Forge/Forge.Forms on GitHub) — generates WPF forms from class metadata/attributes and could be driven from WSDL-derived type information.

Template system

• Templates are WSDL-derived by default (auto-generated from operation schema)
• User-defined templates can still be saved for commonly used custom payloads
• Template picker shows service namespace + operation name
• Placeholders (e.g. {{profileToken}}) auto-filled from session context where possible

Why this is high value

• Eliminates need to switch tools when debugging non-compliant cameras in the field
• Works within ODM's already-established authenticated session — no re-auth needed
• ONVIF version independence: new spec versions supported by updating bundled WSDLs, not code
• Replaces dependency on ONVIF TT (not publicly available) for feature testing and validation
• Directly supports ODM's swiss army knife mission: diagnose any camera, compliant or not
• Useful for testing Apra ONVIF Server simulator behaviour during development

Implementation notes

• SOAP dispatch via raw HttpClient POST with WS-Security header — same construction as NvtSession.fs, more transparent for a debug path than WCF channel factories
• The tab should only be enabled when a camera session is active
• Accessible from the device detail view alongside NVT, PTZ, Imaging tabs
• Bundled ONVIF WSDL files should be versioned and updateable independently of the ODM build

Subtasks

• Research: Evaluate open-source options for automated SOAP/WSDL form generation in WPF — assess Forge.Forms + XmlSchema pipeline, DesteSoft.SoapClient (runtime WSDL invocation), and SoapHttpClient (envelope builder); produce a recommendation with PoC
• Design: UI layout for the debug tab — service selector, operation picker, dynamic input form, request/response panes, template library
• Spike: Fetch WSDL from a live camera (?wsdl on each service endpoint) and parse it using ServiceDescription + XmlSchema — validate that Apra ONVIF Server and real cameras serve usable WSDLs
• Build: WSDL fetcher — fetch from camera, fall back to bundled ONVIF WSDL files
• Build: Dynamic form generator — XSD type → WPF input form (evaluate Forge.Forms)
• Build: SOAP message builder — assemble envelope from WSDL operation + form inputs + WS-Security header
• Build: Response pane — raw XML display with syntax highlighting
• Build: Template library — save/load user-defined templates, built-in ONVIF operation templates
• Integration: Wire debug tab into device detail view; gate on active session

References

• onvif/onvif.session/NvtSession.fs — session auth and endpoint resolution
• docs/principles.md — ODM swiss army knife principle
• Forge.Forms: https://github.com/WPF-Forge/Forge.Forms
• XmlSchemaClassGenerator: https://github.com/mganss/XmlSchemaClassGenerator
• DesteSoft.SoapClient NuGet: runtime WSDL invocation without code generation