-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ICE candidate race #10
Comments
I cannot speak for this particular scenario, but it sounds familiar: Most WebRTC stack don't like to get ICE candidates before an ANSWER is available. You should queue the candidates in your code and fire the candidates, once the ANSWER is ready/processed. |
WebRtcEndpointWrapper has a built-in queue that I want to use for this, but unless we create a constructor that doesn't require an sdp then I think I need to duplicate this effort. I'm proposing a slightly different interface for WebRtcEndpointWrapper:
|
OK, then please ignore 👍 |
Hi! Thanks for using the library :) I have two suggestions:
Does it help? |
Awesome, thanks for the reply.
Ah, this makes sense but seems a bit hacky to violate encapsulation.
This is the most appealing, but is this how WebRTC is usually negotiated? According to this it looks like SDP offers and ICE candidates are usually sent pretty simultaneously? As a newbie I'm still trying to understand how things are "usually" done... (is this just an opinionated decision your library makes?) |
Hey, thanks for the awesome lib!
I'm recreating the one2many kurento demo tutorial, and running into a simple problem: When I receive a "present" message from a client, I immediately set up a libKurento.WebRtcEndpointWrapper with the Sdp, but before it is constructed I also receive "onIceCandidate" from the client, so I am unable to call webRtcEndpoint.addClientIceCandidate on the endpoint to put it in the queue.
There's two ways I can think of fixing this without modifying lib-kurento: 1) Have the client only start sending onIceCandidates AFTER it receives the sdp answer. 2) queue the messages myself and pass them to the WebRtcEndpointWrapper when it is ready (not utilizing its internal queue)
That said, if I could create a libKurento.WebRtcEndpointWrapper WITHOUT specifying an sdp (so it could have it around to start queuing ice candidates whenever they are received), and then when I receive an sdp from the client I can call WebRtcEndpointWrapper.init(sdpOffer), that would allow me to utilize the internal queue of WebRtcEndpointWrapper.
So here's what I'm proposing:
Of course I'm new to all this so I might be way off the mark -- please let me know if I'm thinking about this correctly!
The text was updated successfully, but these errors were encountered: