docs: clarify that ONE inbound SIP Trunk covers every Anveo DID

The step 4 heading said "once per DID" and the intro said steps 3-7 repeat
per DID, both of which overstate the work. The body already noted the trunk
could be reused, but the heading is what gets read first - and it actively
misleads toward creating one trunk object per number.

One inbound SIP Trunk serves the whole account: the $[E164]$ placeholder is
substituted with each DID's own number at call time, and the Asterisk side
matches whatever arrives via _X. and resolves it through
pstn-personal-dids.conf. Same for the outbound Service Trunk in step 3,
which the body already flagged as skippable for DIDs 2+.

Rewrites the heading, adds an explicit up-front note on why one suffices,
and corrects the intro to name which steps actually repeat per number.
This commit is contained in:
Claude
2026-07-24 20:21:23 +00:00
parent 8113d4bb2f
commit a45b9dc08e
+27 -12
View File
@@ -2,9 +2,14 @@
This is the exact sequence that got a real Anveo Direct DID working end to
end (both outbound and inbound) with `asterisk-digital-ocean.sh` +
`pstn-trunk.sh`, confirmed live on a real droplet. Follow it in order for
each additional number — steps 12 are one-time account setup; steps
37 repeat per DID.
`pstn-trunk.sh`, confirmed live on a real droplet.
**Steps 1, 3 and 4 are one-time account setup** — the outbound Service
Trunk (step 3) and the inbound SIP Trunk (step 4) each cover every DID on
the account, no matter how many you add. **Only steps 2, 4.5, 6 and 7
repeat per number**: order the DID, point it at the existing inbound trunk
(skippable entirely if you set the account default in step 4.6), assign it
in the dashboard, and test.
## 0. Prerequisites
@@ -91,7 +96,7 @@ catch-all entry (prefix `1`); a few specific area codes have their own
slightly different override rates, and Virgin Islands is billed
separately/higher (~$0.02/min) despite looking like a normal US number.
## 4. Create the SIP Trunk (inbound forwarding) — once per DID
## 4. Create the SIP Trunk (inbound forwarding) — ONE covers every DID
Anveo has **two unrelated "trunk" concepts** — don't confuse them:
- The **Outbound Service Trunk** from step 3 handles calls *out*.
@@ -99,11 +104,20 @@ Anveo has **two unrelated "trunk" concepts** — don't confuse them:
routing objects live) handles calls *in* — this is what actually
populates a DID's "Destination SIP Trunk" dropdown.
For **each DID**, create one of these:
**You only need ONE of these for the whole account**, no matter how many
DIDs you have. The `$[E164]$` placeholder in step 2 is what makes it
reusable — Anveo substitutes each DID's own number at call time, so the
same trunk object forwards `15551111111@IP:5060` for one DID and
`15552222222@IP:5060` for another. The Asterisk side matches whatever
arrives (`_X.` in `[from-pstn-trunk]`) and looks it up in
`pstn-personal-dids.conf` to decide who rings. Creating one per DID is
possible but pointless unless different DIDs need to forward to genuinely
different destinations.
1. **Trunk Name**: any label (e.g. `asterisk-do-inbound`) — can reuse the
same one for multiple DIDs if you want them all forwarding the same
way, or make one per DID for clarity.
Create it once (steps 14), then per DID only step 5 applies — or set the
account default in step 6 and skip even that:
1. **Trunk Name**: any label (e.g. `asterisk-do-inbound`).
2. **Primary**: type **SIP URI**, value:
```
$[E164]$@<this box's public IP>:5060
@@ -115,12 +129,13 @@ For **each DID**, create one of these:
in the actual INVITE Anveo sends.
3. **Failover**: leave blank.
4. Save.
5. Go to the DID's own **Call Options** tab → set **Destination SIP
Trunk** to this new SIP Trunk object (not the Outbound Service Trunk)
5. **Per DID**: go to that DID's **Call Options** tab → set **Destination
SIP Trunk** to this SIP Trunk object (not the Outbound Service Trunk)
→ Save.
6. **Optional, recommended once you're adding more DIDs**: Account
6. **Recommended if you have more than one or two DIDs**: Account
Options → Service Defaults → set **Default Destination Trunk** to this
SIP Trunk, so future DIDs auto-route here without repeating step 5.
SIP Trunk. New DIDs then auto-route here and step 5 becomes unnecessary
entirely.
## 5. Configure the droplet