No subject


Fri Sep 2 03:59:05 CDT 2011


tail -f /var/log/asterisk/full | egrep --color -w 'chan_sip.*SIP/911|pbx.*S=
IP/911'

Are you basically using 911 as an example extension that we wanted to see l=
ogging for? That seems useful. Thanks. FYI, I grepped for chan_sip, and pbx=
, but didn't really get anything from those with any SIP extension logging.=
 Could that be because I'm using asterisk 1.4? FYI, the customer I'm troubl=
eshooting for is using 1.6, so maybe it would give me something on their ve=
rsion....?

Still one of my concerns is the ability to follow an inbound call from the =
time it hits asterisk, until it is finally gone. I'd like to follow the cal=
l through the logging to have a logical view of what happened to the call f=
rom the time it rang in (where the call got sent to [time conditions, queue=
s, ring groups, extensions, transfers, etc.], what phones were rung trying =
to connect the call, etc.

Any way I this can be done? Can't a call be passed off from one channel to =
another, which would leave me with only seeing a part of the logs for the l=
ife of the call if I only grep the logs based on one channel id?

Thanks,
-
Doug Mortensen
Network Consultant
Impala Networks
P: 505.327.7300

From: Anton Kvashenkin [mailto:anton.jugatsu at gmail.com]
Sent: Thursday, October 27, 2011 8:27 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] Tips & best practices for asterisk troublesho=
oting & parsing logs

Capture pcap with tshark or tcpdump for the future analysis with wireshark.=
 Ngrep is also handy tool for captaring, say, INVITE. You can use grep like=
 this: tail -f /var/log/asterisk/full | egrep --color -w 'chan_sip.*SIP/911=
|pbx.*SIP/911'
Interesting technique from Astresk Cookbook, "Debugging dialplan with Verbo=
se() http://ofps.oreilly.com/titles/9781449303822/DialplanFundamentals.html
2011/10/27 Sammy Govind <govoiper at gmail.com<mailto:govoiper at gmail.com>>
It was a challenge to read through all the interesting experience you've sh=
ared over here. I don't know what others may be using for parsing the logs =
beautifully and make them usable. What I would recommend you at the very be=
ginning ,since you mentioned using egrep, is figure out the Channel identif=
ier string from the logs for a particular call. That's underlined below for=
 you.

[Oct 26 17:58:01] VERBOSE[14274] logger.c:     -- Executing [s at tc-maint:3] =
System("Local/s at tc-maint-2496,2","/var/lib/asterisk/bin/schedtc.php 60 /var=
/spool/asterisk/outgoing 0") in new stack

Once you Figure out this part use egrep tool and you'll end up seeing only =
the data related to this particular call.

More advanced tool or techniques may involve setting up a central logging s=
erver where all the other servers deposit their logs and use monitoring too=
ls like swatch, splunk, zabbix etc etc etc to parse the logs for you and ge=
nerate alerts.

I haven't came across any Asterisk-specific log parser utility so far. Hone=
stly, I never needed one.

On Thu, Oct 27, 2011 at 5:16 AM, Douglas Mortensen <doug at impalanetworks.com=
<mailto:doug at impalanetworks.com>> wrote:
Hello all,

I have been running asterisk systems since summer of 2008. I do not claim t=
o be an expert. But I have worked through many issues during this period. I=
 have setup & manage 5 systems, which serve 6 companies total (and of cours=
e process calls for all of the people they do business with).

I have always been happy with asterisk (well, obviously less happy during t=
he problem times... :-). And I continue to prefer to us it. However, if I c=
ould name the one largest struggle that I have with asterisk, it is the fac=
ilities that it provides for troubleshooting issues & parsing logs.

I am hoping that someone on this mailing list can help me to realize how ig=
norant I really am, and how much time I have wasted parsing, "grep"ping & "=
less"ing logs manually. I am hoping that one of you can help me "see the li=
ght". If so, I would be most grateful.

Specifically, here are the challenges I encounter, which I would desperatel=
y appreciate help with:

Here's an example scenario:

A customer calls me & says that a call just came in & some of their wireles=
s DECT phones (I know, trouble already.... :-) didn't ring, while others di=
d. I tell the customer that I'll start looking into the problem immediately=
.

I am using AsteriskNOW with asterisk 1.6. So I SSH into the system & cd to =
/var/log/asterisk & start looking at the "full" log via "less". We have con=
figured the bulk of our system via FreePBX 2.9. Inbound calls are routed fi=
rst to a time condition which checks whether it is after hours. If it is no=
t afterhours, then are then routed to a queue, which rings all phones (4 wi=
reless DECT phones on 1 DECT wireless server that registers the SIP extensi=
ons on behalf of its 4 phones, and 4 more wireless DECT phones on their own=
 wireless server configured the same, and an ATA connected to a paging amp =
that rings a loud speaker). From there, someone typically will answer the c=
all. Often times they then transfer the call to another extension. However,=
 sometimes no one answers the call, and it winds up going to VM.

>From the logging aspect of asterisk, it has usually felt like I am trudgin=
g through a swampy marsh trying to put the bits & pieces together. The chal=
lenge I've seen is that the above scenario can actually consist of multiple=
 SIP calls w/ different legs. I *think* (but am not 100% sure) that often t=
imes a call can be handed off from 1 asterisk process to another. The resul=
t is that "grep"ping by the asterisk process ID shown after the VERBOSE (or=
 NOTICE or DEBUG section [see below]), I don't actually get to see the full=
 sequence of events in following  all logging that is relevant to that phon=
e call.

[Oct 26 17:58:01] VERBOSE[14274] logger.c:     -- Executing [s at tc-maint:3] =
System("Local/s at tc-maint-2496,2","/var/lib/asterisk/bin/schedtc.php 60 /var=
/spool/asterisk/outgoing 0") in new stack

Then on a busy asterisk system, if I filter by the process id, the one proc=
ess that starts handling the call originally, may wind up immediately takin=
g on another totally unrelated call after handing the initial call off to a=
nother process. If I am not extremely careful, I may wind up mistaking the =
log lines for the 2nd call, as being a part of the 1st call, and then I'm t=
otally barking up the wrong tree.... :-)

Another option I've tried is to enable SIP debugging. Generally, I do like =
this. And one nice thing is that asterisk seems to usually add the SIP "Dat=
e:" parameter with its SIP invites, etc. The result is that I can grep the =
asterisk log like this `egrep -v ^"\[" full` (SIP debug lines don't have th=
e standard timestamp at the beginning) and then I'm only seeing the SIP deb=
ugging, in a pretty clean output. Still, there can be a LOT of SIP traffic =
going on, when I'm ringing 9 different extensions from a queue. Trying to p=
arse it all can make me go cross-eyed. :-) And doing so can take a LONG tim=
e (30+ minutes). The SIP debug lines don't necessarily tell me which call t=
hey correspond with. So if there are multiple calls going on or ringing at =
the same time, this can really get hairy.

So more or less, I think I've sort of established the type of experience I =
have with parsing the asterisk logging in troubleshooting issues. Ultimatel=
y, I usually can get to the bottom of it, but it literally probably takes 4=
5-60+ minutes of just parsing through the log files before I even get to th=
e point, of being able to answer some seemingly simple questions.

Am I going about this the wrong way? Please say yes. Because this is litera=
lly probably the only challenge (& sometimes frustration) I have with aster=
isk. Are there [much] better ways to go about this?

I did a bit of searching online, and it seems that some people have attempt=
ed to create tools to parse & display the asterisk full log in a more struc=
tured simplified manner. But my initial impression was that these were more=
 of "good ideas" that people started on, but they haven't really matured to=
 the point of being really helpful with these types of situations.

A part of me just thinks that it just shouldn't be so hard to be able to te=
ll whether a certain extension did actually get a SIP INVITE sent to it, or=
 whether it responded, or to simply just follow the chain of the route that=
 a call took through asterisk prior to running into trouble (or just where =
it ended up).

It seems to me that there should be some powerful tool that does the hard w=
ork of parsing the related log lines for us, so that we can just *quickly* =
review its output & see the sequence of events to determine exactly what ha=
ppened.

