Re: [rtcweb] inactive m-lines in draft-ietf-rtcweb-jsep-05

Justin Uberti <juberti@google.com> Mon, 04 November 2013 07:36 UTC

Return-Path: <juberti@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8525921E812A for <rtcweb@ietfa.amsl.com>; Sun, 3 Nov 2013 23:36:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.507
X-Spam-Level:
X-Spam-Status: No, score=-1.507 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a20Ds4iMh4dm for <rtcweb@ietfa.amsl.com>; Sun, 3 Nov 2013 23:36:22 -0800 (PST)
Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6D59921E815C for <rtcweb@ietf.org>; Sun, 3 Nov 2013 23:36:18 -0800 (PST)
Received: by mail-vc0-f177.google.com with SMTP id ib11so4301467vcb.22 for <rtcweb@ietf.org>; Sun, 03 Nov 2013 23:36:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xYMKi1EJ1HLNNdMH/xlc+WvC5TbYQ2V7Fu30lxWAMq8=; b=N7Dw3CosbR5xScQjepTvbggJ2YZCx1kAbopEHsnO3S7XBbYuBrC5N8Padz+adQ0wPD kdHdeZyCeIwrb4AUBlwoh57o4qmHicwTOKUXDS5w8uMPYOyzXDEG0r+Xx0ncmhh/Rbt4 DpOMiPEAoxgR+TScfWvZgcSjiedPJ57WzSDzz8ze0y1dYq0IWok2d4sSHXXjKqILynJK VSpn4rSjoY7NtsLchVft4w7uZcmrVb88VcxyiYwqiRK4OJPgL6mZ32plIgaj6NqHLj0i rygGUrI6L/8Z30Rv2qOoQ6CUaEaXd0AdmKYztNqhyOTZW1h+SGjNMgx7YOz+OGHIChrD Hafg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xYMKi1EJ1HLNNdMH/xlc+WvC5TbYQ2V7Fu30lxWAMq8=; b=c1G4n0LP7fYXr1xgAcTauPSBS2pVkmP1OWpvgjUzl/jp5sd/5JuoXek8BO/Yphjgpj n+c1zt6+HSnOAGroUMAqEYJhzmybWPcBL64Nw2TNCY+TTiSBHfDcicvKrruCV/+U6ZIN iPO3qzdPwl7JRPTFEkKMn6KjnA5MSBAFjxXuRUUzVbiYGStbuR0Y4n/XaTGPoQ+LyQWH iVqBqL/I70s44uNyElp+uYjNyyTHrebyqnPagYZDof9HxhNXxMn6v/nkEhkzQgQ5wCUE /M+FKtxwIzbxWB1hE3aZsP4MLpyYidHojEjruR9daCpbvPADBUru8muGyP3/ibMoOdF8 7j1A==
X-Gm-Message-State: ALoCoQnwnXABAsG6Icgc5xxTqdei0bsq5Mg+8i5nYyJW9IyKEjatqt1WbUeHKplqM2OFtSUa6f2RNnAWpH9wlbQsTLl0J/N9CQXOgbmiG4qEyvuMXgmFt96F2qbmSumIHyJWmkDBrMDBdpRrrUNT+wkVWPFi708/Ef5gDXDUZRFSUFXVOg/x0QU4hqGNS31ocPzHALfT4SNt
X-Received: by 10.58.46.18 with SMTP id r18mr10663711vem.4.1383550576364; Sun, 03 Nov 2013 23:36:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Sun, 3 Nov 2013 23:35:56 -0800 (PST)
In-Reply-To: <527494D0.2060107@alvestrand.no>
References: <526FCEC1.7000904@alum.mit.edu> <CABkgnnV4OpPNV41g4owehWOXRv0eiFb6njiu9tChQyOVR8-E3A@mail.gmail.com> <52700422.4020002@alum.mit.edu> <CABkgnnX0+ii2am8LhUHVmP1DHr1ygmVxYZxFMe-AVgL56ZJgOg@mail.gmail.com> <527414A5.9090904@alum.mit.edu> <CABkgnnXKKe-HVo_Z4nP=B7bEYDDp+LzcAoc=p-UKi=WrDtm81g@mail.gmail.com> <52743004.50801@alum.mit.edu> <527494D0.2060107@alvestrand.no>
From: Justin Uberti <juberti@google.com>
Date: Sun, 3 Nov 2013 23:35:56 -0800
Message-ID: <CAOJ7v-20nZOpZbsVG5+Opd6X2JEaaO2OW5c7=9K62M19G=aM8g@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: multipart/alternative; boundary=089e01294482a222fc04ea54f817
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] inactive m-lines in draft-ietf-rtcweb-jsep-05
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Nov 2013 07:36:24 -0000

