It is possible to wrap the unmanaged code from RTD in p/invoke interface but we don't directly support that (although we would of course do our best to assist enhanced members in whatever way we could). I would PERSONALLY institute a proxy on the local network (and have done this many times in environments where multicast is failing), this simply grabs the multicast from the AACC-local-network and wraps it into a UDP stream. Of course, there are implications but, aren't there always :-)

I think that's correct, you can only access it if you have the product and appropriate support from people with administrator access. You may also be able to get it through sales and consultancy channels (I don't know, TBH) but they have chosen not to publish on DevConnect at this time.

Look at the screen-pop facilities of AAAD and AACC, perhaps? There are a number of "Configuring Screen Pop" sections in the "AACC Server Administration" document. This should allow you to launch an application when a new contact arrives.

Unfortunately, I don't really understand your other questions. It's possible that the ALERTING state is emitted multiple times but more likely that it's being emitted from multiple places, it really depends on the context of your application, I think. You might consider firing when a new contact arrives instead of looking at the terminal event (honestly, 9 times out of 10 the correct view is of the agent and the contacts and to process addresses and terminals only when absolutely necessary).

There is a popup feature of AAAD (the standard AACC agent interface) perhaps you might consider that instead?

I'm going to say that's way too involved to get into properly on the forum (but, of course, other community members should feel free to do so, if they wish) ... for my part, I'd prefer you open a [technical ticket] with that one so it can go in my work queue, however, you'd likely need to upgrade your membership too.

Quickly, I would say it means that the original call leg was lost. Most likely, the customer hung-up before the transfer and the software continued to try complete the transfer anyway. Of course, I imagine you've considered this and thus, it would take a good amount of trawling through those logs to put together the IDs and make a more informed guess.

--
[technical ticket]: https://www.devconnectprogram.com/ticket/technicalTicket

You didn't attach any trace, I don't think.

The CA which signed POM service will need to be trusted in the AACC's machine store.

Good pointer to Pridis. One thing to note (and I say this only because this is a DevConnect forum and wish to be clear), it does not *appear* that Pridis have compliance tested that solution with us (or it would be published on https://devconnectmarketplace.com and have a technical Application Note associated with it). As such, I would encourage you to qualify the support status with both Pridis *and* your Avaya Support representatives.

The most recent ones are as posted (versions match the release at time of of publication and do not necessarily indicate a functional update). So "no", there's no change (just a bugfix in PHP, I think).

Try a different browser, I think. The URL downloads the 'aacc-7_0-web-communications-jsp-sdk-updated-0216.zip' file for me. Did you get presented with and agree to the EULA (or licensing or whatever lawyer peoples call that stuff)?

I'm NOT a consultant for AACC operational issues, so my apologies in advance here, but I still don't understand the need. You would assign the appropriate skillsets to the appropriate agents and adjust your orchestration to route to the appropriate agents based on your metrics. This requires no manual intervention but is defined by your business rules and scripted in advance. You could, theoretically, adjust your application routing dynamically or, give your supervisors logins to change the skillset assignments through CCMA but I believe you may be overly focused on independent skillsets instead of restructuring them. e.g. SKILL_A + SKILL_A_OVERFLOW or, more likely, "Service Level Routing" with standby assignments and target service levels.

As previous poster said, the CCMA/SOAP interfaces might be used but they are not well suited to distributed management (i.e. potentially hundreds of clients) and you would likely want to build a CCMA proxy service (i.e. centralized) which batched and brokered the queries and responses from supervisors. This then implies distinct authentication (additional management) or proxy authentication (to the CCMA) at which point the question of just using CCMA through a browser, arises again. Certainly CCMA/SOAP can be used to streamline setup and bulk changes but I would (personally) be cautious about using it outside of that context.

In short, I realize I'm totally ignorant of your specific requirements but would urge you to look at the product designed mechanisms for handling load (and perhaps look to administration focused forums on Avaya Support) as I feel this is not a unique problem and much might be more robustly achieved by "standard" means. Apologies again if this appears unhelpful it is not my intention to be so.

--
PS: I am unsure about "multiple agents IDs", you may have multiple agent IDs in AACC/Aura but since it seems an unusual construction, I'm not sure I could guess at that any better than I can at the above; I might have multiple agents under a "master agent" and then "ready/not-ready" them but still feel it's obscure so, am probably missing something.

Since this will relate to site specific setup, I would triage your site support for this. In order to help them you will likely need to use the standard "CCMA/Historical Reporting" to illustrate the discrepancy you refer to.

Too long ago to say but I would guess this is because the socket is being torn down prematurely and is likely related to specific customer environment. My first action would be to verify the 3rd-party library versions against product versions and make sure they were tested. Beyond that, the previous advice still stands, raise this to your solution provider or, if you are the solution provider, raise a DevConnect support ticket.

I'm sorry, I think you may have the wrong forum. We do not have an Experience Portal (EP) forum on DevConnect (I do not think) but you might find one on 'support.avaya.com'.

AACC has two web-chat interfaces which *might* be used to integrate a chat service. The old WebComms interface and the new Enterprise Web Chat (EWC). I am not aware of any current solutions providing an integration to WhatsApp, nor informed about WhatsApp interfaces that I might comment on the feasibility of such an idea. I can only recommend you look at the WebComms and EWC interfaces to understand what the AACC offers in relation to chat interfaces (the sample code is for a web-proxy and has dependencies around that which may be difficult to bridge).