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

Louisse, your question does not appear to be related to the Avaya Client SDK, but rather to Avaya Aura Contact Center. I suggest using the AACC APIs forum instead of this one for better respones.

https://www.devconnectprogram.com/forums/forums/show/13.page

First to enable TSAPI tracing see this FAQ https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/support/faq/tsapi/index.gsp?tab=general&accordion=faq-5-collapse

JTAPI utilizes TSAPI within AE Services, so that will show you what is occurring.

I am unable to read the chinese characters in the diagram and do not have access to someone who can. It reads like someone on the right places a call into sales office 1 which is sent to CUCM and delivered to a 'CC (agent?). 'That agent appears to transfer the call back to the Avaya sales office where it is delivered to a 'sales office 1(agent?).' To understand what information CUCM sends to Avaya you would want to create monitors on 'sales office 1 agent,'and perhaps on a Vector Directory Number that is used to handle the call before distributing it to sales office 1 agents. (two separate monitors - use 'monitor calls via device' for the VDN monitor).

As to the content of the CTI messaging, that is hard to say. We do not have exposure to how Cisco and Genesys manage call information. It would be best to simply create a test bed and enable the tracing and run whatever call scenarios you need and observe what data Cisco is sending to Avaya. Given with CTI there are a number of ways to do a transfer, and a number of configuration possibilites with respect to handling other out of band meta data the possibilities with the information that is provided are pretty open ended (there are a lot of them). The original calling party information may or may not be available, or it could be substituted by the CUCM CC agent information. There may be UCID information from when the call was handled by the Avaya system before it was sent to CUCM - there may not. CUCM may have attached UUI information - it may not have - Things could be configured so that in the first call let Avaya added UUI, Cisco may pass that back to Avaya as the call is transfered, or it could replace it. Digit manipulation may have changed calling or called party numbers from what the originating system sent. etcetera. I really can not guess my way to a useful answer here so much depends on system configuration, and intent, and need. At a minimum I would expect calling and called numbers. However calling may be the original number (unlikely) or it could be CUCM CC Agent's number. UCID could be from the first call leg in Avaya, or it could be a new UCID and teh two values only associatable based on information provided by the CUCM CTI event stream.

please provide some details on your environment, who supplied it, who configured it? I am looking for company, not individual there. There are a lot of possibities for the environment you are utilizing. In general a business partner or Avaya Professional Services would have deployed and have responsibilities related to initial configuration of the environment, and you would be under a maintenance contract with someone for different levels of 'day 2' support. It could be their responsibility assuming you are using a production environment, or it might be yours - especially if you are in some form of lab environment your company put together and your team did the configuration for the environment. I suggest finding out who did the initial configuration of meetings server and asking them if there is a support contract in place.