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

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.
>
>