Only when we find out what happened, can we even start working on the solut=
ion.

If you have some insight into reviewing, filtering & parsing asterisk logs =
in the process of troubleshooting issues, I would GREATLY appreciate it.

What approach would you take? What are the best practices, tips & secrets t=
hat you've developed?

Thanks all!
-
Doug Mortensen
Network Consultant
Impala Networks Inc
CCNA, MCSA, Security+, A+
Linux+, Network+, Server+
A.A.S. Information Technology
.
www.impalanetworks.com<http://www.impalanetworks.com>
P: (505) 327-7300<tel:%28505%29%20327-7300>
F: (505) 327-7545<tel:%28505%29%20327-7545>


--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
              http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users


--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
              http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users


--_000_EE441A7845B3DF4DB915CE42AE3E33D203E535E04987WENAImpalai_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'f=
ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Anton,<o:=
p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;fon=
t-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p>=
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";color:#1F497D'>Thanks for the input. I wasn&#8217;t aware of n=
grep. I&#8217;ll check it out. A packet analyzer is a good idea. I am accus=
tomed to using a packet analyzer mostly in a &#8220;reactive&#8221; approac=
h, or during an incident. Are you suggesting that I just setup a capture to=
 be running continuously until we become aware of the problem, and then at =
that point, review it to see what really happened (regarding what was &amp;=
 was not transmitted on the network)?<o:p></o:p></span></p><p class=3DMsoNo=
rmal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";col=
or:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span style=3D=
'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Also, t=
hanks for the link in the Asterisk Cookbook. I&#8217;ll check it out.<o:p><=
/o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-f=
amily:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sa=
ns-serif";color:#1F497D'>From your egrep example here:<o:p></o:p></span></p=
><p class=3DMsoNormal>tail -f /var/log/asterisk/full | egrep --color -w 'ch=
an_sip.*SIP/911|pbx.*SIP/911'<span style=3D'font-size:11.0pt;font-family:"C=
alibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=3DMsoNor=
mal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";colo=
r:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span style=3D'=
font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Are you =
basically using 911 as an example extension that we wanted to see logging f=
or? That seems useful. Thanks. FYI, I grepped for chan_sip, and pbx, but di=
dn&#8217;t really get anything from those with any SIP extension logging. C=
ould that be because I&#8217;m using asterisk 1.4? FYI, the customer I&#821=
7;m troubleshooting for is using 1.6, so maybe it would give me something o=
n their version&#8230;.?<o:p></o:p></span></p><p class=3DMsoNormal><span st=
yle=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11=
.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Still one of my conc=
erns is the ability to follow an inbound call from the time it hits asteris=
k, until it is finally gone. I&#8217;d like to follow the call through the =
logging to have a logical view of what happened to the call from the time i=
t rang in (where the call got sent to [time conditions, queues, ring groups=
, extensions, transfers, etc.], what phones were rung trying to connect the=
 call, etc.<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-s=
ize:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-fam=
ily:"Calibri","sans-serif";color:#1F497D'>Any way I this can be done? Can&#=
8217;t a call be passed off from one channel to another, which would leave =
me with only seeing a part of the logs for the life of the call if I only g=
rep the logs based on one channel id?<o:p></o:p></span></p><p class=3DMsoNo=
rmal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";col=
or:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span style=3D=
'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks,=
<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;=
font-family:"Calibri","sans-serif";color:#1F497D'>-<o:p></o:p></span></p><p=
 class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","s=
ans-serif";color:#1F497D'>Doug Mortensen<o:p></o:p></span></p><p class=3DMs=
oNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";=
color:#1F497D'>Network Consultant<o:p></o:p></span></p><p class=3DMsoNormal=
><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#=
1F497D'>Impala Networks<o:p></o:p></span></p><p class=3DMsoNormal><span sty=
le=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>P:=
 505.327.7300<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font=
-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;<=
/o:p></span></p><div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;pa=
dding:3.0pt 0in 0in 0in'><p class=3DMsoNormal><b><span style=3D'font-size:1=
0.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style=3D'fon=
t-size:10.0pt;font-family:"Tahoma","sans-serif"'> Anton Kvashenkin [mailto:=
anton.jugatsu at gmail.com] <br><b>Sent:</b> Thursday, October 27, 2011 8:27 A=
M<br><b>To:</b> Asterisk Users Mailing List - Non-Commercial Discussion<br>=
<b>Subject:</b> Re: [asterisk-users] Tips &amp; best practices for asterisk=
 troubleshooting &amp; parsing logs<o:p></o:p></span></p></div><p class=3DM=
soNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal style=3D'margin-bottom:1=
2.0pt'>Capture pcap with tshark or tcpdump for the future analysis with wir=
eshark. Ngrep is also handy tool for captaring, say, INVITE. You can use gr=
ep like this: tail -f /var/log/asterisk/full | egrep --color -w 'chan_sip.*=
SIP/911|pbx.*SIP/911' <br>Interesting technique from Astresk Cookbook, &quo=
t;Debugging dialplan with Verbose() <a href=3D"http://ofps.oreilly.com/titl=
es/9781449303822/DialplanFundamentals.html">http://ofps.oreilly.com/titles/=
9781449303822/DialplanFundamentals.html</a><o:p></o:p></p><div><p class=3DM=
soNormal>2011/10/27 Sammy Govind &lt;<a href=3D"mailto:govoiper at gmail.com">=
govoiper at gmail.com</a>&gt;<o:p></o:p></p><p class=3DMsoNormal>It was a chal=
lenge to read through all the interesting experience you've shared over her=
e. I don't know what others may be using for parsing the logs beautifully a=
nd make them usable. What I would recommend you at the very beginning ,sinc=
e you mentioned using egrep, is figure out the Channel identifier string fr=
om the logs for a particular call. That's underlined below for you.<o:p></o=
:p></p><div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><div><bloc=
kquote style=3D'border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in=
 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=3DMsoNormal><span s=
tyle=3D'font-size:10.0pt;font-family:"Arial","sans-serif";background:white'=
>[Oct 26 17:58:01] VERBOSE[14274] logger.c: &nbsp; &nbsp; -- Executing [s at t=
c-maint:3] System(&quot;<b><u>Local/s at tc-maint-2496,2</u></b>&quot;,&quot;/=
var/lib/asterisk/bin/schedtc.php 60 /var/spool/asterisk/outgoing 0&quot;) i=
n new stack</span><o:p></o:p></p></blockquote><p class=3DMsoNormal><o:p>&nb=
sp;</o:p></p></div><p class=3DMsoNormal>Once you Figure out this part use e=
grep tool and you'll end up seeing only the data related to this particular=
 call.<o:p></o:p></p></div><div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><=
/div><div><p class=3DMsoNormal>More advanced tool or techniques may involve=
 setting up a central logging server where all the other servers deposit th=
eir logs and use monitoring tools like swatch, splunk, zabbix etc etc etc t=
o parse the logs for you and generate alerts.&nbsp;<o:p></o:p></p></div><di=
v><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=3DMsoNormal=
>I haven't came across any Asterisk-specific log parser utility so far. Hon=
estly, I never needed one.<o:p></o:p></p></div><div><div><div><p class=3DMs=
oNormal><o:p>&nbsp;</o:p></p><div><p class=3DMsoNormal>On Thu, Oct 27, 2011=
 at 5:16 AM, Douglas Mortensen &lt;<a href=3D"mailto:doug at impalanetworks.co=
m" target=3D"_blank">doug at impalanetworks.com</a>&gt; wrote:<o:p></o:p></p><=
p class=3DMsoNormal>Hello all,<br><br>I have been running asterisk systems =
since summer of 2008. I do not claim to be an expert. But I have worked thr=
ough many issues during this period. I have setup &amp; manage 5 systems, w=
hich serve 6 companies total (and of course process calls for all of the pe=
ople they do business with).<br><br>I have always been happy with asterisk =
(well, obviously less happy during the problem times... :-). And I continue=
 to prefer to us it. However, if I could name the one largest struggle that=
 I have with asterisk, it is the facilities that it provides for troublesho=
