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

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.

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

Define one message transaction before sending

Record the Asterisk node and release, manager identity, unique ActionID, intended message technology, Destination, To, From, body representation, approved variables, expected recipient, privacy classification and synchronized time. Redact bodies and credentials unless a tightly controlled investigation requires them.

AMI MessageSend is documented as an out-of-call action. It does not require or select a live call channel, and Channel, Uniqueid, Linkedid or bridge membership must not be invented as message-routing keys.

Keep Destination separate from To and From

Destination selects the message technology and route. For PJSIP it constructs the Request-URI and supports endpoint, endpoint/AoR, endpoint plus explicit URI, default-endpoint URI and PJSIP/user@endpoint forms, all under the documented pjsip: technology prefix.

To and From describe message headers where the technology uses them. If Destination is omitted, To becomes the backwards-compatible destination and is required. That fallback does not make the SIP To header, Request-URI, endpoint, AoR and current contact interchangeable.

Choose endpoint, contact and transport evidence explicitly

An endpoint-based destination may derive its Request-URI from the endpoint’s default AoR and contact. Capture the exact endpoint, selected AoR/contact, resulting Request-URI, DNS result and transport decision rather than recording only a friendly recipient name.

PJSIP transport selection is URI-driven: scheme, transport parameter, configured transport objects, DNS and reusable connections can all matter. A reachable voice registration or successful call does not prove an out-of-dialog MESSAGE will use the intended route or be accepted.

Preserve body and variable semantics

Body cannot contain newlines because they conflict with AMI framing. Use Base64Body when newlines are required; the action documentation says it is decoded before sending and takes precedence over Body. Multiple Variable headers are allowed, with comma-separated name=value pairs.

Define a narrow content class, size limit and allowed header set. MESSAGE and MESSAGE_DATA describe dialplan message fields, but do not authorize arbitrary AMI variables or private headers. Never place passwords, tokens or unbounded user input into routine manager messages or logs.

Separate acceptance, protocol response and recipient outcome

Preserve the raw AMI response by ActionID, then collect message-handler, SIP transaction and authorized recipient observations as different layers. An accepted manager action is not proof of a transmitted request, final SIP response, remote delivery, client notification, display, storage or human acknowledgement.

The dialplan MessageSend application explicitly defines SUCCESS as successful handoff to the protocol handler without guaranteeing delivery. Treat that as a useful boundary, not as an undocumented AMI result field. ARI endpoint messaging is another interface with its own response contract.

Validate with a bounded, disposable recipient

Use a dedicated least-privilege manager identity, an approved nonproduction endpoint and a non-sensitive marker. Prove action availability, constructed Request-URI, To and From headers, selected transport, bounded protocol result, endpoint presentation and cleanup. Include a negative destination that must fail without reaching another recipient.

Remove temporary tracing and retain only the minimum evidence. Documentation does not establish installed capability, compatibility, confidentiality, delivery or presentation, and no live system was tested for this guide.

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 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 →
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 →
Guide · Asterisk 22 ARI Endpoints API and REST data models, current Applications API, ARI overview and ARI security configuration reviewed October 10, 2026; no Asterisk host, endpoint, contact, registration, ARI application, WebSocket, subscription, message exchange, device, client or call was inspected or tested

Asterisk ARI endpoints: state, subscriptions and out-of-call messaging

Observe technology and resource endpoint state, subscribe to exact changes and send bounded out-of-call messages without treating coarse ARI state as registration, contact reachability or delivery proof.

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 →
Troubleshooting · 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 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.

Read guide →