SIP trunking explained for Indian businesses

A SIP trunk is a connection between your phone system and a telecom carrier that carries calls over an IP link instead of a copper circuit or a SIM card. The carrier keeps your phone numbers and its connection to the public network. Each call reaches your system as SIP signalling (who is calling, ringing, answered, hung up) plus a separate stream of audio. For an AI voice agent, a trunk is how software gets a real phone line: it is how the agent answers the number on your hoarding, and how it calls a new lead back.

This guide covers what a trunk is, how it compares with PRI lines and mobile SIMs, how a voice agent actually connects through one, and the failures we have hit connecting real Indian numbers.

What a SIP trunk is

SIP, the Session Initiation Protocol, is defined in RFC 3261 (June 2002) as "an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants." On a phone call, SIP sets the call up and tears it down. It does not carry the voice.

So every call over a trunk has two halves:

• Signalling. An INVITE when a call arrives or when you want to place one, responses such as 180 Ringing or 486 Busy Here, and a BYE when someone hangs up.
• Media. The audio itself, sent as a stream of small packets in each direction, on ports agreed while the call is being set up.

The two halves travel separately, and often between different addresses. That one detail has caused more failed connections for us than anything else, and we come back to it below.

"Trunk" is the old telephone word for a shared line that carries many calls at once. Each simultaneous call uses one channel. The numbers people dial, a DID number or a virtual number, are attached to the trunk by the carrier. One trunk can serve several numbers, and a number can move to a new trunk without the public noticing. That is the core of SIP trunking: numbers and capacity become configuration, not cabling.

SIP trunk vs PRI vs mobile SIMs

Indian businesses usually meet three ways of connecting calls. They differ in how capacity grows and in what they are fit for.

A PRI suits an office switchboard that has been in place for years. It is dependable, and it is tied to a building.

SIMs are tempting because they are quick to set up. They are the wrong tool for a sales team calling leads. TRAI's February 2025 amendments to the TCCCPR (PDF), opens in a new tab restrict senders from using ordinary 10-digit numbers for telemarketing, so that commercial calls originate from designated number series. Promotional calls belong on the 140 series, which we cover in DID and virtual numbers in India.

A SIP trunk is what software wants. Capacity is a setting rather than a cable, and the system answering the calls can sit in a data centre rather than your office. The price is that everything depends on the network path and on configuration that fails quietly.

The regulator is watching this route as well. In its recommendations on revising the National Numbering Plan (6 February 2025) (PDF), opens in a new tab, TRAI noted that operators have allotted numbers to SIP and PRI customers without clear guidelines, and flagged the risk of those numbers being misused for unsolicited commercial calls. Expect number allocation on trunks to get stricter, not looser.

How a voice agent connects through a trunk

Four pieces sit between a buyer's phone and the agent's reply.

1. The carrier. It owns the number, connects to the other operators and sends each inbound call to your gateway. On an outbound call it takes your request and places the call onto the public network.
2. The SIP gateway. Software on a server you control. It accepts the carrier's INVITE, agrees the audio format and turns the phone call into a live session the agent can join.
3. The media path. Audio flows both ways for the length of the call. Every hop adds delay, and delay is what makes a conversation feel wrong. See voice latency and our post on voice AI latency.
4. The agent. It listens, decides what to say and speaks. When the call ends it writes what it learned into the CRM: budget, configuration, locality, timeline, a summary, the transcript and the recording.

On an outbound call the chain runs the other way. The dialler asks the gateway to place a call, the gateway sends an INVITE to the carrier, and the carrier rings the buyer. The number has to leave in exactly the form the carrier routes on. With our carrier that is a routing prefix, then the country code, then the number, with no plus sign: the plus is notation for people, not something to dial. Anything else is rejected at the carrier's switch, which looks from our side like a call that simply failed, with nothing in our own logs to explain it.

Inbound and outbound trunks

A trunk can carry calls in both directions, but the two directions are configured, secured and regulated differently.

Inbound

The carrier sends an INVITE for your number to your gateway. Two things must be right. The gateway has to accept signalling from the addresses the carrier uses for inbound calls. And it has to recognise the number in the exact form the carrier presents it: with or without the country code, with or without a leading plus. Get either wrong and callers hear a ring that never connects.

Outbound

