How to Read Asterisk Logs (asterisk -rvvv): A Complete Guide for Beginners and Admins

Why the log is where you should be looking

Asterisk will tell you exactly what it's doing — you just have to be watching the right window when it does. After enough late nights babysitting PBXes for call centers and small offices, I've come to trust one habit above almost everything else: keep a live console open, place the call that's misbehaving, and read what scrolls past. Nine times out of ten the "mystery" explains itself in a line or two.

A call that rings forever and never connects, audio that only travels one direction, a desk phone that quietly refuses to register — these all leave a trail. This guide is about following that trail in real time with asterisk -rvvv, so you're reading facts instead of guessing.

Before we get into the console, it's worth knowing that Asterisk doesn't keep everything in one place. The live CLI output (what asterisk -rvvv shows you) is only one source. There are also the flat log files under /var/log/asterisk/ — messages and full being the two you'll open most — plus CDR records for call accounting, and whatever custom channels you've defined in logger.conf. For hunting down a live problem, though, the CLI is the fastest feedback loop you've got, so that's where we'll spend most of our time.

New to Asterisk entirely? Get the server running first with our walkthrough on installing Asterisk 20 on Debian 12, then come back and learn to read what it's telling you.

Getting into the console

Connecting to a PBX that's already running is a one-liner:

asterisk -rvvv

The two flags are all you really need to remember. -r means "remote" — attach to the Asterisk process that's already up rather than starting a new one. -v turns up the verbosity, and it stacks: every extra v asks for another notch of detail.

asterisk -rv        # Basic verbosity (level 1)
asterisk -rvv       # Verbosity level 2
asterisk -rvvv      # Verbosity level 3
asterisk -rvvvvv    # Verbosity level 5

Crank it high enough and you'll start seeing the SIP signaling itself, codec negotiation, RTP streams — the works. My advice: start at -rvvv. It's the sweet spot where you can follow a call without drowning in packet dumps, and you can always turn it up once you know roughly where the problem lives.

Commands worth knowing once you're in

You don't have to reconnect to change what you're seeing. A handful of commands let you steer things from inside the console:

core show help                # List all available commands
core set verbose 5             # Change verbosity without reconnecting
core set debug 3               # Enable debug output
logger show channels           # View active log channels

Being able to dial the verbosity up and down on a live system, without dropping your session, is the kind of small thing that saves real time when you're mid-troubleshoot.

Watching a call happen, line by line

Here's what a healthy internal call looks like as it goes through, captured at -rvvv:

-- Executing [100@from-internal:1] Dial("SIP/101-00000001", "SIP/100") in new stack
-- Called SIP/100
-- SIP/100 is ringing
-- SIP/100 answered SIP/101-00000001
-- Channel SIP/101-00000001 joined 'simple_bridge'
-- Channel SIP/100-00000002 joined 'simple_bridge'

Read top to bottom, it's basically a story. Extension 101 dials 100, so the dialplan fires the Dial() application. Extension 100 starts ringing, then answers. Finally both channels drop into a bridge — and that bridge is the moment the two people can actually hear each other. Once you've watched a few dozen of these, a broken call jumps out immediately, because the story simply stops at the point where it went wrong.

How much detail do you actually want?

Verbosity is really just a dial for how deep you're willing to look. Roughly:

• Levels 1 gives you the high-level call progress and little else.

• Levels 2 to 3 add the application messages — Dial, Playback, and friends.

• Levels 4 to 5 start exposing the SIP signaling itself: the INVITE, the 200 OK, the BYE.

• Push past 5 and you're into raw debugging — headers, codec negotiation, RTP.

The difference is stark. At level 1, the same call I showed above is just:

-- SIP/100 is ringing
-- SIP/100 answered SIP/101-00000001

Bump it to level 4 and you're reading the actual signaling on the wire:

<--- SIP read from UDP:192.168.1.50:5060 --->
INVITE sip:100@pbx.local SIP/2.0
Via: SIP/2.0/UDP 192.168.1.50:5060;branch=z9hG4bK1234
From: "101" <sip:101@pbx.local>;tag=as2d4f1
To: <sip:100@pbx.local>
Call-ID: 8f732d01@192.168.1.50
CSeq: 102 INVITE

At that point you're essentially reading the SIP packets as they arrive, which is exactly where you want to be when a call is failing for reasons the friendly high-level messages won't explain.

