Add a New DID¶

This guide walks through provisioning a new DID (Direct Inward Dialing) number on the Astradial platform, from database entry to verified call routing.

Prerequisites¶

Before starting, gather the following:

Step 1: Add DID to database via API¶

curl -X POST https://devsip.astradial.com/api/v1/dids \
  -H "Authorization: Bearer $ASTRAPBX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "number": "+914471234567",
    "organizationId": "org_mna9x47k",
    "routeTo": "1001",
    "routeType": "extension",
    "description": "Chennai office main line"
  }'

Expected response:

{
  "id": "did_abc123",
  "number": "+914471234567",
  "organizationId": "org_mna9x47k",
  "status": "active"
}

INSERT INTO did_numbers (number, organization_id, route_to, route_type, description, created_at)
VALUES (
  '+914471234567',
  'org_mna9x47k',
  '1001',
  'extension',
  'Chennai office main line',
  NOW()
);

psql -U astrapbx -d astrapbx_db

Step 2: Add route in Asterisk dialplan¶

Edit the NUC gateway dialplan to route the DID to the correct organization context.

sudo nano /etc/asterisk/ext_tata_gateway.conf

Under the [tata-did-route] section, add a new entry:

[tata-did-route]
; ... existing routes ...

; Chennai office main line
exten => +914471234567,1,NoOp(Incoming call to Chennai office)
 same => n,Set(ORGANIZATION=org_mna9x47k)
 same => n,Goto(org_mna9x47k-inbound,${EXTEN},1)

Step 3: Regenerate organization config¶

Trigger a config regeneration so the cloud Asterisk picks up the new DID mapping:

curl -X POST https://devsip.astradial.com/api/v1/organizations/org_mna9x47k/regenerate \
  -H "Authorization: Bearer $ASTRAPBX_TOKEN"

Expected response:

{
  "status": "ok",
  "message": "Configuration regenerated for org_mna9x47k"
}

Step 4: Reload Asterisk dialplan¶

On the NUC, reload the dialplan so the new route takes effect without dropping active calls:

asterisk -rx 'dialplan reload'

If the org config was regenerated on the cloud, reload there as well:

asterisk -rx 'dialplan reload'

Step 5: Verify the route is loaded¶

asterisk -rx 'dialplan show tata-did-route'

Confirm the new DID appears in the output:

[ Context 'tata-did-route' created by 'pbx_config' ]
  '+914471234567' =>     1. NoOp(Incoming call to Chennai office)    [extensions.conf:42]
                         2. Set(ORGANIZATION=org_mna9x47k)          [extensions.conf:43]
                         3. Goto(org_mna9x47k-inbound,${EXTEN},1)   [extensions.conf:44]

Step 6: Test call¶

1. Call the DID number from a mobile phone or external line.
2. Watch the Asterisk CLI on the NUC for the incoming INVITE:

   asterisk -rvvvv
   

3. Confirm the call routes through [tata-did-route] to the correct organization context.
4. Verify the call reaches the intended extension or ring group.

Troubleshooting: DID assigned via the marketplace UI but not routing¶

Three real failure modes (all hit while onboarding Mithra scans, DID 918065080710/80702). Work them in this order.

A. The editor "Deploy Config" does NOT reload the running dialplan ⚠️¶

The editor's Deploy Config writes the org's ext_*.conf/pjsip_*.conf and #includes them — but it does not reload Asterisk's running dialplan. So a newly-added DID is on disk and #included yet absent from the live dialplan, and the call goes nowhere.

• Symptom: the config file has the DID and is #included in extensions.conf, but asterisk -rx "dialplan show <DID>@tata-did-route" fails, and dialplan show <org>__incoming shows only ~1 line.
• Fix: ssh root@147.93.168.216 'asterisk -rx "dialplan reload"' (cloud), and on the NUC too if its route changed. Non-disruptive.
• This affects every new DID/org until the deploy auto-reload is fixed. After any marketplace DID assign + Deploy, always dialplan reload.

B. The NUC only forwards specific DID ranges to the cloud¶

Tata DIDs land on the NUC first ([from-tata] in /etc/asterisk/extensions.conf). The NUC forwards only these ranges to the cloud (cloud-endpoint): +9180659780XX and +9180650807[0-2]X. A DID outside those ranges never reaches the cloud — there's no cloud CDR at all for the call.

• Symptom: no CDR on the cloud for the DID (SELECT … FROM asterisk_cdr WHERE dst LIKE '%<DID>%' is empty), even though other DIDs work.
• Check: ssh root@nuc.astradial.com 'asterisk -rx "dialplan show +<DID>@from-tata"' — it must show Dial(PJSIP/${EXTEN}@cloud-endpoint). If it shows a Goto(from-reseller-…) or nothing, the NUC isn't sending it to the cloud.
• Pick DIDs inside the NUC-forwarded ranges when buying for a customer org.

C. Reseller DIDs override the cloud pattern — and must be hidden from the marketplace¶

Some DIDs are explicitly routed to the reseller on the NUC, e.g.:

exten => +918065080710,1,Goto(from-reseller-skylink-inbound,${EXTEN},1)

• Keep reseller DIDs out of the marketplace: set did_numbers.pool_status = 'reserved'. The marketplace GET /available lists only pool_status='available', so reserved hides them. States: available (buyable) · assigned (in use) · reserved (held, hidden) · pending (mid-request).
• Reseller DIDs to date: 918065080710, 918065080711 → reserved, org_id=NULL, description "Reserved - reseller (Skylink)".