Matching VideoRoom subscribers to participants#741
Merged
Conversation
Member
Author
|
I'm thinking of ways to do that at a core level as well: an opaque string identifier that can be passed when attaching a handle, and that can be used for mapping reasons in stuff like Admin API and Event Handlers. Anyway, I'll do that in a different PR: this one is harmless enough to merge right away. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
One thing I noticed when playing with event handlers and plugins is that there sometime is some missing context information that would be helpful to have instead. Among this, we currently have no way to understand who a specific viewer handle in a VideoRoom belongs to: we do know who they are subscribed to, but not if it's a watch stream I created or somebody else. Relying on the session alone doesn't help, as there are applications that aggregate handles from different users in the same sessions (e.g., server side applications).
This PR tries to address this, adding a new private identifier that the participant can use to clarify a subscription belongs to them. Besides providing a better overview of how a VideoRoom is happening (who's publishing, and who's getting/not getting who?), this way if there's any trouble, e.g., ICE failures and things like that, you have more context too.
You may be wondering why not re-use the already existing participant ID for the purpose. The reason for this is is that the participant ID is known to everybody in the room, and I wanted something harder to "abuse" (not that there may be any particular reason to abuse the feature, if not to be annoying...). As such, the idea is that when you join as a participant, you get your ID as before, and you also get a new ID back called
private_id. Then, if you want, every time you subscribe to somebody else in the room you add the sameprivate_idin the request as well. The plugin does nothing with this identifier (no validation), but only stores it, and uses it when notifying handlers. This way, handlers and related applications can use this private identifier to know which handles belong to you as a participant in the room.This feature is absolutely optional: passing the
private_idor not when subscribing results in no change at all in the user experience. As anticipated, it's just a feature that allows for a better matching of some of the handles in the VideoRoom, something I believe would definitely help in monitoring and troubleshooting based on handlers. I plan to merge this soon, since this is pretty harmless, and the idea is to write a new blog post on event handlers soon to show this in use to debug a VideoRoom live.Feedback welcome!