asterisk -vvvr
For even more verbose output try asterisk -vvvvvr. For issuing commands with standard output try asterisk -r followed by core show help.
Example
Here is an example of how to troubleshoot an inbound DID number not working.
asterisk -vvvr
Connected to Asterisk 13.9.1 currently running on pbx1 (pid = 2903)The following output is observed on the Asterisk CLI while making an inbound call
pbx1*CLI>
Executing [12345678900@from-trunk:1] Set("SIP/mysiptrunk-00000067", "__FROM_DID=12345678900") in new stack
-- Executing [12345678900@from-trunk:2] NoOp("SIP/mysiptrunk-00000067", "Received an unknown call with DID set to 12345678900") in new stack
-- Executing [12345678900@from-trunk:3] Goto("SIP/mysiptrunk-00000067", "s,a2") in new stack
-- Goto (from-trunk,s,2)
-- Executing [s@from-trunk:2] Answer("SIP/mysiptrunk-00000067", "") in new stack
-- Executing [s@from-trunk:3] Log("SIP/mysiptrunk-00000067", "WARNING,Friendly Scanner from ") in new stack
-- Executing [s@from-trunk:4] Wait("SIP/mysiptrunk-00000067", "2") in new stack
-- Executing [s@from-trunk:5] Playback("SIP/mysiptrunk-00000067", "ss-noservice") in new stack
-- <SIP/voipms-van2-pjsip-00000067> Playing 'ss-noservice.ulaw' (language 'en')
This tells us that our sip trunk, which we named mysiptrunk in our configuration, is sending us an inbound call with the DID number set to 12345678900. The message "Received an unknown call with DID set to 12345678900" tells us that Asterisk does not recognize this DID number. The end result is that asterisk plays the ss-noservice.ulaw message file. The most likely problem is that we do not have a matching inbound route with the correct DID number assigned to it.
If there is a message such as "Rejecting unknown SIP connection from xx.xx.xx.xx", that usually means the host= statement in the trunk configuration is incorrect. Sometimes trunk providers send calls from multiple IP addresses. In those situations you can create a separate trunk for each IP address the trunk provider uses.
If there are only lines that begin with Using SIP RTP TOS and Using SIP RTP COS, that could mean a missing or incorrect context= statement or incompatible codec setting in the trunk configuration.
If there is nothing at all this could also be incorrect context= or some other problem with the trunk configuration. It could also be a configuration problem on the trunk provider end.
