Event handling

Unfortunately, real world conversations do not always go exactly according to script. Sometimes the user fails to provide input or takes too long to do so. Sometimes it is not possible to process user input or make useful sense out of what the user says. And sometimes the conversation unexpectedly cuts off in the middle due to the end user disconnecting or the session timing out.

DLGaaS has mechanisms to help you gracefully handle these cases via events, depending on how the user input is being processed.

Dialog events

An event in Dialog represents an occurrence outside of what is expected. Dialog has a number of predefined events, and custom events can also be created in Mix.dialog.

When an event is triggered, control is passed to an event handler configured in Mix.dialog.

The following includes details about how DLGaaS handles certain events, and what you need to configure in Mix.dialog and in your client app to handle them.

Event handling in Dialog

Handling for events has to be configured in Mix.dialog. For more information on managing Dialog events, see Manage events.

Some events are triggered by Dialog or by other services orchestrated by Dialog. This can happen because of issues making sense of user input, or because of condition trigers configured in Mix.dialog.

DLGaaS handling of NO_MATCH from NLU

If NLU receives empty or totally uninterpretable input, it returns a NO_MATCH to DLGaaS. The resulting dialog flow is determined by the Dialog application, according to the processing defined in the present question and answer node for NO_MATCH events in Mix.dialog.

Configuring recovery messages for NO_MATCH and NO_INPUT in Mix.dialog

Sometimes a user will not provide input, or the user provides input that cannot be understood. It is best practice to be configure your dialog to respond to some number of these NO_INPUT and NO_MATCH scenarios on a dialog turn, up to the global limits configured in Mix.dialog settings for maxnoinput and maxnomatch respectively.

To gracefully recover from initial NO_MATCH and NO_INPUT events in question and answer nodes, make sure to configure local recovery messages in Mix.dialog.

DLGaaS handling of unusable ASR audio

DLGaaS handles unusable ASR audio depending on the status code returned to it by ASRaaS:

  • Status code of 404 (no speech) or 204 (no ASR result): ASR either does not detect anything recognizable as speech within the no_input_timeout_ms time window, or receives speech audio but cannot produce a recognition result. The Dialog engine treats both of these cases as NO_INPUT.
  • Status code of 200 (Success), with a rejected hypothesis: ASR produces a recognition result, but none of the hypotheses have sufficient confidence to direct the next steps. This is treated as a NO_MATCH by the NLU and Dialog engines.

For a description of the ASR status codes, please see Status messages and codes in the ASRaaS documentation.

By default, if the ASRaaS result does not return a valid hypothesis, the dialog flow is determined by the dialog application, according to the processing defined in Mix.dialog for NO_INPUT and NO_MATCH events in the current question and answer node.

Alternatively, you can configure a Dialog streaming request to pass the ASR result and status to the Dialog client app to decide how to proceed. See Client handling of ASR no valid hypotheses for more details.

Client side event reporting

In other cases, issues arise on the client side and an event needs to be triggered via the API.

Sending Dialog events for problems with externally handled input

When handling user input externally, for example, in an IVR application, the client application needs to flag DLGaaS about ERROR, NO_INPUT, NO_MATCH, HANGUP, or CUSTOM events. This is handled by passing in a Dialog event as part of the next Execute request payload.

This mechanism can also be used to send in events when the client is handling an ASR no valid hypotheses scenario.

The Dialog event is handled according to configurations made in Mix.dialog.

Too much speech with recognition timeout

If you are using speech input and set the recognition_timeout_ms field as part of your ASR parameters or in Mix.dialog project settings, and the user exceeds this time limit when speaking, the speech collection may time out. In this case, ASRaaS returns a 413 code (Too much speech) to DLGaaS, and DLGaaS returns a gRPC status code 9 (FAILED PRECONDITION) to the client app.

The Dialog session does not terminate. To continue the dialog flow, send a new Execute request, passing in a NO_MATCH Dialog event. Make sure you have recovery behaviors for NO_MATCH set in the question and answer node. If you experience this issue frequently with one of your question and answer nodes, consider the following steps to try to prevent the issue:

  • Add clarification to the question and answer node prompts to give a clearer sense to the user what you are looking for in terms of input.
  • Perform additional user testing, and increase the timeout value if the time seems to be insufficient for a significant number of users.

Note that you can configure a Dialog streaming request to pass the ASR result and status to the Dialog client app to decide how to proceed. See Client handling of ASR no valid hypotheses for more details.

Client handling of ASR no valid hypotheses

In some cases, you may want the client application to handle the dialog flow if a valid recognition hypothesis is not returned from ASRaaS for speech input. This is done by setting the end_stream_no_valid_hypotheses parameter of the StreamInput asr_control_v1 message to true.

When this setting is enabled for the streaming request, and ASRaaS fails to return a valid hypothesis, the stream is closed and the last StreamOutput message contains the ASR result in the asr_result field and the ASR status in the asr_status field. The client application is then responsible for determining the next step in the dialog flow and signalling DLGaaS accordingly.

Handling UserDisconnect events

In the course of a conversation, sometimes the user will terminate the conversation early by disconnecting. This can happen in different ways depending on the channel or circumstances:

  • IVR: The caller hangs up the phone.
  • Web chat: The user disconnects actively, or the client session times out.

In the course of a conversation, sometimes the user will terminate the conversation early by disconnecting. This can happen in different ways depending on the channel or circumstances:

  • In IVR, because the caller hangs up the phone
  • In webchat, because the user disconnects from the chat.

In these sorts of cases, the DLGaaS client should send a dialog event of type HANGUP. This will in turn trigger a UserDisconnect event in the dialog session.

Handling for the UserDisconnect event has to be configured in Mix.dialog. Handling the event allows the Mix.dialog application developer to do any necessary cleanup, for example, storing information via a Data Access node. It is the app developer’s responsibility to add logic to then proceed to an ExternalActions node of type Exit, so as to terminate the Dialog session in a controlled way.