Tata Smartflo

Tata's Smartflo is a managed enterprise trunk: provisioning is done by Tata, not by you, so most of this page is about asking for the right thing the first time.

Not yet validated end to end by Tone against a live Smartflo trunk. Every Tone-side field below is exact. The Tata-side steps are a specification to hand your account manager rather than a click-path, because Smartflo trunks are configured by Tata's provisioning team and the portal differs by contract. If you run this, tell support@usetone.ai what you hit.

Before you start

• A Smartflo contract with DIDs allocated, and a named Tata account manager or provisioning contact.
• A Tone organization with KYC verified and SIP trunking enabled by Tone support.
• Your trunk's page in the Tone dashboard open — it carries the signalling IPs Tata must allow, which are specific to your deployment.

The provisioning request

Managed Indian trunks are delivered against a form. Send all of this at once:

And ask them, explicitly, for three things back:

1. Their signalling source addresses, so you can build the ipAcl. Not the media addresses — they are often different, and an allowlist built from the wrong ones refuses every call.
2. Their termination host, port and transport for calls Tone places outbound.
3. The dialled-number format they expect: +91…, 91…, or 0….

Create the trunk in Tone

Enterprise trunks are almost always IP-authenticated:

POST /v1/sip-trunks
{
  "name": "Tata Smartflo — HQ",
  "inboundAuth": "ip_acl",
  "ipAcl": ["203.0.113.64/28"],
  "outboundHost": "sbc.smartflo.example",
  "outboundPort": 5061,
  "outboundTransport": "tls",
  "outboundNumberFormat": "national0",
  "callerIdPolicy": "did",
  "codecs": ["PCMA", "PCMU"],
  "maxConcurrent": 30
}

outboundNumberFormat starts at national0 here deliberately — Indian enterprise trunks frequently want 0 + the ten-digit number rather than +91. If your first outbound test is rejected with a number or routing error, that field is the first thing to change; e164 and national are the other two values.

ipAcl entries must be public IPv4, /24 or narrower. Tone refuses private ranges: a 10.0.0.0/8 in an allowlist is either a typo or a trunk that will never reach us over the public internet, and both are better caught at write time.

Import each DID:

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

Testing

Do these in order — each one isolates a different half:

1. POST /v1/sip-trunks/{id}/test sends OPTIONS to their SBC. If this fails, nothing else will: it is either the wrong host or a firewall.
2. Call a DID from a mobile — proves their inbound delivery and your ipAcl.
3. POST /v1/calls on that DID — proves outbound, caller ID and number format, which are the three things most likely to still be wrong after inbound works.

When it does not work

A note on caller ID

Tone presents the trunk number in both From and P-Asserted-Identity. Indian carriers validate outbound CLI against the numbers on the account, so callerIdPolicy should stay did unless Tata has explicitly confirmed they will pass an arbitrary +91 caller ID for you.