cancel
Showing results for 
Search instead for 
Did you mean: 

Nuisance Caller/CDR

Jonathan_Mc
IR Partner

Nuisance Caller/CDR

Hi
Could the product be also utilised to show (using live CDR data) instances where you have repeat callers(using CLI) and also if you had a customer report a nusance/abusive caller you could use the product to flag any instances where the particular 'nuisance' CLI is presented to the system?

This would then flag an event/alert and allow the administrator to take corrective action.

What about for short calls? Can these be tracked in the current system by analysing CDR output?
Tags (1)
2 REPLIES 2
ArronMeyer
06 Trekker

Re: Nuisance Caller/CDR

I would like to see some information about this as well. I'd like notifications sent for calls dialing an emergency number (911 in the USA).

Re: Nuisance Caller/CDR

Hi Arron.

Coming from a PBX background of Nortel and Avaya, designing for multi-national solutions and their (911) implementations, I would firstly ask, what would you want to do with detail about Emergency Calls in Prognosis.

I personaly would say, that it can only be of historical interest if displayed anywhere in a Prognosis Dashboard or Report. Even a specific alert or email could only serve as a prompt to check after the event. There are no mechanisms to accept a response to an alert in Prognosis, other than refreshing the alert if not acknowledged: its not going to wake you up.

The CM has two inbuilt mechanisms that if configured, will alert specific Attendents or Extensions of an active Emergency Call, in CM it is EON (Emergency Onsite Notification) known as Crisis Alert and in CS1K it is OSN (OnSite Notification) declared in the ESA data block.

Both are audible/visual alerts for an emergency call as it is generated. These also generate error messaging over SNMP which I have used to generate email notifications as an ADDITIONAL prompt that the event has occured, with gateway traps showing which trunk was used to present the call too (for correct routing confirmation).

These mechanisms, available to Prognosis, can never be relied upon as the primary alert, simply because there is no guarantee that the path utilised to pass the alert, will be available when required to pass this critical messaging into Prognosis. It could not be relied upon for someone to act on in a life threatening situation.

 

You have to consider the legal consequences of an employer that needs to act to save life and react to an emergency call generated within their own environment. The functionality of alerting is designed into the communications solution, Prognosis can never be a substitute. The functionality of summary reporting is also built into the solution.

Prognosis could only be a collector and reporting tool on the traps generated for the event as anadditional process. Although a nice to have, and Im sure others would be in that camp, I would be wary of those who have visibility of the alerts on Prognosis becoming the first to react and subverting the processes that must be utilised or the responsibilities of other functionaries, in the customers business.

 

Avaya CM also has an additional print routine, Emergency Access Summary Report, that can be configured to output daily to a printer (Hospitality feature).

 

To summarise:

1. Mechanisms already exist in CM to alert in the event of an emergency call.

2. CM has a daily report that can be activated, to deliver a print routine summarizing the emergency calls generated in the reporting period.

3. Prognosis will receive trap alarms for emergency calls (MIBs), CDR records would not be the best source for creating a report in Prognosis.

4. Prognosis output should not be relied upon as an alerting mechanism for emergency calls, as it is far removed over additional paths, mechanisms and devices, from where alerting is fundemental to the customers communications solution and legal responsibilities..