[Asterisk-Dev] Like a Heartbeat for *
CW_ASN
cw_asn at fibertel.com.ar
Sun Sep 14 17:43:02 MST 2003
Ok, the main subject was Heartbeat application, to assure that * is running
with good health. But this subject it turned aside a lot of needs, and I
think that is great.
We have 2 branches for the same subject.
1-Monitoring * health (method? I not sure, but we can discuss it)
2-Traffic statistics
1-Pure-TDM switches has independent process monitoring each other,
mantaining a very simple dialog. The monitoring process sends a SMNP trap to
a Network Management application. That's we need (I presume).
2-Certainly, Traffic statistics can be obtained reading CDRs, but is not
100% accured when you use re-route features. This issue can be resolved
using counters call routes. In Pure-TDM switches this measures as known as
Grade Of Service. I don't know if these goals can be achieved with little
modifications.
This is just an opinion...
>
> A) If your application is primarily the connection of calls between
> point A and point B, then you could create an automatic dialing
> program that checked for a tone between points A and B, as if they
> were a "normal" dialing customer. Measure call completion via some
> out-of-band IP-based tool - perhaps fire off a UDP packet at the
> other end, or send an file, or something. You might even have a
> remote phone ringer hooked up to a switch to a d/a converter - make
> it as fancy or as simple as you want. If a regularly scheduled call
> fails, set off an alarm.
>
> B) If your application is primarily a database or scripted
> application that is "internal" to Asterisk, then create triggers
> inside of your scripts/dialplan that communicate with your monitoring
> system at certain points. Then, create a "dummy" user like in method
> A that calls in to your production system and performs certain tasks
> at a scheduled time. If while your dummy user is going through the
> system and the triggers are not being fired, then you have a problem.
> Set off an alarm.
>
> The nice thing about A and B is that you can use Asterisk to perform
> a large portion of the testing, since Asterisk can mimic a standard
> user fairly accurately. The only thing it can't do is detect certain
> responses on the RTP channel to verify that a call sounds "good".
> This would require some sort of MOS toolkit at each endpoint.
> (Alternately: RTCP anyone? Anyone? Anyone? Bueller?)
>
> While I understand the desire to having a fully-integrated
> "monitoring" system inside of Asterisk sounds good, I also very
> rarely find that self-monitoring applications that don't melt down in
> a way that defeats their own self-monitoring. External measurement
> from the user's perspective is always a better way to monitor.
>
> Now, if you'd asked about "measurement" of values within Asterisk,
> that is a different story...
>
> JT
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
More information about the asterisk-dev
mailing list