HI Wilson,

Did you share any suggestions on this issue thread, I would be glad to see the response shared.

Hi Team,

Could you please let us know if Jtapi 8.1.3 sdk is compatible with AES connector 6.3.3 ?

AAOD - 7.1
AESC - 6.3.3.27
JTAPI - 6.3.3.aes-21284
Runtimeconfig - 7.21.04.01
Tomcat - 8.5.23

Regards,
Sandeep.

Hi Team,

Could you please let us know if Jtapi 8.1.3 sdk is compatible with AES connector 6.3.3 ?

AAOD - 7.1
AESC - 6.3.3.27
JTAPI - 6.3.3.aes-21284
Runtimeconfig - 7.21.04.01
Tomcat - 8.5.23

HI Team,

Could any body clarify what does INVALID Call state mean in the AES trace for a callid!

AES connector logs:
Good call#
23/09/2020 16:21:18:948 DEBUG - DisconnectUUI.doSetDisconnectUUI:setting disconnect UUI as |Y|OTP Verified |Successfully for callid:187
23/09/2020 16:21:18:963 DEBUG - getObserversFromCallId: gathering observers... done waiting on sync list size of list is 250
23/09/2020 16:21:18:963 DEBUG - getObserversFromCallId: done gathering observers
23/09/2020 16:21:18:963 DEBUG - CTIConnectorManager.dropCall: Call state of call 187 is ACTIVE

Bad Call#
23/09/2020 16:22:30:685 DEBUG - DisconnectUUI.doSetDisconnectUUI:setting disconnect UUI as |Y|OTP Verified |Successfully for callid:258
23/09/2020 16:22:30:700 DEBUG - getObserversFromCallId: gathering observers... done waiting on sync list size of list is 250
23/09/2020 16:22:30:700 DEBUG - getObserversFromCallId: done gathering observers
23/09/2020 16:22:30:700 DEBUG - CTIConnectorManager.dropCall: Call state of call 258 is INVALID


Regards,
Sandeep.

A customer would like to know the below:
In their OD based IVR application grammar .java file, they specify JSON based grammar for Google Speech.

Google Speech documentation lists 14 parameters:
https://cloud.google.com/speech-to-text/docs/reference/rest/v1/RecognitionConfig

They would like to know whether all these are supported in OD-based IVR application or selected ones only?

JSON representation
{
"encoding": enum (AudioEncoding),
"sampleRateHertz": integer,
"audioChannelCount": integer,
"enableSeparateRecognitionPerChannel": boolean,
"languageCode": string,
"maxAlternatives": integer,
"profanityFilter": boolean,
"speechContexts": [
{
object (SpeechContext)
}
],
"enableWordTimeOffsets": boolean,
"enableAutomaticPunctuation": boolean,
"diarizationConfig": {
object (SpeakerDiarizationConfig)
},
"metadata": {
object (RecognitionMetadata)
},
"model": string,
"useEnhanced": boolean
}


Regards,
Sandeep.

Thanks Wilson for the inputs.

Hi Dev Connect team,

Any inputs on the library query posted.
Appreciate your response. Thanks.

One of the customer is using an Email Application which initiates outbound call using standard pdcobcall-07.10.12.02.jar library.
They would like to know – how this library getNextServerFromZone defines which server to use? As they had noticed the app configured on Prod EPM was also showing IP of a test EPM when trying to get the EPM server from zone intermittently. Issue was resolved after restart of app server.

