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.
- Asterisk PJSIP History how-to ↗
- Asterisk res_pjsip_history source and CLI definitions ↗
- Asterisk PJSIP troubleshooting guide ↗
- Asterisk debug-information collection guidance ↗
- Asterisk CHANNEL function and PJSIP Call-ID ↗
- Asterisk: Security Event Logger ↗
- Asterisk: Security Event Generation ↗
- Asterisk: Security Framework Overview ↗
- Asterisk: Logging Configuration ↗
- Asterisk: Basic Logging Commands ↗
- Asterisk: Main Configuration File ↗
- Asterisk source: res_security_log ↗
- Asterisk source: logger.conf sample ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.