Continual Test Call, Monitoring Concept

[Husker97]

Greetings PIAF community,

I am working on setting up monitoring for a call center, where the call center uses a solution from Cisco. For monitoring, we are doing the typical SNMP-based NMS setup watching all the routers, servers, etc for the typical CPU, RAM, network, etc. We are also using Cisco IP SLA (formerly called SAA, and before that RTR) between sites to measure WAN health.

I have a new monitoring concept in my head, and I'm trying to figure out if it is possible to do this.

At the end of the day, a call center really needs to be able to make & receive calls and transport audio from A to B and B to A (although this really applies to any distributed telephony system). A good way to test this is to make phone calls and see if they work. However, making multiple discreet calls is tedious. What if we made a phone call, kept the call active 24/7, and sent a known audio signal in both directions? Then, in some manner we detect the existence of that audio on the other side (so the audio from A is detected at B by a listening device). If the audio does anything strange (e.g., stutters, drops, etc), then there is some problem with some part of the infrastructure (be it network, server, etc). Conceptually this would be an outstanding "early warning" indicator.

If we used PIAF, I figure we could easily script the creation of a call and have some on hold music play or feed sound in some manner. However, is there some way to measure the audio on the other side, in an automated way? Some softphone that would detect if audio is there or not?

Is this a feasible setup, and is it technically possible? And, does this concept even make sense?

 

[jeremywillden]

Two thoughts:
1. The process of setting up and tearing down calls is also potentially important. Perhaps instead of a single sustained call, do a 5-minute call, start a new one just before hanging up the old one.
2. Monitoring for music on hold or something that's humanly recognizable is harder to monitor on the remote side. Perhaps a test pattern that cycles through various audio frequencies at a fixed rate would be easier for the receiver to detect.

 

[wardmundy]

If you used trunks with SMS support (such as Vitelity's new DIDs), you could simply send SMS messages regularly and check for delivery. Audio is so messy.

Another idea might be to send a very brief voicemail to a Google Voice account, have it transcribed, and then grep the transcription of the messages every few minutes to see if delivery was successful.