Diagnostics Toolkit

The Diagnostics page and companion APIs concentrate reload workflows, routing simulations, registration introspection, and web-based test calls—this is the primary entrypoint for day-to-day troubleshooting.

1. Reload & preflight checks

1. How to trigger:
   • UI: Settings → Reload, with switches to reload Routing, ACL, or the full application.
   • API: management endpoints such as /reload/acl, /reload/app, etc., suitable for scripted deployments.
2. Preflight logic: preflight::validate_reload blocks unsafe changes (removing the [console] section, deleting in-use trunks, ACL syntax errors).
3. Common hints: Reload would disable the console means [console] is missing in config.toml; trunk-related errors require restoring the trunk record in the database or TOML files.

(Add a Reload panel screenshot here.)

2. Reading the Diagnostics tabs

Implemented in templates/console/diagnostics.html, the page exposes multiple tabs:

• Connection: shows realm, enabled transports (UDP/TCP/TLS/WebSocket), sample credentials, plus a WebRTC ICE probe that validates [ice_servers] entries.
• Trunks: renders a runtime trunk snapshot. /diagnostics/trunks/test verifies whether an IP or domain matches inbound_hosts/dest and sends carrier OPTIONS probes.
• Routing: /diagnostics/routes/evaluate simulates rule matching for runtime or database datasets, returning the hit route, selected trunk, rewrite result, queue/IVR action, and optional abort code.
• SIP:
  • Active SIP dialogs: lists active INVITE dialogs and lets you inspect SDP offer/answer pairs.
  • Locator registry: /diagnostics/locator/* queries or removes bindings to debug registration issues.
• Web Dialer: embeds JsSIP so you can dial directly in the browser using the credentials from Connection; it captures the latest ~80 WebSocket frames for signaling analysis.

(Add per-tab screenshots here.)

3. Logs, health checks, and external tooling

1. Logging: configure log_level, log_file, and http_access_skip_paths in config.toml. File logs use tracing's structured format.
2. Call records: the callrecord module writes CDRs and recording URLs; the console’s Call Records view reads from models::call_record for reconciliation.
3. Health probe: handler::ami exposes /health, reporting database, SIP core, and task runner status; load balancers or perfcli --ping can consume it.
4. Traffic capture: no built-in packet capture button—run sngrep, tcpdump, or reproduce scenarios via Web Dialer then capture RTP/SIP manually on the host.

4. Typical troubleshooting paths

Scenario	Playbook
Routing changes not effective	Settings → Reload → Diagnostics → Routing (Evaluate database & runtime) → inspect config/routes/*.toml
Registration failures	Diagnostics → SIP → Locator registry → confirm bindings → review proxy.acl_rules for blocked IPs
Inbound trunk rejected	Diagnostics → Trunks → test peer IP/domain → adjust inbound_hosts in config/trunks/*.toml if mismatched
One-way audio or media issues	Verify rtp_start_port/rtp_end_port exposure → reproduce via Web Dialer or a handset → capture RTP and inspect NAT/firewall
Billing or queue anomalies	Compare Call Records with billing templates → Diagnostics → Routing to confirm expected queue/route

5. Automation & scripting

• Reload pipeline: CI jobs that modify config/ or config.toml can call /reload/acl and /reload/app, parsing HTTP responses to ensure preflight success.
• Health monitoring: curl http://<host>:8080/health; alert or remove the instance if status != ok.
• Performance baselines: examples/perfcli.rs performs bulk registrations/calls; compare results with Diagnostics → Routing output to validate optimizations.

Mastering this trio—change, reload, validate—keeps incident loops within minutes and dramatically reduces carrier operations overhead.