Asterisk HOLD_INTERCEPT: turn device hold into channel events safely

Define interception as a channel-scoped policy

HOLD_INTERCEPT(set) enables hold interception on one channel; HOLD_INTERCEPT(remove) removes it. Asterisk documents the function since 13.7.0 and marks both actions as write-only.

Name the exact channel, device and call leg before setting it. Applying interception on a caller, callee, Local-channel half or transferred replacement is not evidence that the device-originated hold action on another channel will be intercepted.

Keep device intent separate from peer hold state

With interception enabled, Asterisk intercepts a hold action signalled from the device and raises an AMI or ARI event instead of passing the hold frame on. The event therefore reports that the channel wanted to put other parties on hold; it is not proof that those parties were actually held.

Document whether the design is notification-only or whether an authorized consumer will perform another action. Without that consumer path, suppressing the frame can intentionally leave the peer media state unchanged.

Identify the AMI and ARI event contracts

AMI exposes Hold and Unhold call-class events with channel identity and correlation fields; Hold can also include a suggested music class. ARI models the corresponding ChannelHold and ChannelUnhold events, and describes the channel as the initiator.

Record interface, event type, channel ID or unique ID, linked ID, timestamp, application or AMI session and subscription scope. A linked ID can correlate channels but does not turn one channel event into bridge-wide state.

Give the consumer an explicit, reversible action

An event consumer can notify an application, update workflow state or request a later channel operation, but each is a separate authorization and lifecycle boundary. Confirm that the target channel still exists and remains owned by the intended application before acting.

ARI documents POST /channels/{channelId}/hold and DELETE /channels/{channelId}/hold for channels in a Stasis application. Those control operations are distinct from observing an intercepted device request, and their documented errors include missing channels, non-Stasis ownership and invalid state.

Do not collapse hold, music and SIP signaling

ARI hold, ARI music-on-hold start or stop, a device-originated hold signal and peer-facing SIP hold are different controls. PJSIP_MOH_PASSTHROUGH() separately chooses whether PJSIP hold uses on-hold re-INVITEs or locally generated music on hold.

Record what the held and holding parties should hear, the selected music class, the offer and answer if SIP signaling is involved, and the final RTP sources. An event, an accepted REST response or a visible hold icon proves less than the intended media result.

Test set, event, action, remove and teardown

On an authorized test call, capture channel creation, set, device hold, AMI or ARI delivery, any consumer action, peer media, device unhold, the paired event, remove, transfer or bridge changes and hangup. Include a negative case where interception is not set.

Correct the earliest proven boundary and keep a way to remove interception if the consumer is unavailable. Redact caller identities and endpoint addresses. This guide is documentation-derived; no function, event, device, music path or call was tested.

Separate interception from PJSIP hold passthrough

HOLD_INTERCEPT() can convert a device hold action into an event; PJSIP MOH passthrough separately controls whether a resulting PJSIP hold is signaled to the peer or handled with local music.