Cloud telephony architecture: how a call travels from carrier to desk

The old phone system still runs, but the contract on its access line ends next quarter. IT is planning the move to cloud telephony. Reception wants to know whether the numbers will keep ringing, and facilities is asking about the lift phone and the intruder alarm.

This guide is for the integrators and IT teams who run that project. Cloud telephony architecture covers every hop a call depends on between the caller and the desk, so the work reaches well past the box on the wall. For a small company, a mid-sized firm or a multi-site organisation, one question settles the design: who keeps calls flowing when an access line, a carrier or a router fails?

What cloud telephony architecture is

Cloud telephony architecture is the set of transport, security and voice components that carries a call between your sites, the public telephone network and a hosted PBX. It sits between each building's internet access and the central services that set up, route and record calls.

Picture the fibre into the building as a local road. The transport network is the motorway system with its junctions, and the hosted PBX is the destination. A fast local road tells you nothing about a closed motorway further along.

Transport and telephony functions

The PBX (private branch exchange) applies your call rules. In a cloud setup it runs in a data centre, and your office keeps only the phones. Routers forward packets, the small units of data that cross the network. Each component below plays its part in the same call, and they often come from different suppliers.

Components of a cloud telephony architecture and what failure looks like

MPLS (Multiprotocol Label Switching) is an IP transport that steers traffic with labels. TDM (time-division multiplexing) is the older technique that shares a circuit by slicing it in time. The SBC guards and organises traffic where your network meets someone else's.

Knowing the path lets you hand each check to the party that owns it, whether that's the platform provider, the carrier or the site integrator.

How a call travels through the architecture

Every call runs on two separate exchanges. SIP (Session Initiation Protocol) signalling sets the call up and tears it down, and RTP (Real-time Transport Protocol) carries the voice. In air-traffic terms, SIP is the control tower and RTP is the aircraft with the passengers on board.

Take a fictional accountancy firm with three offices. A client calls the northern office first thing in the morning. The call enters the public network, and the carrier hands the request to the firm's phone service. Nobody at the northern office is talking yet.

From INVITE to conversation

1. A SIP message called INVITE asks to set up the call. On an outbound call, the INVITE leaves the IP desk phone or the softphone, the calling app on a computer or mobile.

2. The SBC checks the exchange. It applies security rules and network address translation (NAT), which lets devices on a private network talk to the outside world.

3. The PBX picks the destination. It applies opening hours and the greeting, runs the interactive voice response (IVR) menu, then hands the call to the queue and the target extension.

4. Once someone answers, RTP streams carry the audio along the negotiated path. That path can differ from the one the signalling took.

5. A BYE message ends the session. A call detail record (CDR) can keep the technical facts of the call, and it holds no audio.

On an outbound call the platform also selects a SIP trunk, the logical connection between the PBX and a telephone carrier. Our SIP trunk guide explains how trunks are set up and billed.

One call, several checkpoints

TLS (Transport Layer Security) encrypts the signalling wherever it's configured between two devices. It says nothing about whether the audio can cross the firewall or whether the access has enough capacity.

That split shapes diagnosis. A phone that rings with no audio points at the RTP path, NAT or the firewall. A call rejected before it rings points at authentication, routing rules or the carrier interconnect.

Redundancy after the copper switch-off

Carriers across Europe and in the UK are retiring their copper telephone networks on published timetables. Fibre takes over the access, and every other dependency of the phone service is still there. A power cut or a bad configuration still takes reception offline. The migration therefore has to cover how each site uses its phone lines, down to the lift.

A fallback for each dependency

A typical design pairs a main fibre access with a mobile backup. Automatic failover has to detect lost service, and a cable that's still plugged in proves nothing about that. Trunk availability and the route to the platform each need their own check.

Common failures and their fallbacks

Shared dependencies undo redundancy. Two accesses on one power feed or one router fail together, and the PBX high availability guide shows how to find and test them.

