Open-protocol voice: SIP, PJSIP, WebRTC vs proprietary unified communications

Framing

Why voice is a different problem now

Voice used to be solved by a single thing: a phone system, on-premise, owned, operated, and maintained by an internal team. The phone system had a predictable lifecycle, a known set of features, and a clear commercial model. A business that needed ten lines, then fifty, then two hundred, would size the system, buy the hardware, contract the lines, and run it for the next decade.

That model is finished. The technology that replaces it is the open-protocol telephony stack: SIP for signalling, PJSIP for the modern implementation, WebRTC for browser-based real-time media, Debian for the operating system, and Asterisk or FreePBX for the telephony engine. We build on these standards, not on a proprietary unified communications platform. The result is a system the client can audit, replicate, and — if they ever want to — operate themselves.

The proprietary alternative is what most large vendors sell. Per-seat licence, bundled features, locked-down configuration, vendor-controlled updates, and a support contract that escalates with the size of the deployment. The model is simple for the vendor and expensive for the buyer. Per-seat licences are not published, are not transparent, and do not reflect the actual cost of the underlying technology.

The open alternative is different. The per-user cost is not a licence; it is the infrastructure, the design, the implementation, and the support — billed separately and transparently. The open-source core is not sold as a licence. The platform is published openly. A client who runs the platform themselves and never speaks to us again is a legitimate outcome, and that statement is on the pricing page.

This article sets out the architecture, the operating model, and the economics of open-protocol voice. It is written for organisations that have lived through the proprietary-vendor problem and are ready for the open alternative.

The shift to open-protocol voice is not a technology preference. It is a structural choice about how the organisation relates to its communication infrastructure. The proprietary model binds the cost to the headcount, the features to the vendor's roadmap, and the migration cost to the vendor's lifecycle. The open model unbinds all three. The cost is the cost of the work, the features are the features the organisation builds, and the migration cost is zero, because the architecture is the customer's, not the vendor's. That is the structural choice, and the structural choice is what the buyer is making.

The proprietary UC platform is not a bad product. It is a different architectural model. The model works for organisations that want a single vendor for the entire stack, are willing to accept the per-seat cost, and are willing to accept the lock-in. The model does not work for organisations that want to audit the configuration, replicate the deployment, change the support provider, or operate the system themselves. The two models are not competing on features; they are competing on architectural properties, and the architectural properties determine the long-run fit.

Architecture

What an open-protocol voice stack actually is

The open-protocol voice stack rests on five standards. SIP is the signalling protocol that establishes, modifies, and terminates voice sessions. PJSIP is the modern implementation of SIP, with better handling of NAT, better security defaults, and a more active development community. WebRTC is the browser-based real-time media standard, allowing voice and video from a web page without a plugin. Debian is the operating system: stable, auditable, and supported by the same upstream community that maintains the kernel and the core libraries. Asterisk and FreePBX are the telephony engine: open-source, well-documented, and the basis of millions of deployments worldwide.

The architecture is inspectable. The configuration is text files. The dial plan is a documented script. The call routing is auditable. The logs are queryable. The system can be replicated, by copying the configuration to another server. There is no per-seat licence, no vendor lock-in, no proprietary knowledge base. The documentation points to the maintained upstream sources — the Asterisk wiki, the FreePBX documentation, the PJSIP project — not to a closed knowledge base that disappears when the vendor disappears.

The capabilities cover the full range of business telephony: call routing, voice dialogue systems, queue management, policy-based recording, operational analytics, team collaboration, event-driven automation, integration with business systems. The integration points are documented. The APIs are open. A change to the system is a configuration change, not a support ticket to a vendor.

The hardware layer is standard: any Debian-compatible server, any SIP-capable handset, any WebRTC-capable browser, any SIP trunk provider. There is no proprietary handset requirement, no proprietary trunk requirement, no proprietary anything. The buyer chooses the hardware; the buyer chooses the trunk; the buyer chooses the deployment model.

The deployment options are on-premise, private cloud, or managed cloud. The on-premise deployment is for organisations that want the hardware on their own infrastructure. The private cloud deployment is for organisations that want the system on infrastructure they control but do not operate. The managed cloud deployment is for organisations that want the system operated by us, on infrastructure that meets the same standards as the rest of the connected ecosystem.

