Hi all,

we're trying to develop to make sure that calls from prioritised numbers (ALARM) are answered by users (DOC), even if there is an ongoing call to a 3rd party.

Use case: Make sure alarm calls from an alarm server (like Novalert) (ALARM) are answered and acknowledged by users (DOC).

We're trying this with Avaya Aura (no elite licensing) and JTAPI. The DOC Phones are SIP/DECT mobile handhelds.

There is a solution from Avaya and Novaalert, but the problem here is, if there is an ongoing call between DOC and a 3rd party, the 3rd party can listen to the message from ALARM. The customer rejects this solution because of privacy concerns.

The problem is the handling of a 3rd party call.

Strategies:

1. manipulate the connection to the 3rd party in the tested Avya / Novaalert solution

The feature used in this scenario is "Service Observing Listen/Talk Access"

With the pure JTAP approach it seems not possible to manipulate the connction between DOC and 3rd party, because service observing is not some kind of conference.

2. monitor DOC and handle the calls

Idea: If there is a call from ALARM but DOC has a call with 3rd then drop ord forward 3rd party and accept ALARM.

Problem: the SIP/DECT handhelds can only handle 1 call. That means If there is a call on DOC then ALARM wil only receive a busy and that's it. No sinalling on DOC nothing to handle.

3. put a CTI station in front of DOC

CTI and DOC are monitored.

ALARM calls CTI and the call is forwarded to DOC. In tis situation we cann drop a 3rd party call on DOC if necessary.

This works BUT it doubles the cost because CTI stations have to be licensed and it is complex to admin.

3.1. extra dialed numbers

Idea: we reduce the number of CTI stations and identify the targeted DOC station by extra digits.

Lets say DOC is 1234, and CTI is 1111 to send an alarm call to 1234 ALARM calls 11111234

Does this work with SIP?

Questions:

Is there something we've missed?
Any Ideas?

I presume this DOC *DECT) device is not something Avaya built - as such its full support of Avaya CT (JTAPI) I is immediately suspect from my perspective.

You dont provide any detail about how this 'solution' works: "There is a solution from Avaya and Novaalert, but the problem here is, if there is an ongoing call between DOC and a 3rd party, the 3rd party can listen to the message from ALARM. The customer rejects this solution because of privacy concerns." I am guessing maybe the call is conferenced into the existing call. If so you may be able to manipulate the audio streams so the third party does not hear the alarm call using JTAPI's selective party hold capability. Since this operates within CM it may work in spite of the non Avaya SIP device being used by the DOC user.

With idea #2, cant you enable call waiting and for some time period have a second call at the device? I dont recall if there is CTI signaling for a waiting call or not - that would need tested.

With idea 3.1 the extra digits will be discarded - I dont see how that will solve the issue for you. Depending on the number of alarm numbers, if you were working with an Elite config (where VDNs and vectors were present, I could see having a set of VDNs and vectors to handle the extra digits and route to the DOC. it would also give you something to monitor for the alarm calls.

Similar to #3 You could build the equivilent of the vector using DMCC devices (a lot more coding) and use logic in the DMCC app to just fwd the call (DOC is idle), or disconnect DOC call and then route alarm call to DOC after a short pause to allow the call to fully clear. This of course is a more expensive solution in many regards.

John, thank you for your information on 2, 3, and 3.1.

About Novaalert: The Novaalert solution uses a feature called "service observation", but from the perspective of JTAPI this does not result in some kind of conference. There are not 3 connections to the call visible in JTAPI (as far as I remember).

Service Observing is a special form of conference - and there are a couple of variants of it. My guess is Novaalert is doing a version where the conference count does not increase (nothing overt on the station displays). There is also a listen only version - which would do no good here - it was built to augment call recording variants.

I am assuming there is no option to modify the Novaalert application significantly.-

There is a feature called "whisper paging" - that would help here. Perhaps by using the whisper page FAC before the DOC's extension you can get what you want here.

https://support.avaya.com/css/public/documents/101087596
Whisper Page starts on page 1402 (Chapter 188)

Thank you John,

"Whisper Paging" was a great hint. It looked very proising exactly what we're looking for.

We've tried it on our Aura 8 test system and SIP phones but unfortuately it does not work correclty.

Both participants (DOC and EXT) heard signal tone when the whisper paging was placed but then there was no audio from ALARM.

Has anyone used it with Aura 10? (Customer will upgrade to Aura 10 soon)
Has anyone any ideas?

I am not in a position to know if anyone is using it, but it is a relatively common feature in a contact center and it has existed for many many years (decades). I am pretty confident it still works - but I have not tested it in the context of this question.

I do see you are testing it with SIP phones - can you test with H.323 or Digital (DCP) phones in the R8 environment? It may be that this is one of those things that SIP stations does not fully support due to limitations of the functional protocol.

Inthis document https://download.avaya.com/css/public/documents/100108861

There is a clear indication that whisper page is supported with SIP 96xx stations. I do not know of equivilent documents for other phone models, but normally subsequent models would achieve feature parity with what came before (but not always).

Thank you for your support John,

I think we have figured it out ourselves. It seems we've used some incompatible components in our test run.