Skip to main content

​
Jambonz softswitch model

Every PSTN call on Orbit — inbound DID traffic, outbound dialing, SIP trunk traffic from your own PBX, and desk-phone / softphone calling — terminates on the Jambonz session border controller. Jambonz is Orbit’s voice softswitch edge: it handles SIP signalling, and asks Orbit for the routing decision and the verb plan for each call. This page walks through that surface the way a call sees it, so you can onboard SIP and predict which routing rule applies.

​
Where the voice softswitch lives

Three flavours of SIP endpoint all land on the same softswitch edge:
  • Outbound SIP trunks — the carrier connections you configure under Settings → SIP trunks (or via GET /api/v1/voice/sip-trunks) for outbound calling. Outbound PSTN termination exits only via the Devotel wholesale softswitch; a configured trunk that fails to register or stops answering falls back to that default path.
  • Softphone / desk-phone registration — SIP credentials you issue per extension (browser softphone, Yealink / Polycom / Grandstream desk phone). When a device sends REGISTER, the softswitch checks the digest against the credential you created, and stamps the last registration time. Manage credentials under Settings → SIP credentials or POST /api/v1/voice/sip-credentials.
  • BYOC inbound trunks (Bring Your Own Carrier) — calls originated from your own voice infrastructure (an Asterisk / FreeSWITCH / 3CX PBX, or an AI-voice stack you run yourself). These arrive on a shared inbound carrier and are authenticated by the digest credentials or IP allowlist you store on the trunk, then routed per the inbound route model below.

​
Feature codes (star codes)

A desk-phone user has no dashboard in front of them, so the handset can dial a star code — feature codes like *78 for Do-Not-Disturb — and the softswitch resolves the dialed string to a typed action, speaks a short confirmation, and hangs up. Only codes the platform can honour end-to-end are recognised (Do-Not-Disturb on/off, call-park retrieve, voicemail check, malicious-call-id trace); everything else gets a polite “feature not available” prompt and a clean hangup.

​
Inbound vs outbound route model

The softswitch asks Orbit “what should I do with this call?” on every INVITE, and the answer differs by direction.

​
Inbound (PSTN → your tenant)

On an inbound INVITE the dialed E.164 number is resolved in this order:
  1. Exact match — the inbound_routes row for the DID (voice queue, softphone ring list, IVR flow, voicemail, etc.).
  2. DNIS pattern fallback — when no exact row exists, your dnis_routes rules are evaluated: prefix or regex patterns, ranked by priority, with the longest (most specific) pattern winning. Tenant scoping comes from the number’s owning organisation, so a pattern you write can never catch another tenant’s calls.
  3. Once a route row is chosen, business-hours and holiday calendars on that row decide whether the primary destination or the configured fallback (closed-hours behaviour) applies.
The softswitch then renders Orbit’s answer as Jambonz “verb” sequences — dial, say, enqueue, hangup — and executes them for the life of the call. Ring strategies (simultaneous or sequential hunt across SIP credentials) are tracked per call so each no-answer step advances exactly once.

​
Outbound (your tenant → PSTN)

Outbound has two entry points:
  • Registered devices — an INVITE from a softphone / desk phone is validated against the credential: caller-id ownership, outbound_enabled, blocked countries, the concurrency caps described below, and a pre-flight billing hold. If approved, the call dispatches; otherwise it gets an accurate SIP response (403/402/480) and a clean teardown.
  • API-initiated calls — POST /api/v1/voice/calls. Both entry points terminate outbound PSTN traffic exclusively on the Devotel wholesale softswitch; a configured outbound trunk is an optimisation and a failover preference, never a third-party termination change.
For BYOC inbound trunks, the guard chain runs before any verb is emitted: per-trunk routing rules (country/prefix blocklist, time-window check, caller-id rewrite), caller-id ownership against the trunk’s allowed caller IDs or the org’s owned DIDs, a fraud guard (rate and daily-spend caps, premium-rate prefix block), and a pre-flight billing hold. Failures answer the originating PBX with the correct SIP status, not a silent drop.

​
SIP header conventions, registration caps, and concurrency

  • Header lookups are case-insensitive. Upstream proxies forward custom headers (X-Orbit-Org-Id and similar) with arbitrary casing, so every consumer of a SIP header matches names without regard to case. When you integrate your own SIP stack, you can send custom headers in any casing — they will still be found.
  • Per-credential registration cap. A SIP credential caps how many distinct endpoints may hold a live REGISTER binding at once. A keepalive REGISTER refreshes the endpoint’s existing slot; only a genuinely new endpoint beyond the cap is rejected — so a stolen credential cannot be registered from a flood of devices.
  • Per-credential concurrent-call cap. Separately, each credential caps concurrent active calls, reserved atomically so two simultaneous outbound requests can’t both slip under the limit. A stuck call that never reports its status frees its slot automatically after a bounded time-to-live rather than leaking the cap forever.
Both caps are tenant-owned settings you set per credential; there is no platform-imposed ceiling beyond what you configure.

​
Safety controls you own

Per Orbit’s compliance model, these controls are yours to configure — the platform provides them; you decide how strict to be:
  • Abandoned-call safe harbor (US predictive dialing). The dialer already keeps abandoned calls under the federal 3 % ceiling. For the calls that do get abandoned, you can configure a safe-harbor message — per campaign, with an organisation-level fallback for business identity — that plays within two seconds of the called party’s greeting: your business name plus a callback number the party can use for a do-not-call request. Once configured, the message plays automatically on abandoned attempts before hangup.
  • Caller-ID filter on inbound routes. Each inbound route carries an optional caller-ID filter: block repeat spammers’ numbers from ever entering a queue or ringing a softphone (the caller hears a polite “the call cannot be completed” message), or maintain a small VIP allowlist that rings through immediately.
  • Caller-ID privacy. Per-route caller-ID presentation rules decide what the called party sees (your DID, an anonymised identity, or a withheld presentation) where the destination carrier accepts it.

​
Where to go next