Re: Should pc.getRemoteStreams() include all remote tracks after pcsetRemoteDescription() ?

On 03/06/2015 01:07 AM, Justin Uberti wrote:
> The unearthing of various things like this (e.g.
> onnegotiationneeded) make me think we ought to have some sort of bug
> bash where we just go through and fix all the places in the spec where
> text no longer matches reality.

Which reality .....?

We have places where Firefox doesn't match Chrome doesn't match the
spec. At least 2 of the 3 are wrong, but which 2?

I'm all in favour of bashing bugs. Virtual interims anyone?

As for "rejecting a track" being different from closing a track, my
conclusion has always been that there is no such thing; nobody's been
able to explain what they mean by it in a way that makes sense.

I think we have agreement that returning a zero on the port number, or
putting "a=recvonly", in a track's m-line in SDP can be considered
"rejecting" an incoming track.

I think we have agreement that calling track.stop() on an incoming track
causes the next createOffer or createAnswer to put zero in that port
number or putting "a=recvonly" in for that m-line.

(Those agreements need to be documented in JSEP, btw - they're out of
scope for the WebRTC spec, given our current division of labor.)

So I'm pretty sure we don't have any agreement that there's a documented
need for any means of rejecting a track apart from "track.stop()" -
there's no observable difference  between rejecting a track and stopping
a track, so we shouldn't try to create one.


>
> On Thu, Mar 5, 2015 at 9:39 AM, Martin Thomson
> <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>> wrote:
>
>     On 5 March 2015 at 07:01, Jan-Ivar Bruaroey <jib@mozilla.com
>     <mailto:jib@mozilla.com>> wrote:
>     > How does one reject? I've heard talk about calling track.stop()
>     on the
>     > remote track but couldn't find that in the spec.
>
>     This is based on a proposal that Adam floated something like 2 years
>     ago.  It got pretty good feedback, and most of the discussion over
>     that period has sort of assumed that was the way things were.  Like
>     this issue however, no effort has been put in to actually change the
>     spec.
>
>


-- 
Surveillance is pervasive. Go Dark.