search

nimbleape / asterisk-dialogflow-rtp-audioserver

MIT License
43 stars 18 forks source link

DF standart edition quota exceeded . The question is how to increase request timeout? #22

Open Happyman1974 opened 3 years ago

Happyman1974 commented 3 years ago

In the evening hours I see the messages about quota exceeded. The period is every 60 seconds. image_2021_01_06T21_46_31_951Z

Is any way to increase timeout from 60 seconds up to 5 minutes ?

Happyman1974 commented 3 years ago

I found helpful information on the google DF https://console.cloud.google.com/apis/api/dialogflow.googleapis.com/metrics There is a traffic graph wich shows 429 error means your app has made too many requests and has hit the rate limit of an API

API DF Traffic

429 marked with blue color. So, From 00:00 up to 19:00(approximately) the code is 200. which is OK. After that 429 :(

danjenkins commented 3 years ago

Hi @Happyman1974,

So theres a couple of things going on here. the 60 seconds refers to the fact that dialogflow can't accept audio for more than 60 seconds at a time and so after sending audio for 60 seconds we create a new stream.

What looks like is happening here is that the app thinks we're still getting audio from asterisk and so is trying to send it.... but by doing that we've run out of allowed time on their API in the free plan and so they send back 429 - and then we're not seeing that as an error ands just keep going back for more.

So theres 2 issues here....

  1. Make sure that when we get an error back, we give up trying to send that stream forever - don't keep prodding the bear hoping it'll take it.
  2. Make sure that when a stream from Asterisk closes we don't continue to try and send it to Dialogflow.
  1. would be a great introductory issue if you wanted to tackle it.
  2. I've tried to tackle this before and I thought I'd fixed it but theres obviously something getting missed somewhere.
rjp44 commented 3 years ago

I've had a quick look at the code and it seems like that error will always occur when we try to set up a new stream (streamingDetectIntent) in a project that has hit it's daily API limit for free audio intent recognition.

The fact that it is occurring repeatedly in the 60-second stream re-start just means that a call is being held open by Asterisk with someone on the end listening to dead air. I think any new calls coming in for the rest of the day will also be suffering this issue as the error message says the quota you are hitting is a daily one. It would be good if you could confirm this from your logs/testing though.

We already close the stream when the Asterisk call drops, although we don't initiate a call drop for any reason other than getting an intent back with endInteraction which we will never get under these circumstances (there is a separate bug with this at the moment that I will raise an issue for in a second).

So I guess there are two things that may need doing to resolve this:

  1. Introduce some logic to handle DF errors in streamingDetectIntent rather than do nothing and hope the user hangs up.
  2. Introduce a time limit so that if we don't get any intent recognition within a period of time, we drop the call.

On (1), the only obvious thing to do is probably just log and then drop the call. Not very caller friendly though as for an error like this, we will get the same error if they call back and try again so we will keep just hanging up on them. I guess playing a message locally "dialogflow unavailable" then hanging up would be more friendly but also more complexity.

(2) may not even be necessary or useful once this issue is fixed as I'm pretty sure DF handles silent inputs by kicking the session into the default unrecognised intent and you could handle silent callers from there in a much more friendly way by putting them in a context where you hand them a "sorry you do need to talk to me" .endInteraction response after a few cycles round the unrecognised intent.