Asterisk PJSIP transfer event is missing or the transfer stalls

Freeze one failed REFER transaction

Record timestamp and timezone, installed Asterisk release, endpoint, allow_transfer, exact PJSIP channel and bridge, unique and linked IDs, handling-mode write location, Stasis application, ARI WebSocket identity and subscription, REFER Call-ID and Refer-To value, response and NOTIFY sequence, expected destination and observed result.

Classify the first mismatch: unsupported function, transfer disallowed, write on the wrong channel or too late, channel outside application control, event not subscribed or delivered, destination unresolved, policy rejection, originate failure, bridge mutation failure, NOTIFY progression failure or remote endpoint behavior.

Prove release support, permission and timing

Confirm the installed branch includes PJSIP_TRANSFER_HANDLING() at a documented maintenance level: 20.13.0, 21.8.0 or 22.3.0 and later. Confirm the endpoint permits transfers. Then prove ari-only was written on the REFER-receiving PJSIP channel before the attempt and before Stasis application control.

Do not infer the mode from a sibling channel or a shared linked ID. The function is documented as write-only, so preserve dialplan execution or channel-creation evidence for the actual leg.

Check ARI connection, application and subscription scope

Prove the intended ARI client is connected to the correct Asterisk instance, the channel entered the intended Stasis application and the client receives events for that application and channel. Preserve any reconnect or duplicate-consumer interval.

A healthy REST response does not prove WebSocket event delivery. An event visible to another application or another Asterisk instance does not prove the intended controller received it.

Correlate REFER data without inventing local channels

Match the ChannelTransfer event to the incoming REFER by time, Call-ID, requested destination, referring channel and bridge. For attended transfers, preserve any resolved channel and bridge IDs but allow for unresolved identifiers when a proxy or another Asterisk owns the referenced dialog.

Do not reject a valid remote scenario solely because a local channel ID is absent. Conversely, a populated identifier does not prove the ARI application used the correct bridge or authorized destination.

Follow application action, NOTIFY and bridge result

For a blind transfer, trace target validation, channel removal, replacement originate, answer or failure, bridge addition and the final participants. For an attended transfer, trace both dialog sides and the application decision. Preserve the 202 response and every NOTIFY status separately from the new call result.

A 202 Accepted is not a connected transfer. A new answered channel is not sufficient if the old bridge member remains, the wrong party is replaced, NOTIFY terminates incorrectly or audio is unusable.

Correct one ownership boundary and retest

Correct only the demonstrated boundary: maintenance release, endpoint permission, channel selection, write timing, Stasis entry, WebSocket subscription, destination policy, originate handling, bridge mutation or NOTIFY state. Repeat the same transfer and verify an unrelated core endpoint remains unchanged.

If the ARI controller cannot complete the whole transaction, restore core handling rather than leaving transfers acknowledged but unfinished. No PBX, endpoint, channel, bridge, ARI client, event, REFER, NOTIFY, INVITE, packet or transfer was inspected or tested for this diagnostic.

Identify the transfer control surface before retrying

The AMI transfer diagnostic distinguishes manager action, native protocol and bridge-feature evidence.

Separate protocol transfer from AMI cancellation

The CancelAtxfer diagnostic keeps core attended-transfer abort and native SIP signaling distinct.