WOW - Customer actually went thru the support process and resolved the issue. Details below. You can close this ticket.


===========================================
It was great working with everyone on the bridge today. We applied the HotFix for AES 7.0.1 SP3 and this issue is corrected also with SP4.

Here are the release notes for SP4:

Avaya Aura 7.0.1 SP4 Release Notes https://support.avaya.com/css/P8/documents/101037575

AES-15660 - In a certain call scenario AE Services was not providing the deviceID in the Established event report over the device monitor association to the application.

Here is the KB article that is for both AES 6.3.3 SP6 and AES 7.0.1 SP3 which had the same issue: https://support.avaya.com/kb/ext/SOLN300043

==============================================

We have a standard SSC recording App. We GetDeviceId, egisterTErminal and StartMonitor etc etc. Same basic recording stuff. This app has worked since AES/CM Version 4.x.

Since customer updated from 6 to CM7.x and AES 7.x, all non-internal outbound calls (calls hitting the PSTN) don't have an Established message delivered to the recorder in the 3rd Party Monitor. This prevents the recorder from attempting to conference onto these calls.

Each Outbound call produces messaging like the below:

onServiceInitiatedEvent:
onOriginatedEvent:
onConnectionCleared:

There used to be an onEstablishedEvent between originated and connection cleared.

V6.x and below would have this sequence.

onServiceInitiatedEvent:
onOriginatedEvent:
onEstablishedEvent:
onConnectionCleared:


Any ideas?

Hello, we have a recording solution that needs POM agent events to determine call starts and stops.

In CM/AES we get this via DMCC.NET

In IP Office we get this via CCT.NET

In Proactive Contact Dialer we get this via EventAPI (Corba/TAO)

How do we do this in POM??

dotNET is preferred.

Thanks

John, we are using the RTD SDK and Sample App that comes with the SDK. Its asking for a username and password but every account we can think of is failing with invalid user ID.

The PDF says:

Note: The NIrtd_login user name parameter is set up using the Server Configuration tool. For more information about how to create these users, see the Contact Center Manager Administrator’s Guide.

I do not see anything in Server Config Tool relative to RTD or NIrtd_login. Nor can we find the proper "Contact Center Manager Administrators Guide" that explains how to configure the users.

Whats next?

