Re: [rtcweb] Should we reference the pause/resume I-D?

Justin Uberti <juberti@google.com> Fri, 14 March 2014 16:15 UTC

Return-Path: <juberti@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5FB1A0180 for <rtcweb@ietfa.amsl.com>; Fri, 14 Mar 2014 09:15:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.025
X-Spam-Level:
X-Spam-Status: No, score=-1.025 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, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547, 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 dcCBRE92n3Jt for <rtcweb@ietfa.amsl.com>; Fri, 14 Mar 2014 09:15:49 -0700 (PDT)
Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 20EDB1A017B for <rtcweb@ietf.org>; Fri, 14 Mar 2014 09:15:48 -0700 (PDT)
Received: by mail-vc0-f182.google.com with SMTP id ks9so3043514vcb.27 for <rtcweb@ietf.org>; Fri, 14 Mar 2014 09:15:41 -0700 (PDT)
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=DjFHQZfKSzsrCyr3NZxNOCWXcuWmOObUbvO/TSSYEN0=; b=P5hrJ/BZLvqlbGmMBb/Hp5reCyoFaHKS87EqjA4UgWQL2sgfAI3Wq56fqGN90Szphp i40WYT09UUoCE9GYcgANVVpfOp0mfXLAox+NJgbqPVr3x4UGophU7GBZTvNgQXaFi6rj kHH4h1dV5l5InXdH36IwFAmaN13HtL7JLF/Il+Rxb25DR5CKtMtb+R2F0eAJzAYdK/VG VzVrtzN/0GeDJJbHgeZWOc2waJ6Q7zG3Rcb4T/y7Y7L2lJWfJAnKT5EqsRnbSk0Z7atF sDkD4jcd02b3mguej7xHtgL6EZ0Q7GDLzJOlSFDhTi7QqJHm2xDDqJHva2UwjQarlS12 tiPQ==
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=DjFHQZfKSzsrCyr3NZxNOCWXcuWmOObUbvO/TSSYEN0=; b=mZvuPdkUOCObqDI55E6IeXW6ygyE0zIhu2BnwuTNNnQMPl0PYYlXaoXEK170WiyxPU nBMrsq/B1BXSMeLTJ8U93Pr+5foQkuq5baSniK5yp/nE9tKjLYYhpSW0U2xZD36FtOmX lL/pCqphHitc6n/TkbDgoyVMqVU2QnELqF0JNNwqcghGmFCVfp/48EALbrXQvJ6Gdkno VKGFouezosoNvFNaMIqykgmQQm6u4A/6Vj6j+hSbgk8EbInhbVCh+AcMumtwvEJnnxs2 xqW8YAddQlOVrVol5AW7zMBV31W236Iwp6pK7C5b082g9Clf3KMaJKvA0TtKVfABoVs+ 1k6Q==
X-Gm-Message-State: ALoCoQlkZO70dTjCF8AKvQfR0QZuJqlS5G7Up3VELjxVouH9iJJipTZFzjqzQE71jSep4YGmOTnrEN6qkrh3LIH6+D6Tp9Bi9gGQDYUUNVEhSNIgJe9HtFFO+dgMNiG3go7NTao+Dffdnb5ZDtLmfrEEFZFkDssSbvwlPm6Zf9FHedb8B8mIz/OdoebD7FxMNDo0d8oqS8WH
X-Received: by 10.58.96.36 with SMTP id dp4mr5245799veb.21.1394813740959; Fri, 14 Mar 2014 09:15:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.26.43 with HTTP; Fri, 14 Mar 2014 09:15:20 -0700 (PDT)
In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1CF8C0FD@ESESSMB209.ericsson.se>
References: <1447FA0C20ED5147A1AA0EF02890A64B1CF8B463@ESESSMB209.ericsson.se> <CAOW+2dsb1GqQmOxf7V6C1Xd_LG12d+kanSm80=kSwmQY=B7GSg@mail.gmail.com> <CAOJ7v-3S1axGPVWB8TF_ALwZ6ExF-D7m3MGsfrkx6EsQNWNpxQ@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1CF8C0FD@ESESSMB209.ericsson.se>
From: Justin Uberti <juberti@google.com>
Date: Fri, 14 Mar 2014 09:15:20 -0700
Message-ID: <CAOJ7v-34c7B2BzyCr4gGLKj=JCUN2rXo6HoFC7+G1TmzvxKOrA@mail.gmail.com>
To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= <stefan.lk.hakansson@ericsson.com>
Content-Type: multipart/alternative; boundary=089e013a26e68ee4bb04f493615f
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/N7gFju9GeaN0RGZw00LXuGnyMrU
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Should we reference the pause/resume I-D?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 14 Mar 2014 16:15:52 -0000

