In order to honour the DialogFlow endInteraction flag, the bridge listens for MQTT dialogFlowEvent messages emitted by dialogflow-rtp-audioserver on intent recognition and triggers an ARI continueInDialplan to drop the call when it sees an intent with endInteraction set.
This immediately drops the call whilst rtp-audioserver still has the DialogFlow audio in its queue to send to Asterisk so any audio emitted by the last intent is lost.
I think the fix involves having rtp-audioserver send an additional dialogFlowEvent message when it has sent all outstanding data to Asterisk, and delaying the call drop here until we receive this.
In order to honour the DialogFlow
endInteraction
flag, the bridge listens for MQTTdialogFlowEvent
messages emitted by dialogflow-rtp-audioserver on intent recognition and triggers an ARIcontinueInDialplan
to drop the call when it sees an intent withendInteraction
set.This immediately drops the call whilst rtp-audioserver still has the DialogFlow audio in its queue to send to Asterisk so any audio emitted by the last intent is lost.
I think the fix involves having rtp-audioserver send an additional
dialogFlowEvent
message when it has sent all outstanding data to Asterisk, and delaying the call drop here until we receive this.