VOIP / COMMUNICATION PLATFORM
RelayPBX
A platform for building and operating business telephony, combining visual configuration, routing, tenants, SIP diagnostics and different deployment models.
- Product
- PBX platform
- Model
- Multi-tenant
- Focus
- VoIP + operations
THE CHALLENGE
Turn telephony complexity into a controlled operational model.
Business telephony includes routing, numbers, queues, devices, media, carriers and customer policies. Configuration must be flexible, yet resistant to accidental errors and possible to diagnose.
The platform is intended to support different roles: carrier, administrator and end user. Each needs a different level of detail, permissions and information about system health.
An important part was separating the product from its hosting model: the environment can run as a managed, dedicated or self-hosted instance while retaining a consistent feature model.
Create a product layer that enables telephony configuration and diagnostics while retaining control over protocol and deployment details.
SCOPE AND DECISIONS
What was designed, and why.
The functional scope is presented alongside decisions that affect everyday use and future product development.
- 01
A model for tenants, numbers, routes, rules, queues and devices.
- 02
Visual configuration of call flows and operations without guesswork.
- 03
Diagnostics for calls, SIP, media and platform component health.
- 04
Panels for administrators, carriers and end users.
- 05
Managed, dedicated and self-hosted models with documentation.
Flows rather than forms
Routing is presented as a sequence of decisions and elements, so the configuration reflects the actual call flow.
Diagnostics as a product feature
The information needed to analyse a call is part of the platform, rather than a tool used only by the operations team.
Tenant boundaries
Data, roles and configuration are logically isolated, allowing multiple organisations to use a shared platform.
Deployment independence
The application layer and integration contracts remain consistent regardless of the hosting model.
ARCHITECTURE
Product layers and their responsibilities.
The architecture is described in functional terms to make clear where logic, data, integrations and operations belong.
- 01
Portal and panel → roles, configuration, diagnostics and user operations.
- 02
API layer → validation, permissions and the tenant model.
- 03
Routing engine → call rules, queues, IVR and policies.
- 04
SIP/media layer → FreeSWITCH, profiles, trunks, RTP and WebRTC.
- 05
Observability → CDRs, logs, call identifiers, monitoring and alerts.
SELECTED SCREENS
The interface as part of the whole process.
The screenshots show the appearance and how users are guided through the main tasks.
OUTCOME
What the project delivered.
Specific product, process and deployment capabilities delivered by the project, without invented metrics.
- A consistent feature model from a single office to a carrier environment.
- Visual routing configuration connected to diagnostic data.
- Separation of administrator and user roles and responsibilities.
- A choice of hosting models while retaining one platform.
- A foundation for documentation, a knowledge base and further operational modules.
NEXT PROJECT
Pokaż Brykę
A community for car projects with vehicle profiles, modification histories, rankings, categories, a Spotted module and engagement features.