Your gateway sends INVITEs to the carrier, authenticated by address or by credentials, and presents a caller ID the carrier lets you use. For promotional calls in India that caller ID should be a 140-series number, and the calls sit inside the DLT registration, consent and preference rules that apply to any commercial call. TRAI's September 2026 amendments to the TCCCPR (PDF), opens in a new tab add one more step: any sender using automated calls must declare them to its operator in advance, with the numbers they will come from.

The business side of the two directions, with different scripts and different obligations, is in inbound vs outbound AI calling.

One trap applies to both. A carrier does not have to send inbound calls from the same addresses it accepts outbound calls on, and its audio may come from different addresses again. Assuming they match has broken one of our own deployments.

What can go wrong

Almost every failure at this layer is silent or misleading. A gateway reports healthy while doing nothing; a firewall reports a rule added while the port stays open. Most of these are failures we have hit ourselves; two are failures we designed around.

The flood that was not an attack

Inbound calls began declining instantly, and the gateway logged a flood of 486 Busy Here responses. RFC 3261 defines 486 as the callee being "currently not willing or able to take additional calls", and a public SIP port attracts constant scanner traffic, so it looked like an attack. It was not. The trunk held the number in one format and the carrier was presenting it in another, so the gateway had no route for any real call. Tightening the firewall on the attack theory made things worse, because it was narrowed to addresses the carrier used only for outbound calls. The fix was one line: match the number exactly as the carrier presents it.

The firewall rule that did not do what it said

Adding "allow SIP from the carrier" does not revoke an older "allow SIP from anywhere". Both rules match, the port stays open to the internet, and the rule list looks right at a glance. Delete the wide rule first, then add the narrow one, and check the list for what is absent. A second trap: some firewalls accept new rules while switched off, so a server can carry a complete, correct-looking rule set with every port open. An exposed SIP port is found by scanners within hours.

Audio that only goes one way

Two services on one server handing out media ports from overlapping ranges will eventually pick the same port. The symptom is a call where one side cannot hear the other, which nobody can reproduce. We give the gateway's audio its own port range for exactly this reason, and open that range only to the carrier's media addresses.

The health check that lied

A gateway was marked unhealthy for two hours while it answered calls the whole time: the check relied on a tool its software image did not include. On another occasion a service ran an old configuration for six hours after the file changed on disk, because nothing restarted it. The lesson from both is the same. Trust a test call that connects, and nothing else.

The wrong company answering

One failure we designed out: on a shared gateway, a routing rule meant for one number can end up catching calls for another. The new number rings, and a different company's agent answers, with the wrong name and the wrong brochure. We give each client's number its own gateway, and provisioning refuses to repoint a live route to a different account.

Recordings that never arrive

Recordings reach us from the carrier by webhook. A space in the configured webhook address was accepted by the carrier's portal and posted nowhere. A shared secret that is one character out looks exactly like a carrier that was never configured. Neither raises an error anywhere you would look. More in call recording and retention in India.

Calls cut off mid-sentence

A flat cap on call length, meant to clean up calls whose caller had vanished, also hung up on engaged buyers, and the better a call was going, the likelier it was to be cut off. An idle timeout that resets whenever either side speaks does the same clean-up without ending real conversations.

Losing the trunk altogether

The most expensive failure is not technical. Under TRAI's February 2025 amendments (PDF), opens in a new tab, a sender found in repeated violation of the commercial communication rules can have all its telecom resources, SIP trunks included, disconnected across all operators for a year, and be blacklisted.

What to ask a carrier before you connect

• The number in the exact form the carrier sends on an inbound INVITE: with or without 91, with or without a plus.
• The addresses they send inbound calls from. Not "our IP range", the specific inbound addresses.
• The addresses they accept outbound calls on, if different.
• Where the audio comes from, and whether it matches the signalling addresses.
• UDP or TCP for signalling.
• How many simultaneous channels you get, in writing.
• How recordings are delivered, and how long the carrier keeps its own copy.
• Which number series your outbound calls will present, and how the trunk is linked to your DLT registration.

The rest of this series

• DID and virtual numbers in India: what the numbers are, which series TRAI designates for which calls, and what a business needs before its first outbound call.
• Inbound vs outbound AI calling: three different jobs, three scripts, and obligations that are not symmetric.
• Call recording and retention in India: why to keep recordings, what the law says about how long, and who should be able to listen.

For how this fits a property sales team, see AI calling for real estate.

What to do next

Get the carrier checklist above answered in writing before you choose anything else. Then place a test call to and from your own number: a call that connects both ways, with audio both ways, tells you more than any status page.