Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Don't fire SRD() events until target peer identity has been verified. #2251

Closed
wants to merge 1 commit into from
Closed

Don't fire SRD() events until target peer identity has been verified. #2251

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 13 additions & 2 deletions webrtc.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Contributor

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.

Copy link
Member Author

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?

is applied successfully, and a <a>target peer identity</a> is
set, then the user agent MUST wait for
<a href="#dfn-validate-the-identity">identity validation</a>
to complete before proceeding to the next step. If
<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>
Copy link
Contributor

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?

Copy link
Contributor

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?

Copy link
Member Author

@jan-ivar jan-ivar Aug 30, 2019 •
edited
Loading

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.

</li>
<li>
<p>If <var>description</var> is applied successfully, the user
agent MUST queue a task that runs the following steps:</p>
Expand Down Expand Up @@ -3257,8 +3268,8 @@ <h2>Methods</h2>
<p>In addition, a remote description is processed to determine
and verify the identity of the peer.</p>
<p data-tests>If an <code>a=identity</code> attribute is present in the
session description, the browser <a data-cite="!WEBRTC-IDENTITY##sec.identity-verify-assertion">validates the identity
assertion.</a>.</p>
session description, the browser <a data-cite="!WEBRTC-IDENTITY#sec.identity-verify-assertion">validates the identity
assertion</a>.</p>
<p>If the <a data-link-for="RTCConfiguration">peerIdentity</a> configuration is applied to the
<code><a>RTCPeerConnection</a></code>, this establishes a
<dfn id="target-peer-identity">target peer identity</dfn> of
Expand Down