Skip to main content
Hashnode
Piyush Sahoo

What Is Cloud Telephony? How It Works and the Rules That Apply

One call through the stack, the products sold under the name, media location and the rules that apply

Updated 17 min readMarkdown
P
Piyush Sahoo
Part of seriesVoice & Telephony Fundamentals
What Is Cloud Telephony? How It Works and the Rules That Apply

A reference on cloud telephony: how a call flows through a provider's stack, how the product models differ, how media location affects delay, and the rules that apply, each linked to its source.

Cloud telephony is a business phone service whose switching, call logic, and media processing run on a provider's servers instead of hardware at your site. Calls still reach ordinary phones through telecom operators. You manage everything through a console or API, and you pay by usage or per seat rather than buying a PBX.

This guide follows one call through the stack, separates the products sold under this name, works out what media location does to delay, and maps the rules that apply, each linked to its source.

Note: Key takeaways

  • Cloud telephony moves the switch, not the phone network. Your calls still cross operator networks, so numbers, caller ID, and telecom rules all still apply.
  • The name covers several products. Hosted PBX, contact centre software, voice APIs, and SIP trunks leave very different work with your team.
  • Media location sets delay. In our illustrative example, sending Frankfurt-to-Frankfurt audio through Virginia lifts one-way delay from about 91 ms to about 175 ms.
  • Your own application becomes part of the call path. On a programmable service, a slow webhook (callback) means silence for the caller.
  • Telecom rules still apply. Authorisation, number series, automated-call rules, and data laws vary by country, and several changed in 2026.

What is cloud telephony?

Cloud telephony means renting the brain of a phone system as a service. The provider runs the software that decides where each call goes, and you reach that software through a browser or an API.

Something else stays exactly as it was. A customer calling your number from a mobile phone still uses their operator's network, and the provider connects to that network at its edge. Only the part that used to sit in your server room has moved.

The term is loose, and sources use it differently. TechTarget files it under unified communications as a service and separates shared multi-tenant platforms from dedicated hosted setups. Vendors in markets such as India often frame it around virtual numbers, call flows, APIs, and a dashboard. Both are describing real products, so ask which one a vendor means before you compare prices.

How does a cloud telephony call work?

Every call runs on two separate tracks. SIP and your application decide what should happen, and RTP carries the sound. The diagram follows one inbound call, and the steps below match its numbers.

Diagram of one inbound call. Signalling runs from the caller through the operator network to the provider's edge and call control, which exchanges instructions with your application. Audio runs separately from the operator through a media server to an agent or AI. After the call, a call record goes to your application as a hangup webhook.
  1. The caller dials your number. Your DID routes to the provider, so the operator network hands the call to the provider's interconnect.
  2. The edge admits it. A session border controller sits between the outside network and the provider's core. RFC 5853 catalogues the jobs these devices do, including topology hiding and NAT traversal.
  3. Call control decides. It looks up what your number should do. A hosted product runs a flow you built in its dashboard. A programmable service sends a webhook (callback) to your server and waits for instructions.
  4. The media server handles audio. It plays prompts, collects keypresses, records, and can copy audio to another system.
  5. A second leg connects the other party. That can be a mobile number, a softphone, a browser, or an AI agent. Each adds a call leg with its own state.
  6. The call ends and leaves a record. The provider writes a call record with duration, hangup cause, and quality data, and then notifies your application.

An outbound call runs the same stack in reverse: your API request or dialler starts at call control, and the operator network delivers the call last.

What this design adds to your failure list

A PBX in your building fails in familiar ways. A cloud stack adds an HTTP dependency and a longer audio path, so each stage has its own signature:

Stage Depends on What the caller notices when it fails
Operator to provider Interconnect and number routing The call never connects, or the caller hears a network message
Provider to your application Your server's reachability and response time Silence after answer, or the call drops
Media path Packet loss, jitter, and distance Clipped words, one-way audio, or people talking over each other
Agent leg The agent's network or mobile coverage The caller waits, or the transfer fails
Capacity Concurrent-call and calls-per-second limits A busy tone, or a campaign that runs slowly

Which products count as cloud telephony?

Four product families use the label, and each one divides the work differently. The first column in this matrix is the on-site PBX they replace or connect to.

