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

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.

Reviewed 2026-10-14Current 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 testedAdvancedDocumentation based · not lab tested

Freeze one message attempt before changing syntax

Record timestamp and timezone, full Asterisk release, loaded modules, dialplan revision, execution context, destination argument, MESSAGE From, To and body length, endpoint, AoR, contact, transport, outbound proxy, emitted Request-URI, Call-ID, CSeq, final response and endpoint result. Classify the first mismatch as no application execution, invalid protocol, invalid URI, endpoint or contact selection, authentication, transport, method rejection, body policy, accepted-but-not-presented or user-receipt expectation.

Do not alternate destination formats or resend the same content rapidly before preserving the first transaction. RFC 3428 forbids an overlapping out-of-dialog transaction to the same URI, and retries can hide the original routing evidence.

Read the application status before the SIP response

INVALID_PROTOCOL means no handler matched the technology portion; verify the pjsip: prefix and the loaded PJSIP messaging module. INVALID_URI means the selected handler rejected the URI shape. FAILURE is a handler-level failure. SUCCESS only proves handoff to that handler, not a transmitted packet, 2xx response, endpoint display or user read.

Capture the expanded destination exactly as Asterisk received it. Whitespace, quoting, display-name brackets, a missing endpoint, the wrong AoR, an absent contact or an unintended default endpoint can move failure earlier than DNS or peer support.

Compare destination parsing with loaded location state

For endpoint and endpoint/AoR forms, inspect the loaded endpoint association and current contact selected at the same time. For endpoint-plus-URI forms, prove which endpoint supplies policy and which explicit URI becomes the target. For the dialstring-like form, confirm the documented replacement of the contact URI user.

A contact that qualifies successfully only proves the OPTIONS observation. It does not prove MESSAGE support, authorization or display. If the wrong device receives the request, stop at AoR/contact and Request-URI selection instead of rewriting From or body content.

Prove headers and body on the wire

Compare the final Request-URI with To and From after MessageSend() argument precedence, then inspect Content-Type, Content-Length and the redacted UTF-8 body. If an incoming message was reused, inventory copied MESSAGE_DATA() fields and whether outbound marking included a stale or untrusted header.

For large-message symptoms, calculate the full request size rather than body size alone. Apply RFC 3428's 1300-byte out-of-dialog boundary unless the stated path knowledge exception is genuinely available. Do not solve fragmentation or peer rejection by indiscriminately forwarding more inbound headers.

Attribute the final response to the correct hop

Correlate the MESSAGE Call-ID, CSeq, transport and branch through each proxy to the final response. A 401 or 407 can identify an authentication challenge; 404 can indicate target resolution; 405 or 501 can indicate method support; 413 can indicate body size; 415 can indicate media type; and a timeout can precede any endpoint decision. Preserve the actual response rather than mapping everything to MESSAGE_SEND_STATUS=FAILURE.

For 200, prove which final user agent accepted the request and then inspect its presentation policy. For 202, identify the accepting relay and its separate delivery evidence. Neither response proves a person saw the content.

Correct one owner and repeat a bounded matrix

Correct only the demonstrated boundary: dialplan execution, module availability, destination syntax, endpoint or AoR, current contact, explicit URI, header precedence, authentication, transport, peer method support, content type, body size or endpoint presentation. Repeat one known-safe short text and one intended production shape without overlapping transactions.

Keep SIP MESSAGE distinct from SMS/MMS carrier service, in-call text, subscription NOTIFY and voicemail MWI. Record any delivery or read receipt as a separate mechanism. Remove temporary logging and retain redacted evidence. No PBX, module, endpoint, AoR, contact, dialplan, header, body, request, response, packet, device, user interface or message was inspected or tested for this diagnostic.

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 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 Latest API PJSIP_DIAL_CONTACTS, Dial, PJSIP_AOR, PJSIP_CONTACT and AMI object documentation plus PJSIP configuration relationships reviewed October 12, 2026; the generated pages reported branch 23, but the installed Asterisk version, endpoint, AoRs, contacts, registration expiry, qualification, dialplan, SIP responses and call legs remain deployment-specific, and no PBX, endpoint, AoR, contact, registration, device, channel, request, response or call was inspected or tested

Asterisk PJSIP_DIAL_CONTACTS: dial every current AoR contact

Build a call-time PJSIP dial string from the intended endpoint and AoR while keeping contact inventory, qualification, outbound channels and the winning answer independently observable.

Read guide →
Guide · Asterisk Latest API branch 23 PJSIP_PARSE_URI, PJSIP_PARSE_URI_FROM, PJSIP_HEADER and FILTER documentation plus current Asterisk security guidance and RFC 3261 reviewed October 13, 2026; no Asterisk host, module, channel, header, variable, URI, parser result, endpoint, route, transport, DNS result, SIP message or call was inspected or tested

Asterisk PJSIP_PARSE_URI: extract SIP URI parts without inventing trust

Parse a bounded SIP URI into documented components while keeping header ownership, absent-value sentinels, authorization, DNS, transport selection and final routing independently observable.

Read guide →
Reference · SIP standards; extension support depends on both peers

SIP URI structure: identity, routing and parameters

Parse sip and sips addresses without assuming they behave like ordinary telephone numbers.

Read guide →
Guide · Current Asterisk logging, runtime command, logger.conf, debug-collection, call-identifier and console-verbosity documentation reviewed September 30, 2026; no process, logger, trace, storage path or call tested

Asterisk logging without permanent debug overload

Map configured destinations, console levels, call identifiers and a bounded protocol trace without leaving sensitive debug collection active.

Read guide →
Guide · Wireshark 4.x / current upstream tool documentation; inspect installed versions

VoIP packet-capture methodology

Select interfaces, time windows and paired capture points that distinguish network loss from missing evidence.

Read guide →
Diagnostic · RFC 3261 SIP transport behavior, RFC 8085 UDP message-size guidance and current Asterisk PJSIP transport-selection and configuration references were reviewed October 7, 2026; no endpoint, PBX, SBC, proxy, firewall, NAT, VPN, tunnel, route, interface, MTU, fragment, SIP message, transaction, transport connection, certificate, availability, compatibility or call was inspected or tested

SIP works for small messages but a large UDP request fails

Compare message size, selected transport, path MTU, fragments, proxy behavior and the correlated SIP transaction before changing codecs or firewall policy.

Read guide →
Hub

VoIP troubleshooting

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

Explore topic →