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

Asterisk PJSIP NOTIFY: endpoint, URI and in-dialog boundaries

Send one documented NOTIFY through CLI, AMI or dialplan without confusing a configured message, target selection, SIP acceptance or an endpoint action.

Reviewed 2026-10-13Current Asterisk branch-23 PJSIPNotify dialplan, AMI, res_pjsip_notify and res_pjsip configuration documentation, the October 9, 2024 Asterisk feature introduction, and RFC 6665 reviewed October 13, 2026; the dialplan application is documented since Asterisk 18.25.0, 20.10.0 and 21.5.0, while installed maintenance release, loaded module, endpoint and contact state, default outbound endpoint, configured notify type, vendor event contract, authorization, request routing, response and endpoint action remain deployment specific; no PBX, module, endpoint, contact, phone, URI, dialog, NOTIFY, response, packet, reboot, resync or call was inspected or testedAdvancedDocumentation based · not lab tested

Start with the device or application contract

Record the exact vendor or application documentation for the Event header, content type, body, target, authorization, supported firmware and expected action. Asterisk can construct and send a NOTIFY, but it does not define a handset vendor’s reboot, resync, message-waiting or other private event contract.

Treat a copied notify type as executable device control. Review its scope, change window and rollback before use; a syntactically valid request may be ignored, rejected or trigger a disruptive action.

Choose one target model explicitly

The current CLI and AMI surfaces can target an endpoint, an arbitrary URI or a PJSIP channel for an in-dialog NOTIFY. The dialplan application targets an arbitrary URI when to is supplied, or the current channel’s SIP dialog when it is omitted. Those are different routing and identity models.

An endpoint label is not the same evidence as one physical device, an arbitrary URI is not an endpoint configuration, and a channel is not a registration contact. Preserve the actual destination selected by Asterisk rather than inferring it from an extension number.

Build headers and content through the supported interface

A named section in pjsip_notify.conf provides reusable key-value pairs. A key named Content appends a body line; other keys become SIP headers. Current Asterisk documentation reserves Call-ID, Contact, CSeq, To, From, Record-Route, Route and Via, so the module—not a notify profile—owns those fields.

AMI accepts a named Option or repeated Variable values. The dialplan application accepts a named option or a list of header and body values. Do not paste an AMI envelope into dialplan or assume a dialplan argument is a configuration section.

Treat arbitrary-URI sending as a separate configuration boundary

Current Asterisk documentation requires a valid default_outbound_endpoint to send PJSIPNotify to an arbitrary URI. That endpoint supplies outbound request behavior and message Contact; it does not prove the URI is authorized, reachable or associated with the intended device.

Inspect the loaded global value and referenced endpoint before sending. Do not create a broad default endpoint merely to bypass a targeting failure, and do not substitute a guessed contact URI harvested from unrelated logs.

Keep event-subscription semantics separate from vendor commands

RFC 6665 defines NOTIFY within SIP event packages: Event identifies the package, Subscription-State carries subscription state, and matching uses dialog and event information. Asterisk’s manual sending surfaces can also be used for vendor-defined or application-specific messages.

Do not claim that an unsolicited device-control NOTIFY created or updated an RFC subscription. Conversely, do not omit package-required Event, Subscription-State or body semantics from a real subscription workflow merely because a proprietary endpoint command worked without them.

Prove request, response and action as three stages

For one authorized target, capture the loaded notify type or inline values, selected target mode, resolved request URI, transport, sanitized NOTIFY, immediate SIP response and independently observed endpoint or application result. A 2xx response accepts the SIP transaction; it does not prove a reboot, configuration fetch or other requested action completed.

Repeat a safe control where the action is intentionally absent, and retain the exact profile revision and removal path. Redact addresses, credentials, device identifiers and payload secrets. This guide is documentation-derived; no PBX, endpoint, request or action was tested.

Asterisk dialplan — send a named NOTIFY inside the current PJSIP dialog
[notify-lab]
exten => s,1,PJSIPNotify(,approved-dialog-notify)
 same => n,Return()

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

Hub

Asterisk

Understand the programmable PBX and follow the Asterisk 22 LTS documentation baseline.

Explore topic →
Guide · Asterisk 22 LTS

Asterisk PJSIP: understand the configuration objects

Connect endpoint behavior, authentication, contacts and transport without collapsing them into one account setting.

Read guide →
Guide · Asterisk 22 LTS

Asterisk dialplan: contexts, patterns and loaded-call evidence

Build a restricted Asterisk 22 call path, then prove its context, match, priorities and runtime behavior separately.

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 →
Reference · SIP standards; extension support depends on both peers

SIP SUBSCRIBE and NOTIFY: presence, BLF and event state

Separate event subscriptions from registration and identify stale phone indicators.

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 →
Troubleshooting · Current Asterisk branch-23 PJSIPNotify dialplan, AMI, res_pjsip_notify and res_pjsip configuration documentation, the October 9, 2024 Asterisk feature introduction, and RFC 6665 reviewed October 13, 2026; the dialplan application is documented since Asterisk 18.25.0, 20.10.0 and 21.5.0, while installed maintenance release, loaded module, endpoint and contact state, default outbound endpoint, configured notify type, vendor event contract, authorization, request routing, response and endpoint action remain deployment specific; no PBX, module, endpoint, contact, phone, URI, dialog, NOTIFY, response, packet, reboot, resync or call was inspected or tested

Asterisk PJSIP NOTIFY is not sent, is rejected or is ignored

Trace feature availability, notify content, target mode, loaded endpoint state, request routing, SIP response and endpoint action before changing a global PJSIP endpoint.

Read guide →