A fallback counts as tested once your team has caused the failure and watched the expected result happen.

Lifts, alarms and other quiet services

Your inventory has to list lift phones, alarms, payment terminals and any remaining analogue lines. Each one needs its own decision to adapt it, replace it or keep it on a compatible service for a while.

Mobile backup has its own timetable. Operators are switching off 2G and 3G networks, so check which radio technology each device uses. A mobile backup needs confirmed compatibility, coverage and power before it can carry a site for years.

Prioritising voice on the network

Call quality depends on latency, jitter and packet loss. Latency is the transit delay. Jitter is the variation in that delay, and packet loss means some voice fragments never arrive.

A speed test measures volume. Audio needs packets that arrive on time and in order, so a fast access can still deliver broken calls. Measure the three values during normal working hours and compare them with the documented requirements of the platform you've chosen. The VoIP call quality guide covers what to measure and how to fix each problem.

Explicit priority with QoS and DSCP

Quality of service (QoS) decides which traffic goes first when several uses compete for the same capacity. It adds no bandwidth and repairs no faulty access. It works only on the devices that actually control the queue, usually your edge router.

DSCP (Differentiated Services Code Point) is a marking each packet carries to show its treatment class. The values below are a policy to agree with your carrier and provider. Routers on the public internet may ignore them.

DSCP marking and indicative bandwidth by traffic type

Some networks mark SIP signalling CS3 and others CS5. RFC 4594 on DiffServ service classes gives you a shared reference when you agree the policy.

The codec turns voice into digital data. It sets the base bit rate, and your sizing has to add the packet headers that carry and protect that data.

Sizing for concurrent calls

• Measure upload traffic. A backup job or a large file upload competes with calls on the edge router.

• Count simultaneous conversations. Capacity depends on active calls, and the number of installed phones only sets the ceiling.

• Add overhead. The codec's payload rate is a fraction of what crosses the wire.

• Keep headroom. Video and business applications have to fit alongside the capacity reserved for voice.

The decisive test generates representative load while test calls run. Watch the router queues, the markings on outgoing packets and the behaviour of the backup access. A marking that shows in the config and is missing from the packets on the wire protects no call.

Security and European Union hosting

Phone security combines user authentication, encrypted signalling, call authentication and key protection. STIR/SHAKEN is a framework that signs the caller's identity, and carriers decide whether and how they deploy it. A valid signature confirms the number presented. Judging whether the caller's message is honest stays with your team.

Protecting traffic and access

• Encrypted signalling. SIP over TLS encrypts the signalling between the devices that support it.

• Separated secrets. Credentials and keys sit in controlled stores, with access rights that match each role.

• Traceable events. Logging lets you reconstruct an access attempt or a configuration change.

• Prepared revocation. A compromised account comes down within minutes because its owner and the steps are already written down.

Voxbi is a cloud PBX built and hosted in the European Union, so your calls and data stay within European Union borders. AI call summaries come with every Voxbi One plan, and Voxbi Plus AI transcribes every call.

What European Union hosting changes

The GDPR (General Data Protection Regulation) allows transfers outside the European Union under set conditions. Chapter V of the regulation provides the tools, mainly adequacy decisions, standard contractual clauses and binding corporate rules.

Since the Schrems II ruling, the exporter also has to assess the destination country's laws and add safeguards where they fall short. When no safeguard is enough, the transfer can't go ahead.

Hosting in the European Union shrinks the set of transfers you need to assess. Compliance still rests on knowing who has maintenance access, where backups live and which subprocessors handle the data, because obligations follow every onward transfer.

Who runs what: platform, site and carrier

Your operations file should spell out the split. The provider configures and runs the hosted service under its contract. The integrator and the client own the local conditions that let people use it, and the carrier delivers the access and routing it's been contracted for.

A feature in the PBX says nothing about whether the site network is ready. A well-sized access, in turn, can't fix a bad call-distribution rule.

On the platform side

