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).

A SIPREC recorder could record what is happening on the two trunks traversing the SBC. There could be a recording for Leg 1 and another recording for Leg 2.

I say could because you can configure SIPREC (at least on the Avaya SBC) to be applied to various configurations. Lets say inbound calls come from IP A, and outbound calls to to IP B (very simplistic view of the world here). You could configure the SBC to only perform SIPREC on calls from IP A.

You could also configure the ASBC other ways that might impact what calls were handled by SIPREC (recorded) or not. The ASBC is very flexible in this regard.

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.

A session border controller based SIPREC call recording solution will be able to record one or both calls and both parties in the call - Assuming that the calls use SIP for the PSTN/Enterprise ingress/egress.

You can search this page for 'SIPREC' for some potential candidate call recording solutions (note that there are also call analytics solutions that make use of SIPREC). Note that while the listed recording solutions tend to make use of Application Enablement Services for call metadata, the recorder may be capabable of recording calls without access to TSAPI meta data. Note also that this is not a complete listing of possible solutions in the market - just ones that have been successfully Compliance Tested https://www.devconnectprogram.com/site/global/compliance_testing/application_notes/search/index.gsp

I can find nothing that says it is _supported_.

As to it working I think it could - at least for a while - it depends on the behavior of the load balancer and what is balancing, and the nature of the application.

JTAPI (which is a Java implementation of TSAPI) sets up a connection from the client to AES by first exchanging information across port A, and then AES tells the application to setup a connection on port B. The client complies and communication then occurs on port B for an indefinite period (I have seen connections that have been established >> 1 year).

When the LB shifts the traffic if TCP is not disrupted, I feel things will continue to work. If the shift causes TCP to be brought down, then I would view that this will be problematic deployment. If the LB shifting looses a packet or two, they should be re-transmitted, and things proceed unnoticed except for a small delay on an event or request.
When a connection fails, the onus is on the application to create a new session and re-build state. This can be time consuming; for some applications the initialization period can last 10s of minutes. Depending on the application this may be very disruptive (contact center monitoring) or occur quickly enough to even be noticed (click to call or call forwarding activation application). Unfortunately, I have encountered numerous applications that need rebooted to recover when the session fails, and if this the nature of the application you are considering – you will probably view this as problematic. All of this will factor into your perception of it 'working.'

Any complaints about stability of the link are sure to be met with a response of test without the load balancer in the path and proceed from there. The vast majority of the issues with link stability are related to the network (firewalls are notorious for timing out a session and dropping the TCP layer), the remaining few percent come from poor implementation of the protocol in the application (thread misuse), or a bug in the client leading to dropping the connection in some situation.

I feel it is important to better understand what a cluster is, and then if a single AES is managing both call flows I suggest opening a ticket where we can examine the full AES TSAPI g3 and csta traces. It may be to get OCI information there is a requirement that the application was sent information about the original call, and in the tranfer to cluster 2 it never was informed about the original call, and thus OCI information is not sent, because the second cluster is not expected to be able to take advantage of it. This really requires a deeper investigation if a single AES is involved.

Is a "cluster" equivilent to an Application Enablement Services server, and cluster 1 and 2 use different AE Services servers?

I don't know the answer, but by enabling TSAPI tracing, you could observe the information coming from CM to AES and get a better understanding of what is occurring. I would not be surprised to find out that OCI information is something that AE Services maintains, and by switching AE Services servers during the transfer the second AES is unaware of the OCI information that AES 1 had.

[url]https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/support/faq/tsapi/index.gsp?tab=general&accordion=faq-5-collapse
[/url]

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)

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.

DevConnect does not provide API Assistance for Oceana. That support comes directly from the product team to Oceana customers. I do not have detailed instructions on the mechanism to request support for Oceana APIs, but would imagine Customers are expected to open onecare tickets with the nature of their API support questions.

There are so many ways to manipulate called number, in so many places - the answer is no. In a few rare cases you can get one of the vector directory numbers (there can be a sequence of VDNs used - you only get one of the numbers) in lieu of some other version of the extension that is ringing - that occurs in the context of contact center calls and it is my impression that is not what you are working on.

correct, there is no product generally available (public) release that contains the fix to the issue.

The current Experience Portal release remains at 8.1.2
You can check to see if there are newer releases by using
www.avaya.com/support
selecting Software Downloads
Entering Experience Portal
Selecting a release of 8.1.x
clicking the search magnifying glass
looking at the listed releases.

And yes if you need the patch, please open a DevConnect Support Ticket.

The acronym AMM stands for Avaya Multimedia Messaging.
The acronym ACS stands for Avaya Communication Server Configuration.
The acronym UCCP stands for Unified Communications and Collaboration Platform.
The acronym WCS stands for Web Collaboration Service.

Context often helps in this situation as many acroynms have multiple expansions.
AMM might be Avaya Meetings Manager
ACS might be Avaya Client Servcices