> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Choose the right voice product

> Decide between the browser softphone for human agents, the outbound dialer for campaign-scale call lists, and POST /voice/calls for server-side programmatic calls — a decision table, mapped workflows, hybrid patterns, and the SIP trunking case where you skip the call-API entirely.

# Choose the right voice product

Voice on Devotel Orbit has three outbound surfaces. Pick the wrong one and
you end up re-platforming the flow a month in. This page routes you to the
right one once, then links deeper setup guides for each.

## Three surfaces, three jobs

**Browser softphone** — a human agent talks. Place and answer PSTN calls
from a browser (or embedded SIP/web client), with queues, extensions, hold,
transfer, and disposition codes. Set it up with
[the browser softphone guide](/guides/voice-softphone-browser-calling).

**Outbound dialer** — a campaign dials a list, agents take answered calls.
Predictive, progressive, preview, and agentless modes with pacing, DNC
scrubbing, abandon-rate ceilings, and dispositions built in. Set it up with
[the outbound dialer campaign guide](/guides/outbound-dialer-campaign).

**`POST /voice/calls`** — your server originates a call with one request.
One-off programmatic legs: a reminder, a page-cast, a click-to-call from
your CRM, or a `dial` leg inside a programmable flow. Program what happens
when the callee answers either inline (`staticVerbs`) or by pointing the
call at a URL on your server (`answer_url`). See the
[Voice API reference](/api-reference/voice) for the request shape and the
[programmable DSL reference](/reference/programmable-voice-dsl) for the
verb vocabulary.

## Decision table

| Capability                | Softphone                                     | Dialer                                         | `POST /voice/calls`                                               |
| ------------------------- | --------------------------------------------- | ---------------------------------------------- | ----------------------------------------------------------------- |
| Who talks                 | Human agent                                   | Human agent (or voice agent in agentless mode) | Whoever the verbs route to — a person, a queue, or your flow      |
| Originates from           | Browser/SIP client                            | Campaign list upload or CRM import             | Your server, one request per call                                 |
| Recording                 | Per-org policy, per-call toggle on the client | Campaign-level recording setting               | `record: true` on the request                                     |
| AMD (voicemail detection) | N/A — agent decides                           | Configurable per campaign                      | `amd: true` on the request                                        |
| Webhooks                  | Call events to your endpoints                 | Campaign progress + per-call events            | Subscribe to call events; `answer_url` is fetched per call        |
| Transcripts               | Post-call via the call record                 | Post-call via the call record                  | Post-call via the call record (async pipeline)                    |
| Concurrency model         | One call per agent                            | Pacing scheduler, bounded by the campaign cap  | Base rate limit on the voice surface; manage bursts in your queue |
| Work-shape                | Ad-hoc, person-to-person                      | Queue-style lists, thousands of contacts       | One-off calls, any trigger your code has                          |

All three surfaces read the same [call log](/api-reference/voice) after the
fact — pick a surface on who DRIVES the call, not on where the record
lands.

## Common workflows mapped

**A BDR team working leads.** The person decides when to dial and what to
say, so a person drives the call: give them the browser softphone. If the
team also uploads a shared list and works it top-down, that list belongs in
the dialer even when humans talk — see the hybrid note below.

**A scheduled appointment reminder.** Your scheduler fires
`POST /voice/calls` per appointment with `staticVerbs` — a `say` with the
reminder text, optionally a `gather` to confirm or rebook. No list, no
agent, one request per reminder. If the reminder must offer "press 1 for an
agent," let the verb sequence `dial` the queue or ring group.

**A canary ops page-cast.** Your alerting runbook posts one call per
on-call rotation with an `answer_url`; when the engineer answers, your
server returns the verbs — read back the alert and offer a dial-leg into
the incident bridge. The fallback (`answer_fallback`) decides what the
callee hears if your endpoint is unreachable.

## Hybrid patterns

Start with `POST /voice/calls` when volume is small or trigger-driven: a
few hundred reminders a day, internal tooling, a new-segment experiment.
Move the flow to the dialer when you need campaign machinery the API
surface deliberately lacks — ordered priority across contacts, pacing that
respects agent availability and the abandonment ceiling, DNC persisted
across campaigns, and disposition-driven retries.

The softphone and the API also coexist: an agent works inbound queues on
the softphone while your back office originates product-click-to-call legs
via `POST /voice/calls` that route into the same queues.

## Entry points per surface

* Softphone — [Set up the browser (WebRTC) softphone](/guides/voice-softphone-browser-calling), plus the [embedded SDK demo](/guides/sdk-demo-browser-softphone) if the client lives in your own app.
* Dialer — [Launch an outbound dialer campaign](/guides/outbound-dialer-campaign); the exact request shapes sit in the [dialer API reference](/api-reference/dialer).
* Programmatic calls — [`POST /voice/calls` on the Voice API reference](/api-reference/voice); the DSL verbs (`say`, `gather`, `dial`, `hangup`, …) are catalogued in the [programmable voice DSL reference](/reference/programmable-voice-dsl).

## When NOT to expose the API

If the goal is to forward inbound PSTN calls to your own PBX or carrier
rather than to originate AI-flow/agent legs on Orbit, you don't want a
call-origination API at all — you want a SIP trunk. Provision termination
and origination trunks and route the numbers over them; the API surfaces
above stay unused. See the
[SIP trunk setup guide](/guides/sip-trunk-setup).

## Glossary

**AMD** — Answering Machine Detection. The carrier flags the answered side
as a person or a machine so a campaign can drop voicemails and a flow can
branch. In the dialer it's a campaign setting; over `POST /voice/calls`
send `amd: true`.

**STIR/SHAKEN** — the caller-ID attestation framework carriers use to grade
how trustworthy your outbound number's identity is. Orbit attaches the
attestation level to each outbound leg so downstream networks treat
verified calls accordingly; nothing for you to compute at call time.

**DNC** — Do-Not-Call. The dialer enforces your workspace's DNC registry
before every attempt, and any contact can be scrubbed back into no-dial
status from the suppression surfaces. Consent and quiet-hours are required
before a contact enters a list at all — the
[dialer campaign guide](/guides/outbound-dialer-campaign) walks the
eligibility gates.

## Verify your choice

Dial one test call matching the surface you picked and confirm the path end
to end: the softphone rings a browser, the dialer paces one list row to one
agent, and `POST /voice/calls` returns `201` with a call id that appears in
the shared call log. Then build the real flow on the surface that passed.