Choose the question before the action
CoreShowChannels lists currently defined channels. CoreShowChannelMap starts from one named channel and lists the channels currently connected to it; its documentation says Local channels are followed through to their other half. Status lists channel status and can be limited to one channel while optionally returning selected or all channel variables.
These are different snapshots. Use the global list to establish inventory, the connected map to bound a live relationship, and Status when detailed state or explicitly requested variables are required.
Treat each list as a bounded, versioned transaction
CoreShowChannels accepts ActionID; each CoreShowChannel row and the final CoreShowChannelsComplete return it, and the completion reports ListItems. Collect only rows within that response boundary and compare the observed row count with the terminal count.
The published CoreShowChannelMap syntax requires Channel but does not list ActionID, and CoreShowChannelMapComplete publishes EventList and ListItems without an ActionID field. Do not invent correlation support. The map action is documented from 18.19.0 and 20.4.0, but its completion event has later maintenance markers: 18.26.0, 20.11.0, 21.6.0 and 22.1.0. Record the installed release, inspect local behavior, and serialize or otherwise isolate map requests.
Use stable identity alongside the channel name
CoreShowChannel publishes Channel, Uniqueid, Linkedid and BridgeId. Linkedid is the unique ID of the oldest channel associated with the channel, while BridgeId may be empty when it is not in a bridge. Preserve all four plus the snapshot timestamp.
Channel names can change and channels can end between request and response. A name is a live lookup key, not a durable call identifier; a linked ID groups associated channel history but does not prove current bridge membership.
Use Status for deeper state, not stronger truth
A Status row adds fields such as channel type, dialed-number identity, effective connected line, absolute time to hangup, media formats, translation paths, call groups, pickup groups and channel age. Requested variables can be included selectively, while AllVariables broadens disclosure and payload size.
StatusComplete reports the number of Status events returned. The generated event schema does not list ActionID, so do not depend on a terminal correlation field that the reference does not publish. A richer snapshot is still only a point-in-time observation.
Join snapshots to lifecycle evidence
Use Newchannel, Rename, bridge lifecycle and hangup evidence to explain why two adjacent snapshots differ. A channel created after enumeration, renamed during processing, moved between bridges or hung up before a follow-up query can make a correct earlier snapshot look stale.
Preserve event receive order and timestamps, but distinguish transport arrival order from causal certainty. Re-snapshot the smallest relevant scope when a mutation must act on the current name or bridge.
Keep topology, signaling and media separate
A connected-channel map or shared bridge ID is topology evidence. It does not establish remote answer, negotiated streams, packet flow, audible media, recording continuity or business completion. Pair topology with the signaling, RTP and listener evidence required by the incident.
Limit manager privileges and variable collection, because Status can expose channel data. No PBX, AMI session, manager user, permission, channel, bridge, variable, packet, media stream or live call was inspected or tested for this guide.
Verify event delivery before trusting lifecycle joins
The AMI event diagnostic checks permissions, masks, filters and transport before labeling a channel chronology incomplete.
Treat UserEvent snapshot fields as emission-time context
The AMI UserEvent guide keeps channel snapshots, application correlation and final outcomes separate.
Resolve the intended live channel before recording it
The AMI MixMonitor guide uses current channel identity and bridge evidence before starting a channel-bound audiohook.
Resolve the live leg before parking it
The AMI parking guide uses exact channel identity before Park and parkee identity through retrieval or timeout.
Bound every channel list to one ActionID and completion
The channel identity guide keeps a CoreShowChannels response separate from later lifecycle changes and actions.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk 23 AMI CoreShowChannelMap action ↗
- Asterisk 22 AMI CoreShowChannelMap action ↗
- Asterisk 23 AMI CoreShowChannelMapComplete event ↗
- Asterisk 22 AMI CoreShowChannelMapComplete event ↗
- Asterisk 23 AMI CoreShowChannels action ↗
- Asterisk 23 AMI CoreShowChannel event ↗
- Asterisk 23 AMI CoreShowChannelsComplete event ↗
- Asterisk 23 AMI Status action ↗
- Asterisk 23 AMI Status event ↗
- Asterisk 23 AMI StatusComplete event ↗
- Asterisk 23 AMI Newchannel event ↗
- Asterisk 23 AMI Rename event ↗
- Asterisk 23 AMI Events action ↗
- Asterisk 22 AMI Events action ↗
- Asterisk 23 AMI Filter action ↗
- Asterisk 22 AMI Filter action ↗
- Asterisk 23 AMI WaitEvent action ↗
- Asterisk 22 AMI WaitEvent action ↗
- Asterisk AMI event filtering ↗
- Asterisk Manager TCP/IP API ↗
- Asterisk 23 AMI Login action ↗
- Asterisk 23 AMI Ping action ↗
- Asterisk 23 AMI UserEvent action ↗
- Asterisk 22 AMI UserEvent action ↗
- Asterisk 23 AMI UserEvent event ↗
- Asterisk 22 AMI UserEvent event ↗
- Asterisk 23 UserEvent dialplan application ↗
- Asterisk 22 UserEvent dialplan application ↗
- Asterisk AMI command syntax ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- Asterisk CHANNEL_EXISTS dialplan function ↗
- Asterisk CHANNELS dialplan function ↗
- Asterisk CHANNEL dialplan function ↗
- Asterisk CLI channel creation and manipulation ↗
- Asterisk Local channel optimization ↗
- Asterisk func_channel implementation ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.