Feature request: SIP/PBX inbound call integration — auto-populate caller info on incident intake (999-style ANI)
38 views
Skip to first unread message
Khalaf Almazrouei
Aug 15, 2026, 4:57:18 PMAug 15
to Open Source CAD
Hope everyone is doing well. Building on the DMR/voice work, I'd like to propose a call-taking integration.
The idea: when an inbound call arrives on the dispatch line (via a SIP PBX such as 3CX, FreePBX/Asterisk, or a Grandstream UCM), TicketsCAD pops a call-intake screen with fields pre-filled from the call itself — the way ANI works in a real 999/911 center:
- Caller number (from SIP INVITE caller ID) auto-filled into the incident contact field
- Repeat-caller recognition: look the number up against previous incidents/constituents; if known, show name, address on file, and prior incident history alongside the new intake form
- One-click "create incident from call" with timestamp, line/queue, and recording reference attached
- Optionally: call state in the UI (ringing/answered/ended), and linking the PBX call recording to the incident record
Integration paths, simplest first:
- Generic webhook receiver — an api/call-event.php that accepts POSTs (number, direction, call-id, timestamp). Nearly every PBX can emit this: 3CX has Call Control API/webhooks, Asterisk/FreePBX via AMI or dialplan curl, Grandstream UCM via its API. This keeps TicketsCAD PBX-agnostic — no SIP stack needed in the CAD at all.
- AMI/ARI listener for Asterisk-family PBXs for richer call state.
- Full SIP registration by the CAD itself — probably overkill; the webhook route covers the dispatch use case.
The CRM half is mostly already there: constituents exist, incidents have contact fields — this adds a lookup keyed on phone number plus a screen-pop.
I can prototype the PBX side: I run a 3CX V20 instance and a Grandstream UCM6302A with an analog FXO line, so I can generate real inbound-call webhooks for both and document the payloads if a receiver endpoint shape is agreed.
Eric Osterberg
Sep 6, 2026, 6:25:16 PMSep 6
to open-so...@googlegroups.com
Hi Khalaf,
Following up on this one — it's built and shipped now, as of TicketsCAD v4.2.25.
The shape ended up very close to what you proposed. A small external adapter process talks to your PBX (Asterisk/FreePBX over AMI, or a generic webhook receiver for hosted SIP trunk providers like 3CX or Grandstream UCM setups) and normalizes whatever your system sends into one canonical event shape, which it then posts to TicketsCAD over a bearer-token-authenticated endpoint. TicketsCAD itself never speaks SIP, AMI, or ARI directly — same pattern as the DMR bridge, one adapter per external system rather than the CAD trying to understand every PBX's native API.
What you get on the CAD side: every logged-in, permission-holding dispatcher sees a live ring notification the moment a call comes in, with a distinct ring tone. The first person to click Answer atomically claims it — no double-dispatch race — and gets a New Incident form in a new tab, pre-filled with the caller's number and, once claimed, their prior incident history.
On the repeat-caller lookup and RBAC question I flagged before — that got a real answer. There are two dedicated field-level permissions, one for caller history and one specifically for patient history, so an install can grant "can see this caller's past incidents" without also granting "can see their medical history." Five new permissions total cover the whole feature: who can see the call queue, who can claim a call, who can override an active claim or configure trunks, and the two field-level ones.
A few things worth knowing if you want to try it: claiming is a genuinely atomic database operation, so simultaneous clicks from two dispatchers can't both win. If the CAD's claim and the physical phone answer disagree — common on real PBX setups where only one extension can actually pick up — any qualified dispatcher can self-correct within a short configurable grace window, no supervisor approval needed for that first correction. It's keyboard-first too: arrow keys cycle between simultaneous calls, A claims, T reassigns or reclaims, Escape dismisses locally. Missed calls land in a collapsible panel instead of disappearing.
Admin setup is under Settings, Communications and Integrations, Inbound Calls — create a trunk there and you'll get a bearer token shown once, which is what you point your adapter at. The reference adapter is in the repo under services/sip-bridge, with both an Asterisk AMI mode and a generic webhook mode you could adapt directly for 3CX or Grandstream.
Since you offered to generate real inbound-call webhooks from your own 3CX and Grandstream setups — that's still genuinely useful, even with the feature already built. The generic webhook mode has one worked example adapter function in the reference code; a second one written against a real 3CX or Grandstream payload shape (rather than a guess) would harden it for anyone else running those systems. If you get a chance to try it against your own trunk and hit anything that doesn't fit, I'd want to hear about it.
73,
Eric
Following up on this one — it's built and shipped now, as of TicketsCAD v4.2.25.
The shape ended up very close to what you proposed. A small external adapter process talks to your PBX (Asterisk/FreePBX over AMI, or a generic webhook receiver for hosted SIP trunk providers like 3CX or Grandstream UCM setups) and normalizes whatever your system sends into one canonical event shape, which it then posts to TicketsCAD over a bearer-token-authenticated endpoint. TicketsCAD itself never speaks SIP, AMI, or ARI directly — same pattern as the DMR bridge, one adapter per external system rather than the CAD trying to understand every PBX's native API.
What you get on the CAD side: every logged-in, permission-holding dispatcher sees a live ring notification the moment a call comes in, with a distinct ring tone. The first person to click Answer atomically claims it — no double-dispatch race — and gets a New Incident form in a new tab, pre-filled with the caller's number and, once claimed, their prior incident history.
On the repeat-caller lookup and RBAC question I flagged before — that got a real answer. There are two dedicated field-level permissions, one for caller history and one specifically for patient history, so an install can grant "can see this caller's past incidents" without also granting "can see their medical history." Five new permissions total cover the whole feature: who can see the call queue, who can claim a call, who can override an active claim or configure trunks, and the two field-level ones.
A few things worth knowing if you want to try it: claiming is a genuinely atomic database operation, so simultaneous clicks from two dispatchers can't both win. If the CAD's claim and the physical phone answer disagree — common on real PBX setups where only one extension can actually pick up — any qualified dispatcher can self-correct within a short configurable grace window, no supervisor approval needed for that first correction. It's keyboard-first too: arrow keys cycle between simultaneous calls, A claims, T reassigns or reclaims, Escape dismisses locally. Missed calls land in a collapsible panel instead of disappearing.
Admin setup is under Settings, Communications and Integrations, Inbound Calls — create a trunk there and you'll get a bearer token shown once, which is what you point your adapter at. The reference adapter is in the repo under services/sip-bridge, with both an Asterisk AMI mode and a generic webhook mode you could adapt directly for 3CX or Grandstream.
Since you offered to generate real inbound-call webhooks from your own 3CX and Grandstream setups — that's still genuinely useful, even with the feature already built. The generic webhook mode has one worked example adapter function in the reference code; a second one written against a real 3CX or Grandstream payload shape (rather than a guess) would harden it for anyone else running those systems. If you get a chance to try it against your own trunk and hit anything that doesn't fit, I'd want to hear about it.
73,
Eric
--
You received this message because you are subscribed to the Google Groups "Open Source CAD" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-source-c...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/open-source-cad/e30c02db-d7ee-47aa-8582-3730c87100e5n%40googlegroups.com.
Justin Gilbert
Sep 17, 2026, 5:15:27 AM (10 days ago) Sep 17
to open-so...@googlegroups.com
Hi Eric & Khalaf,
We also run 3CX, I am trying to set this up for testing but I am at a bit of a roadblock after minting the token in Tickets. I am not quite sure what next steps would be exactly to get this working.
To view this discussion visit https://groups.google.com/d/msgid/open-source-cad/CAJLaYFXmR6dfs%2BCwr639EC7Y7n_38gduwCW9%2BZpW0oXNjq3E%2Bw%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages