Other cookies are configurable.
Incoplax platform
Platform architecture
Incoplax is a distributed communications platform assembled from small, single-purpose microservices called roles. They run on any number of servers and sites, keep calls up when a server fails, and expose every function through an open API.
This page explains how the platform is put together: its layers, the roles inside a site, how sites cooperate, and how availability, scale and configuration are managed.
Four layers, one configuration
Every deployment is described in four layers. Keeping them apart is what lets the platform grow in any direction (more servers, more tenants, more functions) without being redesigned.
Data model, web applications, server microservices and scripts for a business domain.
- Contact center
- Unified communications
- Meet
- Your own packages
Microservices with one clear job each, combined freely on servers.
- sg
- b2b
- mgc
- mg
- ivr
- huntq
- ws
- …40+ roles
Tenants with closed data and their own storage, arranged in a tree.
- domain tree
- users
- SIP accounts
- numbers
- routes
- scripts
Where the software runs, from one VM to several data centres.
- site
- server
- node
- Site
- A group of highly available servers that delivers the full functionality on its own and keeps data consistent with a quorum (50% + 1).
- Server
- A physical or virtual machine with its own IP address. Each server belongs to exactly one site.
- Node
- An operating-system process running an Erlang runtime. Nodes are laid out on servers automatically from the configuration.
- Domain
- The tenant boundary. Data in a domain is closed by default; each domain is served by a specific site and uses its own storage.
- Entity
- Any object an administrator creates in a domain: users, SIP accounts, numbers, routing rules, IVR scripts.
- Role
- A microservice responsible for one function, running as an application in a node with a name unique across the system.
- Package
- A product-layer bundle of classes, user roles, web apps and microservices that extends a domain with a business function.
Inside a site: roles and their jobs
A site runs a set of roles spread across its servers. Only a few of them face the network; everything else lives inside the cluster and talks over the platform's own internal communication layer.
- SIP phones & softphones
- Browsers & WebRTC
- Carriers, PBXs & gateways
- CRM & business apps
- sgInternal SIP gate for users' devices
- esgExternal SIP gate for carriers and PBXs
- wsWeb server: REST and WebSocket API, web apps
- redirectSpreads SIP load across gates
- bgmgBorder media gate between networks
- b2bback-to-back user agent, one per call
- srregistrar
- stsstates & subscriptions (BLF)
- callstoreactive calls and their context
- mgcmedia gate controller
- mgmedia gate, C++
- mixrecording mixer
- recmovermoves recordings to storage
- ivrvoice self-service scripts
- huntqqueues
- confconference rooms
- selselector meetings
- promptlisten, whisper, barge
- vmailvoicemail
- mdc / sdcdomain centers
- dmsdata model service
- domstoredomain storage
- usrAPI users and sessions
- wssubscrAPI event subscriptions
- emailmailboxes
- immessengers
- svcservice scripts
- msvccustom Node.js microservices
- brokermessage broker
- mic / icconfiguration controllers
- rpci / rpcorole registry, inter-site link
- fs / dfsyncfile storage and sync
- logstorecentral logs
- mwaredata transfer
- PostgreSQL configuration and domain databases
- Mnesia in-cluster object store
- Kafka event streams
- ClickHouse event history and analytics
- S3 / NFS recordings and files
Active-active roles such as sg, b2b, mg and ws run on several servers at once and share the load.
Active-passive roles such as sr, sdc, mgc and sts keep one active instance and hot standbys, and can be split into groups by domain.
Many sites, one system
A site is a group of servers with a fast, reliable network between them. Sites connect over slower, less reliable links between data centres, cities or countries, and each site keeps working when those links go down.
- Domains are bound to sites. A site's domain center (sdc) keeps its domains' data locally and proxies requests for domains served elsewhere.
- One reference copy. Changes go from the site to the master domain center (mdc) and its database, so a site can be added or rebuilt and load its domains back.
- A controlled channel between sites. Cross-site connections run through one rpco on each side instead of a full mesh of server links.
- Independent when isolated. If the link between two cities drops, users in each city still register and call each other. Cross-site calls resume when the link returns.
- Site-level redundancy. Bind a domain to several sites; data replicates automatically and phones fail over to an alternative outbound proxy.
Built to stay up
Each role is responsible for its own availability. Every role can run on several servers, using one of two redundancy patterns depending on what it does.
All instances work at once and requests are distributed between them. If a server goes down, the remaining instances carry on. Used for sg, esg, b2b, mg, ivr, ws.
One instance is active, the others are hot standbys ready to take over. For more capacity the group is split into several groups, each responsible for its own domains. Used for sr, sdc, sts, mgc, huntq.
Supervision all the way down
A failed process is restarted by its supervisor. The core node supervises the roles on its server, and the container itself is supervised by an operating-system daemon.
Quorum against split-brain
Data roles stay active only in the connected group that holds more than half of a site's servers. An external arbiter settles an even split, so two halves never write conflicting data.
Calls survive server failure
In clusters of four or more servers a conversation continues if any one server fails: the call moves to another media gate and keeps going.
Storage failover
Every connection to PostgreSQL, ClickHouse or S3 can list alternatives; the platform switches to the next one available. Call processing goes on even if statistics or recording storage is unreachable.
A hardened edge
Only the edge roles face the network. They have built-in filters, allow and deny lists, and ban the addresses behind repeated failed logins at a low level, so password guessing and floods cost the cluster very little.
Hot configuration changes
New servers, moved roles and changed parameters are applied to a running system. Roles take new settings on the fly or restart themselves one by one.
Scale by adding servers, roles, domains and sites
The platform starts on a single server with every role active and grows by moving roles to their own servers, multiplying them, and splitting data into domains and sites.
What one 4-core server handles
Each figure is the limit when the server does only that job:
- 6,000
- SIP messages per second
- 20,000
- media packets per second, about 200 bridged calls
- 5,000
- routing-rule lookups per second
- 40,000
- registrations per second per core
In a typical mixed load, one server serves about 10,000 subscribers with up to 150 simultaneous calls and 50 new calls per second.
Where to scale next
- More concurrent callsMove mgc and mg to dedicated servers; add media gates beyond about 200 calls.
- Above ~2,000 concurrent callsRun several mgc groups, each with its own set of media gates.
- More calls per secondPut b2b and sg on dedicated servers and multiply them; add redirect in front of many SIP gates.
- Above ~50,000 users or ~1,000 CPSSplit users into domains; up to about 30,000 users per domain is recommended.
- Heavy subscriptions or busy domainsSplit sts, sr and the domain centers into groups bound to domains.
- Around 40 servers of core rolesDivide the system into several sites.
Add servers to a site, add sites to the system.
Add active-active instances; split active-passive groups by domain or hash ring.
Add domains, give a domain its own database, ClickHouse replica or S3 bucket.
Configuration applied hot, delivery in one container
One configuration file describes the whole system and is the same on every server. Each node reads it, finds itself, and starts the roles assigned to its server.
- Administrator, script or AI agentuploads a new configuration file through the API of the master domain
- micmaster infrastructure controller sends it to every site
- iceach site's controller sends it to every server
- Server shellroot node on each server starts and stops nodes as needed
- Nodes and roleseach role compares old and new settings and applies the difference
- The same container everywhere. Every server runs an identical Docker container with all modules and assets, supervised by an operating-system daemon.
- No external orchestrator. The platform manages communication between servers itself, including during updates.
- In-place updates. New modules are swapped into running containers and restarted; each container keeps its last configuration on disk and boots from it.
- Runs where you need it. Linux on bare metal or virtual machines (VMware, Hyper-V), x64 with multiprocessor and NUMA support.
The product layer: build applications on the platform
A product layer installed into a domain turns the communications platform into an information system. It is delivered as packages and versioned independently of the platform.
A typed data structure, for example Ticket or Campaign.
- a collection in storage
- REST API endpoints
- TypeScript wrappers
- change subscriptions
- classes
- controls and editors
- user roles
- web applications
- server microservices
- scripts
- Low-code Builder. Packages are created, exported, imported, activated and deactivated in the Builder, the base application of the product layer.
- Packages add roles and apps. The contact-center package, for example, adds agent, supervisor and administrator roles with their workplace, reports and settings apps.
- No-code scripts. IVR and service scenarios are assembled from components in a visual script editor.
- Real time by default. Any app or microservice can subscribe to a collection or a single entity and is notified the moment it changes.
- Your own microservices. Server microservices are written in TypeScript, compiled by the Builder and run in Node.js under platform supervision (msvc).
- One web app per job. Each user role gets a focused web application built on the same API, instead of one monolithic client.
API-first, and ready for AI tools
The API came before the user interface. Everything the platform can do (configuring the system, managing domains and entities, controlling calls, building packages, subscribing to events) goes through the same open API that Incoplax's own web applications use.
REST over HTTPS
One tree of endpoints for the whole system: domains, users, telephony, data model, files, access control, journals.
WebSocket
Real-time calls, events and subscriptions to changes in any collection or entity.
Events out
HTTP and WebSocket subscriptions for external services, call and CTI events, streams into Kafka.
SIP and WebRTC
Standard endpoints for phones, browsers, carriers, recorders and speech analytics.
What AI tools can do with it
Because nothing is hidden behind a graphical interface, AI coding assistants and agents can work with the platform the way an engineer does: read the documentation, call the API and check the result.
Changes made by an AI agent pass through the same role-based access control as any user's, so the agent gets exactly the rights you grant it.
- Deploy
- Describe the sites, servers and expected load in plain language; the assistant drafts the configuration file and applies it through the configuration API.
- Configure
- Create domains, users, numbers, routing rules, queues, IVR and service scripts in bulk instead of clicking through forms.
- Build
- Scaffold product-layer packages, classes, web apps and TypeScript microservices, then load and activate them in a domain.
- Operate
- Query logs, call events and statistics to explain a failed call, a routing problem or a load spike.
See the architecture on your own workload
Tell us how many users, sites and calls you plan for, and we will show you how Incoplax would be laid out for you: which servers, which roles, and how it fails over.
- Erlang/OTP core
- C++ media processor
- TypeScript, React, Node.js
- PostgreSQL
- Mnesia
- Kafka
- ClickHouse
- S3 / NFS
- Docker