Isolated tracks

Based on the discussion at the meeting, these are the conclusions I took away:


1. We need to surface isolation properties:

partial interface MediaStreamTrack {
  attribute boolean isolated;
  attribute EventHandler? onisolationchange;
};

isolated is true for cross origin, DRM'd, and peerIdentity streams.

Dom suggested that we indicate whether this property is permanent or
not, but I'd rather not do that.  There are cases where an application
can know that this status is permanent (such as when the track comes
from gUM, and a tainted canvas cannot be un-tainted), but I think that
the advantages are fairly marginal.


2. Get the reason for negotiating an isolated RTCPeerConnection right

Since peerIdentity constrained tracks are the only type of isolated
track that can actually be sent over the network, these are the only
type of track that will cause the RTCPeerConnection to request stream
isolation (and the ALPN tag).

This means that other types of isolated tracks will not cause the
session to become isolated.


3. Surface an error when a track stops sending content

We will not prevent an application from calling addTrack on an
isolated track.  For the case where the isolated property changes,
this would prevent an application from preparing a session with tracks
that are currently isolated.

Instead, we will provide an event when tracks start sending
black/silence/null.  I'm thinking that the RTCRtpSender is the right
place to put this event:

partial interface RTCRtpSender {
  attribute EventHandler? onsendnull;
};


4. We need to make a note that metadata is leaked for isolated tracks

That's an editorial tweak, but it's also a note that we need to be
careful with stats.

So far, only audio level concerns me.  More than ever, I'm thinking
that we need to make audio level a property of a track, not something
that appears in stats.


I plan to send pull requests for each of these items to the editors
over the next few weeks.

Received on Thursday, 22 May 2014 14:56:14 UTC