Freeze one failed hold and resume cycle
Record timestamp and timezone, installed Asterisk release, channel names and unique IDs, linked ID, endpoints, bridge membership, dialplan location, loaded moh_passthrough values, per-channel read-back, who pressed hold, SIP methods and responses, SDP direction attributes, music class, RTP sources and what each party heard.
Classify the first divergence: function unavailable, write on the wrong channel, device action absent or intercepted, no re-INVITE, rejected or colliding re-INVITE, unexpected SDP direction, remote system produced silence, wrong local class, no RTP, resume transaction failed or media did not return.
Prove the effective mode on the active PJSIP leg
Confirm the running release meets a documented function floor and the active channel is PJSIP. Read the loaded endpoint option and PJSIP_MOH_PASSTHROUGH() on the exact channel before the hold action. If the dialplan wrote another leg, ran after the action or targeted a channel replaced by transfer, the observed peer behavior can correctly remain unchanged.
Keep endpoint configuration and channel override as separate records. Correct the supported configuration owner—standalone source or managed PBX interface—rather than editing generated files or assuming a reload changed existing channels.
If no hold request left, trace the control path first
Verify the device emitted a hold action and map it to the channel. Check whether HOLD_INTERCEPT() intentionally converted that action into an AMI or ARI event instead of passing the frame onward. Confirm that an application did not replace the channel or perform a different hold operation.
Do not change codecs, NAT or firewall rules when the control path never requested peer-facing hold. With passthrough disabled, absence of a hold re-INVITE can be expected because Asterisk owns local music generation.
If a re-INVITE exists, prove transaction and SDP convergence
Follow Call-ID, tags, CSeq, branch, offer, final response, answer and ACK. Confirm the hold offer and answer are compatible and that resume later restores the intended direction. A 2xx response is not proof of media; a rejected offer does not activate its proposed direction or address.
If 491, 500 or another overlap appears, reconstruct the outstanding offer and protocol-directed retry before changing hold mode. Separate hold from direct-media, transfer, connected-line and session-refresh requests that occur near the same button press.
Assign silence or wrong music to the actual media owner
When passthrough is off, inspect the selected local music class, source, start event, codec path, RTP transmission and listener result. When passthrough is on, inspect the remote endpoint, PBX or provider policy and the RTP it sends. A working local category does not prove the remote path, and a remote hold response does not prove audible content.
Account for suppress_moh_on_sendonly separately, especially when SDP direction appears in a 183 or another early-media response. Its job is to suppress local music for received sendonly or inactive; it does not enable hold passthrough.
Correct one owner and repeat both directions
Correct only the first demonstrated mismatch: supported release, active channel, set timing, endpoint default, intercepted action, remote hold support, transaction retry, SDP direction, local class, media source or RTP path. Preserve the prior configuration and a rollback trigger.
Repeat hold and resume from each required side, then verify ordinary two-way audio, transfer or direct-media behavior and hangup. Retain a local-generation control and remove temporary SIP or RTP logging. No PBX, endpoint, channel, bridge, request, response, SDP body, music source, packet, media stream or call was inspected or tested for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk PJSIP_MOH_PASSTHROUGH dialplan function ↗
- Asterisk PJSIP_ENDPOINT dialplan function ↗
- Asterisk res_pjsip module configuration ↗
- Asterisk pjsip.conf sample ↗
- RFC 6337: SIP usage of the offer-answer model ↗
- RFC 3264: An offer-answer model with SDP ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.