Traditional PABX vs IP PBX vs Cloud PBX: How They Work and How to Choose

2025-02-15 | Communication Systems

How IP PBX, SIP trunks, codecs, security and failover work, and how to choose.

What Is an IP PBX?

An IP PBX (IP Private Branch Exchange) is a business telephone exchange that handles company calls over an Internet Protocol (IP) network. A traditional PABX relies on dedicated telephone lines and circuit switching, connecting each call to a physical line. An IP PBX converts voice into data packets, carries them over the company local network, and connects to the public telephone network through a SIP trunk for outside calls. A cloud PBX places the exchange itself in the provider data centre, with phones and apps connecting over the internet.

The core functions are broadly the same across all three types: extension numbering, internal dialling, call transfer, outside dialling, voicemail and caller display. The differences lie in where the exchange lives, how voice travels, and who is responsible for maintenance and expansion. Before choosing a brand, a company should first clarify its own calling pattern: how many extensions, how many sites, how many people need to answer remotely, and what state the existing cabling and network are in.

Three Types of Phone System Compared

The table is directional guidance only. The real choice depends on each site network quality, concurrent call volume, number arrangements and maintenance capability. Hybrid migration is also common: existing analogue phones join the new system through a gateway, so not every endpoint has to be replaced at once.

How a SIP Trunk Works

SIP (Session Initiation Protocol) is the signalling protocol that creates, modifies and ends calls, defined by RFC 3261. Voice itself travels over RTP. That split matters: SIP agrees how the call is set up, RTP carries the voice. When a phone starts up, it sends a REGISTER message to a registrar, binding its SIP address to its current IP address and port so other endpoints can reach it. Registrations carry an expiry time, and phones re-register before expiry to stay reachable.

The link between an IP PBX and a telecom provider is called a SIP trunk. Authentication generally takes one of two forms: registration, where the IP PBX logs in with a username and password, or IP authentication, where the provider only accepts traffic from registered addresses. Which form applies depends on what the provider supports and how the company network is arranged. For outbound calls, the IP PBX sends the call through the trunk to the provider network. For inbound calls, the provider delivers the dialled number to the IP PBX, which routes the call to a designated extension, group, IVR or voicemail under its routing rules.

Calls between extensions on the same IP PBX are handled by internal routing and stay on the internal network, without going out to the public telephone network. Only calls to numbers outside the company go through the SIP trunk to the public network. Long-distance cost depends on the provider charges and the plan: charges differ by provider, destination and plan, so check the tariff, billing unit and contract terms before committing, and do not assume any charge for a given destination.

Codecs and the Quality Trade-off

A codec decides how voice is compressed, sent and restored. Choosing a codec means trading off quality, bandwidth and processing load. The two endpoints negotiate a codec they both support, so it is not decided by one side alone.

The bitrates above are the raw codec rates. Real network use also adds IP, UDP and RTP header overhead, so bandwidth planning must leave headroom rather than treating the raw rate as the full requirement. Multiply by the number of concurrent calls. On a LAN with ample bandwidth, compatibility and quality usually come first. On a constrained link, the compression trade-off deserves serious assessment. Non-voice signals, such as fax tones, may perform worse on compressed codecs, so companies that still use fax machines should confirm the handling with the provider before deployment.

Network Foundations: QoS, VLAN and PoE

Voice is sensitive to delay and packet loss. On a poorly prepared network, calls break up, overlap or go one-way silent. An IP PBX deployment is therefore a network project as well as a telephone project. Common measures include:

