peerIdentity and transparency

One final thing regarding the peerIdentity "constraint" that I think
is worth discussing briefly.

When an application gets a MediaStream (or MediaStreamTrack) that has
been created with peerIdentity constraints, there is no way to
distinguish this from other streams/tracks.  That might be surprising
to some when they get black/silence (RTCPeerConnection) or errors
(sampling with canvas).

Is there any desire to solve this problem?

I warn that this is a non-trivial issue to address for several reasons:

We already have these sorts of transparency issues when it comes to
MediaStreams that originate from <video> and <audio> tags (using
captureStreamUntilEnded() and equivalent functions).  Those too can be
isolated from the application.  When we get streams out of a "private"
WebRTC call, that will also have similar properties.  I haven't even
begun to describe what happens with webaudio :).

In these different cases, the isolation will be based on a different
property than 'peerIdentity'.

The property can change dynamically, not for gUM streams, but for
these other cases it will.

When tracks from disparate sources are added to the same stream, the
stream itself will gain an amalgam of the track restrictions.

My feeling is that we should be leaving this alone.  At best, we could
tag the streams or tracks with a flag that says if they are isolated
or not.  That's not really much to go on.  It doesn't even tell you if
you could send it to someone over RTCPeerConnection.  Given that the
application is largely in control of instantiation of these objects,
and is ultimately responsible for any isolation that is happening, I'm
happy to do nothing about this issue.

Received on Thursday, 6 February 2014 01:03:05 UTC