On Fri, Mar 14, 2014 at 4:25 AM, Stefan Håkansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> On 2014-03-12 21:56, Justin Uberti wrote:
> > Agreed.
>
> I may well be that the pause/resume doc will not be ready in time, so it
> from that aspect is a bad idea. What about just stating that TMMBN/TMMBR
> 0 meaning pause should be supported?
>

It's not clear to me what the interactions are between the signaling and
media plane when this occurs. That is, if I do doohickey.active = false,
should that cause a=recvonly signaling and a TMMBN notification that the
track is paused? I am concerned that things can get out of sync (i.e. what
happens if we get TMMBR indicating resume, but signaling is still
a=recvonly)?


> > Aren't there also patent declarations against this doc from
> > multiple holders?
>
> I've not looked into that, but I deliberately chose to propose the "old"
> TMMBN 0 way to signal that is mentioned in [1] (and not any of the "new"
> signaling in [1]).
>

OK.


>
> >
> > While SDP will likely be removed from the API in the future, the
> > replacement would be a app-specific message sent over websockets, which
> > seems like it would work just fine.
>
> s/would/could/: I don't think this has been discussed or agreed (and
> websocket is of course just an example).
>

Right, the whole thing is an example, but the point is that the new API
directions don't really affect this particular problem.

>
> I think it is worthwhile to push this kind of signaling into the media
> plane if possible. For example, this would enable the UA to save
> transmission/battery even if the app is badly written.
>
> As an example: if a MST sent over a PC is not used in any way at the
> receiving end, the receiving end UA could signal TMMBR 0 to tell the
> sending UA to not send. Sure, the receiving UA could also fire a
> "negotiationneeded" event, but maybe the app doesn't listen.
>

True, if the app doesn't perform the necessary signaling, things are not
going to work, but that applies to a lot of operations on the
PeerConnection.

Overall this feels to me like something that needs some thought to figure
out all the interactions between the API, the signaling plane, and the
media plane. As such I am inclined to leave this out of 1.0.

>
> >
> >
> > On Wed, Mar 12, 2014 at 12:50 PM, Bernard Aboba <bernard.aboba@gmail.com
> > <mailto:bernard.aboba@gmail.com>> wrote:
> >
> >     While I do like the pause/resume draft, having core RTCWEB WG
> >     documents (such as RTP Usage) depend on it seems like a bit of a
> >     stretch. After all, the document was only adopted last week, and it
> >     is a rare IETF WG document that can go from a -00 WG draft to
> >     publication as an RFC in under a year.
> >
> >
> >     On Wed, Mar 12, 2014 at 11:01 AM, Stefan Håkansson LK
> >     <stefan.lk.hakansson@ericsson.com
> >     <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
> >
> >         Hi,
> >
> >         at the IETF last week there was consensus in the AVTEXT WG
> >         meeting to
> >         adopt the pause/resume draft [1] as a WG draft.
> >
> >         In rtcweb/webrtc we're have the situation that we're discussing
> so
> >         called "doo-hickeys" as an API surface where the web app
> >         (amongst other
> >         things) can pause and resume the sending of a track. This can
> >         be signaled with the direction attribute and a SDP O/A exchange
> >         (and the
> >         app pausing/resuming sending of a track would presumably lead to
> a
> >         "negotiationneeded" event being fired).
> >
> >         But I think we should in addition require the browser to signal
> it
> >         according to one of the methods in [1] (e.g. TMMBN = 0), and also
> >         understand that signaling (a browser receiving TMMBN = 0 must
> >         know that
> >         the other end-point will pause sending).
> >
> >         My argument is that we know that many dislike SDP in rtcweb, and
> a
> >         likely development is that it will be removed in a later
> version. My
> >         speculation is that signaling as outlined in [1] will then be
> >         used for
> >         pause/resume. If we support this from the beginning earlier
> >         implementations could more easily interop with those later
> versions.
> >
> >
> >         Stefan
> >
> >         [1]
> >
> https://tools.ietf.org/id/draft-westerlund-avtext-rtp-stream-pause-05.txt
> >
> >         _______________________________________________
> >         rtcweb mailing list
> >         rtcweb@ietf.org <mailto:rtcweb@ietf.org>
> >         https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> >
> >     _______________________________________________
> >     rtcweb mailing list
> >     rtcweb@ietf.org <mailto:rtcweb@ietf.org>
> >     https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
>
>