VoIP.info Guide

Asterisk logging without permanent debug overload

Capture enough evidence to explain a failure while controlling access and storage.

Reviewed 2026-09-07Asterisk 22 LTSIntermediateDocumentation based · not lab tested

Choose the evidence needed

A failed registration, an unexpected dialplan destination and broken audio require different evidence. Record timestamp, endpoint, called destination and call identifier. Begin with normal logs and the CLI state before enabling detailed protocol tracing.

Capture a bounded reproduction

Identify the smallest test that reproduces the symptom. If SIP logging is necessary, enable it for the reproduction window and disable it afterward. The example shows the CLI toggle, not a recommendation to retain all signaling indefinitely.

A packet capture or SIP trace can expose phone numbers, identities and authentication material. Restrict access and redact a copy before sharing it. Run the first command before the test and the second immediately after it.

Asterisk 22 CLI
pjsip set logger on
pjsip set logger off

Make logs operationally sustainable

Configure rotation and available disk monitoring for your installation. Check that time synchronization and timezone reporting let you correlate PBX, firewall and provider events. A successful logging change should not exhaust the same filesystem that stores voicemail.

Interpret absence carefully

No event in one log does not prove that no packet arrived; the relevant category or component may not be logged. Compare a known-good call with the failing case and confirm capture scope. Keep the original evidence before applying a targeted change, then repeat the same reproduction to verify the outcome.

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.