6 jan 2010 kl. 09.31 skrev Matt Riddell:

> On 6/01/10 9:14 PM, Olle E. Johansson wrote:
>> I would like feedback on what's missing in the AMI in order to monitor an 
>> Asterisk platform. I've added a lot of events and some actions to AMI in 
>> order to enhance monitoring, but new ideas are always welcome.
> 
> RTCP :)
> 
> That's probably it.

Event: RTPQuality
Privilege: call,all
Channel: SIP/jarl.webway.se-00000006
PVTcallid: 76a02abe54fbbacf23574acf0903a...@192.168.40.12
RTPmedia: audio
RTPsendformat: ulaw
RTPrecvformat: ulaw
RTPlocalssrc: 1461473865
RTPremotessrc: 1365699479
RTPrtt: 0.000000
RTPLocalJitter: 0.000052
RTPRemoteJitter: 0.000000
RTPLocalPacketLoss: 0
RTPRemotePacketLoss: 0


>From my pinefrog-1.4 branch :-)
There's a lot to be done here. I'm adding manager events and storing data in a 
realtime database - one record per call leg. What I'm wondering is how we 
should handle call transfers and hold situations. A call that's transferred has 
multiple streams and RTCP is only valid for one stream. We should propably send 
one message like this per stream and have a counter. If you call someone 
locally and then transfers that person to me - the first call will be fine, but 
going from you all the way to the deep frozen north will means that a lot of 
packets just give up, freeze to death and die so that part of the call will be 
awful. We need to make sure we separate the issues and that we're somehow able 
to relate quality to defined peers in sip.conf. The RTCP engine in Asterisk 
needs an overhaul, and I got partial funding to do it. Sitting with wireshark, 
asterisk and five different phones and compare the RTCP traffic. Seems like the 
implementations vary on the phone side as well.

> 
> I'd kinda like to be able to get memory, cpu, disk info, via the manager 
> because all up that's what I care about pretty much on most of the 
> nodes, but understand that they don't really have much to do with Asterisk.
Well, we could have a res_system.so module that did that.

> 
> Reverse Triggers would be nice :D
> 
> Like, connect to port x on addr y if you get a certain event and send 
> some info.
We do have that in voicemail. I was thinking about it for the named ACLs. 
Personally I think if we expose the information in manager and the security 
events log, a third party app could send snmp traps or nagios events. The 
res_snmp code is hard to get into and I don't think we have a trap API in there 
- but that's of course one standardized way of doing it.

> That way you could have central daemons that log from end nodes.
Yes.
> 
> You can always connect back to the Manager and parse the info, but with 
> a lot of machines the load can get kinda high.
> 
> If Asterisk were able to make an outbound connection you'd only see 
> traffic when something was up.
Or an asterisk monitor running on that machine.

I also made a dialplan app where you can check that a manager account is logged 
in. If it's not, if the monitor is missing, you can perform actions inside your 
asterisk now. It's not merged yet, waiting for approval in reviewboard, but I 
have it running in production.

This is really an interesting discussion!

/O
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

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

Reply via email to