Add a New DID Range (Existing Tata Trunk)¶

This guide covers adding a new block of DIDs to the existing Tata trunk — the case where Tata has released another set of numbers (e.g. 8065080700 to 8065080729) to your existing NNI link, and you want them usable for org assignment.

For adding a whole new carrier (Jio, Vodafone, a second Tata trunk), see Multi-Carrier Trunks (Architecture) — that's a different workflow.

TL;DR (after PR-1 lands)¶

1. Admin UI → editor.astradial.com/admin/dids → Add DIDs to Pool. Enter range start / end (E.164 format like 918065080700), provider Tata, region as appropriate.
2. Assign each DID to its owning org from the same page (or let the org request it themselves).
3. Test inbound + outbound to one DID in the new range.

That's it. No dialplan edits. No SSH. The cloud Asterisk regenerates tata-did-route automatically on assign; the new pass-through tata-inbound patterns match anything coming in from the gateway.

What actually happens under the hood¶

Mobile dial → Tata SBC (10.79.215.102)
            → NUC enp86s0  [from-tata _+X. / _X.]   pass-through
            → cloud-endpoint over WireGuard
            → Cloud Asterisk [tata-inbound _+X. / _X.]  pass-through
            → [tata-did-route N,1,Goto(<org>_incoming, ...)]
            → org's IVR / queue / extension

Both from-tata (on the NUC) and tata-inbound (on the cloud) are pass-through contexts: any inbound DID is normalized and handed to the dispatcher. The dispatcher (tata-did-route) is auto-generated from the did_numbers table at every deploy and either has the DID (Goto org context) or hits its own _X. catch-all (number-not-in-service).

So the only thing the database needs to learn is the new DID rows — the dialplan generator handles the rest.

Step-by-step¶

1. Confirm Tata has released the range¶

Run an inbound smoke test even before adding anything to the pool:

ssh root@nuc.astradial.com 'asterisk -rx "pjsip set logger on"'
# from a mobile, dial +91 <a number in the new range>
ssh root@nuc.astradial.com 'tail -200 /var/log/asterisk/full | grep -E "INVITE|<the-DID>"'

If you see an INVITE sip:+91<DID>@10.54.225.90:5060 from 10.79.215.102, Tata's side is live. If the INVITE never arrives, the range isn't released yet — email Tata NOC and stop here.

2. Add the range to the DID pool¶

Two ways, equivalent:

UI: editor.astradial.com/admin/dids → Add DIDs to Pool. Fill range start (918065080700) and end (918065080729), set Provider=Tata, Region=Bangalore, and a monthly price.

API: if you'd rather script it:

curl -X POST https://editor.astradial.com/api/admin/did-pool/admin/bulk \
  -H "Content-Type: application/json" \
  -d '{
    "numbers": ["918065080700","918065080701", ... ,"918065080729"],
    "provider": "Tata",
    "region": "Bangalore",
    "monthly_price": 2499
  }'

Response: {"created": 30, "skipped": 0, "skipped_numbers": []}. Skipped numbers are duplicates (DID already in DB) — usually a sign you've run this twice. Safe to ignore.

The bulk-add endpoint does not redeploy Asterisk — the rows are inserted as pool_status=available with no org owner, so there's nothing to route yet.

3. Assign each DID to its owning org¶

Same admin page → click the ↔ Assign to org icon on each DID row → pick the org → confirm. This:

• Sets org_id and pool_status='assigned'.
• Calls configDeploymentService.deployOrganizationConfiguration() which regenerates the org's per-tenant dialplan files plus deployGatewayRouting() which regenerates /etc/asterisk/ext_tata_gateway.conf.
• Reloads Asterisk dialplan (hot, no call drops).

A new exact-match exten => <DID>,1,Goto(<org>_incoming,<DID>,1) line lands in tata-did-route for every alias of the DID (+91…, 91…, 0…).

4. Configure inbound routing for each DID¶

Either through the org's dashboard (Dashboard → DID → set routing target) or via API. The DID needs routing_type (extension / queue / ivr / ai_agent) and routing_destination set. Without these, the call lands in the org context but has no per-DID landing point.

5. Smoke-test the call path¶

From any mobile:

Dial +91 <one DID from the new range>

Expected:

• The org's configured routing target rings / answers.
• /var/log/asterisk/full on cloud shows Executing [<DID>@tata-did-route] followed by Goto(<org>_incoming, ...).

If you get number-not-in-service, check that:

1. tata-did-route has the DID: asterisk -rx "dialplan show tata-did-route" | grep <DID>
2. The org's incoming context has a matching exten => <DID>,...: asterisk -rx "dialplan show <org_prefix>_incoming" | grep <DID>

6. Test outbound with one of the new DIDs as caller ID¶

In the org dashboard, set one of the new DIDs as the default outbound CID. Then place an outbound call from one of the org's extensions. NUC's from-cloud will pass the CID straight through to Tata. If Tata rejects (403/404), it means the carrier hasn't authorized that DID for outbound even though inbound works — call Tata NOC.

Things that USED to be needed and aren't anymore¶

Before PR-1 (the surgical fix on configDeploymentService.js:636), every new DID range needed:

• A hand-edit to /etc/asterisk/extensions.conf on the NUC adding exten => _+918065080[0-2]X,... patterns.
• A hand-edit to configDeploymentService.js so the next config deploy wouldn't wipe the cloud-side equivalent.
• Two hot reloads, one on each Asterisk.

Now tata-inbound and from-tata are pure pass-through and the dispatcher reads the DID pool from the DB. Adding numbers is data, not code.

Smoke test: Tata side released?¶

If a customer reports a new range "doesn't work", the question is almost always: did Tata release it?

# Watch SIP on the Tata-facing interface
ssh -t user@nuc.astradial.com 'sudo sngrep -d enp86s0'
# Have someone dial the DID

In sngrep, look for an INVITE from 10.79.215.102 (Tata SBC) with the DID in the To/Request-URI. If you see it, Tata is delivering — the issue is on our side. If you don't, the issue is on Tata's side.

Troubleshooting¶

Related¶

• DID Management (admin endpoint reference)
• Outbound Caller ID
• DID Routing Environments (prod vs staging)
• Multi-Carrier Trunks (Architecture) — for adding Jio / Vodafone / a second NNI