oting issues &amp; parsing logs.<br><br>I am hoping that someone on this ma=
iling list can help me to realize how ignorant I really am, and how much ti=
me I have wasted parsing, &quot;grep&quot;ping &amp; &quot;less&quot;ing lo=
gs manually. I am hoping that one of you can help me &quot;see the light&qu=
ot;. If so, I would be most grateful.<br><br>Specifically, here are the cha=
llenges I encounter, which I would desperately appreciate help with:<br><br=
>Here's an example scenario:<br><br>A customer calls me &amp; says that a c=
all just came in &amp; some of their wireless DECT phones (I know, trouble =
already.... :-) didn't ring, while others did. I tell the customer that I'l=
l start looking into the problem immediately.<br><br>I am using AsteriskNOW=
 with asterisk 1.6. So I SSH into the system &amp; cd to /var/log/asterisk =
&amp; start looking at the &quot;full&quot; log via &quot;less&quot;. We ha=
ve configured the bulk of our system via FreePBX 2.9. Inbound calls are rou=
ted first to a time condition which checks whether it is after hours. If it=
 is not afterhours, then are then routed to a queue, which rings all phones=
 (4 wireless DECT phones on 1 DECT wireless server that registers the SIP e=
xtensions on behalf of its 4 phones, and 4 more wireless DECT phones on the=
ir own wireless server configured the same, and an ATA connected to a pagin=
g amp that rings a loud speaker). From there, someone typically will answer=
 the call. Often times they then transfer the call to another extension. Ho=
wever, sometimes no one answers the call, and it winds up going to VM.<br><=
br>&gt;From the logging aspect of asterisk, it has usually felt like I am t=
rudging through a swampy marsh trying to put the bits &amp; pieces together=
. The challenge I've seen is that the above scenario can actually consist o=
f multiple SIP calls w/ different legs. I *think* (but am not 100% sure) th=
at often times a call can be handed off from 1 asterisk process to another.=
 The result is that &quot;grep&quot;ping by the asterisk process ID shown a=
fter the VERBOSE (or NOTICE or DEBUG section [see below]), I don't actually=
 get to see the full sequence of events in following &nbsp;all logging that=
 is relevant to that phone call.<br><br>[Oct 26 17:58:01] VERBOSE[14274] lo=
gger.c: &nbsp; &nbsp; -- Executing [s at tc-maint:3] System(&quot;Local/s at tc-m=
aint-2496,2&quot;,&quot;/var/lib/asterisk/bin/schedtc.php 60 /var/spool/ast=
erisk/outgoing 0&quot;) in new stack<br><br>Then on a busy asterisk system,=
 if I filter by the process id, the one process that starts handling the ca=
ll originally, may wind up immediately taking on another totally unrelated =
call after handing the initial call off to another process. If I am not ext=
remely careful, I may wind up mistaking the log lines for the 2nd call, as =
being a part of the 1st call, and then I'm totally barking up the wrong tre=
e.... :-)<br><br>Another option I've tried is to enable SIP debugging. Gene=
rally, I do like this. And one nice thing is that asterisk seems to usually=
 add the SIP &quot;Date:&quot; parameter with its SIP invites, etc. The res=
ult is that I can grep the asterisk log like this `egrep -v ^&quot;\[&quot;=
 full` (SIP debug lines don't have the standard timestamp at the beginning)=
 and then I'm only seeing the SIP debugging, in a pretty clean output. Stil=
l, there can be a LOT of SIP traffic going on, when I'm ringing 9 different=
 extensions from a queue. Trying to parse it all can make me go cross-eyed.=
 :-) And doing so can take a LONG time (30+ minutes). The SIP debug lines d=
