If you have a busy system, the activity output on the Asterisk CLI screen is totally useless. It scrolls so fast with so much information that you really can’t make sense of anything you see on the screen, and there is no way to limit this information to only to certain important commands and outputs which you really care about for your system. So then how to troubleshoot a call on such a system.
By default Asterisk stores call activity log in folder /var/log/asterisk either in file named messages or file named full. As the name suggests, the full file has more detailed record, and this is what we shall consider for the purpose of this blog.
This file can be hundred of mega byte in size based on how busy your system is. In order to analyze the contents of this file for a particular call, first of all what you need to do is to find the session id for that call. If you carefully note on the What you need to do for troubleshooting purposes is to extract a single call from it in a separate file and and then analyze it.
Consider the following example. Today a client of mine called regarding some issue calling a particular number. We shall assume the number was 7055623000. Now for my particular dial plan, which is very complex, but because I have personally hand coded it all from scratch, I know every line of it. So I would know where a particular call starts and how the dial plan flows. But even if I won’t, I would ask the client for:
- The number the client was having trouble with
- The time when the client was having this trouble.
When you have the number, i.e. 7055623000 in this case and you know the time of problem was around 11:40, open the log file in a text editor or viewer and search for this number. In my dialplan it would look something like following:
[2011-02-24 11:40:15] VERBOSE[13102] logger.c: -- Executing [7055623000@outbound:1] SetGlobalVar("SIP/200.10-b6b41328", "CALL_DIRECTION=OUT") in new stack [2011-02-24 11:40:15] VERBOSE[13102] logger.c: -- Executing [7055623000@outbound:2] Set("SIP/200.10-b6b41328", "userid="10"") in new stack [2011-02-24 11:40:15] VERBOSE[13102] logger.c: -- Executing [7055623000@outbound:3] NoOp("SIP/200.10-b6b41328", " - - - Incoming CID is 0 - - - ") in new stack [2011-02-24 11:40:15] VERBOSE[13102] logger.c: -- Executing [7055623000@outbound:4] GotoIf("SIP/200.10-b6b41328", "1?5:7") in new stack [2011-02-24 11:40:15] VERBOSE[13102] logger.c: -- Executing [7055623000@outbound:5] Verbose("SIP/200.10-b6b41328", " - - - Changing caller id for outbound call - - - ") in new stack [2011-02-24 11:40:15] VERBOSE[13102] logger.c: -- Executing [7055623000@outbound:6] Macro("SIP/200.10-b6b41328", "set_callerid|200") in new stack [2011-02-24 11:40:15] VERBOSE[13102] logger.c: -- Executing [s@macro-set_callerid:1] Set("SIP/200.10-b6b41328", "ext=200") in new stack [2011-02-24 11:40:15] VERBOSE[13102] logger.c: -- Executing [s@macro-set_callerid:2] NoOp("SIP/200.10-b6b41328", "_______________________________________________________________________________________________") in new stack [2011-02-24 11:40:15] VERBOSE[13102] logger.c: -- Executing [s@macro-set_callerid:3] NoOp("SIP/200.10-b6b41328", " S E T C A L L E R I D A N D N A M E ") in new stack [2011-02-24 11:40:15] VERBOSE[13102] logger.c: -- Executing [s@macro-set_callerid:4] NoOp("SIP/200.10-b6b41328", "_________________________________________________________________________________________
You can see that there was only one call made to this number at 11:40. Next see the session id of this particular call, which is b6b41328. Each and every call has a unique session id, and this is using which you’ll extract this one call from the big log file. Do it as follows:
cat /var/log/asterisk/full | grep 'b6b41328' > temp
This will extract all the call activity against the given session id in a file named temp.
Now you simply open the temp file, which is small in size, meaning reading it is not that difficult, and go over it line by line to see where the problem is.
It can take you just under a minute to figure out the problem or many hours, depending upon how familiar you are with the dial plan you are dealing with. Or if it is a syntax related issue, then how good you are with the version of asterisk itself you are using. But at least of you have isolated the part of the big log file where the problem resides.
Recent Comments