• Voice VLAN: placing voice traffic and data traffic on separate virtual LANs, making it easier to apply priority policy, isolate traffic and troubleshoot. Switches can be set to forward phone traffic on a voice VLAN at higher priority.
• QoS priority: marking voice packets for priority so switches and routers handle voice first when congested, reducing delay and jitter. Marking methods include 802.1p priority and DSCP, and the settings must match the network equipment.
• Bandwidth planning: reserving bandwidth for the expected number of concurrent calls, and remembering the upload direction, because voice is two-way traffic. Heavy cloud app use, backups or downloads in the office compete with voice for the same bandwidth.
• PoE power: Power over Ethernet lets one cable carry both data and power, so phones need no separate power adapter. IEEE standards define several levels: 802.3af delivers up to 15.4W per port, with about 12.95W reaching the device; 802.3at (PoE+) delivers up to 30W per port, with about 25.5W reaching the device; 802.3bt Type 3 delivers up to 60W per port, with about 51W reaching the device; Type 4 delivers up to 90W per port, with about 71.3W reaching the device. When choosing a switch, check the total PoE budget as well as the per-port figure. With many phones, total power demand is the sum across all devices.

Where Wi-Fi coverage is uneven, softphones on mobile devices will suffer too. Before deployment, a network assessment is worth doing: cabling condition, switch capacity, PoE budget, wireless coverage and internet connection quality all shape the final call performance.

Security: Encryption and Toll-Fraud Prevention

Once an IP PBX touches the internet, treat it as a system that will be attacked. Common security measures include:

• Encryption: use TLS to protect SIP signalling and SRTP to protect voice media, so intercepted packets are not easily restored. Confirm during deployment that encryption is actually enabled, rather than assuming it is on by default.
• Authentication and passwords: change all default passwords, use strong passwords for each extension and SIP trunk, enable multi-factor authentication for admin access, and restrict admin access to the people and addresses that need it.
• Toll-fraud prevention: toll fraud means unauthorised use of a phone system to place calls, often to international or high-charge destinations. Countermeasures include disabling unused extensions and trunks, restricting dialling destinations per extension, blocking high-charge number ranges, setting spend limits and anomaly alerts, and watching for unusual calls outside office hours.
• Network isolation: voice VLAN and firewall rules limit which traffic can reach the phone system, reducing the chance that an infection elsewhere on the network spreads to telephony.
• Updates and monitoring: update the IP PBX, phone firmware and related equipment regularly, and review call records and login records for unusual registrations and dialling patterns.

Security is an ongoing process, not a one-off setup. Every added extension, routing change or remote access opening should trigger a fresh review of whether any unnecessary entry point has been created.

Everyday Features: IVR, Voicemail, Recording, Conferencing, CRM

Beyond making calls, an IP PBX shapes how incoming calls are handled and recorded:

• IVR and auto attendant: callers hear a voice menu and press keys or speak a choice to reach the right department. Common setups include different flows for office hours and after hours, key-based routing, waiting queues and transfer to groups. Keep menus short, because too many options confuse callers.
• Voicemail to email: messages can be delivered as audio files to a designated mailbox, so colleagues can follow up while away. Decide who receives them, how long they are kept, and how sensitive messages are handled.
• Call recording: recording can support training, review and dispute follow-up. Recording involves privacy, so set the principles before switching it on: tell the other party before recording, state the purpose, set a retention period, limit who can access recordings, and delete them properly when they expire. Do not record without notice, and do not use recordings for purposes beyond what was stated.
• Conferencing: multi-party calls run through the IP PBX without extra conferencing hardware. The number of participants and simultaneous conferences depends on system capacity and bandwidth arrangements.
• CRM integration: some platforms integrate with customer relationship management systems, for example screen pop on incoming calls or click-to-dial. Integration depth varies by platform and CRM, so confirm each item against the actual systems during selection, and do not assume every platform delivers the same integration.

Numbers and Extension Mobility

Moving to a new phone system does not necessarily mean changing phone numbers. Number porting moves an existing number to a new provider, and the process is generally started by the new provider with the old provider. Do not cancel the old line before the port completes, or the number may be unrecoverable. Multi-line systems, direct dial-in ranges or legacy exchange setups may need extra checks and documents, and the transfer may take longer. Leave time for number porting in the cutover schedule, and do not set the cutover date too tight.

Extension mobility is a key feature of IP telephony: a colleague who logs in on another phone or softphone can keep the same extension number and settings. Staff working away from the office can answer company calls through a mobile app, subject to platform support and company policy. Such arrangements must sit alongside security settings such as device authentication and access control, and convenience should not be used as a reason to weaken authentication.

