- From: Justin Uberti <juberti@google.com>
- Date: Fri, 6 Mar 2015 17:52:20 -0800
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CAOJ7v-1EgAomY-d7zWLYsBsXF3qUvCZ6+_zBFv2bMZmBSnLvgQ@mail.gmail.com>
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 all in favour of bashing bugs. Virtual interims anyone? > I think this would be a great idea, perhaps focusing on documenting and editing in existing agreed decisions rather than opening new issues. > > 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. > Agree completely, and this is covered in JSEP. See https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-08#section-5.3.1, para 6. > > > > > 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. > >
Received on Saturday, 7 March 2015 01:53:09 UTC