The Hard Parts of Hybrid: Seven Challenges and How to Engineer Around Them

A hybrid phone system is two systems joined by a link. Almost everything that goes wrong with one goes wrong at the join, and almost all of it is predictable enough to design out before installation rather than diagnose afterwards.

This is a field guide to the seven problems that actually occur, written from the sort of fault reports that land with a Jamaican provider on a Tuesday morning. Each one comes with what causes it and what the fix looks like — not as a warning against hybrid, but because a business that knows where the hard parts are asks much better questions of whoever is quoting.

Challenge 1: Two Dial Plans That Do Not Agree

What it looks like: extension 205 rings at head office but reaches nobody at the branch. Voicemail behaves differently depending on which side of the system the caller came from. Someone dials 9 for an outside line out of habit and gets an internal department. Two sites both allocated the 200 range years ago and nobody noticed until they were joined.

Why it happens: the on-site PBX has a numbering plan that grew organically over a decade, and the cloud platform has one designed last month. Nobody reconciled them, because reconciling numbering feels like paperwork rather than engineering.

The fix: design one numbering plan for the whole estate before anything is connected, and treat it as the governing document. In practice that means a site prefix — Kingston in the 1xx range, Montego Bay in the 2xx, Mandeville in the 3xx — with reserved blocks for growth, a single consistent rule for reaching an outside line, and one decision about where each user's voicemail actually lives. Renumbering forty extensions during commissioning is a morning's work. Renumbering them eighteen months later, after they have been printed on business cards and stored in customers' phones, is not.

Challenge 2: One-Way Audio and Calls That Drop at Ninety Seconds

What it looks like: the call connects, one side hears the other perfectly, the other hears silence. Or every call terminates at a suspiciously round interval — thirty seconds, ninety seconds, five minutes.

Why it happens: this is the classic signature of SIP meeting network address translation. Signalling and audio take different paths, and the router at the edge is rewriting addresses inside the messages in ways that leave one end sending audio to somewhere that no longer exists. The single most common specific culprit is a feature usually called SIP ALG, enabled by default on a great many business routers, which attempts to help and reliably does the opposite. Timed disconnects usually point at session timers or a firewall closing an idle mapping before the next keepalive.

The fix: disable SIP ALG on the edge router — this alone resolves a large share of these cases. Keep a consistent public path for the trunk, allow the audio port range the provider specifies, and set firewall UDP timeouts long enough to survive between registration refreshes. Where the site's connection makes this fragile, terminating the trunk on a session border element rather than directly on the PBX removes the whole class of problem.

Challenge 3: The Internet Link Is Shared With Everything Else

What it looks like: call quality is fine all morning and turns choppy at 2pm. Someone starts a large upload and three calls degrade at once. Quality is worse on outbound calls than inbound, which puzzles everyone until you look at which direction is constrained.

Why it happens: voice is unusually intolerant of the conditions that other traffic creates. A file transfer is happy to wait; a conversation is not. As a working figure, a single uncompressed concurrent call consumes roughly 85 to 100 kbps in each direction once packet overhead is counted, and the constraint is almost always the upstream, which on many business broadband services is a fraction of the advertised download speed. The targets to design against are the standard ones: under about 150 ms of one-way delay, jitter held to a few tens of milliseconds, and packet loss below one percent. Voice degrades noticeably before any of those thresholds look alarming on a speed test.

The fix: size the upstream against realistic peak concurrency rather than headcount — most offices peak at a quarter to a third of staff on calls simultaneously. Mark voice traffic with DSCP and give it strict priority on the edge device. Where possible, separate voice onto its own VLAN. And measure the link over a working week rather than testing it once on a quiet afternoon, because the problem is the peak, not the average.

Challenge 4: Power, Which Is Not a Networking Problem Until It Is

What it looks like: the generator carries the building through an outage and the phones die anyway. Or the UPS in the comms room is rated for the PBX but the switch feeding power to every desk phone is plugged into an unprotected socket, so the system stays up and every handset goes dark.

Why it happens: a hybrid puts part of your phone system in your building, which means part of its availability is now your electrical problem. In the Caribbean, with hurricane season and the ordinary rhythm of outages, this is not an edge case. UPS batteries also age quietly: a unit that held for forty minutes when installed may hold for eight after four years, and nothing announces this.

The fix: map the whole power chain, not just the obvious box — the PBX, every network switch that carries phone traffic, the switch providing power over Ethernet to handsets, the router and the modem or terminating equipment. All of it needs to be on protected power, or none of it is. Then test the runtime under load annually and replace batteries on a schedule rather than on failure. A generator that starts is worth nothing if the phones drop during the fifteen seconds before it does.

Challenge 5: Failover That Has Never Actually Been Tested

What it looks like: the design document says calls divert to mobiles when the trunk drops. The link drops for real and callers get a ring tone into nothing for eleven minutes before anyone realises. The failover was configured, then a number changed, and nobody re-checked.

Why it happens: failover is the one feature that is invisible when it works and is therefore never exercised. Detection timing is also routinely misunderstood: a system will not fail over instantly, it fails over once registration or keepalive timers expire, and if those are set conservatively that is minutes of dead air, not seconds.

