Long delay between two audio element to play

[vincent.zheng]

Here is the version we are using:

CVP is 10.5(1)

UCCE is 10.0(1) Build 1662

Cisco IOS Software, C3900e Software (C3900e-UNIVERSALK9-M), Version 15.2(4)M6a, RELEASE SOFTWARE (fc1)

The normal flow is, play the Greeting message, do a ANILookup web service call, then begin to play the Language selection.

That pretty smooth if ANILookup is not fail, but if ANILookup web service fail due to Java Exception, then for the Language option menu, I will see following:

10.77.80.42.1489465104997.37.Project,03/14/2017 00:18:26.089,Language_Option_Menu,interaction,audio_group,initial_audio_group

10.77.80.42.1489465104997.37.Project,03/14/2017 00:18:39.915,Language_Option_Menu,interaction,utterance,2

Why we have delayed in there? My web service element already set timeout to 8s, but seems like timeout is not affected to the flow...

[Rahul Kumar]

Can you share the entire activity log for both failed and successful calls. Also a little bit more details on the ANI lookup Java class.

[vincent.zheng]

I just update the post with that two log post.

[janinegraves]

I don't really see a 'delay' in your failure log. Be aware that the Audio element does not play to the caller when it's sent to the gateway. It's played 'asynchronously' by the gateway. So the gateway hands off the playing of audio to a background process and returns to VXMLServer immediately to start doing the web service lookup. Look at the time stamps of the enter and exit times of the Welcome element, they are 15 milliseconds apart:

03/14/2017 00:18:26.027,Welcome,enter,

03/14/2017 00:18:26.042,Welcome,exit,done

The menu element is then sent to the gateway 47ms later. Now the gateway must WAIT for both the greeting and the menu prompts to completely finish playing before it begins the NoInput timer and waits for caller input:

03/14/2017 00:18:26.089,Language_Option_Menu,enter,

03/14/2017 00:18:26.089,Language_Option_Menu,interaction,audio_group,initial_audio_group

03/14/2017 00:18:39.915,Language_Option_Menu,interaction,utterance,2

The caller enters input about 12 seconds after the Welcome element is sent to the gateway. This is approximately the same in both the success and the failure logs you sent. I believe that if you time the duration of your welcome message and your Menu initial audio group plus your NoInput timeout value, that it will sum to about 12 seconds. 

[vincent.zheng]

One part I don't understand is why this two line need about 13s

03/14/2017 00:18:26.089,Language_Option_Menu,interaction,audio_group,initial_audio_group

03/14/2017 00:18:39.915,Language_Option_Menu,interaction,utterance,2

but in the success one , just like 2s

10.77.80.42.1489465046418.36.Project,03/14/2017 00:17:36.792,Language_Option_Menu,interaction,audio_group,initial_audio_group

10.77.80.42.1489465046418.36.Project,03/14/2017 00:17:38.770,Language_Option_Menu,interaction,utterance,2

Also for this one ",interaction,audio_group,initial_audio_group" , then means IVR already play the audio? Or it just finish the initialize, but not start to play?

[janinegraves]

The time stamp is when the gateway handed the audio request to its http client process to retrieve, not the time it began (or ended) playing the audio. 

So - do NOT look at the time stamp of the Menu's initial audio group. Since the Menu (which must play to completion before timing caller input) comes after the Welcome which is an Audio Element (which does NOT begin or complete playing audio before returning to VXMLServer).

Compare the time from the beginning of the Welcome (when the welcome was sent to the gateway) until the caller enters an input in the menu (meaning they listened to the welcome and the menu prompt, and then responded).

They are approx'y the same in the success and the failure logs with the difference in times (2.5 s) possibly due to caller response times.

Success log:  11.3 seconds

00:17:27.448,Welcome,enter,

00:17:27.463,Welcome,exit,done  

00:17:38.770,Language_Option_Menu,interaction,utterance,2

Failure log: 14 seconds

00:18:26.027,Welcome,enter,

00:18:26.042,Welcome,exit,done

00:18:39.915,Language_Option_Menu,interaction,utterance,2

Note your Welcome audio prompt is NOT 15 milliseconds in duration, right?

00:17:27.448,Welcome,enter,

00:17:27.463,Welcome,exit,done 

[vincent.zheng]

that means we cannot figure out what time that element actually play the audio right?

Because the wav file for Welcome is about 4s, but from enter to exit for Welcome, it only took 15ms...

[janinegraves]

That's right. You can't tell how long an Audio element plays. It allows

your web service to run while the caller is still listening to the

greeting. Hence, from the caller's perspective, it speeds things up.

However, it's tricky from the standpoint of troubleshooting log files

I'm taking an informal poll of who wants Cisco to include an Audio

element that has a Setting where you can specify configure it to play to

completion before progressing.

You can vote for it at this link on the cisco site:

https://communities.cisco.com/message/248968#248968