- Shipped
- September 3, 2026 at 10:54 PM UTC
- Author
- Kamo
- Commit
- 754050c
The AMI client logs in with 'Events: off' and only sends actions, so nothing on a customer's FreePBX ever told the platform a call was arriving. That silence is what made a missed call on the mobile softphone unrecoverable: a handset whose SIP registration Android had reclaimed was simply not there, and no second signal existed to wake it. A SECOND AMI connection now listens with 'Events: call' and forwards DialBegin (ringing) and DialEnd (answered/ended) to the platform. Separate connection because the action client is a strict request/response pair -- unsolicited events would interleave with its replies and it would read somebody else's packet as its own answer. Details that decide whether this works: - Linkedid, not Uniqueid. Uniqueid is per channel, so the cancellation would arrive under a different id and never match the ring it is meant to end. - Only PJSIP/ and SIP/ endpoint channels yield an extension. Local/, IAX2/ and DAHDI/ legs all reach the parser and none of them is a member's extension. - CallerIDName is dropped when it is just the number repeated, which is what Asterisk fills in when the carrier sent no name. - Best-effort, no retries, a 5s timeout: this is on the critical path of a call ringing right now, and a report that arrives after the caller gave up is worth nothing. - The event endpoint is derived from UPLOAD_URL so an operator configures one URL and cannot point the two halves at different clusters -- a split that would keep uploading recordings while calls quietly stopped ringing. Needs an API key with the new VOIP_CALL_EVENTS scope.