I have a bot in Amazon Lex and I’m using Connect to allow to talk to it through the phone. We want to be able to generate a log of the calls with the recording.
The problem we are having is that we enable the option Enable call recording in Amazon Connect, but never see the recordings on S3 after making calls.
Is it needed to enable something else apart from that option?
The option Enable call recording only works when there is an agent on the other side and it won't work with a bot in Lex.
What you can do is enable live media streaming. Under the section Live media streaming in the configuration of your Connect instance you will see the option Enable live media streaming. Then, in your Connect flow you need to add blocks to start live streaming (usually after the call started) and then to close the streaming (before the end of the call).
Once you do that, you will be able to see the recording in Kinesis, where you can download them or use the API to retrieve them (you should check the docs for Kinesis regarding that).
Once important thing is that only what the caller says gets recorded. What the bot says is not recorded.
Related
I would like to process audio and video from a Mesibo conference on the server side and then, if possible, feed the processed stream back in as a new publisher (participant) in a different group (conference).
By current best guess would be something like this...
Run the Mesibo Javascript API in a virtual browser using node browser-run and Xvfb
Connect to the conference in the browser and somehow extract the necessary WebRTC connection details and feed this back to the node process controlling the virtual browser
Connect to the conference using node webrtc-client
Having to run a virtual browser every time seems like overkill. Also I have no idea where I would get the webrtc connection details (step 2) from in the virtual browser. Does the Mesibo Javascript API expose these anywhere?
Assumedly if I could get the above working then I could use the same webrtc-client instance to feed the process back into the conference, but if I wanted to feed it into a different conference then I'd have to create another virtual browser.
Anybody got any ideas?
mesibo on-premise conference server exposes RTP API, possibly that should help. However, the on-premise conference server will be available publicly in Feb'21 so you will have to wait.
How would you expect step 2? are you looking to access the underlying peerconnection?
My Chrome Extension's background page is set up as an event page, i.e., most of the time it is asleep unless some registered event listener wakes it up.
I'd like to be able to occasionally send messages from my server to the event page of an individual user of my extension. They should not necessarily show up as a desktop notification, it would rather be up to the background script to decide what to do with any incoming message. It might very well store some information in localstorage for example. If the user client was offline at the moment the message is being sent, it would ideally be delivered once it comes back online.
I'd like to avoid polling my server at regular intervals every time the background script is awake, though that would be an obvious solution.
My question is therefore if it is possible to register a special kind of event in my event page so that it wakes up and triggers some functionality once there's an incoming message from my server. Ideally, the server message would not be a general broadcast to all my users, but rather a targeted message to a specific user.
What options do I have?
I read about service workers and their Push API but it seems they are only slowly being rolled out to Chrome Extensions. I am not sure if they are ready for the browser's stable release yet and didn't find any documentation on how they work with extensions.
I also read a bit about Google Cloud Messaging but it is deprecated in favor of a new costly Firebase solution.
Service worker functions like a proxy server, allowing you to modify requests and responses, replace them with items from its own cache, and more. While Chrome has its own approach to caching/installing the resources need to display a Chrome Extension. Therefore, there will be an error when you will attempt to intercept the registration of a service worker to a Chrome Extension.
See for more information:
Introduction to service worker
Service Worker script errors if run in chrome extension
See related SO post:
Chrome Extensions with service worker receiving push notifications
I'm able to successfully load test my bot server by getting the proper auth token from Microsofts auth URL (basically through this page)
I was wondering if this was a valid test on the service considering that we're not actually hitting the bot frameworks endpoint (which has rate limiting)
Is there another way to load test a bot service wherein i can replicate the bot frameworks throttling/rate limits?
I ended up with using load test with Visual Studio and Visual Studio Team Services.
The reason why I used this approach is that you can setup full path of load tests. Azure Bot Service can be either Web App or Function App with endpoint prepared for receiving messages - using HTTP POST so in the end is just web service.
You can setup load tests for different endpoints including number of hits to selected endpoint. In case of Bots you can for instance setup test with 100 fake messages sent to the bot to see the performance.
You can read more under these two links below:
Load test your app in the cloud using Visual Studio and VSTS
Quickstart: Create a load test project
Unfortunately as stated in the documentation you linked, the rates are not publicly available due to how often they are adjusted.
Regarding user-side throttling- this should not actually have an effect either way as long as you simulate reasonable traffic, but even if you go a bit overboard, an individual user hitting rate-limiting would be functionally equivalent to just having a bit more traffic. The single user sending more messages to the bot is the same as three users sending the same amount of messages slightly slower and there's no limit for your bot in terms of how many customers you might have. That said, a user getting a message, reading it, and typing up a response should not put themselves into a situation where they are rate-limited.
However, regarding bot side throttling it is useful to know if your bot is sending messages too fast for the system. If you are only ever replying directly to messages from users, this will not be an issue, as the system is built with replying to each user message in mind. The only area you might run into trouble is if you are sending additional (or unsolicited) messages, however even here as long as you are within reasonable limits you should be OK. (i.e. if you aren't sending several messages back to a user as fast as possible for each message they send you, you will probably not have problems.) You can set a threshold for bot replies within your channel at some reasonable-sounding limit to test this.
If you would like to see how your bot responds in cases where throttling is occurring (and not necessarily forcing it into tripping the throttling threshold), consider setting your custom channel to send 429 errors to your bot every so often so that it has to retry sending the message.
I am referring to the diagram
NodeJS is used as run time in this case and AWS Lambda is used as event notifier (updates comes from other lambda or DB).
My challenge is, the "user browser" can also be a mobile client. The "API" should acts as a service which allows client (mobile or web) to subscribe, unsubscribe, or publish data, nothing else.
Can lambda works as API that has capabilities of "pushing events notifications" to directly clients?
Is there any solution and also sample work/source code can be used as POC?
Next question is, how can I scale such architecture since it becomes stateful (requires memory to remember states of clients connections)?
Or else, how possible is it persist client connections on DB (using frameworks like websocket or socket.io)?
AWS has the SNS service to send notifications, which you can use from Lambda.
You can also directly use the relevant platform's notification system e.g for iOS, Node has an "apn" module that is used to communicate with Apple's APNS service - it's straightforward to use and can be implemented in a Lambda function.
In brief:
Your iOS app registers for APNS which responds with an APNS device token. Your app should then send this to your API / server for storage.
Your API can then send notifications to APNS, referencing any device tokens, along with the private key file you create from the Apple Developer page.
APNS will send the notifications to the registered devices.
Here is a good tutorial.
Your other queries should perhaps be separate questions.
Can lambda works as API that has capabilities of "pushing events notifications" to directly clients?
Yes! As #AndyOS mentioned, SNS is a great service that is quite literally intended to send notifications. I won't go into details here to avoid duplication of response.
Is there any solution and also sample work/source code can be used as POC?
Or else, how possible is it persist client connections on DB (using frameworks like websocket or socket.io)?
If you are looking to use websockets, I'd encourage you to take a look at IoT (https://aws.amazon.com/iot). IoT supports the MQTT protocol (http://docs.aws.amazon.com/iot/latest/developerguide/protocols.html). This page also contains sample client-side code which might help you bootstrap your solution.
Next question is, how can I scale such architecture since it becomes stateful (requires memory to remember states of clients connections)?
You can view the service limits of IoT at http://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html#limits_iot. You would need to decide if your app fits within these bounds, depending on the various metrics your app has (number of requests per second, number of concurrent connections, etc.).
The API endpoint I need to access provides live streaming option only. But the need is for a regular non streaming API. Using the request node module can I achieve this?
You can hook up to the stream on your server and store data that arrives in the stream locally on the server in a database and then when a REST request comes in for some data, you look in your local database and satisfy the request from that database (the traditional, non-streaming way).
Other than that, I can't figure out what else you might be trying to do. You cannot "turn a streaming API into a non-streaming one". They just aren't even close to the same thing. A streaming API is like subscribing to a feed of information. You don't make a request, new data is just sent to you when it's available. A typical non-streaming API is that a client makes a specific request and the server responds with data for that specific request.
Here's a discussion of the Twitter streaming API that might be helpful: https://dev.twitter.com/streaming/overview