Asterisk CLI and PJSIP logging for one failed call

Define one failed-call evidence window

Record the exact running Asterisk version, host or instance, local timezone, source endpoint, destination, test time and observed result. Preserve whether the symptom is no attempt, local rejection, remote SIP response, early-media problem, no audio after answer or later hangup; those require different evidence. Use a non-emergency destination and an authorized test account.

Read the installed command help before collection. Asterisk commands come from loaded modules, and another release can expose different syntax. FreePBX owns generated configuration, so a CLI diagnosis does not authorize direct edits to generated PJSIP or dialplan files.

Capture the loaded relationships before the call

Inspect the named endpoint, its AOR and contacts, then separately inspect transports, outbound registrations and identify mappings that are relevant to the route. A contact can be present while identification, authentication, dialplan, codec or media policy fails. A qualified contact proves only a bounded OPTIONS exchange.

The commands below are inventory prompts, not universal proof. Replace the example object with the exact authorized name, and retain the complete focused output plus timestamp. A missing command or object can indicate an unloaded module, rejected configuration, wrong instance or different configuration backend; do not reload first and erase that evidence.

core show version
core show settings
module show like res_pjsip
pjsip show endpoint test-endpoint
pjsip show registrations
core show channels

Enable only the signaling evidence needed

Preserve existing root and current console verbosity and debug levels. If the question requires the SIP exchange, enable PJSIP logging immediately before one reproduction and disable it immediately afterward. The two commands below mark separate moments and are intentionally not a paste-as-one script. Restore any other changed levels to their recorded values, not an assumed zero.

PJSIP logging can expose identities, destinations, contact addresses, SDP and authentication exchanges. It shows messages processed by the driver, not a complete network capture, RTP delivery, decoded audio or the far end's internal decision. Bound collection by time and call; use a separately approved packet capture only when the network question requires one.

pjsip set logger on
pjsip set logger off

Correlate signaling with the application decision

Follow the complete transaction sequence: request, provisional and final responses, ACK or cancellation, and any authenticated retry. Pair it with the effective dialplan context and the named channels and bridges. Determine whether Asterisk rejected locally, attempted a downstream endpoint, received a remote refusal or established signaling before the media symptom.

Keep the Asterisk C-XXXXXXXX call identifier, channel identifiers, SIP Call-ID and CSeq separate. The Asterisk call ID is not caller ID, and transfers can introduce another Asterisk call ID while creating additional channels and SIP dialogs. For an answered call, prove the relevant PBX legs and bridge before assigning the fault to one trunk or endpoint.

Close the capture and verify the same path

Confirm the PJSIP logger is off, restore console and debug levels, record logger-channel state and check storage growth. Keep the restricted original and make a redacted sharing copy that preserves methods, status codes, sequence and relative timing without credentials or unnecessary personal data.

Correct only the demonstrated owner, then repeat the same call and one known-good control under the same bounded observation. A changed SIP response does not prove two-way audio, DTMF, transfer or recovery. No PBX, module, endpoint, AOR, contact, registration, identify object, transport, dialplan, logger, call, message, packet, media stream or repair was inspected or tested for this guide.

Choose the next evidence branch

If OPTIONS succeeds but the INVITE fails, continue with the focused reachable-but-call-fails path. If signaling answers but audio fails, move to the one-way audio investigation or no-audio investigation and preserve the exact SDP and media direction. If the loaded object itself is wrong, return to the owning standalone or FreePBX configuration workflow rather than repairing the symptom in runtime state.

When FreePBX owns the persistent logger configuration

Use the FreePBX Asterisk Logfile Settings guide to reconcile a CLI capture with the module’s saved rows, generated include, loaded logger channels, destination file and retention path.

Verify group filters before declaring output absent

The LOG_GROUP diagnostic checks function availability, assignment timing, channel ownership, filter state and console verbosity before enabling broader protocol logging.

Use a bounded internal-frame trace

The FRAME_TRACE guide narrows frame classes, channel leg and collection window before enabling broader debug output.

Correlate mutex timing with the executing channel

The lock diagnostic binds each result to the running channel, context, extension and priority before changing shared state.

Use bounded AstDB CLI evidence

The AstDB diagnostic uses database get, showkey and bounded subtree inventory on the same running instance without editing the backing file.

Prove the loaded time priority before editing policy

Use the Asterisk time-condition diagnostic to bind clock and timespec evidence to the context, extension and priority that the channel actually executed.

Bind a variable read to the executing leg

Use the variable-scope diagnostic to prove current channel, creation timing, inheritance depth and loaded priority before changing every caller or callee path.

Trace the loaded exception path by context

Use the exception-handler diagnostic to freeze the context and priority, inspect local special handlers and capture exception fields or immediate TRYSTATUS.

Inspect the exact dynamic target

Use the dialplan lookup diagnostic to compare the supplied context, extension and priority with the loaded dialplan and running branch.

Inspect channel-scoped RTP evidence before tuning

Use the Asterisk jitter-buffer diagnostic to retain exact channel, stream, SSRC, counts, jitter, loss and round-trip context.

Inspect one retained PJSIP exchange after reproduction

Use the PJSIP History guide to start a bounded capture, list entries, open one message and filter only on fields supported by the installed module.

Correlate a scrape with the running process

Use the Prometheus metrics diagnostic to preserve branch, module, listener, URI, response, target identity and live object state separately.