on't necessarily tell me which call they correspond with. So if there are m=
ultiple calls going on or ringing at the same time, this can really get hai=
ry.<br><br>So more or less, I think I've sort of established the type of ex=
perience I have with parsing the asterisk logging in troubleshooting issues=
. Ultimately, I usually can get to the bottom of it, but it literally proba=
bly takes 45-60+ minutes of just parsing through the log files before I eve=
n get to the point, of being able to answer some seemingly simple questions=
.<br><br>Am I going about this the wrong way? Please say yes. Because this =
is literally probably the only challenge (&amp; sometimes frustration) I ha=
ve with asterisk. Are there [much] better ways to go about this?<br><br>I d=
id a bit of searching online, and it seems that some people have attempted =
to create tools to parse &amp; display the asterisk full log in a more stru=
ctured simplified manner. But my initial impression was that these were mor=
e of &quot;good ideas&quot; that people started on, but they haven't really=
 matured to the point of being really helpful with these types of situation=
s.<br><br>A part of me just thinks that it just shouldn't be so hard to be =
able to tell whether a certain extension did actually get a SIP INVITE sent=
 to it, or whether it responded, or to simply just follow the chain of the =
route that a call took through asterisk prior to running into trouble (or j=
ust where it ended up).<br><br>It seems to me that there should be some pow=
erful tool that does the hard work of parsing the related log lines for us,=
 so that we can just *quickly* review its output &amp; see the sequence of =
events to determine exactly what happened.<br><br>Only when we find out wha=
t happened, can we even start working on the solution.<br><br>If you have s=
ome insight into reviewing, filtering &amp; parsing asterisk logs in the pr=
ocess of troubleshooting issues, I would GREATLY appreciate it.<br><br>What=
 approach would you take? What are the best practices, tips &amp; secrets t=
hat you've developed?<br><br>Thanks all!<br>-<br>Doug Mortensen<br>Network =
Consultant<br>Impala Networks Inc<br>CCNA, MCSA, Security+, A+<br>Linux+, N=
etwork+, Server+<br>A.A.S. Information Technology<br>.<br><a href=3D"http:/=
/www.impalanetworks.com" target=3D"_blank">www.impalanetworks.com</a><br>P:=
 <a href=3D"tel:%28505%29%20327-7300" target=3D"_blank">(505) 327-7300</a><=
br>F: <a href=3D"tel:%28505%29%20327-7545" target=3D"_blank">(505) 327-7545=
</a><br><span style=3D'color:#888888'><br><br>--<br>_______________________=
______________________________________________<br>-- Bandwidth and Colocati=
on Provided by <a href=3D"http://www.api-digital.com" target=3D"_blank">htt=
p://www.api-digital.com</a> --<br>New to Asterisk? Join us for a live intro=
ductory webinar every Thurs:<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; <a href=3D"http://www.asterisk.org/hello" target=3D"_blank">http://ww=
w.asterisk.org/hello</a><br><br>asterisk-users mailing list<br>To UNSUBSCRI=
BE or update options visit:<br>&nbsp; <a href=3D"http://lists.digium.com/ma=
ilman/listinfo/asterisk-users" target=3D"_blank">http://lists.digium.com/ma=
ilman/listinfo/asterisk-users</a></span><o:p></o:p></p></div><p class=3DMso=
Normal><o:p>&nbsp;</o:p></p></div></div></div><p class=3DMsoNormal><br>--<b=
r>_____________________________________________________________________<br>=
-- Bandwidth and Colocation Provided by <a href=3D"http://www.api-digital.c=
om" target=3D"_blank">http://www.api-digital.com</a> --<br>New to Asterisk?=
 Join us for a live introductory webinar every Thurs:<br>&nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; <a href=3D"http://www.asterisk.org/hello" ta=
rget=3D"_blank">http://www.asterisk.org/hello</a><br><br>asterisk-users mai=
ling list<br>To UNSUBSCRIBE or update options visit:<br>&nbsp; <a href=3D"h=
ttp://lists.digium.com/mailman/listinfo/asterisk-users" target=3D"_blank">h=
ttp://lists.digium.com/mailman/listinfo/asterisk-users</a><o:p></o:p></p></=
div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></body></html>=

--_000_EE441A7845B3DF4DB915CE42AE3E33D203E535E04987WENAImpalai_--



More information about the asterisk-users mailing list