Cutting through the noise

On a busy box, high verbosity turns into a firehose fast. When you already know which extension or trunk is the culprit, narrow the output to just that:

sip set debug on              # Show all SIP messages
sip set debug peer 101        # Show only for peer 101
pjsip set logger on           # For PJSIP instead of chan_sip
core set debug channel SIP/101-00000001

One quick note that trips people up: if your system runs PJSIP rather than the older chan_sip, reach for pjsip set logger on instead of the sip commands. Filtering down to a single peer means you can make a test call and read only the lines that matter, instead of scrolling through everyone else's traffic.

The CLI or the log files?

Both have their place, and the split is pretty intuitive once you've used them. The live console is for the here-and-now — you're making a test call and watching it unfold. The files on disk are for everything after the fact. The one you'll live in is:

tail -f /var/log/asterisk/full

Reach for the CLI when you can reproduce the problem on demand. Reach for the log files when you're reconstructing something that already happened, doing longer-term monitoring, or feeding events into a log aggregator. In practice I usually have both open — the console for the call I'm testing, and a tail -f running so nothing slips past.

Four everyday problems and how they read

The call won't complete

Scan for Busy, Congestion, or the classic No route to destination. That last one almost always points back at the dialplan or a misconfigured trunk rather than the phone itself.

Audio only flows one way

Turn on RTP debugging and watch where the media is (or isn't) going:

rtp set debug on

One-way and no-audio calls are nearly always a NAT or RTP issue — the signaling completes fine, but the media can't find its way back. We cover the full list of causes and fixes in our guide to fixing VoIP calls with no audio.

A phone won't register

Watch the REGISTER exchange for the peer that's struggling:

sip set debug peer 101

The response codes tell the story — a 401 followed by a successful retry is normal auth; a 403 or repeated 401s usually means wrong credentials.

Calls drop unexpectedly

Look for a BYE or CANCEL and, just as importantly, which side sent it. That single detail — was it the phone, the trunk, or Asterisk itself hanging up — points you straight at the culprit.

A cheatsheet to keep nearby

These are the commands I reach for over and over, collected in one place:

asterisk -rvvv                 # Enter CLI with verbosity
core set verbose X             # Adjust verbosity
logger reload                  # Reload logger config
sip set debug on               # Enable SIP debug
pjsip set logger on            # Enable PJSIP debug
rtp set debug on               # Debug RTP streams
core show channels             # Show active calls
dialplan show                  # View loaded dialplan

A few habits worth building

None of this is complicated, but a couple of small disciplines make a real difference over time. Start at -rvvv and only climb higher once you've narrowed things down — jumping straight to level 5 on a live box just buries the signal. Filter to a single peer whenever you can. Keep a tail -f /var/log/asterisk/full running alongside the console so you catch anything the live view misses. And go easy on high verbosity in production; it genuinely costs performance under load, so turn it back down when you're done. One last thing that'll make your life easier when you ask for help: always grab the relevant log snippet. A five-line excerpt of the actual failure gets you a useful answer far faster than describing the symptom.

Wrapping up

Getting comfortable with Asterisk logs is the single biggest jump from "I hope this works" to actually knowing what your PBX is doing. asterisk -rvvv shows you a call as it happens, higher verbosity peels back the SIP and RTP layers when you need them, and the files on disk fill in the history. The intuition comes with repetition — spin up a lab PBX, make deliberately broken test calls, and watch how each failure reads. Before long you'll diagnose half your problems just by glancing at the console.

And once you're running this in production, don't stop at reading logs — put some thought into managing them too. Sensible logger.conf channels, syslog integration, and log rotation will keep things maintainable long after the novelty wears off.

Appendix

A fully decoded SIP INVITE

INVITE sip:100@pbx.local SIP/2.0
Via: SIP/2.0/UDP 192.168.1.101:5060;branch=z9hG4bKabc123
From: "101" <sip:101@pbx.local>;tag=12345
To: <sip:100@pbx.local>
Call-ID: abc123@192.168.1.101
CSeq: 1 INVITE
Content-Type: application/sdp

An example logger.conf

[logfiles]
console => notice,warning,error,debug,verbose
messages => notice,warning,error
full => notice,warning,error,verbose,debug

Quick reference: what the messages mean