CVP 12.5 DialogFlow Element fetchaudio

[Chris Thomas]

Hello, I am testing out the new DialogFlow elements in CVP 12.5 and am wondering if the standard vxml properties of fetchaudio, fetchaudiodelay, etc... are able to be used with the built in DialogFlow element.

In testing I have a simple DF agent built within GCP and my CVP application works fine with it. I have one intent that is fulfilled by a webhook (also hosted in GCP) which makes an API call to an third party public API. The API call can sometimes take a few seconds to respond, therefore the caller hears silence while the webhook is running and until we eventually get a response back from DialogFlow. I've tried setting the fetchaudio and fetchaudio delay properties on the DialogFlow element and it doesn't seem to be doing anything. I've even put a simple wait within my webhook function to "simulate" a few second delay, so definitely the delay is greater than my fetchaudiodelay setting of 1s. I still hear nothing but silence while the webhook is performing the API call in order to build the response.

I've even tried setting fetchaudio and fetchaudiodelay in the root doc setting of my application and still nothing.

Can anyone provide some input if I might be missing something?

Thanks!

[Bill Westby]

Chris, long shot, like moon shot, but if you play a silence.wav audio element before your dialog flow element with the fetch audio properties and set the fetch audio start delay to xx seconds then maybe that would be honored?  IDK, I'm just starting to dive into this myself.  VVB is waiting for response from dialogflow which is speech vs. integration API so perhaps since that type of MRCP connection is active fetchaudio can't intervene. 

My current frustrations are I can't really use any DTMF to switch intents nor can I force an intent switch that I can figure out :) 

Good luck!   

[JeffCoomans]

DTMF isn't natively supported by the Speech to Text engine within Google just yet. The best way to handle this is at the actual softswitch or voice gateway that is streaming to Google.

We have a Cisco BroadWorks platform, which includes a full RESTful API for call events that we can subscribe to. When we see DTMF on the users (i.e. phone numbers) that are being sent to DialogFlow, we actually translate those to text and send a query directly to the agent. There are a number of methodologies you can use for translating (i.e. you can convert "1" to "one", or if pressing 1 is for the sales department, you can convert "1" to "sales", for example). Additionally, you'll find that using entities and/or contexts within your DialogFlow agent is the best way to handle situations where the DTMF options may be different than someone speaking in natural language.

It's not a simple configuration, as you need to make sure you redirect responses back to your Cisco agent, but this is also not incredibly difficult. The key is making sure you have some sort of gateway in your platform that is capable of sending the actual DTMF for the call to something that ingest it.

[david.macias]

To make sure I understand:

- You are monitoring the VXML events in the voice browser for the presence of DTMF.

- Translating it to language and sending it to DF.

Curious how you're accomplishing this assuming it got it right.

david

[JeffCoomans]

To be technically accurate, we are monitoring the DTMF events on the Cisco BroadWorks platform using the Xtended Services Interface RESTful API. That platform has a very advanced events and triggers API, rather than having to go directly to the voice gateway, and it produces JSON format, rather than SOAP/XML or VXML, but you could do that too if you wanted to.
The reason I like using the softswitch API instead of the gateway API is that no matter what call routing path is used, the DTMF information is coming from one source. . .the softswitch. If you're like us, and you have a ton of gateways out there, making sure you're capturing information from each of them is a pain.

BUT, there is no reason you couldn't do this off the gateway with a script, as well.

To be transparent, this is ALL happening on the softswitch that is sending phone calls to Cisco, prior to reaching their hosted platform.

[david.macias]

Thank you for the explanation. The platform you're using is much different than the platforms I'm familiar with. Sounds very cool that you have such granular control.

david