Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks in JSEP
Justin Uberti <juberti@google.com> Mon, 03 February 2014 20:28 UTC
Return-Path: <juberti@google.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F7D1A0162 for <mmusic@ietfa.amsl.com>; Mon, 3 Feb 2014 12:28:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.313
X-Spam-Level:
X-Spam-Status: No, score=-1.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jx_L3_mMYvcp for <mmusic@ietfa.amsl.com>; Mon, 3 Feb 2014 12:28:24 -0800 (PST)
Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 38B161A015A for <mmusic@ietf.org>; Mon, 3 Feb 2014 12:28:24 -0800 (PST)
Received: by mail-ve0-f173.google.com with SMTP id oz11so5220845veb.4 for <mmusic@ietf.org>; Mon, 03 Feb 2014 12:28:23 -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=gY7dhRCqeeuxmz32DkOn8pNKGysfddcfXlHgGFzi198=; b=CaiMYuA8Xrn1iSiyUVZkqL4XTOh37QKSJmn/qoKO21gB3SYle+Vi7I/G5AqKX1drrZ +Q7fqu+5JQi1HzwaNVvFsScA4O03IlaZgqFkXfDD1kQX293d7zIBNhlHGyhQ9Gqd8QzE MZeqZE9ESqsYPAf3XRAVf97Zf1+0AxfPtwgkDJCG/UNlRptPsjbTgDZLkdu+1PJxUInW KcpcgsBoPtflD3AbqpT2Gu8zZm5bZWN4RyFJebTa3FJJ1N6oBmAzXAvXNvfdRDgwKFmd 2X2GyqerbTkp8v4ClIPzG3YPm2jwQyzlM4Jtt+GH84d1ulScAT8c8wCjNo51HorIfpok vj4Q==
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=gY7dhRCqeeuxmz32DkOn8pNKGysfddcfXlHgGFzi198=; b=NwBjiyVJZv/TGwCBgZS2fmVhFQ1zOtdTAVJmZvAqt8NSwqFusT+/gPSIiAKHLlmm7a pn2tJXk5bQWz4XshScEs5JIFmhcFDUnC3zu55bCnI8Air0Ugr3sFmWlIzv6AMCXiEvsX gMmJoAkmGyiYMH96wiLVXgPkKN09M2kSpKzmeZJp8GTUzy1zyNmgQjjOtTlHTYksIq5n NqnAfPTHJoHBnE5XJzE0w7RwsT4x2jrNgx4/fgOEwuxikC/QT5TJr4b5cwusUpdq+gxu Wgzsj2e/151NsYZ8tMHaNx+hcq8YtC/eVgcHpIqM3K2G9nvv3HoySYsnmr8T3kIyWgd3 GmBg==
X-Gm-Message-State: ALoCoQlVjDJ3dPOsVKodVBwFzjbGyaXd1bUUPdweGqPVGL3TvNuZeU9E40YiBkFobnMGm05zJVov0MvMwwkhDh8+kLPVZdH99O9WDsiN7FP3z/4RPx60UF4hqheVa8cD8zAr7hbBYItX7mB9vSvBRxm0K/AcvcAc/4apwkJtqQQ2QmStAm8oJZRblGRyrKcuNop17vCEwDNA
X-Received: by 10.220.48.194 with SMTP id s2mr87223vcf.43.1391459303878; Mon, 03 Feb 2014 12:28:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.89.170 with HTTP; Mon, 3 Feb 2014 12:28:03 -0800 (PST)
In-Reply-To: <CAOJ7v-2adSjCiwEp=QRcY+=cYKiiubyjz=rjeMHH4qC56BP1Vg@mail.gmail.com>
References: <CAOJ7v-22T7hLMdC2je0nLk34MXQ8L+JFWLtAz--6Ryt+DMaMvQ@mail.gmail.com> <52EFF9E0.40808@nostrum.com> <CAOJ7v-2adSjCiwEp=QRcY+=cYKiiubyjz=rjeMHH4qC56BP1Vg@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Mon, 03 Feb 2014 12:28:03 -0800
Message-ID: <CAOJ7v-1nk=TNhsEPE3cy8MbT-SiOUg+29tHeBkUz4qXyLo6a+A@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c1e7fc8718b604f1865d89"
Cc: Cullen Jennings <fluffy@cisco.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks in JSEP
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Feb 2014 20:28:26 -0000
+mmusic (meant to include the first time around) On Mon, Feb 3, 2014 at 12:25 PM, Justin Uberti <juberti@google.com> wrote: > > > > On Mon, Feb 3, 2014 at 12:19 PM, Adam Roach <adam@nostrum.com> wrote: > >> On 2/3/14 13:27, Justin Uberti wrote: >> >> Therefore, I think we need some similar way for a receiver to do the same >> for a remote track. >> >> >> Yes. >> >> >> And fortunately, I think we have a surface that can be used for this, >> namely the "recv-appId" attribute that has been discussed in the context of >> unified-plan and explained in >> http://tools.ietf.org/id/draft-even-mmusic-application-token-02.txt and >> unified-plan. If an endpoint doesn't want to receive a particular track on >> a m= line, it sets the m= line to a=sendonly and also removes any >> a=recv-appId. >> >> >> No. >> >> The problem is that you're defining semantics to a behavior that is >> indistinguishable from the behavior exhibited by something that does not >> support app-id: if the thing on the other end isn't using app-id, then an >> attempt to put a stream on hold will be misinterpreted as an attempt to >> reject or remove it. >> > > See my response to Martin. Putting a stream on hold will never result in > that being misinterpreted as a reject; on the contrary, without appid, > there is no way to 'fully' reject half of a stream, and, as a problem > confined to pre-unified-plan devices, I think that is probably OK. > >> >> I agree that we want an SDP operation that differentiates between "don't >> send me this now" and "don't send me this ever" [1] -- but it needs to be >> explicit. Something more like "a=i-am-rejecting-this-stream", but with a >> less cumbersome name. >> >> It's not clear to me that adding a new attribute would solve any problem > that appid doesn't solve; you still need to deal with the "other end not > using it" issue. > > >> ____ >> [1] Along with a Javascript control that allows us to do the same thing, >> but that's a W3C issue. >> > > Agree. But while we're on the subject, I am thinking that MST.stop() == > "not ever", and RtpReceiver.active = false causes "not now". > >
- Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks… Justin Uberti
- Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks… Justin Uberti
- Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks… Adam Roach
- Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks… Justin Uberti
- Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks… Adam Roach
- Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks… Jonathan Lennox
- Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks… Justin Uberti
- Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks… Justin Uberti
- Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks… Cullen Jennings (fluffy)
- Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks… Jonathan Lennox
- Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks… Justin Uberti
- Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks… Christer Holmberg
- Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks… Jonathan Lennox
- Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks… Jonathan Lennox
- Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks… Magnus Westerlund
- Re: [MMUSIC] [rtcweb] Rejecting MediaStreamTracks… Harald Alvestrand