Many businesses want a professional PBX or customer contact center, but they do not want to design SIP, media, recording and failover from scratch. They need a reliable number, devices that work, familiar customer channels, and a clean join to the applications they already run.
That is the job PortSIP PBX is aimed at: a commercial communication platform you can install, then wrap with your CRM, portal and operations — instead of owning every line of a PBX engine.
Why PortSIP instead of building the engine
PortSIP is not open-source PBX software. You do not buy the source or unrestricted internals. You get a product with APIs, SDKs and deployment options. For a company that wants workflows — not a second telephony R&D team — that is often the correct trade.
If you later need to own media, write custom SIP behaviour, or sell a multi-tenant CCaaS as your product, the conversation moves to FreeSWITCH, Asterisk or a purpose-built multi-tenant PBX. Those are different contracts with the stack.
Free to explore, paid when you need to scale
The free edition is enough for development, demos and very small teams: 3 extensions and 2 simultaneous calls. Paid licensing is based on extensions and concurrent calls. Paid plans also unlock Contact Center, SBC, PortSIP ONE, WebRTC and the VoIP SDK.
Lab deploy → prove the workflow → connect CRM / WhatsApp → buy capacity when traffic is real
Treat the free edition as a design tool, not a production plan. Capacity, recording policy and HA belong in the paid conversation.
A PBX that runs on your infrastructure
PortSIP PBX installs on Linux through Docker. Current documentation targets Ubuntu and Debian. That matters if you want the PBX on your cloud account, not a shared hosted PBX you cannot isolate.
- A company keeps the PBX in its own VPC.
- A service provider can run a multi-tenant environment with clearer tenancy boundaries.
- App servers stay separate from RTP and SIP.
- Developers integrate CRM, ERP or a customer portal without living on the media host.
Docker is packaging, not openness. You still operate a commercial binary — with clearer upgrades than a pile of hand-installed services.
Desktop, mobile and WebRTC — not one desk phone
Staff move between office, home and travel. PortSIP clients and SDKs cover Windows, macOS, iOS, Android and WebRTC.
Sales on the road
Desktop in the office, mobile on visits, one extension and one presence model.
Remote support
Agents do not need a hardware phone if the client, headset and recording policy are designed up front.
Branches
One central PBX can serve several sites if WAN, SBC and failover are specified — instead of a PBX in every closet.
Embedded calling
SDKs let an authenticated customer start a call from your portal without a second app. That is usually a WebRTC softphone problem, not a new PBX.
From extensions to a Contact Center
Internal dialling is not customer operations. A Contact Center needs intake, queues, agent state and a write-back into the business process. PortSIP’s Contact Center layer is aimed at queueing, reporting, CRM hooks and APIs.
Inbound call → IVR → support queue → agent → CRM record → wrap-up + recording
The PBX owns the call. The business app owns the ticket. Do not rebuild telephony inside the CRM; integrate the two.
WhatsApp is a channel with rules
PortSIP can sit on the WhatsApp Business Platform and route chats to agents or queues. Useful for support, appointments, orders and follow-ups — if you design for Meta’s rules, not “unlimited chat”.
WhatsApp inbound → PortSIP → agent / queue → template after the 24-hour window if needed
Inbound service has a 24-hour customer-care window. After that, you typically send approved templates. Build the workflow around that constraint or the channel will fail in production.
APIs: where the PBX becomes software
REST APIs, webhooks and call-control APIs are the difference between “we installed a PBX” and “the phone system is part of the product.” Typical patterns:
CRM → click-to-call → PortSIP → customer handset
Inbound DID → identify caller → open CRM → route to owner or queue
WhatsApp / form → workflow → agent queue → reply + ticket update
Same idea as any serious SIP / VoIP integration: call control stays in the PBX; business logic stays in your app.
Example: a 20-person service company
A typical brief looks like this:
- One published business number
- Extensions for staff on desktop and mobile
- A support queue and recordings
- WhatsApp next to voice
- CRM screen-pop and reports
- Room to grow without a second platform
Building PBX + Contact Center + mobile + messaging as four projects is how these programmes stall. PortSIP can be the communication foundation; the company software stays focused on tickets, appointments and billing.
Where I implement this
You do not always need to write a PBX. Often the faster path is: pick the platform, deploy it correctly, integrate it, and operate it.
PortSIP free vs paid vs a FreeSWITCH / Asterisk build — based on tenancy, custom media and who will operate it.
Install on your Ubuntu/Debian host or cloud VPC, with backups and a documented upgrade path.
DIDs, IVR, queues, recording and the actual customer workflow — not a default demo tree.
Desktop, mobile and WebRTC clients that match how people actually work.
Click-to-call, screen-pop, webhooks and the fields your agents need on the first ring.
Business Platform wiring plus template / 24-hour-window behaviour.
From architecture through test calls to something you can support next quarter.
The customer should not care whether the last interaction was a call, a mobile client or WhatsApp. The business should have one way to own that interaction. That is the gap between installing a PBX and shipping a communication solution.
You bring the workflow. I turn it into a working platform.