How can i continue conversation more than 65 seconds when using Single Utterance=true.My current implementation works partially, some time get Exceeded 65 seconds error.
I'm using web sockets.
I create a Speech Client & initialize GSA in each session (when starting Single Utterance session) & close Speech Client get .END_OF_SINGLE_UTTERANCE'
Which method from the Speech API are you using? if you are using the "recognize" method you should take into account is is synchronous but limited to 60s.
You might want to use "longrunningrecognize" instead, as it can take more than 60s.
Related
I'm testing some flows that use outbound SMS via Twilio and have been really pleased and impressed by the magic numbers provided e.g. https://www.twilio.com/docs/iam/test-credentials
However, I'm interested to see how our application responds if there's some issue sending an SMS to a number where it essentially hits a timeout value. I haven't found a magic number such as this or know of a way to recreate the scenario, can anyone help me here?
Even if you were using a real auth credentials and real phone number (instead of magic number), I suspect Twilio just queues the request on their side and responds with a HTTP 201, so you'll always get a very fast response from Twilio, but it doesn't necessarily mean the message has been sent to a carrier and delivered to a device.
If you're using Twilio messaging services, you can subscribe to delivery status callbacks to get the status of a SMS e.g. sending, sent, delivered, failed, etc - see here. Note: I don't know if you'd receive callbacks with magic numbers - I suspect not... either way you can provision a Twilio phone number pretty cheaply to test e.g. in Australia (where I'm from) I can purchase a AU phone number for $6 per month and I can release the phone number when ever I want to stop getting billed for it...
If you just want your app to timeout on invocation of the Twilio API you can do something like the following (in .NET core) to force timeout a request in a specified amount of time (1 second in example below):
using var tokenSource = new CancellationTokenSource(TimeSpan.FromMilliseconds(1000));
response = await twilioHttpClient.PostAsJsonAsync($"2010-04-01/Accounts/{accountSID}/Messages.json", request, jsonSerializerOptions, tokenSource.Token);
If timeout is exceeded, an exception will be thrown that you can handle. Note: there's various networking tools that can be used to block or limit outbound requests, which you can use to test timeout scenarios.
When an API call is made after receiving an SMS via Twilio, I occasionally get the error below -
Error: Total timeout is triggered. Configured tt is 15000ms and we attempted 1 time(s)
The API call occasionally takes longer than 15 seconds to return a response (this is due to having to process the SMS etc.). How can I configure the total timeout to say 25000ms?
It is possible to override the timeout settings for a webhook. However, the maximum total time (tt) for webhooks is 15 seconds and you cannot increase it beyond there.
If you find your service cannot respond within that time, you might want to hand off the processing of the SMS to a job and respond to the webhook quicker. If you then intend to reply to the SMS, you can do so using the REST API message resource instead of TwiML.
My main question is how to detect the application termination by the end user when it was in the background (Suspended) to be able to send logout request to the server ?
We already have a timeout interval in the server to kill the session, but assume that the interval is 5 minutes so this means that the session will be alive for 5 minutes after the user terminated the app and anyone can sniff on the data and reuse it.
Notes:
We use HTTPS connection and SSL Certificate Pining.
We also implemented a heartbeat web service to be called by client app every fixed interval to tell the server to keep the session alive for this interval, if this web service didn't call for specific session, the server will kill this session.
Once your app is suspended you don't get any further notice before you are terminated. There is no way to do what you want.
Plus, the user could suspend your app to do something else (like play a game) and then not go back to your app for DAYS.
If you want to log out when the user leaves your app, do it on the willBeSuspended message. Ask for more background time and send a logout right then and there.
Mohamed Amer,
Here is an approach used by Quickblox Server and I feel its pretty much solid though it involves a little overhead.
Once the client application (either iOS android) establishes the session with quickblox server, quickblox server expects the client application to send the presence information to server after a regular interval continuously.
Sending the presense information is pretty much simple. They have written a api which we keep hitting after a interval of 5 mins with session id that we have. They validate the session id and once found valid they will extend the expiration time for the user ascociated with that id for 5 mins more.
What they will do I believe is that,
Approach 1 : they maintain the last hit time and for all the subsequesnt request they check if the request time is within the the time frame of 5 min if yes simply process it. If the request comes after 5 min they will delete the session id for the user and respond saying you have timeout the session.
Approach 2 : Because they provide online and offline info as well they cant simply depend on the incoming request to delete the session id from server so they probably create a background thread which swipes over the db to find the entry with last hit time greater then 5 min and removes it from DB. and declares the user session expired.
Though this involves client apps continously hitting the server and increases the burden on the server for the app like chat application in which presense information is so vital this overhead is still fine i believe.
Hope I have provided you with some idea at least :)
My application is communicating with a service. The service provides user login , registration , update functionality (IAM Service) . Since, this feature is critical & we don't want to impact user performance, we set the timeout 500 millisec, considering the fact that both my application & the IAM service are in the same data center.
On analysis, we found that the IAM service on an average takes 10 - 12 millisecs & my application which simply sends the request takes 1 - 2 millisecs. Also, it does not happen for every request, just a few request.
The network engineer says the network is good & there are no leaks.
Request your inputs to understand, how should I proceed to analyze the root cause to recognize which component is taking time.
Make sure the Application and the Service are synchronized (have the same time stamp)
Log the Time stamp of request being sent by the App
Observe the time stamp when the request hits the wire
Log the Time stamp when the Request is being received by the Service
Log the time stamp when the Service sends out the response
Observe the time stamp when the response hits the wire
Log the time stamp when the app receives the response
The next time the timeout occurs - check the log to find out which two laterally adjacent time stamps have a difference of more than the 500ms. Now once you have the profiled information - focus on the particular segment that causes the timeout.
I can't find any specific documentation about the dispatchPeriod variable in the Google Analytics SDK for iOS.
If I set it to 10 does that mean it will send data to the Google Analytics server every 10 seconds? Does it only send data if new page views or events have been recorded or is it going to send data regardless? I don't want to use this feature if it will eat up too much battery life but my app has very few events to record (basically just launching and exiting). If I set the dispatch time to 10 seconds and only record events when the app opens and when it closes will it be continually dispatching during my apps runtime or will it only dispatch when those events are recorded?
I have just added Google Analytics to my app and here is what I found out:
If you don't explicitly call dispatch and have set the dispatchPeriod to let's say 10 secs, then when you call trackPageview/Event/Whatever, these requests to Google Analytics are being queued and actually sent in those 10 secs periods. If there are no requests in the queue, your app doesn't send anything (to be precise I didn't sniff the network communication, but at least the GANTrackerDelegate methods are not called).
Confirmed, just sniffed communication with Wireshark and there is no traffic between my iDevices and the world when I don't track anything.