Power and Internet Outage Response

IP voice depends on power and network, so an outage hits calls directly. Write the response plan before deployment, not during an incident:

• Backup power: use an uninterruptible power supply (UPS) for switches, routers, modems and phones. Size the UPS by the real load and the expected hold-up time. A small UPS may only last minutes, so do not assume one UPS will carry the whole outage.
• Failover rules: set a failover destination for each main number and critical extension, for example another site, a group, a mobile app, an auto attendant or voicemail. Write the rules down explicitly, rather than relying on assumptions.
• Line redundancy: where needed, consider a second line or mobile network backup so one line failure still leaves another path.
• Testing: simulate a line failure and a site outage, and confirm that calls reroute as designed. An untested response plan is the same as no plan.

The response plan promises no specific availability figure. Availability depends on power, network, the provider platform and the setup itself, and any figure only means something with real testing and contractual backing.

Emergency Calls to 999: Confirm Before Deployment

Emergency calling is the part of an IP PBX deployment that must never be left vague. IP voice differs from a traditional fixed line: a number is not necessarily tied to one physical address, an extension may log in from different places, and calls may be impossible during a power or internet outage. Before deployment, confirm the following with the provider:

• How emergency calls are connected, and how caller location information is handled;
• How the registered address for each extension or device is set, and how it is updated after a move;
• Whether failover routing affects emergency call connection and location information;
• What alternative contact methods apply during a power or internet outage, and what staff should do.

When making an emergency call, state the current location clearly at the start of the call, in case the call drops. The company should also write the emergency arrangements into internal guidance, so staff know when IP phones cannot reach emergency services and which alternative method to use. Do not assume the new system emergency arrangements are identical to the old system until they have been confirmed.

Selection Checklist

Before deciding, work through the following questions. The answers directly shape which system type fits and how it should be deployed:

• How many concurrent calls and extensions are needed? Will more sites be added?
• How many colleagues need remote or mobile answering, and on which devices?
• Are the existing cabling, switches, PoE budget and Wi-Fi coverage enough for voice traffic?
• How should existing numbers be handled? Is number porting needed? Are there direct dial-in ranges?
• What are the IVR, voicemail, recording and conferencing needs? Is the recording policy written?
• What are the security requirements? Who manages the system? How are passwords, authentication and anomaly alerts handled?
• How are outage response and emergency calling confirmed with the provider?
• How is maintenance responsibility divided? Does anyone in-house handle day-to-day administration and troubleshooting?
• How do legacy analogue phones, fax machines and other equipment migrate?

A phone system and the office network stand or fall together. For how office networking supports voice traffic, see the office network solution. Where colleagues often use softphones from different spots, the coverage and stability in the Wi-Fi solution also shape call performance directly.

Frequently Asked Questions

Do internal extension calls go through the public telephone network?

No. Extension-to-extension calls on the same IP PBX are handled by internal routing and stay on the internal network. Only calls to numbers outside the company go through the SIP trunk to the public network.

Does moving to an IP PBX mean replacing every phone?

Not necessarily. IP phones connect directly to the network. Legacy analogue phones can join through a gateway or adapter, depending on equipment support and provider arrangements. Audit each device during planning, and do not assume every old device will work.

Can calls still be made during an internet outage?

IP voice needs network and power. During an outage, IP phones on the affected network will be impacted. Response depends on pre-set failover rules, backup lines or mobile network arrangements. Test those arrangements before deployment to confirm they actually work.

Must the other party be told about recording?

Yes, as a matter of principle. Before recording, say that the call is being recorded and state the purpose, set a retention period and access permissions, and delete recordings properly when they expire. Set the detailed arrangements under company policy and applicable requirements, and do not assume notice is unnecessary.

What about 999 emergency calls?

Confirm emergency call connection and location arrangements with the provider before deployment, including how registered addresses are set and updated, whether failover affects emergency calls, and what alternatives apply during a power or internet outage. When calling, state the current location clearly at the start of the call.

免費上門勘查及報價 | 收費指南