Closed ghost closed 4 years ago
@digitaltoast i believe you can adjust your query so Dialogflow will not send any audio back. in ./lib/DialogFlowConnector.js lookup the following code
this._initialStreamRequest = {
session: this._dialogFlowPath,
queryInput: {
audioConfig: {
audioEncoding: audioConfig.audioEncoding,
sampleRateHertz: audioConfig.sampleRateHertz,
languageCode: audioConfig.languageCode,
singleUtterance: true,
},
},
outputAudioConfig: dialogFlowAudioOutputConfig
};
Just remove the last line 'outputAudioConfig' this should prevent DIalogflow sending audio back.
Here is the discovery document i am using to understand the json request,
https://dialogflow.googleapis.com/$discovery/rest?version=v2beta1
See "GoogleCloudDialogflowV2beta1DetectIntentRequest":"properties":"outputAudioConfig": Here is stated that "description": "Instructs the speech synthesizer how to generate the output\naudio. If this field is not set and agent-level speech synthesizer is not\nconfigured, no output audio is generated."
I've just pushed up a new branch which a) moves config around so theres less of it in the DialogFlowConnector file, and b) enables disabling the output audio in the config file
In the process I moved some config options around so pay attention to that
Thinking about it, more needs to be done to enable this - namely closing the connection and restarting it in this scenario
if (data.outputAudio && data.outputAudio.length !== 0) {
this._sendAudioToAsterisk(data);
// we got the audio, so now we need to restart the dialogflow stream
this._createNewDialogFlowStream();
}
On the high usage quota.... I'm not really sure what could be causing that to be honest, I'd need to have a play and see if theres a loop where I'm not closing off connections or something?
Oh actually, probably dont even have to restart the connection and @digitaltoast you don't need to lower the limit to 8 seconds either.... you should be able to use the one dialogflow session for 59 seconds over multiple intents etc ... I think! I'd need to try it out, give this branch a go and see how you get on
Wow - you are both stars! Thanks so much, @danjenkins - I will take a go at this. You'll be very intrigued to see what it's going to be used for!
@digitaltoast has the most recent additions helped?
@danjenkins yes - working perfectly for what I need - thank you!
I'm still battling on with trying to get just the text of a recognised town returned efficiently.
I don't want dialogflow to talk to me at all, and I only want the caller to say a town name, and have the corresponding town name returned.
In other words: Asterisk audio file says: "What is the town". Then enters stasis, kicks off Dialogflow with the FindTown intent, sends the audio, waits for fulfilment text.
It appears that Asterisk is sending back speech that Dialogflow has sent to Asterisk when on speakerphone - even though I don't want Dialogflow to send ANY audio back to me. So I figured out that I had to change my intent training phrases to match on whatever Dialogflow was sending to me.
Yes, I have set a default intent, and it triggers it nicely, but even when I clear out the default prompt text completely, it still says "What is the town?".
All was going well, until I hit the limit of 1,000 requests per day.
I've set clearTimeout to 8000 (8 seconds) which should be enough for Google to say "what town" and the user replies "London".
I'm comparing the stats below with the history in Dialogflow - I have about 50 conversations, each with an average of 3 interactions.
In the last 7 days, I've had 161 sessions with an average of 2.35 queries per session.
If I have changed the timeout to 8 seconds, how come I am seeing latency of 35 seconds? Why am I seeing 94% errors on 1,384 requests? And I've checked - my quota is definitely 1,000 per day
I'm totally confused now! Before I hit StackOverflow for answers, I am wondering if, possibly, this package is sending lots more queries than I realise?