Matrix of five models against five layers. On-site PBX: you run everything except PSTN access. SIP trunk with your PBX: the provider supplies PSTN access, you run switching, logic, and the agent interface, and you set capacity. Hosted PBX and contact centre: the provider runs everything and you set call logic. Voice API: the provider runs access, switching, and capacity, while you run call logic and the agent interface.
  • Hosted PBX (UCaaS) replaces office extensions, usually with desk phones or softphone apps, and often bundles chat and video.
  • Contact centre software (CCaaS) adds queues, agent desktops, supervisor views, and reporting, so your team can start without building anything.
  • A voice API (CPaaS) gives you numbers, call control, and media as building blocks. You write the logic and the interface.
  • SIP trunking supplies only the carrier connection. Your PBX or AI stack stays in charge of the call.

The billing model tends to follow the split. Retell's guide describes per-user monthly subscriptions, while other services bill pay-as-you-go. As a rule of thumb, seat pricing grows with headcount and usage pricing grows with minutes, so model both against your own traffic.

How does cloud telephony differ from VoIP, PBX, SIP, and IVR?

These terms get compared as rivals, yet they answer different questions. Cloud telephony describes where the system runs, and the others describe a technology, a function, or a feature.

Term What kind of thing it is How it relates to cloud telephony
VoIP A way to carry voice as IP packets Almost always used inside it, though VoIP can also run on-site
SIP A signalling protocol One common way to set up its calls
SIP trunk A carrier connection One of the products sold under the label
PBX The function of switching calls inside an organisation Runs at your site, or in the cloud as a hosted PBX
IVR A menu feature on a call A feature that usually runs on the provider's media servers
Cloud telephony A delivery model The umbrella over the products above

So "VoIP or cloud telephony?" is rarely the real choice. The useful question is which layers you want to run yourself.

Which cloud telephony model should you choose?

Start from what you already own and who drives the calls. The map below handles most cases in three questions.

Decision map. If you are keeping a PBX you already run, choose a SIP trunk. Otherwise, if software or an AI agent drives the calls, choose a voice API, or a SIP trunk if your AI stack speaks SIP. Otherwise, if agents need queues and a ready-made desktop now, choose contact centre software. Otherwise choose a hosted PBX.

Three situations deserve a second look:

  • You need a contact centre with unusual routing. Ready-made software suits standard flows. Once your routing depends on your own data, a custom contact centre on an API may fit better, at the cost of building the agent interface.
  • You are building voice AI. Your AI platform often decides this for you. SIP or WebSocket streaming each suit different stacks, so check what your platform supports first.
  • You are migrating in stages. Some organisations run hybrid setups during a longer cloud migration. A SIP trunk lets you keep a PBX while you move teams across one at a time.

Where should the media run?

Distance matters more on a phone call than on most web traffic, because neither person can wait for a retransmission. ITU-T G.114, a 2003 Recommendation still listed as in force, says most applications get essentially transparent interactivity below 150 ms of one-way delay. It treats 400 ms as the ceiling for general network planning.

Consider a Frankfurt caller talking to a Frankfurt agent. Both legs of that call meet at the media server, so its location sets the path length.

Illustrative stacked bar chart of one-way delay. Media in Frankfurt with both people in Frankfurt totals about 91 ms. Media in Frankfurt with the agent in Paris totals about 93 ms. Media in Virginia with both people in Frankfurt totals about 175 ms, past the 150 ms level from ITU-T G.114.

Only the distance segment is calculated. G.114 gives a planning figure of 5 µs per km for optical fibre. Frankfurt to northern Virginia is about 6,550 km on a great circle, and we assumed routes run 30% longer. The round trip through Virginia therefore covers about 17,000 km and adds about 85 ms. The other segments are round assumptions, so measure your own path before you rely on these totals.

Choosing how agents connect

Agents don't all need the internet. Reaching them over the phone network moves the dependency from your office link to mobile coverage.

Agent connection Network it depends on Best when Watch for
Mobile number over PSTN The agent's mobile coverage Field teams and work from home A second call leg on every conversation, and less control over the handset
SIP softphone or desk phone Your office or home broadband Fixed teams with a managed network Firewall rules and NAT
Browser over WebRTC The agent's broadband Click-to-call inside your CRM Headsets, browser permissions, and Wi-Fi quality
AI agent over SIP or a stream The link between provider and your AI stack Automated conversations AI processing time adds to the network delay above

TRAI's February 2025 numbering recommendations put a SIP call at about 87 kbps with G.711 and 32 kbps with G.729. At those rates, 40 softphone agents on calls at once need about 3.5 Mbps with G.711 or 1.3 Mbps with G.729, by our arithmetic. Budget that in each direction, and leave headroom.

Sizing capacity

Cloud telephony removes hardware limits, but contractual ones remain. Two numbers cap you: concurrent calls and calls per second. Our SIP trunking guide works through the Erlang B math for inbound lines and the rate calculation for diallers, and both apply to any model here.

