Asterisk AMI SendText is accepted but the message is missing or reaches the wrong channel

Freeze one request and one symptom

Record node, release, manager identity and authority, ActionID, exact Channel, Uniqueid, Linkedid, channel technology, bridge peers, Message metadata, Content-Type, raw response, synchronized signaling evidence and authorized endpoint observation. Redact or hash sensitive bodies.

Classify the first symptom as rejected action, stale or wrong channel, unsupported content, no protocol attempt, protocol rejection, endpoint not rendering, wrong recipient or missing acknowledgement. Do not combine several calls or retries into one timeline.

Re-resolve the channel before blaming messaging

Confirm the named channel still exists with the same Uniqueid and still represents the intended call leg. Transfers, Local optimization, bridge replacement and hangup can invalidate a cached channel name while a related Linkedid remains visible.

A successful response for one exact channel does not prove its bridge peer received anything. Correct the target identity before changing transports, endpoint settings or message content.

Verify action availability and narrow authority

Check the installed action inventory and the dedicated manager user’s permissions. Keep unknown action, permission denial, invalid channel and accepted action as different states. Do not grant Command or write=all as a shortcut.

Preserve request framing without logging credentials or private message bodies. AMI field boundaries and client parsing must be correct before channel-driver behavior is diagnosed.

Test content and channel-driver capability separately

Repeat only with an approved minimal text body and a content type documented for the selected driver. If that works, reintroduce one content attribute at a time. An empty optional content type, text/* type and enhanced-messaging attribute are not interchangeable.

Compare the installed driver and channel with the dialplan SendText documentation, but do not read SENDTEXTTYPE or SENDTEXTSTATUS as the result of the AMI action. Unsupported behavior is not repaired by inventing a different MIME type.

Follow protocol transport to endpoint presentation

For chan_pjsip, retain one bounded in-dialog SIP MESSAGE exchange where policy permits, including dialog identity, Request-URI, Content-Type, body length, final response and time. Then check endpoint presentation and user acknowledgement separately.

A protocol response is not proof that a client displayed, stored or notified the user. Conversely, an endpoint UI symptom alone does not prove Asterisk selected the wrong channel. Keep server, network and client evidence in their own layers.

Repair the first proved boundary and retest once

Correct only the demonstrated fault: stale channel, missing authority, malformed AMI request, unsupported content class, driver limitation, signaling failure or endpoint policy. Retest on one disposable authorized call with a negative-recipient control and remove temporary captures.

Use out-of-call MessageSend only when its destination and technology contract is actually required; do not substitute it merely because in-call SendText failed. No PBX, action, message, channel, endpoint, packet, recipient or live call was inspected or tested.

Confirm whether the operation should be out of call

The AMI MessageSend diagnostic follows endpoint, contact, Request-URI and remote presentation when no current channel owns the message.