Skip to main content

​
Outbound country coverage matrix for agents

Every agent has an Outbound coverage page: a per-country matrix of outbound voice destinations, each row flagged enabled, regulated, or disabled. Read it before you configure an agent’s outbound calling, not after the first call fails. Dashboard anchor: open an agent, then Outbound coverage — dashboard route agents/[id]/outbound-coverage. API anchor: GET /api/v1/voice/country-coverage (scope voice:read).

​
1. The problem: first-contact SIP 403s

Country regulation does not announce itself during setup on most voice platforms. You configure the agent, load the dial list, place the first live call, and the first signal that a destination is blocked is a cryptic SIP 403 from the provider, mid-campaign, with no reason attached. Regulated destinations fail the same way: the call is rejected because a registration, a disclosure, or a calling-hours condition was never cleared. The matrix inverts that order. It shows every destination’s status while you are still in setup, so a flag costs you a compliance review instead of a failed first contact.

​
2. The per-destination matrix schema

The matrix renders one row per destination country: The three statuses:
  • Enabled — outbound calls to the destination proceed normally.
  • Regulated — the destination carries regulatory conditions: caller registration, disclosure requirements, or calling-hours limits. The note names the condition; the per-country checklist of what your workspace must clear is in country requirements.
  • Disabled — sanctions or regulatory restrictions apply; plan to treat the destination as a block in your workspace policy.
The header tiles total the rows per status, the search box narrows the table by name, ISO code, or prefix, and the status tabs show only regulated or disabled rows: the two you act on. The same ledger is readable over the API:
Each row carries countryIso, countryName, dialingPrefix, status, regulatoryNote, and citationUrl. The whole ledger returns in one response, sorted by ISO code, with no pagination, and it changes rarely, so cache it for minutes rather than re-fetching per render. An empty array means “coverage data unavailable”: fall back to treating destinations as unflagged and re-fetch.

​
3. Before the first call, not after

Open the matrix before you configure the agent’s outbound calling, and again before a dialer campaign ships a new destination set:
  1. Pull the ledger over the API or open the page, and filter to regulated and disabled.
  2. Match those ISO codes against the countries your contact data actually dials.
  3. Route each flagged destination to whoever owns compliance in your workspace, with the row’s note and regulator reference attached.
  4. For a regulated destination, clear the named condition — a registration, a disclosure, adjusted calling hours — and record the approval in your workspace’s Compliance configuration. See country requirements for the per-country checklist.
  5. For a disabled destination, remove it from your outbound lists or document why your policy keeps it.
  6. Re-check when the destination set changes; flags move as regulators update their rules.
A destination with no row is treated as enabled. The matrix warns; your workspace policy decides.

​
4. Linked numbers, voice destinations, and compliance posture

Coverage describes destinations: where your agent calls. The numbers you link to the agent describe origination: the caller ID the destination sees. Validate that side separately with caller ID coverage validation; a destination can be enabled while your originating number is not cleared for it. Set your posture per status once, in the dashboard’s Compliance section: These controls are workspace-level: one workspace’s approved list never affects another, and Devotel Orbit imposes no platform-wide country blocks. The single platform-wide guard is the US federal calling window, which applies regardless of workspace policy. The matrix never steers carriers: every outbound call exits over the same Devotel wholesale softswitch.

​
5. Worked example: a North America to EU rollout

An operator rolls an outbound agent out from the United States and Canada to Germany, France, and the Netherlands, with an existing contact list that also reaches India and Turkey.
  1. Open Outbound coverage for the agent and search the rollout set. US, CA, DE, FR, and NL all read enabled: no action on those rows.
  2. Switch the status tab to regulated. IN surfaces: TRAI sender-ID and DLT registration are required for commercial outbound. The compliance owner submits the pre-clearance via Settings → Compliance and records the approval before India stays on the list.
  3. Switch the tab to disabled. TR surfaces: foreign VoIP origination is blocked without a local partnership. The operator removes Turkey from the outbound list rather than carrying numbers that cannot complete.
  4. The EU rows need no clearance, so the rollout ships with the enabled set. India joins after sign-off, and the advisory log confirms dispatch behaviour matches the posture set in Compliance.
Run the same sweep before any list import and flags surface at import time. The matrix is the pre-flight check; the advisory log is the audit trail, not the discovery mechanism.

​
6. Troubleshooting

Calls to a country with no row went through. A missing row is treated as enabled by design. Route the destination through pre-clearance if you want it flagged. A regulated row has no regulator link. Some conditions come from general regulatory posture rather than one citable rule. Read the note, and use country requirements plus your own counsel for the jurisdiction. The API returns an empty array. The endpoint degrades softly rather than erroring. Re-fetch; if emptiness persists, check status.orbit.devotel.io before you assume flag data. Advisories appear but calls to a flagged destination still complete. That is the intended behaviour. Coverage logs advisories and applies your workspace policy; it never hard-blocks on its own, and it never re-routes a call.