This is a trace of a good scenario:
23/01/2020 03:45:39:112 INFO - 5387F0C266EF473595D76E0E622FA32E:/VPN_email_starter : Executing IPluggableExecutable com.avaya.sce.pdc.pe.launchobcall : Launching vxml outbound call to ->VPNRinging: with toURI:message:subject
23/01/2020 03:45:39:112 DEBUG - 5387F0C266EF473595D76E0E622FA32E:/VPN_email_starter : getNextServerFromZone: One server in zone:0 found, returning server:10.xxx.xx.34
23/01/2020 03:45:39:112 DEBUG - 5387F0C266EF473595D76E0E622FA32E:/VPN_email_starter : VPService: invoking webservice: https://10.10.18.34/axis2/services/VPAppIntfService
23/01/2020 03:45:39:118 DEBUG - 5387F0C266EF473595D76E0E622FA32E:/VPN_email_starter : VPService: secure connection complete
23/01/2020 03:45:39:118 DEBUG - 5387F0C266EF473595D76E0E622FA32E:/VPN_email_starter : LaunchVXML call to webservice with following arguments: appname:VPNRinging applurl:http://hq-avaya-app1:7080/VPNRinging/Start touri:989149736349 parameters: uui:1579740107 zone:

This is a bad case:

23/01/2020 23:45:54:093 INFO - 5B3EE28BFE670C73CFE8B16C119988E2:/VPN_email_starter : Executing IPluggableExecutable com.avaya.sce.pdc.pe.launchobcall : Launching vxml outbound call to ->VPNRinging: with toURI:message:subject
23/01/2020 23:45:54:093 DEBUG - 5B3EE28BFE670C73CFE8B16C119988E2:/VPN_email_starter : getNextServerFromZone: One server in zone:0 found, returning server:10.xxx.xx.131
23/01/2020 23:45:54:093 DEBUG - 5B3EE28BFE670C73CFE8B16C119988E2:/VPN_email_starter : VPService: invoking webservice: https://10.10.18.131/axis2/services/VPAppIntfService
23/01/2020 23:45:54:099 DEBUG - 5B3EE28BFE670C73CFE8B16C119988E2:/VPN_email_starter : VPService: secure connection complete
23/01/2020 23:45:54:099 DEBUG - 5B3EE28BFE670C73CFE8B16C119988E2:/VPN_email_starter : LaunchVXML call to webservice with following arguments: appname:VPNRinging applurl:http://hq-avaya-app1:7080/VPNRinging/Start touri:989046605469 parameters: uui:1579812167 zone:
23/01/2020 23:45:55:166 ERROR - 5B3EE28BFE670C73CFE8B16C119988E2:/VPN_email_starter : LaunchVXML error:Transport error: 401 Error: Unauthorized
23/01/2020 23:45:55:166 INFO - 5B3EE28BFE670C73CFE8B16C119988E2:/VPN_email_starter : Completed IPluggableExecutable com.avaya.sce.pdc.pe.launchobcall

The address 10.xxx.xx.34 is a product EPM server. The address 10.xxx.xx.131 is a test server.

hi Wilson,

This is also seen for the latest OD version. Could you advice what can we check further from OD side.

OD 7.10.12.02
license server section of runtimeconfig displays message Licenseurl is Invlaid, server is not up once logged off and logged in.

When the same url is updated or when we click update the license true. Then again if you logoff and login and check we get the same exception.

Is there is any known issue in this version ?
Any advice on how to mitigate this exception seen on and off.

Regards,
Sandeep.

App developed with OD 7.0.1 , in the flow there is a DB operation where the DB timeout parameter is set to 60 sec for transaction timeout.

When the call flow is interpreted on IVR we see that it is waiting for 60 secs and then throwing a error.badfetch on platform.
The Platform timeout is 15 secs.

Customer would like to know why the MPP timeout is not being considered. As we know the platform timeout for a page will be overridden by the app, would like to know if there is any default timeout that comes into picture for the app during the DB transaction.

