Asterisk AMI AbsoluteTimeout: timer, channel and hangup evidence

Bind the timer to one current channel

Record the Asterisk node, installed release, manager identity, unique ActionID, exact Channel, Uniqueid, Linkedid, bridge membership, channel creation time, action time, requested Timeout and business policy owner. Resolve the live channel immediately before the action.

AbsoluteTimeout takes a channel name and a maximum duration in seconds. A bridge, linked call, endpoint or caller ID can contain or identify more than one channel; the action does not describe a whole-call object.

Treat Timeout Set as acknowledgement, not expiry proof

The current, Asterisk 22 and Certified 22.8 action pages say that AbsoluteTimeout acknowledges a set time with the message Timeout Set. Preserve that raw response with its ActionID.

The generated action record does not document a timer-start event, expiry event, remaining-time field, replacement rule or whole-call result. Do not turn the response into proof that the intended leg stayed alive until the requested second, that a later action did not replace it, or that any other leg ended.

Separate AMI control from dialplan timeout types

The TIMEOUT() function exposes absolute, digit and response channel timeouts in seconds. Its absolute value limits call time and documents zero as disabling that dialplan timeout; digit and response govern extension-entry behavior instead.

Do not apply the function's zero-value statement automatically to an AMI action unless the installed action behavior is verified. Also keep AMI AbsoluteTimeout seconds separate from Originate or application-specific timeout fields that may use different units and phases.

Model T, h and hangup handlers separately

Asterisk documents uppercase T as the special extension executed when the absolute timeout is reached. Lowercase t is the response-timeout extension, and h is the post-hangup cleanup extension. Custom hangup handlers add another ordered cleanup surface.

A timer can therefore reach the expected channel while a missing T path, generated FreePBX dialplan, later cleanup or blocking handler creates a different observed workflow. Preserve the exact context and dialplan revision before changing any of those owners.

Distinguish requested from final channel termination

HangupRequest and SoftHangupRequest report a requested hangup with channel identity and a cause. The final Hangup event carries the disposed channel identity, cause text and, when present, a technology cause. These are different evidence boundaries.

The AMI specification says Hangup ends event activity for that exact Uniqueid; it also notes that hangup dialplan can execute before that final event appears. A request event is not final disposal, and a final event for one leg does not prove that every channel sharing a Linkedid ended.

Validate one controlled lifetime without production guessing

In an approved nonproduction window, use one disposable call, exact channel identity, a short harmless timeout and synchronized monotonic and wall-clock capture. Preserve the response, T and cleanup execution, request events, final Hangup, other bridge-leg lifetimes and endpoint result.

Test cancellation or replacement only when explicitly authorized and supported by the installed branch. Use a dedicated least-privilege manager identity. Documentation does not establish timer precision, availability, compatibility, call completion or media quality, and no live system was tested for this guide.

Do not confuse timer expiry with a direct Hangup request

The AMI Hangup guide gives direct termination its own target, cause and final-event ledger.