Under the hood.

SIP, WebRTC and Asterisk ARI

The call platform runs on Asterisk, driven via the ARI (Asterisk REST Interface) instead of traditional dialplan logic. That makes routing, IVR steps and call events programmable and testable, without having to maintain dialplan scripts.

Agents connect via WebRTC directly from the browser; external trunks run over standard SIP. No proprietary, closed signalling protocol — whatever comes in via SIP can also go back out via SIP to another trunk or provider.

The Velio–Talk bridge

An agent in Velio can call a colleague in Nextcloud Talk, consult with them and hand over the call — without that colleague running a phone app, and without the agent needing a Talk client. The non-voice part — directory search and presence — runs over Nextcloud's open OCS API.

For voice, Velio brings its own media bridge: a headless component that couples an Asterisk channel to a Talk conversation and transcodes the audio between the two worlds (WebRTC ↔ RTP, Opus ↔ G.711). The bridge runs as a separate process alongside the platform and talks WebRTC to the customer's Nextcloud environment. The Talk colleague simply stays in Talk — one participant is added representing the Velio side, recognisable by the conversation name.

The transfer choreography is built to be transport-agnostic: the call only knows it is going to "a channel". As a result Velio supports both its own WebRTC bridge and the official Talk SIP bridge as a voice path, without the rest of the product changing. Call recording stops the moment the Velio side leaves the call — no continuous recording of a Talk colleague without a legal basis.

OIDC, RBAC & sessions

Authentication runs via OpenID Connect against your existing identity provider — no separate local user database to maintain. Roles (agent, supervisor, admin) are enforced at both API and UI level via RBAC, scoped per contact center rather than platform-wide.

Predictability over complexity

Velio runs on cloud VPS infrastructure, fully provisioned via Ansible. A deliberate choice: predictability over complexity — no active multi-node HA clustering, but an environment that can be rebuilt identically within minutes from playbooks.

That means: in case of an incident, we recover by redeploying, not by failing over to a continuously running shadow environment. Less maintenance overhead, less hidden state, and infrastructure that one person can still fully understand.

Data that doesn't come back from a playbook — the database, the recordings — is covered by continuous backups with point-in-time recovery and an encrypted copy off the server. "Redeploying" thus also brings your data back, right up to the moment just before the incident.

Security as a baseline requirement, not a feature

• Parameterised queries — no string concatenation toward the database
• Scans for known vulnerabilities in dependencies, ahead of every release
• Encrypted connections end-to-end, including between internal components
• Disk encryption by default — recordings and backups on LUKS-encrypted volumes, key per customer

We're open about where this stands: Velio is in active development, and an independent, external security review is planned before larger deployments follow.

In short

Architecture & design philosophy

The full document covering the product vision, the design principles and the High Level Design — including reference architecture, interfaces, security and deployment, with schematic diagrams. Written for architects, administrators and partners who want to understand how and why Velio is built the way it is.