From the app trace we see the DB transaction failing after 60 sec timeout:
Line 204757: 27/03/2018 16:03:41:819 INFO - 65652F4AB1BA727A7AA7B40D23E9827F:/IVR101 : [expression4] Expression [AppVariables:TransferCount] Is Null [null]
Line 204758: 27/03/2018 16:03:41:819 INFO - 65652F4AB1BA727A7AA7B40D23E9827F:/IVR101 : [expression5] Expression [AppVariables:TransferCount] Is Empty
Line 204759: 27/03/2018 16:03:41:819 INFO - 65652F4AB1BA727A7AA7B40D23E9827F:/IVR101 : Using SCESession 65652F4AB1BA727A7AA7B40D23E9827F:/IVR101 servlet : CheckAndGetCustSegment
Line 204759: 27/03/2018 16:03:41:819 INFO - 65652F4AB1BA727A7AA7B40D23E9827F:/IVR101 : Using SCESession 65652F4AB1BA727A7AA7B40D23E9827F:/IVR101 servlet : CheckAndGetCustSegment
Line 204760: 27/03/2018 16:03:41:819 DEBUG - 65652F4AB1BA727A7AA7B40D23E9827F:/IVR101 : Customer Segment (CUSTCAT) Value =
Line 204761: 27/03/2018 16:03:41:819 DEBUG - 65652F4AB1BA727A7AA7B40D23E9827F:/IVR101 : CUSTCAT is EMPTY - Getting Customer Segment (CUSTCAT) For = 067144149
Line 204762: 27/03/2018 16:03:41:819 DEBUG - 65652F4AB1BA727A7AA7B40D23E9827F:/IVR101 : Request To Adapter - SessionID = 8df371c3-301f-4172-ac8f-da07ff9b4afa
Line 204763: 27/03/2018 16:03:41:820 DEBUG - 65652F4AB1BA727A7AA7B40D23E9827F:/IVR101 : Request To Adapter - TransactionID = 180327160341819
Line 204764: 27/03/2018 16:03:41:820 DEBUG - 65652F4AB1BA727A7AA7B40D23E9827F:/IVR101 : Request To Adapter - ApplicationID = IVR101
Line 204765: 27/03/2018 16:03:41:820 DEBUG - 65652F4AB1BA727A7AA7B40D23E9827F:/IVR101 : Request To Adapter - ChannelID = IVR-101
Line 204766: 27/03/2018 16:03:41:820 DEBUG - 65652F4AB1BA727A7AA7B40D23E9827F:/IVR101 : Request To Adapter - SubChannelID = 101
Line 204767: 27/03/2018 16:03:41:820 DEBUG - 65652F4AB1BA727A7AA7B40D23E9827F:/IVR101 : Request To Adapter - VasCode = DBA
Line 204768: 27/03/2018 16:03:41:820 DEBUG - 65652F4AB1BA727A7AA7B40D23E9827F:/IVR101 : Request To Adapter - ActionID = 001
Line 204769: 27/03/2018 16:03:41:820 DEBUG - 65652F4AB1BA727A7AA7B40D23E9827F:/IVR101 : Request To Adapter - MSISDN = 067144149
Line 204770: 27/03/2018 16:03:41:820 DEBUG - 65652F4AB1BA727A7AA7B40D23E9827F:/IVR101 : Request To Adapter - AdditionalInfo = {OriginApp=}
Line 204771: 27/03/2018 16:03:41:820 DEBUG - 65652F4AB1BA727A7AA7B40D23E9827F:/IVR101 : Sending Request To Adapter
Line 204772: 27/03/2018 16:04:41:942 INFO - 65652F4AB1BA727A7AA7B40D23E9827F:/IVR101 : Using SCESession 65652F4AB1BA727A7AA7B40D23E9827F:/IVR101 servlet : error_badfetch
Line 204772: 27/03/2018 16:04:41:942 INFO - 65652F4AB1BA727A7AA7B40D23E9827F:/IVR101 : Using SCESession 65652F4AB1BA727A7AA7B40D23E9827F:/IVR101 servlet : error_badfetch
Line 204773: 27/03/2018 16:04:41:944 DEBUG - 65652F4AB1BA727A7AA7B40D23E9827F:/IVR101 : session id:au1502-2018086120337-14 | IVR101:error_badfetch | ***badfetch***
Line 204774: 27/03/2018 16:04:41:944 INFO - 65652F4AB1BA727A7AA7B40D23E9827F:/IVR101 : Using SCESession 65652F4AB1BA727A7AA7B40D23E9827F:/IVR101 servlet : checkNextNode


