Skip to main content

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 with autoAnswer=1 and 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 (the answer-after convention).
  • Alert-Info: info=alert-autoanswer;delay=0 — honoured by Polycom, Aastra, Mitel devices.
An endpoint that honours neither header still rings and plays your intercom opening on manual answer — degraded, never silently unanswered. The INVITE also carries X-Intercom-Mode: two_way|ptt so softphone answer handlers can apply mic policy per mode.

Response

A 200 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 mode outside two_way/ptt, or extra fields — the schema is strict).
  • 400 — you intercommed your own user id (user_id target only).
  • 404 — for a sip_username target, 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.

Example

Related: Paging groups, ring groups & call park for the many-to-one broadcast sibling, and Colleagues for presence-aware contact lists.