Unfinished webrtc negotiation rework #1293
Open
Conversation
This file contains 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
|
I'm not smart enough to know what the perfect negotiation is? That'd be cool to have the video/audio streams directly! Tho... how would that be passed back to the application? Want to do a quick screencall to explain the concept & see if we can find someone else to continue? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Why
To be able to use single GUNs peer connection for sending video and audio in a meeting app
How
Implement perfect negotiation to be able to add or remove new application specific video/audio/data channels with proper renegotiation and see incoming streams on the other side
Current state
Abandoned. Broken and I don't even recall why. afair it is because I was only able to send one ACK for a single message
Initial idea (afair)
Per each peer we need separate bidirectional signalling channel so that both sides could trigger renegotiation when adding new audio/video streams. So I tried to implement bidirectional channel via ACKs, but was only able to send only one in a given "channel" (gundb specifics?)
Why make pull request then?
atm I abandoned the project. If someone else wants the same feature they can maybe start from here. Or this is gibberish and can be ignored.
In any case. If you will decide to continue from here. You will probably first have to implement bidirectional communication between selected peers first and after that perfect negotiation will be easy peasy