-
Notifications
You must be signed in to change notification settings - Fork 62
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
Fix loop when an SDP offer is received without video #536
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this solution better than what I did on the V3.
I'm going to port it over to v3 as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks! 🚀 please rebase your branch with the main.
I might be wrong but just thinking out loud; this seems like a design change considering we will no longer negotiate the video/audio in case the offer SDP does not include the video/audio. This might impact the end user, right? and we probably want to release this as a new minor version of the SDK.
Even without these changes the answer SDP from the SDK would not have a video section, if the offer didn't. Apart from the possibility of regressions that can always happen with changes, it seems to me more like a refactoring or fix, rather than a behaviour change. Let me know what you think. |
Gotcha, then I think it's fine. Thanks for the details. 👍 |
f6081f0
to
f91d9d1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🥇
When an SDP offer is received without video, the current code still performs a
getUserMedia()
request withvideo
set totrue
.Then the local streams are added to the RTCPeerConnection, before the remote description has been added to it.
This triggers an additional
onnegotiationneeded
that callsstartNegotiating()
again, which in turns calls_createAnswer()
again, which will trigger newonnegotiationneeded
events in a loop that continues for the duration of a session.I'm not sure about the side effect of this loop, but I'm concerned it may appear as missing ICE candidates in the answer SDP, as if the loop is impacting the correct addition of ICE candidates to the answer SDP that's being built.
To reproduce this and see the loop:
onnegotiationneeded
With the changes in this PR instead the constraint for getUserMedia will depend on the combination of available devices and what was received in the offer. An audio-only offer will only cause a getUserMedia with
video
false
.