What rules apply to cloud telephony?

The call flow is the same everywhere, but the rules around it vary by country, and they change often. Check these points for each market you call:

  • Provider authorisation. Many countries license who may sell hosted voice. India, for example, lists cloud-based EPABX under its enterprise communication service authorisation.
  • Number series and telemarketing. Some regulators reserve series by call type. If you're in India, promotions use 140xx and regulated service calls use 1600xx (TRAI, July 2026).
  • Automated calls. Rules such as the US TCPA cover calls started by software. India's Third Amendment adds an advance declaration of application-initiated calls.
  • Where the media runs. Some countries restrict carrying domestic calls abroad or between networks. India's OSP guidelines treat some of this as toll bypass.
  • Recordings and personal data. Privacy laws such as the EU's GDPR, or India's DPDP Rules, set notice and retention duties.

Confirm the current text and take legal advice for your case.

What should you ask a cloud telephony provider?

Feature lists look alike across vendors, so these questions test the parts that are harder to change later. Skip any that don't match your model.

Question Why it matters
Which authorisation or licence covers the service you're selling me? Your supply chain depends on it, and the framework is mid-migration
Where does media run on calls in each country I serve? It sets delay, and it can decide whether a call is allowed
How do I declare A2P use, and who records it? Undeclared calls count as unsolicited once the rule starts
Which number series do I get for each call type? The wrong series is a compliance problem, not only a routing one
What name will my calls display? Caller name display now depends on subscriber records
What happens when my webhook fails or times out? This decides whether a bad deploy drops live calls
Do I get MOS, jitter, and packet loss for each call? You can't fix quality that you can't see
How are concurrency and CPS sold, and what happens at the limit? Callers hear busy tones at the ceiling
Where do recordings live, and for how long? It feeds your retention and consent decisions

How Vobiz handles cloud telephony

Vobiz is a programmable voice platform, so it sits in the voice API and SIP trunking columns of the matrix above. You build the logic and connect the systems you already use.

Test calls and capacity purchases are billed to your account. Run them with your own credentials, and confirm numbers and quantities first.

Frequently asked questions

What is cloud telephony in simple words?

It is a business phone system that a provider runs for you on its own servers. You get numbers, call routing, recording, and reports through a browser or API. Customers still call you on normal phone numbers, and you buy no PBX hardware.

Is cloud telephony the same as VoIP?

No. VoIP is the method of carrying voice as IP packets. Cloud telephony is a way of delivering a phone system, with the provider running it. Most cloud telephony uses VoIP inside, but VoIP can also run on equipment at your own site.

Yes, in most countries, when providers hold the right authorisation and you follow the calling rules. In India, for example, DoT lists cloud-based EPABX under its enterprise communication service authorisation, and TRAI's rules govern number series, consent, and automated calls. Check the current text and take legal advice for your case.

Do I need internet for cloud telephony?

Not always at the agent's end. An agent can take calls on a mobile number over the phone network, with no office data link involved. Softphones and browser calling do need stable broadband. Your application servers also need reliable internet to answer webhooks.

How does cloud telephony differ from a cloud PBX?

A cloud PBX is one product within cloud telephony. It focuses on office extensions and internal calling. Cloud telephony also covers contact centre software, voice APIs, and SIP trunks, which suit customer calling, software-driven calls, and existing phone systems.

Can cloud telephony connect to AI voice agents?

Yes. An AI agent usually joins a call over a SIP trunk or a real-time audio stream over WebSocket. Your AI platform often decides which one to use. In India, automated outbound calls appear to match TRAI's A2P wording, so check that with your provider.

Further reading on Vobiz

Sources

Indian regulators and government

Legal commentary

Standards

Other guides we read

For voice AI agents that live in the cloud, Vobiz is AI-native cloud telephony: SIP trunks, numbers and a voice API.

About the author

  • Piyush Sahoo
    I'm a Founding Member at Vobiz, telephony for AI voice agents. I write about where voice agents meet the phone network: SIP, phone numbers, latency, echo, barge-in and everything that breaks on real calls but not in browser demos. More at piyushsahoo.me

Comments

Join the discussion

No comments yet. Be the first to comment.

Voice & Telephony Fundamentals

Part 2 of 5
Up nextWhat Is Answering Machine Detection? Errors, Tuning and RulesHow AMD classifies who picked up an outbound call, which errors cost most, how to test it on your traffic, and how dialler rules count its mistakes.

More from this blog