Skip to main content
November 3, 2026 · By Piyush Sahoo 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 Indian rules that changed in 2026, each linked to its source.
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 Mumbai-to-Mumbai audio through Virginia lifts one-way delay from about 91 ms to about 257 ms.
  • Your own application becomes part of the call path. On a programmable service, a slow webhook (callback) means silence for the caller.
  • India’s framework changed in 2026. A new enterprise communication authorisation arrived in June, automated-call rules were issued in September, and caller name display was due from 1 November.

​
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. Indian vendors 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. 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:

​
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. 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. 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. 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 Mumbai caller talking to a Mumbai 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 Mumbai with both people in Mumbai totals about 91 ms. Media in Mumbai with the agent in Delhi totals about 97 ms. Media in Virginia with both people in Mumbai totals about 257 ms, past the 150 ms level from ITU-T G.114. Illustrative stacked bar chart of one-way delay. Media in Mumbai with both people in Mumbai totals about 91 ms. Media in Mumbai with the agent in Delhi totals about 97 ms. Media in Virginia with both people in Mumbai totals about 257 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. Mumbai to northern Virginia is about 12,850 km on a great circle, and we assumed routes run 30% longer. The round trip through Virginia therefore covers about 33,400 km and adds about 167 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. 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.

​
How does cloud telephony work in India?

The call flow is the same in India, but the rules around it are denser, and several changed this year. Older articles on the topic can miss all of the 2026 items. Timeline of Indian rules. June 2021: DoT OSP guidelines bar toll bypass, a duty on OSPs. February 2025: TCCCPR Second Amendment, a duty on senders. November 2025: DPDP Rules notified, a duty on data fiduciaries. June 2026: enterprise communication authorisation, a duty on providers. September 2026: TCCCPR Third Amendment issued, a duty on senders. November 2026: CNAP due, a duty on operators. May 2027: DPDP phased window ends by our count, still ahead. Timeline of Indian rules. June 2021: DoT OSP guidelines bar toll bypass, a duty on OSPs. February 2025: TCCCPR Second Amendment, a duty on senders. November 2025: DPDP Rules notified, a duty on data fiduciaries. June 2026: enterprise communication authorisation, a duty on providers. September 2026: TCCCPR Third Amendment issued, a duty on senders. November 2026: CNAP due, a duty on operators. May 2027: DPDP phased window ends by our count, still ahead. These rules change often, and this table is a map rather than legal advice. Confirm the current text for your own case.

​
The enterprise communication authorisation

“Cloud telephony” isn’t the regulator’s term. DoT’s closest category is the enterprise communication service authorisation, under the Telecommunications Act, 2023. The rule-based scope on that portal page lists “cloud-based EPABX service”, and its summary writes “cloud-based EPABX/CPaaS”. The page gives a national service area and a 20-year validity. Khaitan & Co reports that DoT notified the underlying rules on 23 June 2026, and it flags that they don’t spell out each service in detail. We read the portal and that note, not the Gazette text. Three reported conditions matter to a technical buyer:
  • Connectivity. The link between a user and a cloud EPABX can be internet connectivity or a domestic leased circuit from an eligible provider.
  • Tenant separation. The provider must logically partition the parts of its platform that handle different users’ telecom resources, and keep logs of that partitioning for at least two years.
  • Localisation. Data, network-system, and user-information location conditions broadly follow the main authorisation rules.
The portal also says it no longer accepts new applications under the old Telegraph Act, and that existing licensees apply to migrate. Your provider could therefore hold either an older licence or a new authorisation, so ask which covers the service you’re buying.

​
Automated calls under the Third Amendment

TRAI announced the Third Amendment on 18 September 2026. Its text defines an A2P call as a voice call started by an application, software system, or automated platform without direct human dialling, including artificial voice. Autodialled campaigns and outbound AI agents appear to match that wording, so raise it with your provider before launch. Undeclared A2P calls count as unsolicited commercial communication. The regulation also lets a terminating operator charge the originating operator up to ₹0.05 per minute on A2P calls, with an exemption for the 140xx, 1600xx, and 1601xx series. Both provisions start 60 days after Gazette publication. The notification is dated 18 September 2026, so by our count they can’t start before about 17 November 2026. We could not confirm the publication date, so check whether they apply on your launch date.

​
Caller name display

DoT’s circular tells access providers to show a calling name from 1 November 2026. A called user’s saved contact name takes priority. Otherwise, the name comes from the originating operator’s subscriber record. Business and bulk users may be offered a “preferred name”, which must be a registered trade mark or a GST-registered trade name, verified by the operator. The circular defers 2G, 3G, and PSTN networks for later examination, and it doesn’t mention SIP or PRI. Ask your provider how your calls will display, and which name sits on your connection.

​
Toll bypass and OSP status

The 2021 OSP guidelines apply to voice-based business process outsourcing, and they exclude entities outside that activity. If you are an OSP, they shape your cloud design directly:
  • OSPs may take EPABX services from telecom service providers, or place their own EPABX in a third-party data centre in India.
  • An EPABX abroad is allowed, provided you keep CDR and system-log copies at an OSP centre in India.
  • You stay responsible for any toll bypass, including through remote agents.
Khaitan & Co reports a wider reset of telecom authorisation rules in June 2026. We could not confirm whether it changes the OSP position, so check before you design around it.

​
Recordings and personal data

Recording is standard in cloud telephony, and a recording that identifies a person is likely to be personal data. The DPDP Rules were notified in mid-November 2025 with an eighteen-month phased period, which by our count ends in mid-May 2027. They require clear consent notices and let people withdraw consent. That end date could move. MeitY proposed in January 2026 cutting the window to 12 months, and reports differ on whether the cut covers all data fiduciaries or only significant ones. A tracker updated on 9 October 2026 says the change had not been gazetted, and we found no Gazette notice either. Take advice on your notice wording, retention period, and transcripts.

​
What should you ask a cloud telephony provider in India?

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.

​
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

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.
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.
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.
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.
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

Build on Vobiz

Get a number and place your first call.