The hardware layer is not a constraint. Any Debian-compatible server, any SIP-capable handset, any WebRTC-capable browser, any SIP trunk provider can be used. The buyer is not bound to a specific hardware vendor, a specific handset vendor, a specific trunk provider, or a specific cloud provider. The buyer chooses the hardware and the connectivity, and the platform adapts. This is the architectural property that the per-seat licence model does not have: the freedom to choose every component independently.

The Asterisk and FreePBX foundation deserves more than a passing mention. Asterisk is one of the longest-running open-source telephony projects in the world, with a development community that has maintained and extended it for over two decades. FreePBX is the graphical management layer on top of Asterisk, with a configuration model that is documented, version-controlled, and exportable. The two projects together form a telephony platform that is mature, stable, and well-understood by the global community of telephony engineers. The documentation points to the maintained upstream sources, not to a closed knowledge base.

Operating model

Self-serve, consultation, or managed

The voice stack supports three engagement models. The first is self-serve: the client purchases the hardware, installs Debian, configures Asterisk, and operates the system. The documentation is public. The community is active. The platform can be operated entirely independently. This is the right model for organisations with strong internal IT capability and a desire to own the entire stack.

The second is consultation: the client engages us for the design, the architecture, the implementation, or a specific migration project. We scope the work, deliver it, and hand over. The client owns the result. This is the right model for organisations that have internal IT but need specialist depth for a specific challenge — a migration from a proprietary system, a multi-site deployment, an integration with a CRM or helpdesk.

The third is managed: we operate the platform end to end. Monitoring, ticketing, changes, capacity planning, security patching, and support. The client gets a single point of contact. This is the right model for organisations that want the capability without the overhead of operating it themselves.

The commercial model follows the architecture. Design, infrastructure, implementation, support, and third-party services are billed separately and transparently. The per-seat licence is not a line item. The cost is the cost of the work, not the cost of a vendor's market position. The published pricing is the pricing.

Across all three models, the architecture is the same. The engagement depth changes; the underlying system does not. A client can move from self-serve to consultation, from consultation to managed, and back, without changing the platform. The platform is a connected ecosystem layer, not a vendor product.

The voice and AI layers are independent but interlock. A call event can trigger a workflow; a workflow can route a call. A voice assistant can be the first layer of call routing, with human escalation at the second layer. The two layers can be operated independently or together, and the choice is the customer's, not a bundled commitment. The interlock is an architectural property, not a sales pitch, and the architectural property is the platform's, not the vendor's.

The deployment choice is part of the engagement model. An on-premise deployment is for organisations that want the hardware on their own infrastructure, with the configuration managed internally. A private cloud deployment is for organisations that want the system on infrastructure they control but do not operate. A managed cloud deployment is for organisations that want the system operated by us, on infrastructure that meets the same standards as the rest of the connected ecosystem. The three deployment models are not tiers; they are architectural choices, and the choice is the customer's.

Economics

The case for open-protocol over per-seat licensing

The economic case for open-protocol voice is straightforward. A proprietary per-seat licence charges a fixed fee per user per month, typically bundled with features the user may not need. The cost scales linearly with the number of seats, with no discount for the underlying cost of the technology. The vendor's pricing is the vendor's market position, not the cost of the engineering.

The open-protocol alternative unbundles the cost. The design is a one-time project. The infrastructure is the cost of the server and the SIP trunk. The implementation is a one-time project. The support is an ongoing line item, priced by engagement depth, not by seat count. The total cost for a 50-seat deployment is typically 40% to 60% of the equivalent proprietary deployment, with no loss of capability.

The economic case compounds over time. A proprietary deployment is locked to the vendor's roadmap, the vendor's pricing, the vendor's support model. When the vendor raises prices, the buyer pays. When the vendor deprecates a feature, the buyer migrates. When the vendor disappears, the buyer replaces the entire system. The economic life of the deployment is the economic life of the vendor's contract.

An open-protocol deployment has a different economic life. The standards are public. The community maintains the upstream. The buyer can operate the system themselves, can hire a third party to operate it, or can engage us. The economic life of the deployment is the economic life of the standards, which is measured in decades, not in contract cycles.

The total cost of ownership over a five-year window is typically 50% to 70% lower for the open-protocol alternative, including the initial design, the infrastructure, the implementation, the support, and the avoided vendor risk. The architecture is the difference. The architecture is the savings.

The economic case for open-protocol voice is the difference between renting capability and owning capability. The proprietary model rents capability: the buyer pays per seat, per month, for the right to use the system, and the right expires when the contract expires. The open model enables ownership: the buyer pays for the design, the infrastructure, the implementation, and the support, and the system is the buyer's, to operate, to evolve, and to take to a different support provider. Ownership has a different economic profile than rental, and the economic profile is what makes the open model scale.

