W3C home > Mailing lists > Public > public-webrtc@w3.org > October 2012

RE: User media constraint: peerIdentity

From: Li Li <Li.NJ.Li@huawei.com>
Date: Wed, 24 Oct 2012 16:20:49 +0000
To: Martin Thomson <martin.thomson@gmail.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <B60F8F444AAC9C49A9EF0D12D05E0942216D13B7@szxeml535-mbx.china.huawei.com>
Martin,

How about sending the tagged stream to a <video> element for self-view? Is it permitted? 
If so, I'm not sure if the <video> object will keep the tag. If it doesn't, the stream can run free.
Even if it keeps the tag, as you said, requiring all other stream processing API outside WebRTC to deal with this constraint (and errors from it) is difficult.

Is it true that such constrained streams can only follow this path:

camera/mic -> peer connection -> network  

If so, we can force this path in WebRTC API easily without leaking our constraint/errors to other API.

We can construct a peer connection object with peerIdentity:identity constraint, and use a new constraint "targetConnection: pc" in getUserMedia() to tie the stream to the peer connection object.

With these constraints, the getUserMedia() success callback and pc.localStream will return null to prevent the page from accessing the stream other than sending it to a remote peer.

Thanks.
Li


-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Tuesday, October 23, 2012 5:50 PM
To: Li Li
Cc: public-webrtc@w3.org
Subject: Re: User media constraint: peerIdentity

On 23 October 2012 14:40, Li Li <Li.NJ.Li@huawei.com> wrote:
> This is an interesting idea. But I wonder how browsers can prevent a page from using any post-processing API [1] to access the constrained media stream.

It's fairly straightforward.  Tag the media stream, and refuse to
permit any operation on that media stream *except* sending to an
authenticated RTCPeerConnection.

> Do we require those APIs to be aware of peerIdentity and refuse any such constrained media streams?

Yes.  To the extent that failure is a possibility and reporting that
failure is probably necessary.  This would introduce a new failure
mode to each of those APIs.  Most of the awareness would be attached
to the stream itself.  Of course, the extent to which this is possible
depends on the details of the browser implementation.  I imagine that
this could be made very difficult to achieve.
Received on Wednesday, 24 October 2012 16:23:06 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:30 UTC