Asterisk channel inventory, identity and lifetime

Separate inventory, identity and action

Begin with the question being answered: which channels were visible at one observation time, whether one exact channel still exists, which call or bridge it belongs to, or whether an authorized operation reached the intended leg. Those are different evidence.

CHANNELS() supplies a space-delimited list of known channel names and can filter that list with a POSIX.2 regular expression. CHANNEL_EXISTS(name_or_uid) returns whether one channel name or unique ID exists at that instant. Neither result proves the channel will remain present, is the intended leg, is bridged, carries media or will accept a later operation.

Keep names, Uniqueid and Linkedid distinct

A channel name identifies a live channel object and includes driver-specific material. The built-in CHANNEL variable exposes the current channel name, while UNIQUEID identifies the current channel. Linkedid is a call-correlation value shared across related legs; it is not a substitute for the unique identity of the one leg an operation will target.

Record the exact name, Uniqueid, Linkedid, creation or observation time and current application together. A familiar endpoint label or matching Linkedid can still describe the wrong leg.

Treat CHANNELS output as an ephemeral snapshot

Capture the full unfiltered list first when authorized, then apply the narrowest anchored expression needed for classification. Preserve the expression and timestamp. Because calls create, rename, optimize and destroy channels while the list is being read, a result is a point-in-time inventory rather than a transaction or lock.

Do not split a channel name on punctuation and infer identity from fragments. Use the whole returned token and correlate it with the same-time CLI, AMI or event evidence.

Account for Local-channel optimization and renames

Local channels begin as paired legs and, by default, can optimize out after the destination answers. The documented optimization removes the Local channel and its channel-specific information from the path; /n deliberately retains it when the dialplan requires that behavior.

A Local name that disappears can therefore be expected lifecycle evidence rather than a failed call. Prove the surviving endpoint channel, bridge membership and correlated identifiers before deciding that a leg was lost.

Revalidate immediately before an authorized operation

Discovery and action are separated by time. Recheck the exact name or unique ID, call correlation, state and application immediately before a redirect, requested hangup or other authorized control operation. Broad expressions, endpoint labels and an old inventory are unsafe selectors for destructive work.

The CLI documentation says a requested hangup takes effect when the driver next reads or writes; acknowledgement is therefore not proof that the channel has already gone. Observe the resulting lifecycle separately.

Use correlated snapshots and events for diagnosis

AMI CoreShowChannels returns currently defined channels as an event list associated with the request ActionID. Preserve the ActionID, every channel event and the completion boundary. Compare that bounded response with lifecycle events and the CLI from the same node and time window.

For an authorized staging call, capture successive snapshots before creation, during ringing, after answer, after Local optimization and after hangup. No PBX, module, dialplan, channel, bridge, manager session, packet, media stream or live call was inspected or tested; this guide is documentation-derived.

Resolve a channel immediately before Getvar or Setvar

The AMI variable diagnostic checks live channel name, Uniqueid and Linkedid before interpreting a blank result.

Correlate endpoint active-channel counts at one boundary

The AMI endpoint inventory guide keeps a timestamped ActiveChannels count separate from channel identity and lifetime evidence.