jitsi-meet
jitsi-meet copied to clipboard
Feature request: Make speakerstats counter resume after reload if users context.users.id provided in token didn't change.
Is your feature request related to a problem you are facing? I would like to be able to resume speakerstats counter for participants with same id provided via token after reload instead of creating a new speakerstats for new user
Also it makes cleaner speakerstats table if its sent for further processing.
Describe the solution you'd like Solution requires two main things
-
Add id from token to partipant self.username as first xxxxxxxx of the username with which we make sure that occupants nick will be actually equal to token_id. Example : a0ef2c62-f9524779-6f52-4c46-9049-d3846e1ab5f5 a0ef2c62-372188d3-d10e-4297-b939-5a463f91b296 Different users with same nick. Inside mod_auth_token.lua
self.username = session.jitsi_meet_context_user.id .. "-" .. message;
-
Change Speakerstats table to be indexed with nick instead of jid so we could easily check if newly joined participant have same nick as previous one and just either create new table on same nick index (with passing oldSpekerTime) or keep the old one. Inside mod_speakerstats_component.lua
local nick = jid_resource(occupant.nick);
local speakerStatsForOccupant = room.speakerStats[nick];
room.speakerStats[nick] = new_SpeakerStats(nick, context_user, oldtotalDominantSpeakerTime );
function getoldtotalDominantSpeakerTime(room, nick)
if room.speakerStats[nick] then
return room.speakerStats[nick].totalDominantSpeakerTime
else
return nil
end
end
-- In case user already exist in the table pass oldtotalDominantSpeakerTime = getoldtotalDominantSpeakerTime(room, nick)
function new_SpeakerStats(nick, context_user, oldtotalDominantSpeakerTime)
return setmetatable({
totalDominantSpeakerTime = oldtotalDominantSpeakerTime or 0;
_dominantSpeakerStart = 0;
_isSilent = false;
_isDominantSpeaker = false;
nick = nick;
context_user = context_user;
displayName = nil;
faceLandmarks = {};
}, SpeakerStats);
end
I have made it working so first i just wanted to check if there is interest from your side for this so we could discuss further best approach for implementation. Describe alternatives you've considered I have checked on meet.jit.si and default behaviour is that new speakerstats table is created for new user and counter starts from zero. In this case the same user will have his counter starting from the point where he reloaded and no new index in speakerstats table will be created in case nick index already exist(user with same token id logged in) Prerequisite is to make sure that the user have same token id, it can be accomplished with cookie for example.
Prerequisite is to make sure that the user have same token id, it can be accomplished with cookie for example.
That is not an option there will always be guests that join without a token.
It doesn't have to be the case if token authentication is enabled and guest domain is disabled ? For example we have application that have guests from application view but even when "guest " wants to join he gets appropriate token so from jitsi aspect it is authenticated user( it is not guest). And guests are not allowed (not-authenticated) When application guest reloads we make sure that token is reused by using cookie. I can send more specific code regarding that if required.
Even if guests are allowed, it would not break default functionality, new user table would be created, it would just not create a new one for authenticated ones.
The problem here is that you need to sync backend and UI. You need to implement that in both lua and js. Not sure UI clients has access to this mapping of a jid to the id coming from jwt.context.user.id. If you do not do the implementation in UI, the backend will send the current state when joining and UI will still create a new entry for the participants that are becoming dominant speaker, as the event coming from jvb is based on the endpoint id, which is the nick in the room.
Every user will have unique jid which will be consisted of two parts : session.jitsi_meet_context_user.id .. "-" .. message;
only in case there is token_id, and if not it will stay as random_uuid().
We are still sending update to jids inside mod_speakerstats_component.lua
` if next(users_json) ~= nil then
local body_json = {};
body_json.type = 'speakerstats';
body_json.users = users_json;
local stanza = st.message({
from = module.host;
to = occupant.jid; })
:tag("json-message", {xmlns='http://jitsi.org/jitmeet'})
:text(json.encode(body_json)):up();
room:route_stanza(stanza);
end
`
We are just changing speakerstats table to be indexed with index instead of jid and not creating a new table for user if it already exist in the table, which means that if there is no token_id everything will work as it is working now (creating new user table) Mapping between token_id and nick would be one to one (exactly the same). JIDs will stay unique.
I am not sure what exactly needs to be implemented in UI, can you please provide me with more insights as my solution is working now and it might be i am missing something ?
And you say that user A has id in token AAA but when it joins the meeting that user is with nick in the room BBB, verything works as today, where jvb is sending a dominant speaker changed to BBB and so on. The user A reloads and has CCC as nick in the room, you have stored in the speaker stats in the backend that the id in the table is AAA and for every new participant that joins this is what will be reported. But jvb is sending dominant speaker changed event for CCC and every one that was already in the meeting will create a new UI entry for that change and will add that use A started talking, but this entry is different from the previous one for BBB.
Isn't this what you observe with the change?
And you say that user A has id in token AAA but when it joins the meeting that user is with nick in the room BBB, verything works as today, where jvb is sending a dominant speaker changed to BBB and so on. The user A reloads and has CCC as nick in the room
I say that user A has id in token AAA but when it joins the meeting that user is with nick AAA in the room.The user A reloads and has AAA as nick again in the room If there is no token_id ,everything works as today, where jvb is sending a dominant speaker changed to BBB and so on.
Logic is below: With token If there is token_id than :
User A
token_id: AAA
nick: AAA
jid: AAA+UUID-A
After reload:
User A
token_id: AAA
nick: AAA
jid: AAA+UUID-B
Only UUID part is changed
When user A reloads it gets the same nick as it was having before (Nick == token_id) but it gets diffrent JID JVB keeps sending to nicks which didn't change. We don't create new speakerstats index, we can just create new table on the same index and update speakertime with previous state. SpeakerStats Users table stays the same and counter continues.
Without token If there is no token_id than
User A
token_id: nil
nick: occupant.nick()
jid: UUID-Y
After reload:
User A
token_id: nil
nick: occupant.nick()
jid: UUID-Z
In this case it works the same as now and both nick and jid changed, new speakerstats table added, counter starts from zero.
I say that user A has id in token AAA but when it joins the meeting that user is with nick AAA in the room.The user A reloads and has AAA as nick again in the room
So you say you will be changing what nick to use when joining the room. Reusing nicknames is very dangerous, when for example you lose internet connection and you hit reload button you will not be able to join till your session on the server expires, which happens in a minute.
I am not changing the "how to get nick" function, i am using your function to get the Nick, its just automatically set to TokenID, as jid is TokendId+UID, meaning it stays the same if tokenID is the same. Okey if that is dangerous, didn't see that , as reconnect works well also in less than a minute with smacks plugin.
Sent from Outlook for Androidhttps://aka.ms/AAb9ysg
From: Дамян Минков @.> Sent: Saturday, January 27, 2024 2:51:33 PM To: jitsi/jitsi-meet @.> Cc: Srdjan ilic @.>; Author @.> Subject: Re: [jitsi/jitsi-meet] Feature request: Make speakerstats counter resume after reload if users context.users.id provided in token didn't change. (Issue #14271)
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
I say that user A has id in token AAA but when it joins the meeting that user is with nick AAA in the room.The user A reloads and has AAA as nick again in the room
So you say you will be changing what nick to use when joining the room. Reusing nicknames is very dangerous, when for example you lose internet connection and you hit reload button you will not be able to join till your session on the server expires, which happens in a minute.
— Reply to this email directly, view it on GitHubhttps://github.com/jitsi/jitsi-meet/issues/14271#issuecomment-1913161754, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BDU4RMEHNTIWFVCYHY7AKY3YQUA6LAVCNFSM6AAAAABCGTBO56VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTGE3DCNZVGQ. You are receiving this because you authored the thread.Message ID: @.***>
NOTICE: This e-mail and any accompanying documents contain confidential information intended for a specific individual which is private and protected by law. If you are not the intended recipient, any disclosure, copying, distribution or other use of this information is strictly prohibited. You are also requested to advise us immediately if you receive information which is not addressed to you. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
I am not changing the "how to get nick" function, i am using your function to get the Nick, its just automatically set to TokenID, as jid is TokendId+UID, meaning it stays the same if tokenID is the same.
You do not have token id of participant A distributed and available to all other participants, so you cannot match that to be able to update the local UI based on jvb reports.
If user identity is equal to (nick+jid ) you are right, but your function takes nick from jid so its duscussable, as they are dependent. That is why i don't see issue of keeping the same nick for same user after reload although i agree it would be better solution to introduce new field for that in order to not hijack current logic.
Sent from Outlook for Androidhttps://aka.ms/AAb9ysg
From: Дамян Минков @.> Sent: Saturday, January 27, 2024 3:46:19 PM To: jitsi/jitsi-meet @.> Cc: Srdjan ilic @.>; Author @.> Subject: Re: [jitsi/jitsi-meet] Feature request: Make speakerstats counter resume after reload if users context.users.id provided in token didn't change. (Issue #14271)
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
I am not changing the "how to get nick" function, i am using your function to get the Nick, its just automatically set to TokenID, as jid is TokendId+UID, meaning it stays the same if tokenID is the same.
You do not have token id of participant A distributed and available to all other participants, so you cannot match that to be able to update the local UI based on jvb reports.
— Reply to this email directly, view it on GitHubhttps://github.com/jitsi/jitsi-meet/issues/14271#issuecomment-1913177092, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BDU4RMHC6PHHA45J5JM34U3YQUHLXAVCNFSM6AAAAABCGTBO56VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTGE3TOMBZGI. You are receiving this because you authored the thread.Message ID: @.***>
NOTICE: This e-mail and any accompanying documents contain confidential information intended for a specific individual which is private and protected by law. If you are not the intended recipient, any disclosure, copying, distribution or other use of this information is strictly prohibited. You are also requested to advise us immediately if you receive information which is not addressed to you. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
I have it, as a nick :)
Sent from Outlook for Androidhttps://aka.ms/AAb9ysg
From: Srdjan ilic @.> Sent: Saturday, January 27, 2024 3:57:55 PM To: jitsi/jitsi-meet @.>; jitsi/jitsi-meet @.> Cc: Author @.> Subject: Re: [jitsi/jitsi-meet] Feature request: Make speakerstats counter resume after reload if users context.users.id provided in token didn't change. (Issue #14271)
If user identity is equal to (nick+jid ) you are right, but your function takes nick from jid so its duscussable, as they are dependent. That is why i don't see issue of keeping the same nick for same user after reload although i agree it would be better solution to introduce new field for that in order to not hijack current logic.
Sent from Outlook for Androidhttps://aka.ms/AAb9ysg
From: Дамян Минков @.> Sent: Saturday, January 27, 2024 3:46:19 PM To: jitsi/jitsi-meet @.> Cc: Srdjan ilic @.>; Author @.> Subject: Re: [jitsi/jitsi-meet] Feature request: Make speakerstats counter resume after reload if users context.users.id provided in token didn't change. (Issue #14271)
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
I am not changing the "how to get nick" function, i am using your function to get the Nick, its just automatically set to TokenID, as jid is TokendId+UID, meaning it stays the same if tokenID is the same.
You do not have token id of participant A distributed and available to all other participants, so you cannot match that to be able to update the local UI based on jvb reports.
— Reply to this email directly, view it on GitHubhttps://github.com/jitsi/jitsi-meet/issues/14271#issuecomment-1913177092, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BDU4RMHC6PHHA45J5JM34U3YQUHLXAVCNFSM6AAAAABCGTBO56VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTGE3TOMBZGI. You are receiving this because you authored the thread.Message ID: @.***>
NOTICE: This e-mail and any accompanying documents contain confidential information intended for a specific individual which is private and protected by law. If you are not the intended recipient, any disclosure, copying, distribution or other use of this information is strictly prohibited. You are also requested to advise us immediately if you receive information which is not addressed to you. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
But you cannot have the same nick in the room twice. So this cannot be used. This will break experience for anyone that needs to reload due to bad network.
Even if new user logged in with new jid and previous left ?
Sent from Outlook for Androidhttps://aka.ms/AAb9ysg
From: Дамян Минков @.> Sent: Saturday, January 27, 2024 5:00:57 PM To: jitsi/jitsi-meet @.> Cc: Srdjan ilic @.>; Author @.> Subject: Re: [jitsi/jitsi-meet] Feature request: Make speakerstats counter resume after reload if users context.users.id provided in token didn't change. (Issue #14271)
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
But you cannot have the same nick in the room twice. So this cannot be used. This will break experience for anyone that needs to reload due to bad network.
— Reply to this email directly, view it on GitHubhttps://github.com/jitsi/jitsi-meet/issues/14271#issuecomment-1913210907, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BDU4RMAQYEG7TTDU3ITOWEDYQUQDTAVCNFSM6AAAAABCGTBO56VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTGIYTAOJQG4. You are receiving this because you authored the thread.Message ID: @.***>
NOTICE: This e-mail and any accompanying documents contain confidential information intended for a specific individual which is private and protected by law. If you are not the intended recipient, any disclosure, copying, distribution or other use of this information is strictly prohibited. You are also requested to advise us immediately if you receive information which is not addressed to you. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
Even if new user logged in with new jid and previous left ?
The problem is when the previous will leave, it can be up to a minute. In that minute the participant cannot join.
Okey, i hope you will consider this in future by introducing new field like have_token_id :) , as it's really intuitive to see counter continuing for auth user after reload. Thanks for response! If you need my code that works for our case let me know to make PR. Regards, Srdjan
Sent from Outlook for Androidhttps://aka.ms/AAb9ysg
From: Дамян Минков @.> Sent: Saturday, January 27, 2024 5:57:02 PM To: jitsi/jitsi-meet @.> Cc: Srdjan ilic @.>; Author @.> Subject: Re: [jitsi/jitsi-meet] Feature request: Make speakerstats counter resume after reload if users context.users.id provided in token didn't change. (Issue #14271)
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Even if new user logged in with new jid and previous left ?
The problem is when the previous will leave, it can be up to a minute. In that minute the participant cannot join.
— Reply to this email directly, view it on GitHubhttps://github.com/jitsi/jitsi-meet/issues/14271#issuecomment-1913259149, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BDU4RMACLTBXQDTWTMVPRB3YQUWV3AVCNFSM6AAAAABCGTBO56VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTGI2TSMJUHE. You are receiving this because you authored the thread.Message ID: @.***>
NOTICE: This e-mail and any accompanying documents contain confidential information intended for a specific individual which is private and protected by law. If you are not the intended recipient, any disclosure, copying, distribution or other use of this information is strictly prohibited. You are also requested to advise us immediately if you receive information which is not addressed to you. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
In case websocket is used, it will reconnect properly. I agree that reload is issue. Sent from Outlook for Androidhttps://aka.ms/AAb9ysg
From: Дамян Минков @.> Sent: Saturday, January 27, 2024 5:57:02 PM To: jitsi/jitsi-meet @.> Cc: Srdjan ilic @.>; Author @.> Subject: Re: [jitsi/jitsi-meet] Feature request: Make speakerstats counter resume after reload if users context.users.id provided in token didn't change. (Issue #14271)
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Even if new user logged in with new jid and previous left ?
The problem is when the previous will leave, it can be up to a minute. In that minute the participant cannot join.
— Reply to this email directly, view it on GitHubhttps://github.com/jitsi/jitsi-meet/issues/14271#issuecomment-1913259149, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BDU4RMACLTBXQDTWTMVPRB3YQUWV3AVCNFSM6AAAAABCGTBO56VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTGI2TSMJUHE. You are receiving this because you authored the thread.Message ID: @.***>
NOTICE: This e-mail and any accompanying documents contain confidential information intended for a specific individual which is private and protected by law. If you are not the intended recipient, any disclosure, copying, distribution or other use of this information is strictly prohibited. You are also requested to advise us immediately if you receive information which is not addressed to you. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.