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

Should have read Justin's mail before I wrote.

I'm not sure that the .stop() part is entirely clear, but I agree the rest
is.
I'll leave the issue open pending reexamining the spec and discussing
with Justin.

-Ekr

On Fri, Mar 6, 2015 at 7:26 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Fri, Mar 6, 2015 at 2:02 AM, Harald Alvestrand <harald@alvestrand.no>
> wrote:
>
>>  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 sure that's true, but I'd love to get a list of these so we can bash
> them
> out. Do you have any to contribute?
>
>
> 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.
>>
>
> Yes, this would be my expectation.
>
>
>
>> (Those agreements need to be documented in JSEP, btw - they're out of
>> scope for the WebRTC spec, given our current division of labor.)
>>
>
> https://github.com/rtcweb-wg/jsep/issues/112
>
> -Ekr
>
>
>> 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>
>> wrote:
>>
>>> On 5 March 2015 at 07:01, Jan-Ivar Bruaroey <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.
>>
>>
>