Re: Does addTrack require the streams argument?

About #1:  I like the idea that .ontrack on the remote side doesn't have
any streams if none were in the call to addTrack.    That seems consistent.

About #2: Why does it matter if the track in addTrack is a stream of the
given stream or not?  This is just the local side's way of saying what
should pop out on the remote .ontrack.  If that's what the local side
*wants* to do, why not?  It's weird, but I don't see any benefit of
guarding against it.

I'm in favor of filing #2 but not #1.

On Wed, Nov 25, 2015 at 6:51 AM, Adam Bergkvist <adam.bergkvist@ericsson.com
> wrote:

>  From this discussion I see two issues that could be filed.
>
> #1 RTCPeerConnection.addTrack() should check if track is member of
> supplied streams
>
> #2 Don't create a default stream in 'dispatch a receiver' steps
>
> File?
>
> /Adam
>
> On 2015-10-23 19:44, Peter Thatcher wrote:
> > I think it should be optional.  I see it as perfectly valid for the JS
> > to want to addTrack on one side and see ontrack on the other and not
> > care about MediaStreams in between.  Requiring a MediaStream is just
> > extra burden for no benefit.
> >
> > On Fri, Oct 23, 2015 at 2:17 AM, Stefan Håkansson LK
> > <stefan.lk.hakansson@ericsson.com
> > <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
> >
> >     Trying to resolve Issue #288 [1].
> >
> >     As Jan-Ivar points out, the addTrack method does not mandate the
> >     application to supply MediaStream(s). The question is if this is a
> >     mistake or not, i.e. that it should not be allowed to send a track
> >     without telling what MediaStream it should belong to at the remote
> >     (receiving) end.
> >
> >     I would argue that it should be OK to do so, mainly because I see no
> >     reason for mandating it, but also because it would not let us get
> rid of
> >     the default processing (creating a new MediaStream) at the receiving
> end
> >     if a track with no stream info is added since (?) this would be the
> >     situation in many cases when the sending device is not a browser, but
> >     some other kind of (legacy-ish) device.
> >
> >     Also, note that there is no check on whether or not the track is
> member
> >     of the MediaStream(s) given to addTrack at the sending end - the API
> >     allows for making the track member of a MediaStream on the remote end
> >     even if it is locally not member of the corresponding MediaStream.
> >
> >     As for the larger question: 'Can a live track be consumed outside of
> a
> >     stream (assuming PeerConnection is a consumer)?' my take on that is
> >     "yes" and PeerConnection is the example. The gUM defines out
> >     _MediaStream_ consumers, but I don't see it prohibiting
> MediaStreamTrack
> >     consumers to be defined.
> >
> >     Views, comments?
> >
> >     Stefan (not having strong views, just wanting this to be settled)
> >
> >
> >
> >     [1] https://github.com/w3c/webrtc-pc/issues/288
> >     [2]
> >
> http://w3c.github.io/mediacapture-main/getusermedia.html#dfn-consumer
> >
> >
>
>