Sorry John, I did not mean EventAPI (That's a Proactive Contact API) I meant DevLink. Could DevLink help with ACD Stats for IP Office running either version of Contact Center (ACCS or IPOCC)?

If I focus on RTD for ACCS how do I get ACD Stats for IPOCC?

What about EventAPI? Where does that come into play? Is that an IPOffice only thing or is that an ACCS or CC thing?

I would like to receive ACD stats for IP Office Service Edition. Can I get these stats regardless if there is ACCS or IPOCC?

Currently I'm using CCT.NET APIs to get call activity and agent activity and could, in theory, crunch my own numbers. However, I don't see call events in CCT.NET when they arrive in queue, only when presented to the agent. If a call hits the queue and gets abandon I don't ever know it was there. This of course will skew my crunched numbers.

I'm using these version:

Avaya IPOffice Server Edition Version 9.1.5.0 Build 145
CCT.NET ClientAPIVersion [8.2.0.19]
CCT.NET ServerAPIVersion [9.0.0.9]

Excellent explanation. Thank you for the background. I can see how Agent Events would not necessarily be needed for call control and the overhead would not be needed.

We are attempting a few features with DMCC Agent Events for lighting up dashboards, screen pops, and other real time elements within our product that deal with agent states. One in particular is a screen recording component that starts when the call begins and needs to run thru "After Call Work" and stop when the agent is "Ready" again. For this we need to know when a call starts (no problem - onEstablished) to when the call ends (no problem - onConnectionCleared) to when After Call Work beings (problem - event wont fire) until back to ready (problem - event wont fire).

I suppose a work around would be to start polling after we receive conncleared and poll until they are "ready" again. In the middle would be after call work. Of course this gets crazy tricky because now you are talking about maintaining a state machine where you count CallStarts and CallStops and when are you "done". After each call id is cleared or when there are no more active call ids. I was hoping for events to fire so I could just catch and put in a DB for processing by other elements. Running a state machine is doable but a ton of overhead on its own.

Thank you for your response.

However, that is flat out theeeee most ugliest solution ever. That's like saying poll the device to find out when a call is held. Hell NO, there is an onHeldEvent for that.

Why isn't there an AgentReadyEvent for when the agent is ready. Actually there is..... They started coding it because you can wire up the event handler, it just doesn't fire. Why would they compile in an implementation that does not work or is incomplete.

Using the SDK I can write the code below. The problem is only the onHeld Event will fire. The other 3 are hanging out clipping their toe nails.

ThirdPartyCallController.ThirdPartyCallControlEvents ThirdPartyEvents = new ThirdPartyCallController.ThirdPartyCallControlEvents(false);
ThirdPartyEvents.HeldEvent = true;
ThirdPartyEvents.AgentNotReadyEvent = true;
ThirdPartyEvents.AgentReadyEvent = true;
ThirdPartyEvents.AgentWorkingAfterCallEvent = true;
serviceProvider.getThirdPartyCallController.StartMonitor(_Item.DmccDevice.getDeviceIdAsString, ThirdPartyEvents, _Item);

serviceProvider.getThirdPartyCallController.OnAgentNotReadyEvent += new AgentNotReadyEventHandler(ThirdPartyEventMonitor_OnAgentNotReadyEvent);
serviceProvider.getThirdPartyCallController.OnAgentReadyEvent += new AgentReadyEventHandler(ThirdPartyEventMonitor_OnAgentReadyEvent);
serviceProvider.getThirdPartyCallController.OnAgentWorkingAfterCallEvent += new AgentWorkingAfterCallEventHandler(ThirdPartyEventMonitor_OnAgentWorkingAfterCallEvent);
serviceProvider.getThirdPartyCallController.OnHeldEvent += new HeldEventHandler(ThirdPartyEventMonitor_OnHeldEvent);

What's the Status of these EVENTS?

The need for these events does not lend itself to polling. I need to know every time an agent changes state. Am I to poll GetAgentState every 500 milliseconds for 2000 agents all logged into 2 or more skills? that would be 4000 plus calls to AES every half second. That is gross overload on the network and AES.

These must be handled via EVENTS that fire as call backs otherwise they are useless.

Thoughts?

Anyone have any advice on where to start for Call Recording on IP Office.

We currently have multiple solutions for Aura using DMCC.net API. Is that available in IP Office.

We've also heard newer versions (IPOCC and Select) can come bundled with some sort of recording capability. Can a 3rd party solution Tap those recordings or harvest them and pull them in. What format are they?

Also, where would I get CTI information such as alerting,active,held,retreived and Metadata such as ANI,DNIS,Skill,Queue,VDN,UCID etc?

Where to begin?

No not yet

I need to retrieve and store the following stats, by agent, by group, by call center etc.

Calls per Hour
Number of Calls Taken
Total Number of Calls
Average Hold Time
Percentage of Time in AUX
Percent of Calls Answered
Average Speed of Answer
Percentage of Overflow Calls

I'm not even sure where to begin. We have done many different DMCC implementations for monitoring events and recording calls but I wouldn't know where these stats live.

I've researched a bit on DevConnect and it looks like I need to get stats from CMS using either ODBC or CLINT.

Where to being??

We are a C# .net house so I would need some advise relative to windows and .net.

Thank you.

Yes, this is a call recording application.

I have asked the customer for their SR-#.

We did not re-register and re-create monitors. I might have explained the sequence of events incorrectly.

On start up we new a service provider and wire up startappresponse, resetappresponse, serverconndown and
serverconnnotactive. Then we call startapplicationsession. This is synchronous, no activity occurs until the call to startappsession returns. We get a startApplicationSessionResponse and make note of the
session id.

Next, we start our initialization. For SO, we do a getdeviceid and start monitors (thirdparty events and
phone events) on the agent phones and getdeviceid, start monitors (callinformationlink events and media
events) and register terminal on the dmcc phones. Finally, we dial feature access code. For SSC its the same process except no dialing of feature access.

During this start up process, On the agent phone, we wait for getdeviceidresponse before starting monitors. On the DMCC phone we wait for getdeviceidresponse before starting monitors and then wait for onstartmonitorresponse before registeringterminal and then wait for onregisterterminalresponse before dialing feature access codes. However, we dont wait for the entire lifecycle of one item (agent phone an dmcc phone pair) to complete before going onto the next item in our list. We do however have a sleep interval between adding devices to the collection to ease the activity at startup, normally 250 mils per item, higher if AES is farther away and slower to respond.

Once we are completely initialized, we simply receive events and act on them accordingly. Life is good.

Now for the serverconndown event.

Previously, prior to your post recommending we read chapter 4, we would consider serverconndown as a catastrophic event and thus gracefully shut down all our devices and stop our service (at least attempt to anyways). Last week, we changed this logic to invoke serviceprovider.reconnect. We would have expected this to fire onresetapplicationsessionresponse but it seems to fire
onstartapplicationsessionresponse again. If thats the case no big deal we just needed to understand the sequence. Although we did seem to get a onresetapplicationsessionresponse out of nowhere (while life was good and before the first onserverconndown and thus before calling .reconnect). What is the cause of
onresetapplicationresponse (could not find it in the SDK doc). Now when we do get a serverconndown . . . After the serverconndown event and thus after .reconnect, if we get an error in onstartapplicationsessionresponse then we consider it catastrophic and gracefully shutdown, if not we
consider it okay and carry on.

That is where we are now. Do you agree with the startup procedures? Do you agree with the handling of the ServerConnDown event? The only thing we have not done from chapter 4 is the OnMissedAtLeastOneKeepAliveEvent (not sure of the value other than for logging purposes), should we add that callback and do a .reconnect, the doc was not clear.

I have opened support ticket: 14282