[asterisk-biz] Remote SIP monitor

[Olle E. Johansson]

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: 76a02abe54fbbacf23574acf0903a068 at 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