Dialogflow CX - Send sys.no-input incrementing

[Karl Burnam]

Happy Monday!

How would we allow Dialogflow flow to throw the sys.no-input-default, sys.no-input-1 (2) etc?

Basically we are trying to use the built in No Input event handlers from Dialogflow CX.

[Arsen Chaloyan]

Hi Karl,

You may use one of the two notations below to trigger a built-in or a custom event. The second one is known to work with all the platforms.

builtin:event/$name

builtin:grammar/event_$name 

where '$name' is supposed to be replaced with the actual event name. For example:

builtin:event/sys.no-input-default

builtin:grammar/event_sys.no-input-default

--
You received this message because you are subscribed to the Google Groups "UniMRCP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unimrcp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/unimrcp/5c32e95b-4060-4162-8ac6-52d32ec150e4n%40googlegroups.com.

--

Arsen Chaloyan
Author of UniMRCP
http://www.unimrcp.org

[Frank Wang]

Hi, I want to ask another question related to this topic. During our testing we found that google dialogflow will generate sys.no-input-default or no-input-(1-6) itself if input audio or text is empty, particularly in the case when gdf cancels streamDetection due to the expiration of no-input-timeout, dialogflow will generate the no-input event with correct sequence number (1-6) and send a detection result back. however since the function call is already cancelled, the result cannot be received by gdf plugin. is there way not to cancel streamDetection upon no-input timeout so gdf can receive the no-input detection result without a need to send our own no-input events? the reason we ask about this is we want dialogflow to decide which no-input handler (1-6) to use instead of client deciding it. Hope my description is clear to you or I can clarify more. thanks.

[Arsen Chaloyan]

Hi Frank,

This is a conceptual problem. First of all, there is no way of specifying the no-input timeout used by the Dialogflow CX API from the client. But this is a part of the story as many of you could possibly live with that. More importantly, Google's implementation of the no-input timeout does not have a notation similar to the input timers employed over MRCP. In other words, the client shall be able to specify when the (no)-input timers are supposed to be actually started, which may (and should) not coincide with the time the request is placed. Normally, the input timers are started after the prompt playing is complete.

In other words, the only reliable way to go around is to primarily rely on the implementation of the no-input timeout of the plugin by invoking corresponding event handlers from the client application using the technique I described in my previous reply in this discussion. The drawback is you would need to manually maintain the no-input counter in your application.

To view this discussion on the web visit https://groups.google.com/d/msgid/unimrcp/f6eb4277-fe65-48d3-bbd0-e6d995511256n%40googlegroups.com.

[Frank Wang]

Arsen,

you are right, there is no way of specifying no input timeout on dialogflow side and the client has to maintain its own timer. the notion of no input timeout I was referring to is the gdf's no input timeout config. on google side, I was referring to the no-input handlers which are triggered when no input is received. it's not necessarily caused by a timeout, but either no audio detected or an empty query text is received. in your gdf implementation, when the no input timer is reached, you simply cancel the detect stream, which triggers "No-input 1" handler as shown below, however, gdf cannot receive this response anymore after the stream is cancelled thus we are missing the bot response associated with the handler. and  at the same time, you return your own timeout error to your client, which is our app.  like you said, our app needs to keep a counter so we know which No-input handler (1, 2 or 3) we need to trigger by sending a corresponding event. since different intent may have different number of no-input handlers, it's going to be tedious work to maintain a counter for each intent in our app. these handlers are supposed to be designed in dialogflow and transparent to our app. 

that being said, we did our own experiment with Dialogflow API using freeswitch, basically when our timer is reached, instead of closing the detect stream immediately, we first send an empty query text to dialogflow using detectIntent method and receive a No-input handler from dialogflow (say No-input 1), we then close the detect stream. When the timer is reached again next time, we send another empty text and dialogflow will return us No-input 2 handler. and so on so forth ...

In summary, in order to receive a handler with correct counter from dialogflow, we need to send empty text before closing the detect stream. Not sure if it's something you can add to your gdf's feature list.

Thanks,

Frank

[Arsen Chaloyan]

Frank.

I apologize for the late response.

> in your gdf implementation, when the no input timer is reached, you simply cancel the detect stream, which triggers "No-input 1" handler as shown below

If that is the problem, then what precludes you from making the no-input timeout used by the GDF plugin longer. The timeout can either be set globally from the configuration of the plugin and also be adjusted per request from the client.

Irrespective to the above, since GDF 1.21.0 version, no-input events received from Dialogflow CX agents are skipped by default. You may control the behavior by setting the skip-no-input parameter, which applies to CX agents only.

> that being said, we did our own experiment with Dialogflow API using freeswitch, basically when our timer is reached, instead of closing the detect stream immediately, we first send an empty query text to dialogflow using detectIntent method and receive a No-input handler from dialogflow (say No-input 1), we then close the detect stream. When the timer is reached again next time, we send another empty text and dialogflow will return us No-input 2 handler. and so on so forth ...

> In summary, in order to receive a handler with correct counter from dialogflow, we need to send empty text before closing the detect stream. Not sure if it's something you can add to your gdf's feature list.

That is an interesting approach which can possibly be implemented in the future, if it proves to help. The problem is I cannot focus on this right now but have logged an internal ticket to revisit the subject when there is an opening in the schedule.

To view this discussion on the web visit https://groups.google.com/d/msgid/unimrcp/4bd7a959-4b17-4c33-b518-000fc79c012dn%40googlegroups.com.