tail -f /var/log/asterisk/full | egrep --color -w
'chan_sip.*SIP/911|pbx.*SIP/911'
Are you basically using 911 as an example extension that we wanted to see
logging 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
troubleshooting for is using 1.6, so maybe it would give me something on their
version....?
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 call
through the logging to have a logical view of what happened to the call from the
time it 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.
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 life
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
troubleshooting & 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
Verbose() 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
shared 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
beginning ,since you mentioned using egrep, is figure out the Channel identifier
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 server
where all the other servers deposit their logs and use monitoring tools like
swatch, splunk, zabbix etc etc etc to parse the logs for you and generate
alerts.
I haven't came across any Asterisk-specific log parser utility so far.
Honestly, 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 to 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 course
process calls for all of the people they do business with).
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 troubleshooting issues & parsing logs.
I am hoping that someone on this mailing list can help me to realize how
ignorant 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 light". If so, I would be most
grateful.
Specifically, here are the challenges I encounter, which I would desperately
appreciate help with:
Here's an example scenario:
A customer calls me & says that a call just came in & some of their
wireless DECT phones (I know, trouble already.... :-) didn't ring, while
others did. 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 configured the bulk of our system via FreePBX 2.9.
Inbound calls are routed 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 extensions 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 call. 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 trudging
through a swampy marsh trying to put the bits & pieces together. The
challenge 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 times a call can be handed off from 1 asterisk process to another. The
result 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 phone 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 process
that starts handling the call originally, may wind up immediately taking on
another totally unrelated call after handing the initial call off to another
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 totally
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
"Date:" 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 the standard timestamp at the beginning) and then I'm only
seeing the SIP debugging, 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 parse it all can make me go cross-eyed. :-) And doing so can take a
LONG time (30+ minutes). The SIP debug lines don't necessarily tell me which
call they 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. Ultimately, I
usually can get to the bottom of it, but it literally probably takes 45-60+
minutes of just parsing through the log files before I even get to the point, of
being able to answer some seemingly simple questions.
Am I going about this the wrong way? Please say yes. Because this is literally
probably the only challenge (& sometimes frustration) I have with asterisk.
Are there [much] better ways to go about this?
I did a bit of searching online, and it seems that some people have attempted to
create tools to parse & display the asterisk full log in a more structured
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
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 just where it ended
up).
It seems to me that there should be some powerful tool that does the hard work
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 happened.
Only when we find out what happened, can we even start working on the solution.
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
that 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-microsoft-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"Microsoft
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 vlink=3Dpurple><div class=3DWordSection1><p
class=3DMsoNormal><span
style=3D'font-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;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","sans-serif";color:#1F497D'>Thanks
for the input. I wasn’t aware of ngrep. I’ll check it out. A
packet analyzer is a good idea. I am accustomed to using a packet analyzer
mostly in a “reactive” approach, 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 & was not transmitted on the
network)?<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","sans-serif";color:#1F497D'>Also,
thanks for the link in the Asterisk Cookbook. I’ll check it
out.<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","sans-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
'chan_sip.*SIP/911|pbx.*SIP/911'<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","sans-serif";color:#1F497D'><o:p> </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
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 troubleshooting for is using 1.6, so maybe it would give me
something on their
version….?<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","sans-serif";color:#1F497D'>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 call
through the logging to have a logical view of what happened to the call from the
time it 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-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","sans-serif";color:#1F497D'>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 life
of the call if I only grep the logs based on one channel
id?<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","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","sans-serif";color:#1F497D'>Doug
Mortensen<o:p></o:p></span></p><p
class=3DMsoNormal><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
style=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> </o:p></span></p><div
style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in
0in'><p class=3DMsoNormal><b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style=3D'font-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
AM<br><b>To:</b> Asterisk Users Mailing List - Non-Commercial
Discussion<br><b>Subject:</b> Re: [asterisk-users] Tips
& best practices for asterisk troubleshooting & parsing
logs<o:p></o:p></span></p></div><p
class=3DMsoNormal><o:p> </o:p></p><p
class=3DMsoNormal style=3D'margin-bottom:12.0pt'>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' <br>Interesting technique from
Astresk Cookbook, "Debugging dialplan with Verbose() <a
href=3D"http://ofps.oreilly.com/titles/9781449303822/DialplanFundamentals.html">http://ofps.oreilly.com/titles/9781449303822/DialplanFundamentals.html</a><o:p></o:p></p><div><p
class=3DMsoNormal>2011/10/27 Sammy Govind <<a
href=3D"mailto:govoiper at gmail.com">govoiper at
gmail.com</a>><o:p></o:p></p><p
class=3DMsoNormal>It was a challenge to read through all the interesting
experience you've shared 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 beginning ,since you mentioned using egrep, is figure
out the Channel identifier string from the logs for a particular call.
That's underlined below for
you.<o:p></o:p></p><div><p
class=3DMsoNormal><o:p> </o:p></p></div><div><div><blockquote
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
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";background:white'>[Oct
26 17:58:01] VERBOSE[14274] logger.c: -- Executing [s at
tc-maint:3] System("<b><u>Local/s at
tc-maint-2496,2</u></b>","/var/lib/asterisk/bin/schedtc.php
60 /var/spool/asterisk/outgoing 0") in new
stack</span><o:p></o:p></p></blockquote><p
class=3DMsoNormal><o:p> </o:p></p></div><p
class=3DMsoNormal>Once you Figure out this part use egrep 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> </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 their logs and use
monitoring tools like swatch, splunk, zabbix etc etc etc to parse the logs for
you and generate
alerts. <o:p></o:p></p></div><div><p
class=3DMsoNormal><o:p> </o:p></p></div><div><p
class=3DMsoNormal>I haven't came across any Asterisk-specific log parser
utility so far. Honestly, I never needed
one.<o:p></o:p></p></div><div><div><div><p
class=3DMsoNormal><o:p> </o:p></p><div><p
class=3DMsoNormal>On Thu, Oct 27, 2011 at 5:16 AM, Douglas Mortensen
<<a href=3D"mailto:doug at impalanetworks.com"
target=3D"_blank">doug at impalanetworks.com</a>>
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 through many issues
during this period. I have setup & manage 5 systems, which serve 6
companies total (and of course process calls for all of the people 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 troubleshooting issues
& parsing logs.<br><br>I am hoping that someone on this
mailing list can help me to realize how ignorant 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 light". If so, I would be most
grateful.<br><br>Specifically, here are the challenges I encounter,
which I would desperately appreciate help with:<br><br>Here's an
example scenario:<br><br>A customer calls me & says that a
call just came in & some of their wireless DECT phones (I know, trouble
already.... :-) didn't ring, while others did. I tell the customer that
I'll start looking into the problem immediately.<br><br>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 configured the bulk of our system via
FreePBX 2.9. Inbound calls are routed 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 extensions 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 call. Often times they then transfer the call to
another extension. However, sometimes no one answers the call, and it winds up
going to VM.<br><br>>From the logging aspect of asterisk, it
has usually felt like I am trudging through a swampy marsh trying to put the
bits & pieces together. The challenge 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 times a call can be handed off from 1 asterisk
process to another. The result 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 phone
call.<br><br>[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<br><br>Then
on a busy asterisk system, if I filter by the process id, the one process that
starts handling the call originally, may wind up immediately taking on another
totally unrelated call after handing the initial call off to another 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 totally barking up the
wrong tree.... :-)<br><br>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 "Date:" 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 the standard
timestamp at the beginning) and then I'm only seeing the SIP debugging, 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 parse it all can
make me go cross-eyed. :-) And doing so can take a LONG time (30+ minutes). The
SIP debug lines don't necessarily tell me which call they correspond with.
So if there are multiple calls going on or ringing at the same time, this can
really get hairy.<br><br>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. Ultimately, I usually can get to the bottom of it, but
it literally probably takes 45-60+ minutes of just parsing through the log files
before I even 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 (& sometimes
frustration) I have with asterisk. Are there [much] better ways to go about
this?<br><br>I did a bit of searching online, and it seems that some
people have attempted to create tools to parse & display the asterisk
full log in a more structured 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.<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 just where it ended up).<br><br>It seems to me that
there should be some powerful tool that does the hard work 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
happened.<br><br>Only when we find out what happened, can we even
start working on the solution.<br><br>If you have some insight into
reviewing, filtering & parsing asterisk logs in the process of
troubleshooting issues, I would GREATLY appreciate it.<br><br>What
approach would you take? What are the best practices, tips & secrets
that 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+, Network+, 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 Colocation Provided by <a
href=3D"http://www.api-digital.com"
target=3D"_blank">http://www.api-digital.com</a>
--<br>New to Asterisk? Join us for a live introductory webinar every
Thurs:<br>
<a href=3D"http://www.asterisk.org/hello"
target=3D"_blank">http://www.asterisk.org/hello</a><br><br>asterisk-users
mailing list<br>To UNSUBSCRIBE or update options
visit:<br> <a
href=3D"http://lists.digium.com/mailman/listinfo/asterisk-users"
target=3D"_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a></span><o:p></o:p></p></div><p
class=3DMsoNormal><o:p> </o:p></p></div></div></div><p
class=3DMsoNormal><br>--<br>_____________________________________________________________________<br>--
Bandwidth and Colocation Provided by <a
href=3D"http://www.api-digital.com"
target=3D"_blank">http://www.api-digital.com</a>
--<br>New to Asterisk? Join us for a live introductory webinar every
Thurs:<br>
<a href=3D"http://www.asterisk.org/hello"
target=3D"_blank">http://www.asterisk.org/hello</a><br><br>asterisk-users
mailing list<br>To UNSUBSCRIBE or update options
visit:<br> <a
href=3D"http://lists.digium.com/mailman/listinfo/asterisk-users"
target=3D"_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><o:p></o:p></p></div><p
class=3DMsoNormal><o:p> </o:p></p></div></body></html>
--_000_EE441A7845B3DF4DB915CE42AE3E33D203E535E04987WENAImpalai_--