Installed on your servers, or hosted by us.
The same software either way: a Debian VM dedicated to you, with all your resellers and customers inside. You choose who runs it.
On your servers
Ready-to-use image or Debian package, on your hypervisor: KVM, Proxmox, OpenStack, VMware or VirtualBox. Your teams run it with their usual tools, and the data never leaves your infrastructure.
Hosted by usoptional
A VM dedicated to you, hosted in your region. We handle updates, monitoring and backups. High availability is an option.
Installation
From the image to the first call: create the operator and its administrator, install the certificate, set up email, open the network, then create a customer, its trunk and an extension.
A complete VM: Debian 13, PostgreSQL, nginx, Kanadr with its telephony engine, and the synthetic voice. As qcow2 for KVM, Proxmox and OpenStack, as OVA for VMware and VirtualBox, with SHA-256 checksums to verify before import.
No password in the image: the SSH key and the hostname are provided at first boot, through cloud-init or the OVA properties.
The VM generates its own secrets (database, telephony engine access, encryption key), configures telephony and sets up the recordings volume. Two VMs built from the same image share no secrets.
For a machine where the telephony stack is already installed: apt install kanadr, then the settings described in the guide. The image remains the recommended route.
12 GB minimum, grown to the size of the VM at first boot. A second, empty disk holds the recordings; failing that, a 50 GB file.
kanadr verifier runs read-only checks on the settings, the keyring, the database, the telephony engine (SIP profiles, call records), the files, the portal and the service.
Network and certificates
A fixed public IP address, ideally carried by the VM itself. The VM does not install a firewall: filter upstream, or on the machine.
| Port | Protocol | Used for |
|---|---|---|
| 443 | TCP | Portal and API (HTTPS) |
| 80 | TCP | Redirect to HTTPS, Let's Encrypt validation |
| 5060 | UDP and TCP | SIP for phones and softphones |
| 5061 | TCP | SIP over TLS for softphones |
| 5080 | UDP and TCP | SIP for trunks, can be restricted to the provider's addresses |
| 16384 to 32768 | UDP | Voice (RTP) |
| 3478 | UDP and TCP | TURN server for the browser phone: STUN and relay |
| 5349 | TCP | TURN over TLS, for networks that only let TLS through |
| 40000 to 41999 | UDP | TURN relay |
| 22 | TCP | Administration, from your addresses only |
| 112 (IP), 5432 | VRRP, TCP | Between the two VMs of an active/passive pair |
The VM must advertise its public address, otherwise audio only goes one way. The guide lists the two settings to check.
A name for the machine (pbx.your-brand.com) and a wildcard domain for customers: each one gets its own SIP domain (customer.pbx.your-brand.com), where its phones register.
Your own, or Let's Encrypt with automatic renewal, passed on each time to the portal and to SIP over TLS.
Links to third-party services go out over TLS from the machine: no inbound port to open for them.
Telephony
G.711 voice relayed, G.722 and Opus transcoding available. One VM handles 1,000 sessions (about 500 established calls) and 100 new sessions per second.
One per customer, with registration or IP-based: format of called and presented numbers, pilot number, P-Asserted-Identity host, provider networks. A profile groups what a provider's trunks have in common; editing it updates all of them.
SIP over TLS 1.2 and 1.3 and SRTP voice for SIP softphones, enabled by each customer with one setting. The browser phone is always encrypted.
Piper, installed on the VM, in French and English: announcements, voicemail and conference rooms, with no external service.
International prefixes refused for all customers, forwarding included (satellite numbers on +882, for example). Emergency numbers always remain reachable.
Language set per operator, per customer and per account: portal, emails, announcements and voicemail. French and English available today, any other language on request; synthetic voices in about thirty languages, transcription in most. Each organization's time zone sets its opening hours, its dates and its billing months.
Sizing
Measured on the image: 50 customers with 20 extensions each, authenticated extension-to-extension calls, G.711 voice relayed by the VM, quality computed on every call. The number of customers matters little: the number of concurrent calls is what loads the machine.
| VM | Concurrent calls | Extensions (guideline) |
|---|---|---|
| 1 vCPU, 2 GB | 100 | 700 to 1,000 |
| 2 vCPUs, 4 GB (default image) | 200 | 1,300 to 2,000 |
MOS 4.48 as long as the CPU is not saturated. Beyond 250 calls on 2 vCPUs, or 125 on 1 vCPU, it degrades.
Less than 800 MB of memory at 300 calls. 1,000 phones re-registering every minute make 17 registrations per second; a 2-vCPU VM absorbs 200.
Above 75% CPU at peak, add vCPUs. Recording, transcoding, conferences, ring groups and queues need headroom.
16 MB per hour of recorded call (stereo MP3): 50 GB holds about 3,000 hours. The volume can be grown live.
Operations
Through apt, from our signed repository, checked daily. Nothing installs on its own: the new version is flagged in the portal and in monitoring, and you choose when. The database is snapshotted before each migration, rolling back to an earlier version is done with apt, and your settings are never overwritten.
kanadr sauvegarder produces a live archive: full database, keyring, recordings, voicemail, announcements and music. Restoring replaces the database in a single transaction; an archive from a newer version is refused.
Two VMs and a floating IP. Database replicated continuously (a few seconds behind at most), files and keys copied every minute. The active node announces itself every second; after 3 seconds of silence, the passive node takes over. A VM that can no longer reach its witness gives up the IP: never two active nodes.
Service is back in less than two minutes and phones do not need to re-register. Calls in progress are lost, along with at most the last minute of voice messages. The former active node comes back as passive, with no automatic failback.
Recordings sit on their own volume, grown live. When it is full, only new recordings stop: calls, the database and voicemail keep working. Alerts at 80% then 95%.
Prometheus metrics, read locally or over HTTPS with a token: version and pending update, telephony engine status, calls in progress, registered extensions, trunks by status, license, webhooks, banned addresses, volumes, replication. Reference alerts included.
A customer's trunk going down then coming back, with the provider's reason; license; storage. One alert per state change, not one per attempt. Each reseller sets up its own.
Health, calls in progress, trace of every call, live SIP capture (text, ladder diagram, decrypted pcap for Wireshark), configuration reload without dropping calls, telephony engine restart that waits for calls to end.
Security
Passwords of at least 12 characters, account locked for 15 minutes after 5 failures. Second factor mandatory for your teams and your resellers (authenticator app and recovery codes), passkeys.
From your portal, with a signed JWT, single-use and valid for a few minutes; or through an OpenID Connect directory: Microsoft Entra, Google Workspace, Keycloak.
Tied to a role, never with more permissions than the person who creates them, with an expiry date if you want, revocable at any time. 300 requests in a burst, then 10 per second.
Trunk and mail server passwords, webhook and second-factor secrets are encrypted in the database and never returned by the API. The encryption key can be rotated with one command.
Every action, every sign-in and every refusal, with who, when and from where. The log is chained: kanadr audit verifier checks that it has not been tampered with.
After 10 failures in 5 minutes, an address is banned for one hour, for SIP and voice only: the portal stays reachable. Allowlist; the addresses of trunks and registered phones are spared.
Closed by default. You open it for 4 hours to 7 days, it closes on its own, and every action by our support team shows up in the audit log.
Every release is tested so that a customer, a reseller or an API key cannot read or change anything outside its scope.
Static analysis (warnings treated as errors), dependency audit (vulnerabilities, licenses, provenance), secret scanning across the whole history, tests against the real telephony engine on every change, a written security review for every major release.
A reported vulnerability gets an answer within 3 business days. The fix ships through the apt repository, and you are notified directly, with the version that fixes it.
Integrations
Everything the portal does goes through the API, described in OpenAPI in French and English: resellers, customers, numbers, rate cards, trunks, diagnostics, settings. Your customers get their own documentation, limited to their operations. Stable error codes.
The same operations for your AI tools, with the permissions of the key used.
Signed with a secret. For you: last month's calls, new customer, new extension, trunk down or back up. For your customers: new voice message, recorded call. Disabled after 20 failures in a row, with the cause displayed.
With any service compatible with OpenAI's transcription API: online (OpenAI, Mistral) or installed on your servers (Whisper). Each message is transcribed in its customer's language; if the service is down, the email goes out without the text.
With your Claude API key and a monthly budget per instance and per customer; once the budget is reached, it pauses until the next month. It proposes every change before making it and has no access to account security.
Desk phones provisioned remotely through hardware profiles: Yealink desk (T31G to T87W) and DECT (W70B base), Grandstream HT802 and HT812 adapters. A bundled profile can be duplicated to fit another model, and Yealink's RPS sets up a phone straight out of the box. On computers, the phone in the browser, in your brand, installable (Chrome, Edge, Safari), or the Windows and Mac app. On mobile, the iPhone and Android app in your colors, set up from a QR code.
Data and GDPR
You are the controller for your accounts and billing; each customer is the controller for its employees, and you are its processor. Installed on your servers, we have access to no data; hosted by us, data stays on your server, wherever it is hosted and we act as your processor (GDPR Article 28). A template processing record is provided for your register.
Recordings six months at most, call log at least one year (French Electronic Communications Code, article L34-1), voice messages kept indefinitely by default. Configurable by the operator and per customer; purging runs every hour.
Export of a person's data as JSON, deletion of their account, voicemail and recordings. The audit log remains, protected against any change.
In the call log, external numbers can be partially masked; showing them in full is reserved for the customer's admin, and logged.
No transfer outside the European Union by the platform itself. Transcription and the assistant only make one if you configure a provider that does.
The daily report only counts users per customer, identified by an ID: no personal data reaches us.
Technical FAQ
What infrastructure does Kanadr run on?
Kanadr runs on a dedicated Debian 13 VM that hosts all of an operator's resellers and customers. The image ships as qcow2 (KVM, Proxmox, OpenStack) or OVA (VMware, VirtualBox), or as a Debian package (apt install kanadr). The stack is PostgreSQL, nginx and Kanadr's telephony engine, with a core written in Rust. It needs at least 12 GB of disk and a fixed public IP address.
How many concurrent calls can a Kanadr VM handle?
A 2 vCPU, 4 GB Kanadr VM handles 200 concurrent calls, roughly 1,300 to 2,000 office extensions; a 1 vCPU, 2 GB VM handles 100. Measured call quality stays at a MOS of 4.48 as long as the CPU is not saturated, and degrades beyond 250 calls on 2 vCPU. Concurrent calls, not the number of customers, are what size the machine.
How does Kanadr high availability work?
Kanadr runs two VMs active/passive behind a floating IP. The database is replicated continuously, a few seconds behind at most, and files are copied every minute. After 3 seconds of silence from the active VM, the passive one takes over: service is back in under two minutes and phones do not need to re-register. Calls in progress are dropped.
Which phones work with Kanadr?
Kanadr remotely provisions Yealink desk phones (T31G to T87W), the Yealink W70B DECT base and Grandstream HT802 and HT812 adapters; with Yealink RPS, a phone configures itself straight out of the box. There is also a browser phone (Chrome, Edge, Safari), a Windows and Mac app, and an iPhone and Android app in the operator's brand.
Are Kanadr calls encrypted?
Yes. With Kanadr, the browser phone is always encrypted. For SIP softphones, SIP over TLS 1.2 or 1.3 and SRTP media are turned on with a single setting. Links to third-party services (SIP connectors) go out over TLS, with no inbound port to open.
Where is data stored, and who is responsible under GDPR?
When installed at the operator, Kanadr has no access to any data. When hosted by Kanadr, data stays on the operator's server, wherever it is hosted, and Kanadr acts as the operator's processor (GDPR Article 28). The platform itself sends no data anywhere else; transcription and the assistant only do so if the operator picks a provider that does. Call recordings are kept for six months at most.
Last updated: October 31, 2026

