VoIP.infoThe independent guide to business communications.
VoIP.info Troubleshooting

Asterisk AMI MessageSend is accepted but the message is missing or reaches the wrong destination

Find the first divergence across AMI framing, technology destination, endpoint and contact choice, SIP addressing, transport, remote response and client presentation.

Reviewed 2026-10-26Current branch-23-generated, Asterisk 22 and Certified Asterisk 22.8 MessageSend action references, current MessageSend, MESSAGE and MESSAGE_DATA dialplan references, current ARI endpoint messaging, PJSIP transport selection and AMI specifications were reviewed October 26, 2026; installed release, loaded message technology, endpoint, AoR, contact, Request-URI, To and From headers, transport, body handling, remote policy, user-agent presentation, manager permissions and downstream workflow remain deployment-specific; no PBX, manager session, action, endpoint, contact, message body, packet, SIP transaction, remote service, user interface, recipient or live call was inspected or testedAdvancedDocumentation based · not lab tested

Freeze one action and one symptom

Record node, release, manager identity and authority, ActionID, Destination, To, From, Body or Base64Body choice, non-sensitive variable names, raw response, endpoint/AoR/contact snapshot, resulting Request-URI, transport evidence, protocol response and authorized recipient observation.

Classify the first symptom as rejected action, invalid technology, invalid URI, wrong endpoint or contact, malformed AMI body, no protocol attempt, remote rejection, wrong recipient, client not rendering or missing acknowledgement. Do not merge retries or several recipients into one timeline.

Verify AMI framing and body precedence first

Confirm the action exists on the installed release and that the dedicated manager user has only the required authority. Check header termination, unique ActionID and field boundaries without logging credentials or private content.

Body must not contain newlines. If Base64Body is supplied, validate the source encoding and remember that it takes precedence over Body. A framing or decode defect must be corrected before endpoint, transport or client settings are changed.

Resolve Destination before interpreting To

Expand the exact documented destination form into message technology, endpoint, optional AoR or explicit URI, selected contact and final Request-URI. If Destination was omitted, state that the backwards-compatible To-as-destination behavior was used.

Then inspect the To and From message headers separately. A plausible To header does not prove the Request-URI was correct, and changing only To may leave the same wrong endpoint, contact or network destination in place.

Follow endpoint, contact and transport selection

Capture the current endpoint, default AoR, contact set, URI, DNS answer, transport parameter or scheme, selected transport object and reusable connection where policy permits. Stale contacts, a surprising default endpoint, URI replacement and proxy policy can move the request away from the intended recipient.

Do not infer message reachability from call registration or OPTIONS alone. Reproduce with one approved minimal recipient and change only the first demonstrated routing field.

Separate protocol response from client presentation

Retain one bounded SIP MESSAGE transaction where policy allows: Request-URI, To, From, Content-Type, body length, transport, response code and time. Then check remote policy, client support, notification, display, storage and user acknowledgement independently.

No packet attempt points back to Asterisk routing or handler selection. A remote final response narrows the network path but does not prove the user agent displayed or retained the body. UI absence alone does not prove the request used the wrong destination.

Repair the first proved boundary and retest once

Correct only the demonstrated fault: manager permission, AMI framing, body encoding, technology prefix, Destination form, endpoint/AoR/contact, To or From header, URI or transport, remote policy or client behavior. Retest with one disposable authorized recipient and a negative-recipient control.

Use in-call SendText only when a current channel is actually the owner; do not substitute it merely because out-of-call MessageSend failed. Remove temporary captures. No PBX, action, endpoint, message, packet, recipient or live system was inspected or tested.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.

Continue your research

Guide · Current branch-23-generated, Asterisk 22 and Certified Asterisk 22.8 MessageSend action references, current MessageSend, MESSAGE and MESSAGE_DATA dialplan references, current ARI endpoint messaging, PJSIP transport selection and AMI specifications were reviewed October 26, 2026; installed release, loaded message technology, endpoint, AoR, contact, Request-URI, To and From headers, transport, body handling, remote policy, user-agent presentation, manager permissions and downstream workflow remain deployment-specific; no PBX, manager session, action, endpoint, contact, message body, packet, SIP transaction, remote service, user interface, recipient or live call was inspected or tested

Asterisk AMI MessageSend: out-of-call routing and delivery evidence

Construct an out-of-call message without confusing its technology destination, SIP Request-URI, To and From headers, body handling, action response or recipient outcome.

Read guide →
Guide · Current branch-23-generated, Asterisk 22 and Certified Asterisk 22.8 SendText action references, current SendText and ReceiveText dialplan applications, current AMI and dialplan MessageSend references, current CHANNEL and the AMI specifications were reviewed October 26, 2026; installed release, loaded channel driver, enhanced-messaging support, live channel identity, content handling, signaling method, endpoint rendering, manager permissions, event filters and downstream workflow remain deployment-specific; no PBX, manager session, action, message body, channel, endpoint, packet, signaling exchange, user interface, recipient or live call was inspected or tested

