Asterisk HOLD_INTERCEPT event is missing or hold behavior is wrong

Freeze one hold cycle and the first divergence

Record timestamp and timezone, Asterisk branch and loaded function, device, channel name and unique ID, linked ID, bridge membership, where HOLD_INTERCEPT(set) ran, device hold and unhold times, AMI and ARI subscriptions, received events, consumer actions, SIP re-INVITEs and SDP, music class and media heard by each party.

Classify the first failure: interception never set, wrong channel, device emitted no hold action, event absent, wrong interface or subscription, consumer missed or rejected it, target channel changed, peer was intentionally not held, music path differed, or unhold and cleanup failed.

Prove the function was attached to the signalling channel

Follow the device to the live channel that receives its hold action. Confirm the set operation executed before the signal and was not removed, replaced or stranded on a former Local or transferred channel. The function is channel-scoped and write-only; infer its effect from the controlled sequence and resulting event rather than a read-back claim.

If a transfer or masquerade changes topology, remap the active device and peer legs before retesting. A shared linked ID is correlation, not proof of attachment.

Verify AMI or ARI delivery independently

For AMI, retain Hold or Unhold, channel identity, unique ID, linked ID and suggested music class when present. For ARI, retain ChannelHold or ChannelUnhold, application, timestamp and initiating channel. Then prove the consumer connection, permissions and subscription scope covered that channel at that time.

An event in Asterisk logs does not prove a remote client received or processed it. Conversely, absence in one client does not prove the channel failed to raise it until the server-side interface and subscription path are checked.

Separate intercepted intent from actual hold action

The documented function suppresses the hold frame and raises an event instead. If the requirement is to place another channel on hold, identify the authorized consumer action and exact target rather than expecting the intercepted frame to continue automatically.

For ARI control, verify the target is still in the intended Stasis application and retain any 404, 409 or 412 response. A successful request is still not proof of peer-facing SIP signaling or audible music.

Trace SIP hold and music as separate media paths

If PJSIP is involved, record PJSIP_MOH_PASSTHROUGH() state and any on-hold re-INVITE or UPDATE, SDP direction attributes, peer response and RTP sources. If Asterisk generates music locally, record the chosen class and the channel receiving it.

Do not diagnose a missing event by changing codecs, NAT or music files. Move to the existing music-on-hold or re-INVITE diagnostics only after proving that the control and signaling stages reached them.

Correct one owner and prove the paired teardown

Correct only the first demonstrated mismatch: set timing, channel owner, subscription, client processing, target mapping, authorization, ARI state, PJSIP hold mode, music class or media path. Preserve the previous dialplan and application version.

Repeat hold and unhold on the same authorized scenario and confirm event pairing, intended peer state, music or silence, resumed media, remove behavior and hangup cleanup. No PBX, channel, event, consumer, SIP exchange, music stream or call was inspected or tested.

Continue from the event into the peer-facing hold path

After proving interception and any authorized consumer action, use the PJSIP hold diagnostic for channel override, re-INVITE, SDP, remote media and resume evidence.