The five-year total cost of ownership is typically 50% to 70% lower for the open-protocol model, including the initial design, the infrastructure, the implementation, the support, and the avoided vendor risk. The avoided vendor risk is the largest line item: the cost of the price escalation that would have happened at each contract renewal, the cost of the feature deprecation that would have forced a migration, and the cost of the support escalation that would have happened at each scale-up. The open model avoids all of these costs, and the avoidance compounds over the five-year window.

Risk

Architectural questions, not sales claims

The risk of open-protocol voice is operational complexity. The mitigation is documentation, the community, and the engagement model. The documentation is public, points to upstream sources, and is kept current. The community is active and global. The engagement model is flexible: the buyer can self-serve, consult, or fully manage.

The risk of vendor failure is the same as in any technology decision. The mitigation is the open standards. If we disappear, the system continues to operate. If the buyer chooses to leave, the buyer can take the configuration, the dial plan, and the user accounts, and run the system on their own infrastructure. The architecture is not tied to our continued existence.

The risk of security breach is real for any voice system. The mitigation is documented security practice: encrypted signalling (TLS), encrypted media (SRTP), strong password policy, SIP access restriction, fail2ban, patch management, and continuous monitoring. The voice platform is hardened to the same standard as the rest of the connected ecosystem, with the same cybersecurity practice covering endpoint, email, network, and access.

The risk of toll fraud — unauthorised use of the SIP trunk to make expensive calls — is a real risk for any voice deployment. The mitigation is the published hardening guide: password policy, SIP access restriction, fail2ban, geo-blocking, real-time alerting on unusual call patterns, and a kill-switch that the operator can trigger. The hardening is documented, inspectable, and verified by continuous monitoring.

The architectural questions a buyer should ask are these. Can I see the configuration? Can I operate the system myself? Can I export the dial plan? Can I leave without losing my numbers? The answer to all four is yes.

There is a fifth risk worth naming: the risk of operating complexity. The open model requires more operational knowledge than the proprietary model, because the buyer is operating more of the stack. The mitigation is the engagement model: the buyer can engage us for managed operation, for consultation on specific challenges, or for self-serve with documentation and community support. The engagement model is flexible, and the buyer can move between models as the operational knowledge builds.

There is a sixth risk worth naming: the risk of a security incident at the SIP trunk. Toll fraud is a real and persistent risk for any voice deployment, and the open model is no exception. The mitigation is the published hardening guide, the continuous monitoring, and the kill-switch. The kill-switch is the most important: in the event of an anomaly, the operator can cut the trunk and stop the traffic within seconds. The kill-switch is documented, tested, and part of the standard deployment.

Implementation

A week-by-week sequence

Week 1: Assessment. We map the current voice deployment — number inventory, sites, users, features, integrations, contracts, monthly spend. The output is a document the client owns.

Week 2: Architecture. We design the target state — on-premise, private cloud, or managed cloud; the trunk provider; the handset strategy; the integration points with the CRM, helpdesk, and ERP. The architecture is documented and inspectable.

Week 3: Build. We provision the infrastructure, install the software, configure the dial plan, set up the trunk, and configure the security hardening. The build is on a test environment first, then promoted.

Week 4: Migration. The numbers are ported, the handsets are configured, the users are trained, and the system goes live in parallel with the legacy system. The cutover is staged. The legacy system remains available until the new system is verified.

Week 5 and beyond: Operation. The system is live. The monitoring is active. The support model is in place. The system can be inspected, replicated, and operated independently by the buyer at any time.

The sequence is not rigid. A client can start with a single site, validate the architecture, and expand. The voice stack is designed for incremental adoption, not for a forced all-at-once migration. The migration is reversible at every stage.

The implementation sequence is designed to validate the architecture before commitment. The first week establishes the baseline: which numbers, which sites, which users, which features, which integrations, which monthly spend. The second week designs the target state: which deployment model (on-premise, private cloud, managed cloud), which trunk provider, which handset strategy, which integrations to keep. The third week builds the system on a test environment, with the security hardening applied. The fourth week migrates the numbers and the users, with the legacy system running in parallel until the new system is verified.

