Where Does a Cloud PBX Live?

What "the cloud" actually is

The word "cloud" sounds abstract, but behind it is something very concrete: powerful computers (servers) sitting in a special building, far from your office. When we say the PBX is in the cloud, we mean that the software that manages the calls — the menus, the queues, the extensions and the recordings — runs on those servers and not on a box of equipment in your closet.

This building is called a data center, and sometimes a "server farm". It is built for one purpose: to keep computers on, connected and protected, around the clock, year after year. For the customer it is invisible — you only see the phone and the control panel.

The term "cloud" itself came from the drawings of network engineers: when they drew a network diagram, they marked the internet — the part that doesn't belong to anyone in particular — as a cloud. Over time the name came to cover any service that runs "out there, on the internet" instead of at your place.

What is inside a data center

A good data center is built on the assumption that anything can break — so everything has a backup:

• Power — two connections to the electric grid, large batteries that hold the servers for the first seconds of an outage, and generators that kick in after them.
• Communications — several internet providers in parallel, on fiber that enters the building from different directions.
• Cooling — servers produce a lot of heat; duplicate air-conditioning systems keep the temperature constant.
• Physical security — identity-checked entry, cameras, guards, locked cabinets.
• Fire suppression — systems that extinguish with gas and not water, so as not to destroy the equipment.
• Staff — people who monitor the building and the equipment around the clock.

For comparison: an equipment closet in an office depends on a single power outlet, a single internet line and the room's air conditioner. If one of them goes down — the PBX goes down. This is one of the main differences between an on-site PBX and a cloud PBX.

How a call gets to the server and back

1. You pick up the handset and dial. The phone turns your voice into data packets (VoIP).
2. The packets go out through the office router to the internet, and reach the PBX server.
3. The PBX decides what to do: connect to another extension, send to a queue, or send the call out to the telephone network.
4. The other party's voice makes the same trip in the opposite direction.

All of this happens in fractions of a second. What determines quality is mainly the path between the office and the server: enough bandwidth, low and stable latency, and a router that doesn't interfere with the SIP protocol. Geographic distance plays a smaller role than it seems — Europe is close enough to Israel for a call to sound natural.

Why deploy in several countries

A serious provider doesn't put all its servers in one building. Deploying in several data centers, in several countries, gives two things:

• Protection from failures — a fire, a regional power outage, a cut undersea cable or a software fault in one center doesn't stop the service. Calls move to other servers. More on this in resilience and redundancy.
• Flexibility under load — when there are many calls at once (for example a nonprofit's fundraising night), the load is divided among several servers.

What moves to the cloud — and what doesn't

When the PBX is in the cloud, the "brain" sits in the data center: the settings, the menus, the recordings, the call log and the connection to the telephone network. Only the "hands" stay in the office: phones, headsets, a switch and a router. This is also what makes it possible to work from anywhere — an agent's phone at home connects to exactly the same server as a phone on a desk in the office.

This has a practical consequence that is easy to miss: there is no longer a "PBX in the office" that you have to get to. Opening a new branch? Connect phones to the internet there. Moving? Take the phones in your hand. A yeshiva that opens a dormitory in another building gets extensions there without running lines between the buildings.

And what about updates? On an on-site PBX, a software update is a project — a technician, a time window, a risk. In the cloud, the servers are updated and maintained by the provider, and you just keep working.

Questions to ask every provider

• Where are the servers? In one country or several? At one site or several?
• What happens when a data center goes down? Is there an automatic switchover, and do the numbers keep working?
• What happens when my office goes down? Where do calls go when you have no power or internet?
• Who backs up the recordings and the settings? And for how long?
• Who do you talk to when there's a problem? An automated answer, a ticket system, or a person?

A common mistake is to look only at the price and the list of features. Two providers can offer exactly the same IVR menu, but the real difference will show on the day something goes wrong — and then it becomes clear who built the infrastructure properly.

What stays the office's responsibility

The cloud solves the servers part, but the network in the office stays yours. Three things make the difference:

• Stable internet — and preferably backup internet for a business whose phone is the heart of its work.
• An orderly network — a good switch, working cables, and sometimes voice prioritization.
• UPS — so the router and the switch don't shut off in a short power outage.

And most important: even when the office is completely down, the cloud PBX keeps working. It just needs to know where to send the calls — and that is something you define in advance.

A short tour inside a data center

Most people will never enter a data center, so here is a description in plain words. From the outside it is a gray building with no big sign and no windows in the halls, usually in an industrial area. At the entrance there is a gate, a guard, and entry with a personal card — sometimes a fingerprint too. A visitor registers in advance, and a staff member accompanies them the whole time.

Inside there are large, cold halls. In each hall there are long rows of metal cabinets more than two meters tall. These are the racks, and in each rack sit dozens of servers — flat metal boxes, one above the other, with no screen and no keyboard. Each server is a powerful computer. From the front you see only blinking lights; from the back, bundles of network and power cables, each one labeled and in order.

The noise is surprising: hundreds of fans working together, and you have to raise your voice to talk. The cold is deliberate, too. The air conditioners push cold air under the raised floor, the air rises through holes in the floor in front of the servers, passes through them, and comes out hot at the back. After each row there is a "hot" aisle followed by a "cold" aisle. This is how a constant temperature is kept without wasting energy.

On another floor or in an adjacent building are the electrical rooms: large panels, battery cabinets that fill an entire room, and outside, generators the size of a truck with fuel tanks for days. Near the entrance there is a control room with screens showing temperature, power consumption, the state of the internet connections and every alert that has been opened. That is where the shift staff sit, even at three in the morning.

The servers of your PBX are a few boxes in a few racks in halls like these. They don't look any different from their neighbors. What makes them special is the software running inside — it is what knows your extensions, your menu and your queue.

How the phone finds the nearest server

The phone in the office doesn't know which building the server sits in, and it doesn't need to. In its settings it gets a name for the PBX — a word-based address, like the name of a website. When it powers on, it asks the internet's naming system (DNS) which address this name leads to, and gets the address of a server. It registers with that server: it announces "I'm extension 204, I'm here", and from that moment calls to it pass through that server.

When there are servers in several countries, a provider can steer the answer so that each phone gets a suitable server — not necessarily the closest one on the map. "Close" on a network is measured in time, not in kilometers: sometimes the route from Israel to a building in London is faster than the route to a building in Athens, because that is how the undersea cables and the connections between providers run. What matters is low and stable latency, and the provider checks that in practice.

If the server the phone is registered with stops answering, the phone tries to register again. This time it gets the address of a different server, and registers with it. The extension "disappears" for a few dozen seconds and then comes back — usually without anyone in the office noticing. The same thing happens on the other side: your numbers are connected to the telephone network through several entry points, not through one server. A call coming from a mobile number enters at the point that is working at that moment.

Example: an hour without one site

Suppose that on a Tuesday at 14:03 a main communications cable near one data center is cut, and for an hour the building cannot be reached from the internet. What happens to a law office in Bnei Brak with twelve extensions, some of which were registered with a server in that building?

• 14:03 — two calls that were in progress through this server are disconnected. The customers dial again within a minute, and the new calls come in through another site. They ring at the office as usual.
• 14:03–14:05 — the phones that were registered with the server that went down find that there is no answer, and register again with another server. In the control panel, on the extensions screen, you can briefly see an extension as unregistered and then registered again — now with another of the provider's servers, as far as the system is concerned.
• 14:05 onward — all calls, incoming and outgoing, work. The menus, queues and routing settings were not affected, because they aren't stored in only one building. The recordings of the calls that were disconnected were saved up to the moment of disconnection.
• 15:10 — the cable is repaired. The servers at the site come back to work and rejoin the rest. The phones keep working with the server they moved to, or gradually move back; nothing needs to be done from the office.

What did the secretary see? At best — nothing. At worst — one call that was cut off in the middle, and a customer who dialed again. That is the difference between a deployment at several sites and a single server: not that there are no faults, but that the fault stays small and local, instead of becoming a whole hour without a phone.

Numbers worth knowing

• Bandwidth per call — one call uses about 100 kilobits per second in each direction with the standard codec, and less with compressed codecs. Ten simultaneous calls are about one megabit — very little compared with a regular internet connection of tens or hundreds of megabits. More on this in bandwidth.
• Travel time to Europe — a data packet from Israel to Western Europe and back usually takes a few dozen milliseconds. The ear starts to notice delay only when it reaches hundreds of milliseconds, so the distance isn't noticeable.
• Calls per server — a single PBX server can handle hundreds of simultaneous calls, and sometimes more. So a jump in load at one customer — a fundraising night, a sales day — isn't felt by its neighbors.
• Electricity — a full server rack consumes as much power as several apartments. This explains why the battery rooms and generators take up such a large part of the building.

These numbers are general orders of magnitude, not a commitment. What they teach: the expensive and complicated part of the PBX — the servers, power, cooling and connections — is shared among many customers, so each of them gets an infrastructure that they would not have built on their own.