Hi,

We have recently encountered a problem where the aesconnector could not retrieve the UUI data, but checking from AES TSAPI trace logs, the UUI was actually propagated for the corresponding call.

This behavior occurs much frequently over the past few months, whereas previously it only occurs a few times.

We have also restarted Tomcat, but problem still persists. Any help will be very grateful!


EP version: 7.0.1
AES version: 6.3.3 SP3




Many thanks

Are you using OD and AES connector? I would need the logs to see what you are talking about.

Hi Wilson,


We will gather the required logs for study.

At the mean time, have you ever heard of adding a 1 second delay in vector before routing the call to IVR in order for the UUI data to have time to propagate?


Many thanks

This might make sense if we can determine the UUI is not delivered in time.

I see.....

Its very strange, as the systems were running fine for over 2 years, and it is just recently that UUI data are not propagated in AES. Hence we are quite confirm it is not a configuration problem, instead we suspect it could be either of the following:

1. The AES and Web application servers have been running for a long time and may require a reboot
2. The AES and Web application servers are running slow, hence adding a 1 second delay in vector may help to have enough buffer time for the UUI data to be delivered.


Do you think the above points would be valid?

Thanks

I don't have enough information to make a guess.

Hi Wilson,

We have some new update on this case.

We performed the following 2 changes and below is the symptom:

Change 1:
Added 1 second delay in vector before the call is assigned to AAEP


Change 2:
Reboot the EMC server


And we have the following obeservation:
Change 1:
Instead of assigning "Agent ID" to the UUI field, the "VDN" is assigned



Change 2:
After rebooting the server, everything seems to resumed normal. But the problem reported in Change 1 still occurs occasionally.


I can elaborate some more on how the flow works:

Customer dial to Hotline > IVR picks up call > assign VDN1 to UUI and transfer the call to CSR

CSR picks up the call and ask if customer would like to participate in survey > if yes, then assign the CSR Agent ID number to UUI field and transfer the call to VDN1

IVR survey hotline answers the call, and writes the UUI "Agent ID" to database for record keeping

Now, the problem is, occasionally the VDN1 UUI value is captured in Survey hotline. Whereas in normal case, the UUI should be the Agent ID


Many thanks

It would help me better to understand the problem if you can show me some logs both the app trace.log and aesconnector log when the problem occurs.

Hi Wilson,

I have attached some logs for your checking, incident occurred on 21/1 and 27/1.
There are screenshots which highlighted the wrong "Agent ID" captured.


4580 and 4581 are VDN

Where as it suppose to be capturing 4708 or 4744, which are Agent IDs

So I looked the aes connector logs, I only see 4580 or 4581 is being used as UUI

27/01/2019 08:30:43:253 DEBUG - CTICallOperation.makeCall 4240: Connecting with UUI 4581...

27/01/2019 08:30:43:253 DEBUG - CTICallOperation.makeCall 4240: Connecting with UUI 4580...

The UUI should be assigned by the application. I am not sure how your application really works and how you expect it to be assigned the agent ID. Is something in the application logic that you can explain?

Hi Wilson,

Yes, you are correct. The UUI value is assigned by our custom made EMC application.

There are actually 2 areas where the UUI value will be assigned.
The first step is from IVR (AAEP).
The second step is from EMC desktop to IVR (AAEP).

Now, the UUI 4581 and 4580 is assigned by IVR. Whereas 47xx is assigned by EMC application.
Our assumption, is that the EMC application did not replace the previous UUI value, hence 4581 and 4580 is still carried back to IVR.

We wonder if this could be a timing issue, where the EMC application initiated the Call Transfer command, but did not assign the UUI value fast enough before the transfer is completed.

FYI, the whole solution have been running for many years, until recently (around 1/2 year ago), the problem start to rose, where the UUI value could not be inserted into the UUI field by our custom made EMC application.

We have rebooted the EMC server a few weeks ago, and the problem seems to have some improvements. We wonder if rebooting the AES server could help on this too.

Let me know your thoughts on this, some advice or ideas would be much appreciated!

So you are actually talking about incoming calls in IVR like this one below and the uui is supposed to be 47xx. Do you have the JTAPI log on the app server? That is where AES connector is getting this from.

27/01/2019 08:35:51:369 DEBUG - CallInfoData.CallInfoData:4240: callid 4551
27/01/2019 08:35:51:369 DEBUG - CallInfoData.CallInfoData:4240: ani 28143499
27/01/2019 08:35:51:369 DEBUG - CallInfoData.CallInfoData:4240: dnis 4581
27/01/2019 08:35:51:369 DEBUG - CallInfoData.CallInfoData:4240: ucid 00001045481548549344
27/01/2019 08:35:51:369 DEBUG - CallInfoData.CallInfoData:4240: uui 4581

Hi Wilson,

Hope all is well.

We found that the problem may be located on the XML server of the EMC service.
After we restarted the service, Agent ID information were able to propagate in the TSAPI trace log.

The "ecLogicalAgent" field actually shows agent ID.
Whereas in failed situation the value "ecOther" is returned

The current workaround is to restart the "XML Server" service everyday.

We also have another server running EMC as a backup, and found that the issue occurs around after 20 days of operation.

Do you have any experience or idea on this?




Many thanks!

I don't have any experience with EMC.

I would suggest you raise case with Avaya CM support teamm for this. The reason being we would have run an ASAI MST on the CM Side to determine whether CM is sending UUI which is received in SIP header over the ASAI messages to AES. AES would be able to provide the UUI to the application over TSAPI only when it has received it from the CM over ASAI firstbankcard