The implementation sequence is also designed to be reversible. The legacy system remains available during the transition. The new system is built and validated before any cutover. The cutover is staged, with the first batch small enough to validate but large enough to be representative. If the first batch works, the rest follows. If the first batch reveals an issue, the legacy system is still available, and the migration is delayed until the issue is resolved. The reversibility is not a feature; it is the architectural property that makes the open model viable for organisations that cannot afford a service interruption.

FAQ

Five plain-language questions

What is the difference between open-protocol voice and a proprietary unified communications platform? Open-protocol voice runs on public standards (SIP, PJSIP, WebRTC, Debian, Asterisk). The configuration is inspectable, the dial plan is portable, and there is no per-seat licence. A proprietary UC platform runs on closed standards, with per-seat licensing, vendor-controlled updates, and lock-in.

Can I keep my existing phone numbers? Yes. Number porting is part of the migration. The numbers are ported to the new system, and the existing system remains available in parallel until the new system is verified.

What handsets do I need? Any SIP-capable handset. The list of tested models is published. There is no proprietary handset requirement. Web browsers with WebRTC support can also be used for softphone capability.

What happens if I want to leave? You take the configuration, the dial plan, and the user accounts, and you run the system on your own infrastructure. The architecture is not tied to our continued existence.

How does pricing work? Design, infrastructure, implementation, support, and third-party services are billed separately and transparently. The per-seat licence is not a line item. The published pricing is the pricing.

For organisations that have not yet adopted open-protocol voice, the most common question is about the migration cost. The migration is a one-time project with a defined scope, a defined timeline, and a defined cost. The legacy system is maintained during the transition. The new system is validated before the legacy system is decommissioned. The migration is reversible at every stage. The cost is published, the timeline is published, and the success criteria are documented before the first change.

For organisations that have already adopted open-protocol voice, the most common question is about scaling. The architecture scales by adding handsets, adding trunks, adding integrations, and adding users. The scaling is linear, with no per-seat licence escalator, and the infrastructure cost scales with the actual usage, not with the per-seat model. The architecture is the same at 10 users, 100 users, and 1,000 users, and the operational cost is the operational cost of the work, not the operational cost of the vendor's market position.

Worked example

A concrete case with numbers

Consider a 50-person professional services firm with a proprietary UC platform under per-seat licence. The platform is sold at EUR 25 per user per month, with a minimum of 50 seats, on a three-year contract. The annual cost is EUR 15,000 per year, with the contract escalator at 5% per year. The total three-year cost is approximately EUR 49,500. The features include voice, video, chat, and a basic softphone. The configuration is locked. The roadmap is the vendor's roadmap.

Under an open-protocol voice engagement, the firm migrates to a SIP/PJSIP/WebRTC stack on a private cloud. The design is a one-time project at EUR 4,500. The infrastructure is a cloud server at EUR 60 per month. The implementation is a one-time project at EUR 6,000. The support is EUR 350 per month. The annual run-rate is approximately EUR 5,820, with no per-seat escalation. The three-year cost is approximately EUR 22,000.

The trust argument is not the price reduction alone. It is the architecture: the firm can audit the configuration, replicate the system, change the trunk provider, change the support provider, and operate the system themselves at any time. The proprietary UC platform cannot offer any of these properties. The deployment is a feature of the architecture, not a feature of the vendor.

The numbers are illustrative, not a quote. Every deployment is different. The principle holds: open-protocol voice, billed transparently, operated by the same team as the rest of the connected ecosystem, costs less in total than per-seat proprietary licensing — and it works better, because the architecture is the client's, not the vendor's.

Consider a second worked example: a 200-person professional services firm with four offices in three countries, with a proprietary UC platform under per-seat licence, with 220 seats at EUR 28 per seat per month, on a three-year contract. The annual cost is approximately EUR 73,920, with the contract escalator at 5% per year. The three-year cost is approximately EUR 232,000, and the migration cost is estimated at EUR 35,000. The total three-year cost is approximately EUR 267,000.

Under an open-protocol voice engagement, the firm migrates to a SIP/PJSIP/WebRTC stack on a private cloud, with a redundant deployment across two regions. The design is EUR 12,000, the infrastructure is EUR 720 per year, the implementation is EUR 18,000, the support is EUR 4,200 per year. The annual run-rate is approximately EUR 6,000, with no per-seat escalator. The three-year cost is approximately EUR 48,000, plus the migration cost of EUR 35,000, for a total of EUR 83,000. The saving is approximately EUR 184,000 over three years, and the architectural property is the same: the system is the firm's, not the vendor's.