Under the hood

Auto-provisioning, explained.

Telvia's Windows client never asks users for SIP servers, ports, or usernames. Instead, it authenticates against settings.telvia.ca with a license key and user password, and receives its entire configuration in one response. Here's the full lifecycle.

First run

When Telvia is launched for the first time on a machine it shows the Activate window. The user enters their license key and their password, and the app POSTs /api/provision. On success the response contains the full SIP, webhook, recording and CRM configuration — Telvia writes settings.json and license.json and opens the main window already signed in.

Returning users

On subsequent runs Telvia shows a pre-filled Sign In window — the license key is never shown in full. The user enters only their password. The client calls /api/login and, if the server's config_version is newer than the version stored locally, re-runs /api/provision automatically to pull fresh configuration. Admins can therefore change SIP, CRM, or recording settings centrally and have them propagate on next login.

Periodic checks

While the main window is open, Telvia POSTs /api/check every check_interval_seconds (default 120). This is what makes revocation fast:

  • active — no visible change.
  • blocked — full-window overlay appears, SIP unregisters, calling is disabled. Flipping the license back to active re-registers SIP and removes the overlay.
  • revoked — local data is wiped (license, settings, recordings, call history, logs). The app closes; next launch returns to Activate.

Security model

The password the user types is only used for provisioning. It never doubles as a SIP password. Actual SIP credentials are generated per-license on the server, delivered over TLS as part of the provisioning response, and stored in the user's private local profile. Because credentials can be revoked centrally, losing a laptop is a two-click problem: block the license in the admin portal and the next check wipes the client.

All endpoints require HTTPS. Session tokens are 256-bit random values rotated on every login. machine_id is a SHA-256 fingerprint of hostname and username — it's used for device tracking, never for auth.