Asterisk AMI SendText: in-call message and channel evidence

Bind the request to one live in-call channel

Record the Asterisk node and release, manager identity, unique ActionID, exact Channel, Uniqueid, Linkedid, channel technology, bridge membership, current application, intended recipient and synchronized time. Resolve the live channel immediately before sending.

AMI SendText is documented as an in-call message to a channel. It does not target a user account, device inventory, AoR, contact, bridge or Linkedid, and a caller label does not identify one channel lifetime.

Keep the message and content type inside a bounded contract

The action requires Message and permits an optional Content-Type. Define the approved content class, maximum length, character handling, privacy classification and retention policy before sending. Do not place secrets, credentials, regulated data or unbounded user input into routine manager traffic or logs.

An omitted content type lets a handler choose its default; it is not evidence that text/plain was selected or that an endpoint will render the body. Preserve the exact non-sensitive metadata and a hash or redacted sample when the body itself should not be retained.

Separate basic text from enhanced messaging

The dialplan SendText reference distinguishes BASIC and ENHANCED transmission and documents SUCCESS, FAILURE and UNSUPPORTED outcomes. It says chan_pjsip uses an in-dialog SIP MESSAGE, while encoding and transport remain at the channel driver’s discretion.

The AMI action does not expose the dialplan SENDTEXTTYPE and SENDTEXTSTATUS variables as its result contract. Do not transfer those variables mechanically to an AMI response or assume every channel technology supports the same content types, addressing attributes or delivery method.

Keep in-call SendText distinct from out-of-call MessageSend

AMI MessageSend and the MessageSend dialplan application address out-of-call messages through a message technology and destination URI. Their Destination, To, From, Body or Base64Body and handler-status contracts do not turn AMI SendText into an endpoint-routing action.

Choose the interface from the required ownership boundary: a current call channel for SendText, or an explicitly constructed message destination for MessageSend. A working voice channel does not establish out-of-dialog messaging support, and a reachable endpoint does not prove an in-dialog message will be displayed.

Treat acceptance, transmission and presentation as different evidence

AMI is asynchronous. Preserve the raw action response by ActionID, then collect channel-driver or protocol evidence permitted by policy and the endpoint observation separately. An accepted action is not proof of a SIP final response, remote delivery, notification, display, user acknowledgement or durable history.

ReceiveText waits on the current channel and reports its own status and received body to dialplan variables. It is not a universal receipt event for a prior AMI SendText action and must not be inserted into an active call flow merely as a diagnostic probe.

Validate safely on a disposable call

Use a dedicated least-privilege manager identity and one authorized nonproduction call. Prove current channel identity, supported content class, action response, selected transport, bounded endpoint presentation and cleanup. Include a negative channel or unsupported content case that must not expose a message elsewhere.

Remove temporary message logging and redact captures. Documentation does not establish installed capability, interoperability, confidentiality, delivery, presentation or user outcome, and no live system was tested for this guide.

Continue from in-call SendText to out-of-call MessageSend

The AMI MessageSend guide replaces a live-channel target with an explicit technology destination, Request-URI and message headers.