Correlate the ODBC resource with the channel that called it

Use the func_odbc diagnostic to preserve function arguments, row state, elapsed time, channel identity and fallback separately.

Keep an ODBC transaction timeline attached to its channel

Use the ODBC mutation diagnostic to correlate loaded functions, connection state, active transaction, completion branch and teardown.

Use PJSIP CLI output as one Realtime checkpoint

The PJSIP Realtime diagnostic reconciles CLI output with mapping, connector, row and cache rather than treating it as direct database proof.

Inspect the loaded target before diagnosing periodic audio

The periodic-hook diagnostic verifies module availability and the loaded context and extension before media changes.

Inspect the installed media-wait contract before tuning it

The silence and noise diagnostic starts with installed application help and loaded dialplan before duration or media changes.

Inspect the installed condition-wait contract before tuning it

The WaitForCondition diagnostic begins with local application help and the loaded dialplan rather than an assumed upstream syntax.

Verify the installed epoch-wait and timeout contracts

The WaitUntil diagnostic begins with local help and the loaded priority before changing the host clock or timezone.

Verify the loaded Dial contract before changing peers

The Dial diagnostic begins with local help, active priority and exact arguments before endpoint or network changes.

Verify the installed Originate contract before changing peers

The Originate diagnostic begins with local help, active priority and exact arguments before endpoint or network changes.

Capture live channel identity at Bridge invocation

The Bridge diagnostic begins with installed help, loaded arguments and the exact live target before network changes.

Verify BridgeWait and BridgeAdd before media changes

The holding diagnostic begins with installed help, module state, loaded arguments and exact live channels.

Verify installed AMI actions and permissions first

The AMI bridge diagnostic begins with local action availability, modules and manager authorization.

Verify the installed transfer action first

The AMI transfer diagnostic begins with local help, module state and manager authorization.

Confirm CancelAtxfer and atxferabort locally

The CancelAtxfer diagnostic starts with installed action help, permissions and effective feature configuration.

Confirm Local modifiers and manager action locally

The Local optimization diagnostic starts with the effective dial string, loaded action, permissions and live bridge state.

Confirm local manager action and event support

The channel snapshot diagnostic checks installed maintenance release, action help, permissions and event filtering.

Inspect the loaded AMI event contract

The AMI event diagnostic checks installed actions, manager permissions and effective filters.

Confirm the loaded UserEvent producer surface

The UserEvent diagnostic checks installed documentation, app_userevent, dialplan reachability and the manager delivery path.

Confirm the installed AMI device-state surface

The AMI device-state diagnostic gates the write action by branch maintenance release, loaded module and provider ownership.

Confirm presence modules, provider and writer

The AMI presence-state diagnostic gates each read or list by the installed modules and keeps CLI changes inside CustomPresence: ownership.

Confirm the loaded hint before diagnosing its aggregate

The AMI extension-state diagnostic starts with the installed branch, dialplan context, exact extension and mapped providers.

Compare source, loaded dialplan and reload result

The AMI dialplan diagnostic uses a narrow manager view, the actual configuration owner and a later reload as separate evidence.

Compare bounded file state with loaded module state

The AMI configuration diagnostic prevents a successful readback from standing in for parser or runtime proof.

Use module show as a bounded state check

The module capability diagnostic compares module inventory with the exact registry and runtime object the feature should expose.

Bound the administrator AMI registry check

The AMI command-inventory guide uses manager show commands and one command-detail query as an administrative comparison surface.

Inspect manager state from an administrative boundary

The AMI login diagnostic uses server-side evidence to distinguish listener, account, permission and session-lifetime faults.

Use server-side evidence to challenge a core snapshot

When AMI core data appears stale or wrong, the core-query diagnostic compares the same node and clock with the process and configuration boundary.

Challenge queue snapshots at the owning boundary

When AMI queue data appears wrong, the queue-snapshot diagnostic compares the same node and time with effective configuration, runtime state and history.

Challenge mailbox output at the owning boundary

When AMI mailbox state appears wrong, the mailbox-query diagnostic compares the same node, context, backend, folder and time.

Capture state without exposing its values

The HASH and ARRAY diagnostic records channel identity, key names, snapshot timing and branch results while redacting sensitive values.

Inspect dynamic dial targets with bounded evidence

The DIALGROUP diagnostic captures loaded function, active priority, redacted readback, status and per-leg causes without logging secrets.

Trace CURL without dumping secrets or bodies

The Asterisk CURL diagnostic captures loaded functions, effective option names, timing and result class with bounded redaction.

Confirm installed function help before tracing input

The input-parsing diagnostic checks the active dialplan and installed function syntax before changing validation.

Compare function help with the loaded dialplan

The VALID_EXTEN upgrade diagnostic combines current function inventory with dialplan show evidence from the same node.

Correlate DTMF with the channel and bridge

The dynamic-feature diagnostic keeps digit evidence, channel variables and application execution on one bounded call.

Correlate AMI variables with exact channel identity

The AMI variable diagnostic records channel lifetime, response, event and fresh-read evidence together.

Correlate AMI AstDB evidence with local inspection

The AMI AstDB diagnostic keeps exact family, key, action response and consumer evidence together.

Correlate CLI PJSIP state with completed AMI lists

The AMI inbound-registration guide preserves node, action, rows, completion and observation time.