Airtel (via your SBC)

Airtel's enterprise voice trunks usually terminate on customer premises equipment — an AudioCodes, Ribbon, Oracle/Acme or Cisco SBC in your data centre. Tone connects to that SBC, not to Airtel directly, and this page is about the SBC hop.

Not yet validated end to end by Tone against a live Airtel trunk. Tone-side fields are exact; the SBC guidance is generic because it depends on your make and model. If you run this, tell support@usetone.ai what you hit.

The shape

Airtel PRI/SIP  →  your SBC  →  Tone gateway  →  your agent
                   (you own this hop)

Your SBC keeps doing what it already does toward Airtel. You are adding one more SIP peer on its other side. That means:

• Nothing about your Airtel contract changes. No new provisioning request, no new DIDs.
• The SBC is where number formats get normalised. If Airtel hands you 0-prefixed or bare ten-digit numbers, your SBC almost certainly already normalises them for your PBX; do the same toward Tone.
• Your SBC's public address is what Tone allowlists, so it must be static.

Before you start

• An SBC with a public IPv4 address and capacity for another peer.
• The DIDs you want a Tone agent to answer, and a plan for which calls route to Tone versus your existing PBX.
• A Tone organization with KYC verified and SIP trunking enabled by Tone support.

Configure the peer on your SBC

Whatever the vendor, the peer toward Tone is:

Allow Tone's signalling IPs — on your trunk's page in the dashboard — inbound on your SBC, and allow your SBC to reach Tone outbound. Open both SIP and the RTP range; a firewall that passes SIP but not media produces a call that rings, answers, and is silent, which is the single most misleading failure in this whole setup.

Create the trunk in Tone

POST /v1/sip-trunks
{
  "name": "Airtel via DC SBC",
  "inboundAuth": "ip_acl",
  "ipAcl": ["203.0.113.32/32"],
  "outboundHost": "sbc.yourcompany.example",
  "outboundPort": 5061,
  "outboundTransport": "tls",
  "outboundNumberFormat": "e164",
  "callerIdPolicy": "did",
  "codecs": ["PCMA", "PCMU"],
  "maxConcurrent": 30
}

ipAcl is your SBC's public address — a single /32 if you have one SBC, or the pair if you run an HA cluster that can egress from either. Private ranges are refused, so the address must be the one Tone actually sees, not the SBC's internal interface. If your SBC is behind NAT, the allowlist entry is the NAT's public address.

Import each DID:

POST /v1/sip-trunks/{id}/numbers
{ "e164": "+911244567890", "agentId": "…" }

Routing only some calls to Tone

Most people do not send an entire Airtel trunk to an agent. Because routing lives on your SBC, you can send one DID, a range, or a time-of-day condition — and keep everything else going to your existing PBX. Tone only ever sees what your SBC sends it, and answers only the DIDs you imported: anything else gets a 404, which is a useful safety net while you are still moving dial plan around.

Testing

1. POST /v1/sip-trunks/{id}/test — OPTIONS from Tone to your SBC. Proves the outbound half and your firewall, before any real call.
2. Call one imported DID from a mobile.
3. POST /v1/calls with that DID.

If step 2 rings and then goes silent, it is media, not signalling — check the RTP range in both directions before anything else.

When it does not work