• Administration in Voxbi Cockpit. You manage users, extensions, queues, IVR menus and closing schedules from the web interface.

• Live call dashboards. They show volumes and queue states, so you can tell an overloaded team from a technical fault. They come with Voxbi Plus and up on Voxbi One, and with Voxbi Business and up on Voxbi Managed.

• Business integrations. Odoo and Microsoft 365 are included from Voxbi Plus, and Microsoft Teams costs €50 a month extra. On Voxbi Managed, from Voxbi Professional up, Odoo costs €29.50 a month and Teams €72.50 a month, each priced per phone system.

• API. Applications can start calls and sync call data through the API, included from Voxbi Plus on Voxbi One and from Voxbi Professional on Voxbi Managed.

• Number porting. Inbound porting is supported from Voxbi Starter up, and the move with your current provider is handled for you. Agree the date with that provider and everyone affected.

On the site and integrator side

• Working connectivity. Main and backup accesses are configured, monitored and tested.

• Owned equipment. Routers, traffic priority, firewalls and backup power each have a named owner on site.

• Checked compatibility. Existing devices and their uses are listed before any line is cancelled.

• Organised operations. Carrier contracts, escalation contacts, failover tests and rollback steps stay where the on-call team can find them.

The SIP trunk, where all three meet

The SIP trunk and its backup route are where platform, carrier and site meet. Your file should say who detects an incident, who switches the route and who confirms service is back.

Changes follow the same rule. A firewall change, a new access or an edit to the dial plan should trigger the matching tests. A configuration that passed at installation can drift out of shape after one local intervention.

Diagnosing a degraded call

Choppy or robotic audio at a single site gives you a good place to start. Back at the accountancy firm, the northern office's auto attendant answers normally, but external conversations break up. The integrator measures that office's access first and leaves the desk phones alone.

The list of circuits and routers shows what the affected calls have in common. That narrows the investigation to one stretch of the path.

Symptoms, likely causes and first checks

Test one hypothesis at a time

Each row is a starting hypothesis. Delay and echo can come from different causes, so check the hypothesis against a measurement or a trace before you change anything. A practical order is the access first, then the markings, then the signalling.

• Keep the context. The ticket records the site, the call direction and who was involved, within your data access rules.

• Change one thing. A single change shows whether the hypothesis held.

• Attach the evidence. Measurements, traces and the identified route let the provider or carrier pick up the analysis.

Evidence of this kind ends the back-and-forth that starts when one side points at a speed test and the other at a phone showing as connected.

Checklist before cutover

Before you switch off the old service, check that every use works and every responsibility has an owner. A phone that rings may still fail to transfer a call, and a safety device may still fail to reach its destination. A pilot at a low-risk site proves the scenarios before you roll them out. The people side of the move is in our cloud PBX migration guide.

For each check, record the expected result, the observed result and the owner of any open issue. Take measurements across a representative period, peak hours included, because an empty office carries none of the usual load.

Checks before go-live

• Full inventory. Circuits, routers, power supplies, trunks and dependent devices are listed for every site.

• Working backup. Critical sites keep reception, alarms, lifts and payment terminals running on the backup.

• Verified priority. DSCP markings and queue handling are confirmed on every exit.

• Recorded measurements. Latency, jitter and loss are logged during busy periods.

• Tested exchanges. Signalling and audio both work on a real phone.

• Rehearsed failover. The switch to backup and the return to normal are documented and carried out.

• Documented contracts. The voice carrier, commitments, subprocessors and the European Union location of the data are on file.

• Reception signed off. Queues, IVR menus and closing schedules are tested in Voxbi Cockpit.

Sign-off belongs to the named leads at the client, the integrator and the provider. Clear any open issue on emergency calls or safety equipment before the cutover, and keep a rollback path within the technical and contractual limits you've agreed. To have your current setup reviewed before the move, write to hello@voxbi.com with your list of circuits, dependent devices and carrier contracts.