-
Notifications
You must be signed in to change notification settings - Fork 114
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
Don't fire SRD() events until target peer identity has been verified. #2251
Conversation
<a href="#dfn-validate-the-identity">identity validation</a> | ||
fails, <a>reject</a> <var>p</var> with a newly | ||
<a data-link-for="exception" data-lt="create">created</a> | ||
<code>OperationError</code>, and abort these steps.</p> |
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.
If the description was applied successfully, but we reject the promise and abort the steps, won't that mean that the JavaScript layer and the JSEP layer are out-of-sync? I.e. there may be JSEP transceivers or m= sections or whatnot, but no JavaScript equivalent RTCRtpTransceivers?
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.
Do we need to tell JSEP to roll back?
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.
You and @alvestrand make the same observation.
In practice if your peer connection has a target peerIdentity (cannot be changed), and you get a bad-identity remote description, you're most likely toast anyway and will want to discard the peer connection, unless there's hope you'll get a valid offer reasonably soon thereafter, in which case you apply SRD again (which is legal).
A corner case may be a previously established connection without a target peerIdentity, then you set one, and then you get a bad-identity remote description. In this case I don't know whether having JSEP apply successfully is any worse than not applying it.
To be safe we should probably just hold off applying anything until the identity is validated. Right now Firefox does it in parallel with SRD, an optimization with little benefit, I suspect.
@@ -1417,6 +1417,17 @@ <h4>Set the RTCSessionDescription</h4> | |||
</li> | |||
</ol> | |||
</li> | |||
<li> | |||
<p>If <var>description</var> is set as a remote description and |
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.
It doesn't make sense to apply the description before you have verified the identity, I think.
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.
@alvestrand Good point. @martinthomson WDYT?
Start the process before applying the description |
This is OBE based on the TPAC 2019 plan of moving the normative language into the identity spec. |
Fixes https://github.com/w3c/webrtc-pc/issues/2173.
Preview | Diff