Version 2.7.2 splits inbound and outbound calls into two independent webhook event chains, adds queue control through the REST API, and header-based SIP trunk identification for gateways where several lines share one IP address.
A separate event chain for outgoing calls
Previously, outgoing calls placed from a SIP user’s extension had no events of their own at all.
Now there’s call.outgoing → call.outgoing_answered → call.outgoing_ended, independent of
the inbound chain call.incoming → call.answered / call.missed → call.ended. Recognizing
an outgoing call is tied to the specific SIP user, not the dialplan context — this matters
because both a user and a trunk can share the same context name that matches a routing table’s
name.
linkedid, channel, and channel_vars in every event
Every payload now includes linkedid — an identifier shared by all channels of one logical call
(for example, both legs of an internal call) — and channel, the Asterisk channel name. This
lets a CRM group multiple webhook events from the same call without relying on uniqueid
proximity or timestamps. A new channel_vars object carries the values of allowed Asterisk
channel variables (by default, ULINE, the call-parking slot).
Queue member pause and status via the REST API
POST /api/v1/queues/members/pause/ pauses or unpauses a queue member via AMI’s QueuePause,
and GET /api/v1/queues/members/ returns live member status (pause state, status, calls
handled) — both endpoints work directly against Asterisk, regardless of whether
dashboard-listener is running.
SIP trunks for multi-port GSM gateways
A new free-text field, custom_identify_settings, lets you define a custom [identify] block
for a trunk. This solves a specific problem: when several ports on the same GSM gateway register
from a single IP address, Asterisk can’t tell them apart by IP — only by the Contact: header in
the incoming request. Previously, [identify] only supported IP-based recognition.
An important change for existing webhooks that use routing tables
If you have a webhook configured to match only by routing table (no context or queue) for
inbound events, after the upgrade those calls will start being sent as call.outgoing* instead
of call.incoming/call.ended, as before. The migration carries over existing settings
automatically, but the handler on the CRM side needs to be updated to expect the new event
types. Recommended upgrade order: run migrate and sync_webhooks first, then restart
dashboard-listener.