Asterisk AMI SendText: in-call message and channel evidence

Send bounded text to one live channel without confusing action acceptance, channel-driver capability, content type, protocol transport or recipient presentation.

Read guide →
Troubleshooting · Current branch-23-generated, Asterisk 22 and Certified Asterisk 22.8 SendText action references, current SendText and ReceiveText dialplan applications, current AMI and dialplan MessageSend references, current CHANNEL and the AMI specifications were reviewed October 26, 2026; installed release, loaded channel driver, enhanced-messaging support, live channel identity, content handling, signaling method, endpoint rendering, manager permissions, event filters and downstream workflow remain deployment-specific; no PBX, manager session, action, message body, channel, endpoint, packet, signaling exchange, user interface, recipient or live call was inspected or tested

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

Locate the first divergence across channel identity, manager authority, content handling, driver support, protocol transport and endpoint presentation.

Read guide →
Guide · Current Asterisk MessageSend, MESSAGE, MESSAGE_DATA and res_pjsip documentation plus RFC 3428 reviewed October 14, 2026; the APIs have been documented since Asterisk 10.0.0 and the endpoint message_context option since 13.5.0, but installed modules, endpoint and contact state, URI construction, authentication, peer method support, SIP transaction result, endpoint display and user receipt remain deployment specific, and no PBX, module, endpoint, AoR, contact, dialplan, header, body, request, response, packet, device, user interface or message was inspected or tested

Asterisk PJSIP MessageSend: Request-URI, headers and delivery evidence

Build one SIP MESSAGE deliberately, keep its Request-URI separate from To and From identity, and prove the protocol response without treating handler acceptance as user receipt.

Read guide →
Troubleshooting · Current Asterisk MessageSend, MESSAGE, MESSAGE_DATA and res_pjsip documentation plus RFC 3428 reviewed October 14, 2026; the APIs have been documented since Asterisk 10.0.0 and the endpoint message_context option since 13.5.0, but installed modules, endpoint and contact state, URI construction, authentication, peer method support, SIP transaction result, endpoint display and user receipt remain deployment specific, and no PBX, module, endpoint, AoR, contact, dialplan, header, body, request, response, packet, device, user interface or message was inspected or tested

Asterisk PJSIP MessageSend fails or uses the wrong URI

Trace one text message from the Asterisk message object through destination parsing, endpoint and contact selection, SIP request, response and endpoint presentation.

Read guide →
Guide · Current Asterisk PJSIP_ENDPOINT and CHANNEL function documentation, res_pjsip endpoint configuration reference, object-relationship guidance and PJSIP troubleshooting guidance reviewed October 13, 2026; PJSIP_ENDPOINT is documented since Asterisk 12.0.0, while installed branch, maintenance release, loaded modules, configuration backend, object names, defaults, endpoint identification, channel association, contacts, signaling and media remain deployment specific; no PBX, module, configuration, endpoint, identify object, channel, SIP exchange, packet or call was inspected or tested

Asterisk PJSIP endpoint inspection: configuration fields, channel identity and proof

Read one loaded endpoint field without confusing configuration, inbound endpoint identification, AoR location, a live channel or negotiated SIP and media state.

Read guide →
Guide · Current Asterisk PJSIP_AOR, PJSIP_CONTACT and PJSIP_DIAL_CONTACTS function documentation plus PJSIP object-relationship and troubleshooting guidance reviewed October 13, 2026; both inspection functions are documented since Asterisk 13.2.0, while installed branch, maintenance release, loaded modules, configuration source, object names, registrations, contacts, qualification state, timing and routing remain deployment specific; no PBX, module, configuration, endpoint, AoR, contact, registration, OPTIONS exchange, packet, channel or call was inspected or tested

Asterisk PJSIP AoR and contact inspection: identity, fields and runtime evidence

Read one Address of Record and its current contact objects without confusing endpoint configuration, registration, qualification or a generated dial string.

Read guide →
Guide · Current Asterisk PJSIP transport-selection, object-relationship and proxy guidance plus Asterisk 22 res_pjsip and outbound-registration references reviewed October 7, 2026; no Asterisk host, transport, socket, connection, DNS response, proxy, registrar, endpoint, certificate, request, media path or live call was inspected or tested

Asterisk PJSIP transport selection: URI, DNS, connection and object boundaries

Trace the URI scheme and transport parameter through SRV resolution, transport-object choice and TCP or TLS connection reuse without treating an endpoint field as the only selector.

Read guide →
Guide · Operational guidance; Asterisk 22 / FreePBX 17 where applicable

Least privilege for PBX users and integrations

Separate the right to register, place calls, administer the PBX and read sensitive data.

Read guide →
Hub

VoIP troubleshooting

Use symptoms and evidence to isolate registration, routing, media and device faults.

Explore topic →