Intercom: peer-to-peer auto-answer
The intercom dial is the one-to-one counterpart of a paging group: instead of broadcasting to every member of a group, you buzz exactly one extension, and the target’s device answers on speaker automatically. It covers the floor-comms pattern teams expect from a UCaaS platform — “ask the front desk a question”, “top up a colleague on push-to-talk while they roam”. An intercom dial is an ephemeral action, not stored config. There is no intercom entity to create or manage — each dial is validated, resolved, and rung on the spot, then audit-logged. Dialling a target you have not pre-configured anywhere still works as long as the target exists.Paging groups (many) vs intercom (one)
Both are internal, extension-to-extension calls: they never place an
outbound PSTN call. An intercom dial rings a device registered on your
own SIP realm, end of story.
Dial an extension
POST /api/v1/voice/intercom/dial
The endpoint requires an authenticated session with an owner, admin,
developer, or agent role — any softphone-capable user can intercom a
coworker.
Request body:
Auto-answer semantics — user target vs SIP target
The target kind determines how the device picks up:user_id— an in-app auto-answer invite is pushed to that user’s softphone widget. The invite carries a deep link withautoAnswer=1and the mode, so the widget accepts the call on speaker instead of showing a ringing UI. This is the right kind when you address coworkers by their user id.sip_username— the target is resolved against your organization’s registered SIP credentials and rung directly on its device Contact binding with a SIP INVITE carrying the hands-free auto-answer headers (below). SIP usernames are checked per organization — a deskphone or registered softphone is reached by its SIP username, no user id mapping required.
Hands-free headers vs ring-style
There is no single vendor-standard way to ask a phone to auto-answer, so the INVITE sends both widely deployed forms together — a phone ignores the one it does not understand:Call-Info: ...;answer-after=0— honoured by Cisco, Grandstream, Snom, Yealink (theanswer-afterconvention).Alert-Info: info=alert-autoanswer;delay=0— honoured by Polycom, Aastra, Mitel devices.
X-Intercom-Mode: two_way|ptt so softphone answer
handlers can apply mic policy per mode.
Response
A200 response reports the outcome of each stage:
Check
sipOriginated before telling the operator the line is open: a
verified-but-unrang target returns 200 with sipOriginated: false and
sipTargetNotMapped: true so you can show “Target verified, could not
reach device” instead of a misleading “Dialing…”.
Error cases
- 400 — body failed validation (unknown target kind, a
modeoutsidetwo_way/ptt, or extra fields — the schema is strict). - 400 — you intercommed your own user id (
user_idtarget only). - 404 — for a
sip_usernametarget, no enabled, non-deleted credential with that username exists in your organization. The check is org-scoped: another organization’s credentials are invisible to you.