Hi guys,

I am experiencing delay problems in EP7 with Tomcat 6 integration. I found from the application logs that it take 5 seconds before running the first VXML step. And also there is silence between each phrase prompt.

I have also done the following test: AVP 5 with the same Tomcat 6 (loaded with EP7 runtime), and it doesn't have this delay problem.

After comparing the application logs, I found that whenever I dial to EP7 there is a step "get global parameters from VPMS..." where it will perform the following:
14/11/2014 16:19:11 DEBUG - CFAF5D78DF54FE086D4415569FF005DB:/HEC_Main : PlatformParams: get global parameters from VPMS...
14/11/2014 16:19:16 DEBUG - CFAF5D78DF54FE086D4415569FF005DB:/HEC_Main : PlatformParams: AppRuntimeVarsResponse.getGlobalAppRuntimeVars returns status - success
14/11/2014 16:19:16 DEBUG - CFAF5D78DF54FE086D4415569FF005DB:/HEC_Main : PlatformParams: get parameter|value - __VPLicenseServerURL|https://CESCETEPA1:8443/WebLM/LicenseServer
14/11/2014 16:19:16 DEBUG - CFAF5D78DF54FE086D4415569FF005DB:/HEC_Main : PlatformParams: get parameter|value - __VPappintf|/axis2/services/VPAppIntfService
14/11/2014 16:19:16 DEBUG - CFAF5D78DF54FE086D4415569FF005DB:/HEC_Main : PlatformParams: get parameter|value - __VPapplog|/axis2/services/VPAppLogService
14/11/2014 16:19:16 DEBUG - CFAF5D78DF54FE086D4415569FF005DB:/HEC_Main : PlatformParams: get parameter|value - __VPappvars|/axis2/services/VPAppVarsService
14/11/2014 16:19:16 DEBUG - CFAF5D78DF54FE086D4415569FF005DB:/HEC_Main : PlatformParams: get parameter|value - __VPzoneepm__0|10.34.4.46
14/11/2014 16:19:16 DEBUG - CFAF5D78DF54FE086D4415569FF005DB:/HEC_Main : PlatformParams: get parameter|value - __VPzonename__0|Default


As you can see from the time stamp there is a 5 seconds gap between get global parameter and the next step. This does not happen if I dial to AVP 5.

I have attached the application log files captured when running on EP7 and VP5.

Please kindly help to shed some lights on whats causing this.


Many thanks!

Hi Martin,

Thanks for the reply.

Actually we had further foundings.

We have checked AES TSAPI log, and noticed Caller Number can be retrieved.

If the IVR transfer the call to a VDN by blind transfer, we are able to see the Caller Number all the way till agent ends the call.

However if the IVR transferred the call to a VDN with step "adjunct route to link 1" using "attSingleStepTransferCall" function, the Caller Number will be replaced with "TXXX#1" at the "CSTARouteRequestExt" event.

Do you have any clue about this??


Many thanks!

Hi,

The CTI system which connects to AES using JTAPI is receving "dynamic device identifier" instead of the Caller Number.

We would like to know if this is a configuration issue?


Thanks!

Hi Shweta,

Sorry I cant seem to view your message...

Anyway, I would like to know whether the Enhanced Call Classfiication license needs to be applied in order for Call Classification feature function properly??


Many thanks!

Hi Ross,

Thanks for the prompt response.

I have already asked VP support, but they refer this problem as a development issue, so I have to ask through this channel.

I noticed from other posts or forums, developer seems to have successfully receive the correct connection signals. Could this be related to version of VP or CM?

Also, does it make a difference to enable SA8874 feature on CM?

Many thanks!

Hi,

I am recently writing an Outbound application to distinguish if it is a human answering the call or other (eg Fax machine, voicemail, etc).

However all answered calls were distinguished as "live voice", whereas only busy tone was successfully determined.

Please advice if there are anything required in terms of coding, configuration on AVP/CM is necessary in order to have this working.

FYI, the CM has enabled the SA8874 feature and the CCXML code already has hints.enable_call_classification enabled.


Many thanks!

Jack