How to calculate Session Duration or Call Duration in TokBox API?
We need to display Session/Call duration for each Session-Id, we created from Backend. In our case, only 2 people can connect to a session as we are sharing session-id & token with two users only. Now On the Admin Panel, we need the Actual Call time between these two users.
Is there any API which provides these statics?
There is no such API to calculate the exact call duration.
You can check your invoices on the dashboard under the billing section.
Another way is, you can log the timestamps on event listeners. Like when the first-person joins the session, connectionCreated event gets fired, in that you can log your time stamp and send it to your server. Similarly, when someone leaves the session, you get connectionDestroyed event. Refer to this page for all events related to the session.
You can also refer to our Session Monitoring API - https://tokbox.com/developer/guides/session-monitoring/ which lets you receive real-time session callback events on your server endpoint thereby monitoring the user's session activity.
By using the events mentioned above you can calculate the session duration.
Thanks!
Related
Our web application is using UserAuthentication Cognito, there is a problem that arises when a lot of users authenticate in 1 second. We want to limit the Quotas if possible and have a warning when it exceeds a certain amount to prevent system overloading. We haven't found a solution to this problem yet.
Can you help us solve this problem? Maybe with some example code or a return response containing content of message and place of error log whenever it breaks the limit.
You can try using cloudwatch alarms to send notifications when certain quotas are being exceeded. This notification can be directly sent to your app to perform further actions.
If your app cannot recieve notifications, you can use the alarm to trigger a lamdba which updates a database. You can then create a pre authentication lambda trigger that will query this database before logging user in.
Here's the documentation for cognito cloudwatch alarms: https://docs.aws.amazon.com/cognito/latest/developerguide/tracking-quotas-and-usage-in-cloud-watch-and-service-quotas.html
I have implemented agora cloud recording and i am able to save recording files in Amazon S3. I am having issues in recorded video, where I am able to see one person only in my recording. Person who did not start recording.
Below are the steps.
Start Video Call
Other Person Joins call
Acquire - Start Recording - Query (Status 5) - Recording is working
Finish recording - recording uploaded success
Check recording in Amazon S3 (I am able to see another person in recoding but not myself)
I have subscribed to both UID, also tried subscribing using select all
"subscribeVideoUids": [ "#allstream#" ], "subscribeAudioUids": [ "#allstream#" ],
Need to understand what is incorrect. Please find the full request below.
{"cname":"1000","uid":"3924255811","clientRequest":{"token":"006d144dfdf7042dcc742acaca3c34af3afe220IAD6qWGaJzXtNJerzqvOQv1tItIa4sVXAb82LOj2vRAygRejJGdfUjEAAubpgRidf8lgXwEA","recordingConfig":{"maxIdleTime":30,"streamTypes":2,"channelType":0,"videoStreamType":1,"transcodingConfig":{"height":640,"width":360,"bitrate":500,"fps":15,"mixedVideoLayout":1,"maxResolutionUid":"3924255811","backgroundColor":"#000000"},"subscribeVideoUids":["#allstream#"],"subscribeAudioUids":["#allstream#"],"subscribeUidGroup":0},"recordingFileConfig":{"avFileType":["hls"]},"storageConfig":{"accessKey":"xxxxxxxx","region":14,"bucket":"dummybucket","secretKey":"xxxxxxxx","vendor":1}}}
In my experience, when only 1 user is recorded sometimes this is due to the recorder using the same UID as one of the users in the channel.
When calling the Agora Cloud Recording (acquire, start, stop) the UID should be unique from the users already in the channel.
Yes, This will not work if only a single user is present on the channel, below is the solution I applied to make it work.
Create a new or local client that will join the channel but do not create this client's audio and video track.
Now before proceeding to record, open a new window and on this window's load, create one more client (by doing the same as above) and this time allow to create it's audio and video track.
This newly created client will behave like a local client in this window and a remote client in the original window.
What happening here is-
The first time when we create a client, it joins the channel but not publishing any stream in the channel, but we have a UID of this client which we will use to send recording requests.
On the second time when we open a new window and create a new or local client, this client is a remote client for the original window (In which recording is taking place or is being requested) and this is the client who is being recorded.
Ideally, there are two users in the channel in which one is publishing the stream (newly window client) and another one is not publishing but requesting the recording (original window client). Logically, the user who is being recorded is the same in both windows with different uids.
To record a single user, there should be at least two unique uid in the channel from which one uid person can request to record and another uid person can be recorded.
Hope this will help.
Here is the scenario:
User logins to the bank successfully (via Fastlink)
Right after user logs in, I get user's provider_accounts (via /providerAccounts API)
Then when I call to get the accounts, (via /accounts) I sometimes get empty response (zero accounts found?)
When I try later (seconds or minutes after) I get some accounts information back.
Is this because Yodlee is still trying to gather account information when I'm making /accounts api call?
This is because the accounts are still being added/linked.
Using the requestId and providerAccountId provided by FastLink callback, you need to poll continuously to know the refresh status of the account linking process and once it's done, you can call the get accounts.
Read more about the refresh status in the "Add/Update Account Process Status" section.
Yodlee makes things easier now with webhooks. Read more here:
Using Webhooks with the Yodlee Core API
TL/DR: You need to wait for the add/link completion before retrieving the accounts.
I am trying to wrap my head around the Firebase User Engagement Calculation. I am doing a lot of debugview testing now, and as the online documentation states (https://support.google.com/firebase/answer/6317485), Firebase is firing the user_engagement event by default on a periodic basis within a session while the app is in the foreground.
What I have seen thusfar is that user_engagement is fired quite reliably in the beginning and end of an engagement (this can be occurring multiple times in a specific session).
Scenario:
Say for instance I started my session and exited the app, but returned again within the the same 30 minutes time slot. The session_start won't fire again, but only user_engagement. This is quite clever, because I can actually then query first and last engagement experienced within this scenario.
My question is:
How would I actually then query the difference between the beginning of a user_engagement and end of the user engagement ? Currently engagement_time_msec allows me to measure: The additional engagement time (ms) since the last user_engagement event (https://support.google.com/firebase/answer/7061705?hl=en), and not since the beginning of the user_engagement. What if I wanted to measure engagement from the first engagement and last engagement, assuming my specific scenario describe earlier. The idea of this question is to ask how would an example query look like to address this question.
Since I posted this question, I found it would be a lot wiser to look at Session Duration and not Duration between User Engagement Events.
As far as I know, one can not update settings of the user_engagement event, but one can however determine when a session should start (after 0, 5, 10, 15, etc seconds) and b) when a session should end (after 10, 30, 60, etc minutes of inactivity).
To help you get started here is great examples:
How to calculate Session and Session duration in Firebase Analytics raw data?
Session Calculations
Session-Duration Distribution-table in Firebase
Sessions-per-User Distribution-table in Firebase
Important: a Firebase session starts by default after at least 10s since a user_engagement event was triggered (and a session ends after a period of at least 30 minutes of no triggers of user_engagement). And so, whenever users use your app for a period of less than 10s, you will accrue user engagement without a session. This typically means that you will have higher active user base in your dashboard, than users which started a session under your Firebase Events'-tab.
Our site uses Facebook connect. When a new user signs up we ask for permission to pull their interest data, their list of friends, and their friends' interests. Fetching this data used to be a very quick process (couple seconds). Over the last week or so, the time to fetch this data has increase to 10+ seconds. According to Facebook insights, our site is not being throttled. We didn't make any changes to our site.
Anyone else experiencing this issue with Facebook? Have any ideas for how to address it?
Thanks!
As of 1/26 at 7:55 PM EST, the live status page doesn't indicate any irregular activity.
Sometimes this occurs because a user simply has a lot of likes and interests. I would recommend making this operation asynchronous following a flow something like this:
User connects with your app
Get the access token and store it in a queue that a background process can access.
Get all the information you need immediately to make the app work.
Some time later
In a background process, grab an access token from the queue, parse it and handle it however you'd like.
A simpler, although less stable option, is redirecting the user to a page upon installation which makes an AJAX request to that page telling it to download the information from the graph. This keeps the response time low, but does require your user to have Javascript enabled and for them to stay on the destination page long enough for the request to be created.