VoIP.info Guide

Asterisk PJSIP History: bounded in-memory SIP evidence

Capture a short SIP interval in memory, filter it by supported fields and preserve one dialog without turning permanent tracing into a memory or privacy risk.

Reviewed 2026-10-18Current Asterisk res_pjsip_history source plus official PJSIP history, troubleshooting, logging and CHANNEL documentation reviewed October 15, 2026; the history module has extended support status in current source and was introduced in Asterisk 13.8.0, while exact module availability, CLI grammar, loaded state, memory headroom, message volume, logger filters and retention policy remain installation specific; no host, module, process, memory state, endpoint, trunk, message, capture, credential, packet, dialog or live call was inspected or testedAdvancedDocumentation based · not lab tested

Choose history, logger or packet capture deliberately

Asterisk documents pjsip set logger as a live protocol trace that writes received and transmitted SIP messages through logging. res_pjsip_history is a separate module: it retains messages in process memory after capture is enabled and lets an operator inspect or filter them later. A network packet capture observes an interface instead. None of the three proves what an unseen remote hop received.

Use history when a brief, authorized reproduction needs later CLI inspection without flooding the live console. Use the logger when a persisted Asterisk log is required, and use a packet capture when transport, retransmission or interface evidence matters. Preserve the tool, interface, time window and direction with every conclusion.

Verify the running module before enabling capture

Confirm the exact Asterisk version, inspect installed CLI help and verify that res_pjsip_history is loaded. Current project source marks the module as extended support, not core support. A command shown in branch source or an older article is not proof that the deployed package includes the module or identical grammar.

Begin with an empty, approved evidence window. Record the pre-capture state, then enable history immediately before one reproduction. A message sent before capture starts cannot appear later, and a quiet summary does not prove the phone, proxy or carrier never sent it.

Separate on, off and clear

The documented lifecycle uses pjsip set history on to begin retaining messages, pjsip set history off to stop accepting new ones and pjsip set history clear to remove retained entries. Turning capture off does not clear what is already stored. Clearing first destroys the evidence needed for later filtering, while leaving capture enabled extends the scope beyond the approved incident.

Asterisk explicitly warns that history is in memory and can exhaust memory if left running. Bound the capture by time and event, watch process health under the site change policy, disable it immediately after reproduction and clear it after authorized evidence has been exported or summarized.

Filter only on fields the module supports

pjsip show history lists retained entries and their number, timestamp, direction, address and first SIP line; pjsip show history entry <number> displays one retained message. The documented query fields are entry number, timestamp, address, request method and SIP Call-ID. Current source defines comparison, boolean and LIKE operators, but installed help remains authoritative for syntax.

Start with the unfiltered summary, open one known entry and copy its exact Call-ID before adding a where expression. Keep spaces, quoting and case as the running CLI expects. A zero-result query can mean a wrong value, unsupported field, parse error or capture boundary—not absence of signaling.

Correlate a dialog without collapsing call legs

Use Call-ID, method, CSeq, direction, address and timestamp together. Asterisk is a back-to-back user agent, so its endpoint-facing and trunk-facing legs can have different Call-IDs even when they belong to one user-visible call. ${CHANNEL(pjsip,call-id)} can expose the Call-ID for one PJSIP channel; Asterisk unique ID and linked ID remain different internal correlation keys.

Authentication challenges, retransmissions, forks, transfers and session refreshes also create legitimate repeated messages. Preserve the full request and response sequence for each leg before labelling an entry duplicate, missing or unrelated.

Protect and dispose of the evidence

SIP history can contain phone numbers, network addresses, Contact and Route values, SDP, message bodies and authentication material. Restrict CLI and file access, retain only the incident window, redact shared extracts without removing the correlation fields, and follow the organization’s retention and deletion policy. Never paste reusable credentials or an unbounded production trace into a ticket.

After one supported correction, clear the old history, repeat the same bounded scenario and a nearby control, stop capture and compare sequences. Confirm the final call result and media separately because signaling history does not inspect RTP or audible quality. No host, message history, packet, dialog, media stream or live call was tested for this guide.

Correlate bounded SIP history with independent security records

PJSIP History and the security-event logger have different capture and retention paths; one cannot prove the other was complete.

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.