The fix: write the failover behaviour down as a set of specific outcomes — after this many seconds, inbound calls to this number go to that mobile, then to message capture — and test it by physically unplugging the link, at least twice a year, during business hours. Check the detection timers actually match the outcome you promised. Where the site justifies it, a mobile broadband backup path gives the trunk somewhere to fail over to, which is worth considering given how well 4G coverage holds up across the island relative to fixed lines. And make sure someone is alerted when a failover happens, because an outage nobody notices is an outage nobody fixes.

Challenge 6: Toll Fraud, Which Arrives Faster Than People Expect

What it looks like: a bill with several thousand dollars of international calls to destinations the business has never contacted, all placed between Friday evening and Sunday morning, all from one extension.

Why it happens: a phone system reachable from the internet is scanned continuously by automated tooling, typically within hours of appearing. The way in is nearly always mundane: an extension whose password is the extension number, a default administrative credential never changed, or a voicemail box configured to allow outbound dialling. Attacks are deliberately timed for when nobody is looking at the bill, and the losses are usually real charges for real terminated calls.

The fix: this one is entirely preventable with unglamorous discipline. Restrict trunk access to known addresses so unregistered sources cannot originate calls at all. Bar international dialling by default and enable it per extension for the people who genuinely need it. Use long random secrets for every extension, never the extension number. Set a hard spend ceiling and an alert threshold on the account. Turn off call-through from voicemail unless it is a documented requirement. Above all, insist on out-of-hours anomaly alerting from your provider — the difference between a fraud incident and a fraud disaster is measured in hours.

Challenge 7: The Support Boundary

What it looks like: intermittent audio problems on branch calls. The PBX maintainer examines the on-site system, finds nothing, and points at the trunk. The trunk provider examines their side, finds nothing, and points at the PBX. Two weeks pass. The fault, when eventually found, was a firewall rule at the seam that belonged to neither party's mental model of the system.

Why it happens: a hybrid has a boundary in the middle by definition, and if the commercial arrangement also has a boundary in the same place, faults that live exactly there have nobody obviously responsible for them. Both parties are usually acting in good faith; neither has visibility of both sides.

The fix: this is a procurement decision rather than a technical one. Buy the trunk, the cloud platform and responsibility for the on-site configuration from a single provider who can see both ends of the call and has no counterparty to defer to. If splitting is unavoidable, put in writing which party owns the seam, agree a joint diagnostic procedure before you need it, and make sure both can be on the same call.

WOCOM is a licensed Jamaican carrier operating its own voice network, which is why we take that whole chain — network, trunk, cloud platform and the configuration at your end — as one accountable scope. The architecture is set out on our hybrid phone service page.

One More: The Feature Ceiling

Not a fault so much as a slow disappointment. Cloud platforms gain capabilities continuously; an on-site PBX does what it did on the day it was commissioned. In a hybrid, anything the local system cannot do must be handled on the cloud side or not at all, and a few things — consistent call recording across both halves, a single reporting view, presence that reflects both — need deliberate design rather than arriving for free.

The remedy is to decide explicitly which side owns which capability, and to put anything fast-moving on the cloud side where it can keep improving. Left undecided, a hybrid drifts toward the lowest common denominator of its two halves, which is precisely the outcome nobody bought it for.

FAQ

What causes one-way audio on a hybrid phone system?

Almost always network address translation handling at the site edge. Signalling and audio take separate paths, and a router rewriting addresses inside SIP messages can leave audio being sent to an address that is no longer valid in one direction. The most frequent single cause is the SIP ALG feature enabled by default on many business routers; disabling it resolves a large proportion of cases, with firewall port and timeout settings accounting for most of the rest.

How much internet bandwidth does a hybrid phone system need?

Budget roughly 85 to 100 kbps in each direction per simultaneous call for standard uncompressed voice, and size against peak concurrency rather than staff count — most offices peak at a quarter to a third of employees on calls at once. Upstream capacity is usually the binding constraint. Note that internal desk-to-desk calls run over your own network and consume no internet bandwidth at all, which is one of the practical advantages of keeping the local system.

How do I protect a hybrid phone system from toll fraud?

Restrict trunk access to known IP addresses, bar international dialling by default and enable it only per extension where needed, use long random passwords for every extension rather than the extension number, disable outbound dialling from voicemail, and set a hard spend limit with alerting. Attacks are automated and typically launched outside business hours, so out-of-hours anomaly alerting from your provider is the control that limits the size of an incident.

What happens to a hybrid system during a power cut?

Only what your power design allows. The on-site PBX, every network switch carrying voice traffic, the switch powering the desk phones, and the router all need protected power — if any link in that chain is unprotected, the phones go down regardless of the others. UPS batteries also degrade substantially over a few years, so runtime should be tested under load annually rather than assumed from the original rating.

How often should hybrid failover be tested?

At least twice a year, by physically disconnecting the link during business hours and confirming that calls land where the design says they should, within the time the design says they should. Failover is invisible when it works, so it is the feature most likely to have been quietly broken by an unrelated change months earlier.

Ask Whoever Is Quoting You About These Seven

None of these problems are reasons to avoid a hybrid phone system. They are the questions that separate a design from a price list. Numbering plan, NAT handling, upstream capacity, power chain, tested failover, fraud controls, and who owns the seam — a provider who has answers to all seven has built one before.

WOCOM will walk your site, size the link, design the numbering and take responsibility for the whole chain. Call 876-906-7240 or visit wocomja.com/contact.