Harald's understanding is correct.

Concerning the original question about Section 5.3.1, the text tried to
indicate that the processing described should be performed for each "send"
MediaStreamTrack. The local endpoint has no control over how the remote
endpoint associates MSTs with m= lines. However, the mapping of "enabled"
to the directional attribute is something we need to discuss, and if
sensible, write into the draft.


On Fri, Nov 1, 2013 at 10:59 PM, Harald Alvestrand <harald@alvestrand.no>wrote;wrote:

> On 11/01/2013 11:49 PM, Paul Kyzivat wrote:
> > On 11/1/13 2:10 PM, Martin Thomson wrote:
> >> On 1 November 2013 13:52, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> >>>
> >>> "MediaStreamTrack.readonly Read only
> >>>      Is a boolean value with a value of true if the track is
> >>> readonly (such a
> >>> video file source or a camera that settings can't be modified), false
> >>> otherwise."
> >>>
> >>> That seems to imply that one that isn't read-only must be read-write. I
> >>> don't see any mention of write-only.
> >>
> >>
> >> This attribute only really pertains to the constraints API, which is
> >> used to do things like switch cameras between capture modes.  This is
> >> to do things like change resolutions or capture rates on physical
> >> devices.  The assumption here is that this interface is not
> >> appropriate for tracks that originate from the network and so this is
> >> a clear signal to an application that trying to apply constraints is
> >> going to fail.
> >
> > OK, so that doesn't mean what I thought it did. (Sorry, but I haven't
> > been following the WebRTC API side of this.)
> >
> > Looking at:
> >
> > http://dev.w3.org/2011/webrtc/editor/getusermedia.html#mediastreamtrack
> >
> > I don't find any notion of readonly or writeonly tracks. If you are
> > going to use the presence of readoly and writeonly tracks to determine
> > the directionality of the m-line, what property of the track
> > determines that?
>
> A MediaStreamTrack is unidirectional. Think of it as an SSRC; it helps
> (even though simulcast and repair flows make the picture more complex).
>
> The basic decision of UnifiedPlan was to map a maximum of 2
> MediaStreamTracks (one in each direction) to each m-line.
>
> So the directionality of an m-line is dictated by whether there are
> tracks mapped to it in each direction, and whether they are active (if
> we decide to map "active"; this isn't clearly decided yet, I think).
>
> Table:
>
> Tracks that are mapped
> to this M-line                            Resulting m-line state at A
>
> None                                        a=inactive
> A->B, disabled                         a=inactive
> A->B, enabled                         a=sendonly
> A->B enabled, B->A disabled  a=sendonly
> A->B enabled, B->A enabled  a=sendrecv
>
> I think you can complete the rest of the table in your head.
>
> The defense for this somewhat arcane mechanism is that it creates SDP
> that interoperates with endpoints that expect one outgoing and one
> incoming video track, both described by the same M-line.
>
>
>
> >
> >> I know that this oversimplifies the process and that constraints could
> >> be used to provide indications back to RTCPeerConnection about what
> >> constraints to apply to its negotiation functions, but I think that
> >> the conclusion was that this was overcomplicating things.  And we know
> >> very well that it is already complicated beyond the comprehension of
> >> mere mortals anyway.
> >
> > Its currently beyond my comprehension. Take that for what its worth.
> >
> >     Thanks,
> >     Paul
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
>
>
> --
> Surveillance is pervasive. Go Dark.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>