Other cookies are configurable.
Incoplax IP PBX · Class 5 softswitch
The IP PBX that scales like a softswitch
Business telephony for your offices, your customers or your own software. Incoplax brings calls, queues, voice menus and recording together on a platform you can run on your own servers or in your cloud.
Start with a single-server PBX, or design a redundant cluster for multiple sites and customer organisations. Automate administration through the API, provision compatible phones and expand capacity as demand grows.
One product, three ways to use it
The same software runs as a company PBX, as the Class 5 softswitch behind a hosted PBX service, or as the telephony engine inside another product.
Enterprises
Replace ageing PBXs across offices with one system
- One numbering plan across offices, with branch resilience designed for your network and failure scenarios
- Branch PBXs connect as subscribers while you migrate, so nothing is switched off overnight
- Phones, softphones and browser calling under one account per employee
Service providers
Launch hosted PBX and SIP trunking on your own network
- Multiple customer PBXs on one cluster, each with its own domain and administration
- Resellers get their own branch of the tree, admins and licence pool
- Provision customers, numbers and phones from your BSS through the API
Integrators and software vendors
Build telephony into your product
- Create tenants, users and devices from your own portal through the REST API
- React to calls and registrations in real time over WebSocket or webhooks
- Extend call handling with visual scenarios instead of patches
Five things a modern PBX has to get right
Manage business calling, customer PBXs and integrations on one distributed platform. Choose the services and redundancy design that fit your deployment.
Fault tolerant
Redundant services keep new calls moving after a failure. Configured call recovery can restore existing conversations, subject to device and carrier support.
02API first
Automate user and number management, control calls and receive events through REST and WebSocket APIs.
03Multitenant
A tree of isolated domains: an operator, resellers and their customers, each with its own users, numbers, routes, admins and licences, on shared servers.
04Auto-provisioning
Once the network and model template are ready, compatible phones retrieve settings built from their accounts and device details.
05Scalable capacity
Scale signalling, media and voice menus separately. Use workload-specific sizing figures and validate your own peak traffic.
Everyday calling, queues and team services
Transfers, park, pickup, conferences, forwarding, groups, queues and voicemail work on any SIP phone, softphone or browser, because the server does the work. Each service has a code you choose and can be allowed or denied per user and number.
- 1HoldPut the caller on hold.
- 2ParkDial the park code and a slot, for example *71 105.
- 3WaitThe caller hears the park music while you walk away.
- 4RetrieveAnyone dials *72 105 on any phone and takes the call.
- 1HoldPut the caller on hold.
- 2ConsultCall a colleague and introduce the caller.
- 3CompleteThe caller is connected and your connection ends while they continue talking.
- 4Or conferenceTurn the three of you into a conference instead.
Codes shown are examples; administrators set their own.
Transfers and hold
- Blind transfer to any number
- Attended transfer with leg replacement
- Transfer into a conference
- Music on hold, chosen per call from tagged playlists
- Second incoming call during a conversation
Park and pickup
- Call park on numbered slots with its own music
- Retrieve a parked call from any phone
- Directed pickup of a ringing colleague
- Group pickup by presence
- Intercom calls
Conferences
- Ad-hoc three-way and larger conferences from the phone
- Drop one participant or end the conference by code
- Conference rooms for 100+ participants
- Moderated conferences with participant controls, voting and schedules
- Start and control conferences through the API
Supervisor tools
- Silent monitoring: hear both sides
- Whisper: only your colleague hears you
- Join a call as a third party
- Barge in on a busy colleague
- Access granted per user and number
Forwarding
- Always, when unregistered, busy, no answer, declined or DND
- Cascades A → B → C → D
- Filters by caller number
- Schedules: working hours, out of hours or custom periods
- Done on the server, so it works with any phone
Groups
- Group numbers that ring in ordered levels
- Parallel ringing of extra numbers, such as a mobile
- Boss and secretary: parallel, cascade or direct, with a VIP list
- Groups with configurable call-handling rules
- Several devices on one account ring together
Queues
- Hunt groups and queues with priorities and weights
- Ring one agent at a time or staggered by timers
- Waiting, queue and pre-answer IVR scenarios
- Overflow to another number after a time-out or attempts
- Personal queues created on the fly
Personal services
- Voicemail with message-waiting light and keypad control
- Leave a voice message straight into a mailbox
- Hot-desking: sign in on any phone with a PIN
- Callback requests left in the user's box
- Fax to e-mail and e-mail to fax (T.30)
IVR you design visually, not with code
Auto-attendants, voice menus, after-hours service, self-service and voice bots are scenarios built from 60+ ready components. The same engine runs service scenarios for routing decisions and data processing.
- Incoming callto the main number
- Greetingspeech synthesis
- Business hours?compare with the schedule
- Closed → voicemailand a callback request
- Menupress a key or say it
- 1 · Sales queue
- 2 · Look up the callerweb request to the CRM
- VIP → priority queueothers → support queue
- 3 · Order statusspeech recognition + GPT, answer by voice
- 0 · Operatorattended transfer
- Business hours?compare with the schedule
- Greetingspeech synthesis
VoiceCall controlLogicData and integrationAI and speech
- Visual editor
- Drag components onto a map, group them into regions, and follow any branch with one key: tracing highlights where a caller can go from here and how they got there.
- Versions you can trust
- Every save is kept with its author. Compare two versions side by side and roll back in a click.
- Runs like the rest
- Each call gets its own scenario process as a SIP user agent; the IVR service runs Active-Active and scales with the cluster.
- Speech engines
- Speech recognition and synthesis through Microsoft Azure Speech and other cloud engines; your own voice bot can take over any step through the API.
Call recording and speech recognition
Recording is set by rules, not by phones: decide which calls are recorded, where the files go and which calls are turned into text. Transcripts land next to the call record, ready for search, quality checks and AI analysis.
- 1AnswerA recording rule matches the numbers, direction and schedule; the “call is recorded” notice plays if enabled.
- 2RecordThe media gate writes each side separately. Hold music is replaced by silence.
- 3MixOne stereo MP3: caller on the left, called party on the right. Parts from a moved media gate are joined.
- 4StorePlaced in the storage of every tenant that asked for it: NFS, S3 or local disks.
- 5TranscribeTranscription rules queue the call; the transcript with timecodes and speaker sides is added to the call journal.
- 6UsePlay it in the apps by role, download it by link or API, or react to the “recording ready” event.
Rules and compliance
- Record by caller and called number, direction (internal, incoming, outgoing or all) and schedule
- Calls between tenants: each tenant that asks gets its own copy
- Automatic “this call is recorded” notice, short or long
- Start or pause recording during a call through the API
- Access by role, with a security log of who listened or downloaded
External recorders and speech
- SIPREC (RFC 7866) to external recording systems
- Two-stream or mixed SIP streams to any recording server
- Several recorders at once, alongside local recording
- Transcription with Vosk or Whisper on your own servers, or a cloud speech service
- Live recognition and synthesis inside IVR scenarios
WebRTC and WebSocket built in
The browser is a first-class phone. WebRTC calls, SIP over secure WebSocket and a real-time WebSocket API let you put calling and live call data into any web page or CRM screen.
web app, CRM page or softphone
- SIP over secure WebSocketRegistration and call signalling from the browser to the SIP gate
WSS - DTLS-SRTP mediaEncrypted audio and video between the browser and a media gate
Opus · G.711 · VP8 · VP9 · H.264 - WebSocket APIRequests and live events for your web app on the same host and port as HTTPS
/ws · /ws/token/v1/:TOKEN
SIP gate · media gate · API
WebRTC
- Calls and video calls in any modern browser, no plugin or app
- A built-in web softphone in the employee and agent applications
- Your own web apps register as SIP devices over secure WebSocket
- WebRTC media recovery depends on the configured recovery path and client support
- Registrations are cleared when a WebSocket drops, and the softphone re-syncs its calls on reconnect
WebSocket API
- One connection carries requests, responses and event notifications
- Capabilities switched on per connection: REST, call and device control, events, IVR control, recordings, service scenarios
- Subscriptions to call, contact-center, IVR and data-change events, renewed by the client
- Applications sign in as users; external systems connect with an integration token
- An alternative to webhooks: the client opens the connection, so nothing has to reach in through your firewall
Resilience for new calls and active conversations
In a redundant deployment, surviving services can accept new calls after a failure. Existing conversations can also be restored when call recovery is enabled and endpoints and carriers support the required signalling and media changes. Audio may be interrupted during recovery.
- 1Call in progressThe system records which signalling and media nodes serve every dialog, in a replicated call store.
- 2A server is lostNode health is watched continuously. Affected dialogs are identified and a restore task is created for each.
- 3Call restoredThe recovery service rebuilds the dialog using supported recovery methods such as INVITE/Replaces. IVR restarts from the beginning or from a saved checkpoint, when the scenario provides one.
- Active-Active everywhere it matters
- SIP gates, B2BUA, media gates, conferences and provisioning all run in several working copies. New calls simply go to the copies that are alive.
- Automatic takeover for stores
- Registrar, queues, voicemail and controllers run Active-Passive; a standby copy takes over by itself.
- One address for phones
- Configured virtual IP failover can keep a stable address for clients. Alternative proxies or DNS-based connection strategies are also possible.
- Carrier links that move
- Configure transfer of trunk registrations to a surviving external gate. Restoring an active carrier call also depends on the carrier's recovery capabilities.
- Configurable quorum protection
- Enable and configure quorum tracking to reduce split-brain risk. Services in a partition that loses quorum stop serving clients and changing data. Automatically generated configurations have this tracking disabled by default.
- Hot standby for a whole tenant
- A domain can mirror its settings and statistics to a second installation and take over if the leader disappears.
- Planned maintenance
- Use the service-draining tools before planned maintenance. This is a separate procedure from emergency call recovery; validate it against your deployment.
Capacity you can plan on
These sizing references summarise tests across processors, normalised to a 2.5 GHz core. Each row is a separate workload; the maxima cannot be combined. Validate capacity with your codecs, recording, IVR and integration workload.
| Load profile | Calls/s | Concurrent calls | IVR sessions |
|---|---|---|---|
| Calls per second focus | 72 | 300 | |
| Concurrent calls focus | 6 | — | |
| IVR focus | 6 | 1,500 |
Per core: up to 6 calls per second, 180 concurrent calls or 125 IVR sessions. Size for 70% CPU at peak and add a reserve for redundancy.
- 1
Start small
One server can run the system. For resilience, distribute redundant services across servers and configure failover and quorum.
- 2
Split the heavy parts
As load grows past 60–70%, move databases, media, SIP signalling and IVR to their own servers.
- 3
Add servers, not projects
Each SIP gate instance handles up to 3,000 SIP packets a second; add instances and gates, media gates or scenario servers as needed.
Separate customer PBXs on shared infrastructure
Tenants are domains in a hierarchy. A provider sells hosted PBX to resellers and end customers; an enterprise separates subsidiaries or countries. They share infrastructure while tenant data and administration are separated by domain and access rights.
- pbx.example.netOperator domain: cluster, sites, border rules, licences
- reseller-a.pbx.example.netReseller with its own admins and licence pool
- acme.reseller-a…UsersNumbersTrunksRoutesIVRRecordingsAdmins
- globex.reseller-a…UsersNumbersTrunksRoutesIVRRecordingsAdmins
- initech.pbx.example.netEnterprise customer served directlyUsersNumbersTrunksRoutesIVRRecordingsAdmins
- reseller-a.pbx.example.netReseller with its own admins and licence pool
- Isolated by default
- Tenant objects belong to domains. Access is governed by domain boundaries and roles; authorised operator administrators can manage customer domains.
- Licences flow down the tree
- Each domain keeps part of the licences it receives and passes the rest to its children, so resellers manage their own pool.
- One admin or many
- Run every tenant from the operator domain, or give each customer its own administrators and web console.
- Calls between tenants on request
- Two tenants can call each other directly once both admins add a route.
- Placed where you need it
- Choose which sites serve a tenant; its registrations and data follow it, and a tenant can have a hot standby elsewhere.
- Per-tenant settings
- Numbering plan, routing, class of service, storage rules and the business applications you enable differ per domain.
Auto-provisioning for compatible phones
Prepare a template for the phone model and configure network discovery or the provisioning address. Then add its MAC address and account: the phone can retrieve its lines, keys and server settings automatically on boot.
- 1Power onThe phone learns the provisioning server from DHCP, or finds it by PnP multicast in its network segment.
- 2Ask by MACIt requests its configuration file, named after its MAC address, over TFTP or HTTP.
- 3Find the accountThe MAC is matched to a SIP account, searching every tenant on the cluster.
- 4Build the configThe template for that phone model is filled from the account, tenant, operator and site constants, plus BLF keys and per-device overrides.
- 5DeliverThe generated configuration is delivered to the requesting phone. Protect access to the provisioning service and its configuration data.
- 6RegisterThe phone registers on its SIP gate and is ready to call.
Templates per model
Text or XML templates for each phone family, managed as files or through the API. Templates can include other templates, as deeply as needed.
Smart placeholders
[sipuser.login], [constants.sg.addr], [nslookup.pool.ntp.org], [random.N] spread phones across SIP gates and NTP servers without per-phone work.
Scales with the cluster
The provisioning service runs Active-Active like the rest. Firmware and other shared files are served from a static folder.
Connect telephony to your CRM
Use APIs and events to build calling into your CRM, helpdesk or ERP. The exchanges below are integration patterns: opening cards, synchronising contacts and attaching recordings require logic in the CRM or an integration service. Confirm connector availability and implementation scope for your system.
- Screen popThe integration uses a call event to open the matching customer carddlg_call event
- Click-to-callAn agent clicks a number; the PBX rings the agent, then the customerPOST /rest/v1/uc/calls
- Call loggingThe call ends: duration, result and who hung up land on the recorddlg_end event
- Recordings and transcriptsThe integration attaches a recording link and, when ready, a transcriptrecords_moved event
- Contact syncImplement field mapping, update rules and conflict handlingREST + data-change events
- Live call controlTransfer, hold, record or hang up from the CRM screen/rest/v1/uc/calls/{id}
- Webhooks into the PBXA CRM event, such as a new order, starts a scenario: a notification call or a callback/api/token/v1/:TOKEN
- IVR look-upsDuring a call the IVR asks the CRM who is calling and routes VIPs firstweb request component
Each integration gets its own token, optional IP and client-certificate checks, and only the endpoints and events its roles allow. Details and examples: Communications API.
API first: the console is just another client
Connect your billing system, CRM or customer portal to the APIs used by the web console. Integration tokens and roles define which resources and actions each connection can access.
Configure
Tenants, users, SIP accounts, numbers, trunks, routes, hunt groups, feature codes, IVR scenarios: create, read, update and delete over REST, with filters and masks.
Control
Place, answer, transfer, hold and record calls; run scenarios and take over IVR steps from your own system.
Observe
Call events, registration states and data changes over WebSocket or webhooks; call records into Kafka and ClickHouse for analytics.
Endpoints, events and recipes: Communications API · Documentation ↗
Developer examples: provisioning and events
Example: create a SIP account with a device
POST /rest/v1/uc/sipusers
Authorization: Bearer <token>
{"name": "Reception",
"login": "reception",
"pwd": "…",
"phonenumber": "1001",
"opts": {"ap_devices": [{
"mac": "805EC0A1B2C3",
"device_model": "Yealink SIP-T21 E2",
"blf": [{"number": "1002"}]}]}}
# requires a matching template and provisioning setup Example: subscribe to permitted call events
["subscribe",{"qid":1,
"events":["callevents.*"],
"objects":"any"}]
→ ["notify",{"class":"callevents",
"type":"dlg_start", …}] Automate administration with your AI agent
An agent integrated with the REST and WebSocket APIs can help prepare configuration, manage resources and inspect call events. The workflow below is an integration example, not a turnkey deployment service. Infrastructure setup, agent tools and permissions must be provided and validated.
“Create the tenant acme.example with 20 users and desk phones, a main number with a menu, and prove that option 1 reaches the sales queue.”
- 1PreparePrepare configuration for an installed platform. Review the proposed changes and validate the target environment.
- 2ConfigureTenants, users, SIP accounts, numbers, trunks, routes, queues, IVR scenarios and recording rules, created and changed through the API.
- 3TestTrace numbers through routing with the diagnostic API, place test calls into IVR and queues, and check the call events that come back.
- 4OperateInspect available logs, events and registration states; propose fixes for review and repeat the checks.
Verify that the tenant and call flow exist, then confirm that a real test call choosing option 1 reaches the sales queue.
- Same rights as a person
- An assistant works with the token it is given and the roles behind it. Read-only access is the natural start.
- API-based workflows
- Build agent actions around documented API methods and validate their results. Available actions depend on the integration and its permissions.
- Choose and validate your agent
- Use an agent capable of calling the APIs through suitable tools. Confirm connector availability and supported operations for your chosen assistant.
A softswitch built from small, redundant parts
Each job in the call path is a separate microservice. Gates face the outside world, the B2BUA holds the logic, media gates carry the audio and video, and every one of them runs in as many copies as the load requires.
Active-Active: every copy works Active-Passive with automatic takeover (registrar, queues, voicemail)
Scale each part on its own
More registrations? Add SIP gates. More concurrent calls? Add media gates. Heavier IVR? Move scenarios to their own servers. Nothing has to be re-architected.
Many sites, one system
Sites can serve the same domains. Autonomous operation requires a site-aware configuration; it is not the same as splitting a single cluster. Quorum and replication must be designed for the intended failure scenarios.
Hardened edge
Border rules filter SIP by address and pattern, repeated failed logins put the source on a ban list, and edge rules rewrite SIP headers to match carrier requirements.
Routing that stays readable at any scale
Every call, internal, external, between tenants or started by the system, passes the same six-stage pipeline. Two-step routing with vectors and rules keeps thousands of numbers manageable, and every decision can be traced.
- 1. AdmitIncoming control
- Border filter by address
- SIP message rewriting
- Carrier account match and trunk limits
- Number normalisation
- 2. ChooseRoute selection
- Vectors, then rules, by priority
- Filters: from, to, domain, carrier, direction
- Time schedules on every rule
- 3. RewriteModification
- Per-character masks, regular expressions, ranges, tables
- Re-route with the new numbers
- 4. CheckRights
- Class of Service and Class of Restriction
- Toll lists for destinations
- Feature permissions per user
- 5. ActExecution
- Internal user or group
- User behind a branch PBX
- External trunk
- Another tenant
- Service code or IVR
- Deny
- 6. PresentOutput control
- Caller ID and name per tenant
- Number rules per carrier
- Forking to all devices
Time-based routing
Working hours, out-of-hours and custom periods per rule: night service, holidays and weekend menus without scripts.
Carrier failover and load sharing
If a trunk is down or full, the next rule takes the call. Rules with equal priority share the load between carriers.
The right number on every screen
Caller ID and display name are built per tenant and per carrier, to present the intended callback number.
Test before going live
Trace any number through vectors, rules and presentation with the diagnostic API before a change reaches users.
Technical specifications
| Signalling | SIP 2.0 over UDP, TCP, TLS, WebSocket and secure WebSocket |
|---|---|
| Media | RTP, SRTP, DTLS-SRTP for WebRTC; DTMF per RFC 2833 and in-band |
| Audio codecs | G.711 A-law and µ-law, G.722, G.726, G.729 and G.729a, GSM, Opus, Speex |
| Video codecs | H.264, VP8, VP9, H.263 |
| Redundancy | Active-Active call services and Active-Passive stores; configured call recovery subject to device/carrier support; configurable quorum protection |
| Sites | Multi-site deployment; autonomy depends on site, replication and quorum design; configurable virtual IP failover |
| Multitenancy | Hierarchical domains with isolated data, own admins and licence pools |
| Provisioning | TFTP, PnP and HTTP; templates per phone model; BLF keys and overrides |
| PBX features | Transfers, park, pickup, intercom, barge-in, monitoring and whisper, ad-hoc conferences, forwarding, groups, queues, voicemail, hot-desking |
| IVR | Visual editor with 60+ components: voice, call control, logic, data and integration, GPT, speech synthesis and recognition, answer detection, external control over API |
| Recording | Rules by number, direction and schedule; stereo MP3 to NFS, S3 or local disks; SIPREC (RFC 7866) and SIP streams to external recorders; transcription with Vosk, Whisper or cloud engines |
| Fax | T.30 send and receive in IVR, fax to e-mail, e-mail to fax |
| Carriers | SIP trunks with registration or IP peering; peer and upstream PBXs; PSTN through gateways |
| API | REST and WebSocket; webhooks; events to Kafka; call records to PostgreSQL or ClickHouse |
| WebRTC | SIP over secure WebSocket, DTLS-SRTP media, audio and video in the browser, built-in web softphone |
| CRM integration | APIs and events for custom CRM, helpdesk and ERP integrations; connector availability and development scope must be confirmed |
| AI tools | API-based agent integration for configuration and checks; requires suitable agent tools and role-based access |
| Security | TLS certificates per gate, border filter, dynamic ban list, SIP header rewriting, LDAP |
| Hardware | Minimum: 4 cores, 8 GB RAM, 100 GB disk. Production: size CPU, RAM, database and recording storage, disk performance and redundancy for the workload |
Plan your deployment
Part of the Incoplax platform: architecture, technology stack and Unified Communications.
Frequently asked questions
Is Incoplax an IP PBX or a softswitch?
Both. Use it as a company phone system, a multi-site enterprise platform or the Class 5 softswitch behind your hosted PBX service. Deployment, capacity and enabled applications are planned for your use case.
What happens if a server fails?
In a configured redundant deployment, surviving services can handle new calls. Recovery of existing conversations must be enabled and depends on endpoint and carrier support; audio can be interrupted. IVR restarts from the beginning or a configured checkpoint. Quorum protection must be configured separately.
How many calls can it handle?
The sizing reference gives 2,000 concurrent calls or 72 new calls per second for 12 cores at 2.5 GHz, in different workload profiles. These are planning references, not combined maxima or guarantees for every server. Allow capacity for redundancy, recording, IVR, databases and storage.
Can we host several customers on one installation?
Yes. Customer domains have their own users, numbers, routes and administration. Resellers can manage a branch of the hierarchy; authorised operator administrators retain access according to their roles.
Will our phones work?
Check SIP interoperability and provisioning separately. Automatic configuration requires a suitable model template, device details and a working discovery or provisioning setup. Share your phone models and firmware versions when planning the deployment.
Can it integrate with our CRM?
The APIs support workflows such as click-to-call, call logging and recording links. The CRM or an integration service must implement the corresponding logic. Confirm whether a ready connector exists for your system and which functions require development.
Can an AI assistant manage the PBX?
An agent with suitable API tools can assist with configuration and checks on an installed platform, within the permissions of its token. Agent integration and testing are required. Confirm support for your chosen assistant; API availability alone does not make infrastructure deployment automatic.
What is included and how is it licensed?
Use this page as a capability overview. Before ordering, request a proposal that specifies the PBX applications, user and tenant capacity, redundancy, integrations, speech services and support included in your deployment.
How do we migrate and plan support?
Existing PBXs can remain connected while users move in stages. Agree ownership of installation, carrier configuration, migration, acceptance testing and ongoing support before rollout. Start with a pilot covering your main call flows.
What information is needed for a proposal?
Share user and site counts, peak simultaneous calls, expected call rate, phone models, carriers, CRM, recording retention and resilience requirements. Include your preferred hosting environment and any existing PBX that must remain connected.
How is it deployed and sized?
Deploy on Linux servers or virtual machines in your data centre or cloud. The documented minimum is 4 cores, 8 GB RAM and 100 GB disk. Production sizing also needs database and recording storage, disk performance and resilience capacity; the minimum is not a production sizing recommendation.
How do we see it in action?
Request a live demo using the form below. Bring your call flows and integration requirements so the discussion can focus on your deployment.