From the platform we see it is waiting for 60 sec and then throwing error:
@2018-03-27 05:03:41,783||FINEST|CommonVXI.Cache|21314|Session=au1502-2018086120337-14|SBinetChannel::getHttpConnection Called url=https://10.51.169.15:7443/IVR101/error_runtime?___DDSESSIONID=65652F4AB1BA727A7AA7B40D23E9827F%3A%2FIVR101|au1502.etisalat.corp.ae####
@2018-03-27 05:04:41,837||FINE|CommonVXI.Cache|21314|Session=au1502-2018086120337-14|SBinetHttpStream.cpp:1403:SBinetHttpStream::getHeaderInfo: Waited 60053ms for HTTP response|au1502.etisalat.corp.ae####
@2018-03-27 05:04:41,837||FINE|CommonVXI.Cache|21314|Session=au1502-2018086120337-14|SBinetHttpStream.cpp:1409:SBinetHttpStream::getHeaderInfo: rc=51, HttpStatus=-1234|au1502.etisalat.corp.ae####

Whereas the timeout for the below page is 10 seconds.

@2018-03-27 05:04:45,084||FINEST|CommonVXI.Cache|21314|Session=au1502-2018086120337-14|SBinetChannel::getHttpConnection Called url=https://10.51.169.15:7443/IVR101/SendingAICDataOnDisc?___DDSESSIONID=65652F4AB1BA727A7AA7B40D23E9827F%3A%2FIVR101|au1502.etisalat.corp.ae####
@2018-03-27 05:04:55,087||FINE|CommonVXI.Cache|21314|Session=au1502-2018086120337-14|SBinetHttpStream.cpp:1403:SBinetHttpStream::getHeaderInfo: Waited 10005ms for HTTP response|au1502.etisalat.corp.ae####
@2018-03-27 05:04:55,087||FINE|CommonVXI.Cache|21314|Session=au1502-2018086120337-14|SBinetHttpStream.cpp:1409:SBinetHttpStream::getHeaderInfo: rc=51, HttpStatus=-1234|au1502.etisalat.corp.ae####


Let me know if there will be timeout set from app side , I will also have it reviewed from Platform side.

I have attached the app trace for reference. Let me know if you need any other information.

Thanks in advance.

Hi Team,

Could you advice on the following issue of requests not seen in the ICC logs for the request sent by the app server.

What could cause the request or events not to be seen in the ICC logs and
Why the ICC time out is not triggered when there is a delay in response from AIC.


Attached ICC.docx with my observations.
The app trace log from two app servers and corresponding ICC trace are attached.

Hi Ross,

Thanks for the inputs,

How can we make the connector use the Java HttpURLConnection and not the commons http client. Any specific setting in the runtimeconfig or ddconfig.xml that helps in changing this.

Attachments

AIC - 7.3.4
OD/ IC connector version – 7.0.1
4 IC servers being used .


Issue: Application server not receiving VDUID details from AIC leading to HTTP VOX transfer failure resulting in survey application failure

Does the exceptions seen in ICC logs indicate the need to increase the threads,
Line 160: 03/12/2017 00:00:10:813 DEBUG - ICConnectorServer.httpThreadPool: There are no active threads available, retry
Line 237: 03/12/2017 00:00:11:064 DEBUG - ICConnectorServer.httpThreadPool: There are no active threads available, retry
Line 320: 03/12/2017 00:00:27:731 DEBUG - ICConnectorServer.httpThreadPool: There are no active threads available, retry
Line 397: 03/12/2017 00:00:27:982 DEBUG - ICConnectorServer.httpThreadPool: There are no active threads available, retry
Line 474: 03/12/2017 00:00:28:233 DEBUG - ICConnectorServer.httpThreadPool: There are no active threads available, retry

They were not able to get customer details during transfer to agent. After restarting the app server the issue was resolved.
They would like to know if there was any issue from ICC side.

Attached the screen shot of ICC config from runtimeconfig and the traces.