RE: questions about direct assignment

Some of this depends on what we define the origin of Tracks to be.  For example, in a video conferencing case where the conferencing server sends you a PeerConnection with individual video Tracks from all the participants in the conference, is the origin of those Tracks the conferencing server itself, or the individual participants?  If it's the latter, we will certainly have multiple origins in one PeerConnection. 

- Jim

-----Original Message-----
From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com] 
Sent: Monday, June 03, 2013 8:15 AM
To: robert@ocallahan.org
Cc: Stefan Håkansson LK; Jim Barnett; Martin Thomson; public-media-capture@w3.org
Subject: Re: questions about direct assignment

On 2013-06-03 09:51, Robert O'Callahan wrote:
> On Mon, Jun 3, 2013 at 6:15 PM, Adam Bergkvist 
> <adam.bergkvist@ericsson.com <mailto:adam.bergkvist@ericsson.com>> wrote:
>
>     But the key idea is still that all new tracks that the user agent
>     adds (local in the gUM() case, and remote in the PeerConnection
>     case) have the same origin so the stream would never change origin.
>
>
> I'm not up to date on the latest thinking on the WebRTC security model 
> but this might not be the case for PeerConnection. Imagine if you get 
> a gUM track with origin A and add it to a PeerConnection. The remote 
> machine sees a MediaStream with a track with origin A. Then later the 
> local machine gets a PeerConnection track with origin B and adds it to 
> the MediaStream feeding into the PeerConnection. Now the remote 
> machine sees its MediaStream get a new track added with origin B.

Yes, you're right. It may be too limiting (use case-wise) to only expect one origin from a remote peer.

/Adam

Received on Monday, 3 June 2013 12:59:14 UTC