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

Bernard Aboba <bernard.aboba@gmail.com> Fri, 14 March 2014 17:57 UTC

Return-Path: <bernard.aboba@gmail.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 815081A019E for <rtcweb@ietfa.amsl.com>; Fri, 14 Mar 2014 10:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, 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 yksmBePxAp7x for <rtcweb@ietfa.amsl.com>; Fri, 14 Mar 2014 10:57:07 -0700 (PDT)
Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id ADAC11A017C for <rtcweb@ietf.org>; Fri, 14 Mar 2014 10:57:06 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id t61so2459773wes.17 for <rtcweb@ietf.org>; Fri, 14 Mar 2014 10:56:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=n8EelCPfFA+A+q4zQ4oMRP+mhaiaTJIoqbRQbXkFKCE=; b=qEAssVLbYLNWg1tcVy3ohZV625AlcjJgVv7nAO75KAmGVdOM23KUljvhubT46jofF1 8WPhgptXoNTCkMKrA1MHjb6khKnIMbD++ZsNvDEzKmdt/0NPl6dogmhDBDbdYEYc8Gzd hJC8uBkz06JuPfC0fw/7jIELzwSirMG6yyYlhpt5vCB04wzXZLDrOJGXaQ2aEb1KNo0B OglG5UX3tQ0ZN+nhaqKzyom2Qsh60EqiEOnXyECrObmw+S4aUXm2DcMg0p/j9kMLrq59 XuX2Ry/k3ugD1cEThCqDYPepI9nWEhR2iDZoERINJP7yIjicA0yLT+sCgFVK7XWKOBbs i82w==
X-Received: by 10.194.63.145 with SMTP id g17mr2934522wjs.72.1394819819170; Fri, 14 Mar 2014 10:56:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.217.161.66 with HTTP; Fri, 14 Mar 2014 10:56:39 -0700 (PDT)
In-Reply-To: <CAOJ7v-34c7B2BzyCr4gGLKj=JCUN2rXo6HoFC7+G1TmzvxKOrA@mail.gmail.com>
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> <CAOJ7v-34c7B2BzyCr4gGLKj=JCUN2rXo6HoFC7+G1TmzvxKOrA@mail.gmail.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Fri, 14 Mar 2014 10:56:39 -0700
Message-ID: <CAOW+2dsukDeZykNjdLW-VzvxE65TFz6YiFr=E-ZJyrhpD5Rj9Q@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
Content-Type: multipart/alternative; boundary=047d7bacb502d8f03404f494cb47
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/LuHg5dWQ-ZMvSx4qd-LwaoyL4io
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 17:57:10 -0000

Justin said:

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

[BA] I agree.


"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)?"

[BA] A few thoughts:

a. Even though TMMBR/TMMBN is mandatory-to-implement in the RTP usage
document, I don't think we can assume that the pause/resume will be
supported by all mixers.. It therefore probably isn't a good idea for a
browser to automatically send a TMMBN 0 indication when setting
rtpsender.active = false.  Since the application might or might not use SDP
for signaling, this is probably something that needs to be under
application control.  BTW, Section 6.3, isn't clear about the response to
an unsolicited TMMBN (TMMBR 0?).

b. As described in Section 1, pause/resume is for use in scenarios where
signaling might not meet the performance requirements.  Due to the
differing transport characteristics of RTCP and signaling over reliable
transport, trying to use both pause/resume and signaling is quite likely to
result in them being out of sync, so my assumption was that an application
wishing to support pause/resume would not choose to use signaling for the
same purpose.   There is also the potential for conflict between
codec-specific messages (e.g. layer drop in H.264/SVC) and some potential
uses of pause/resume (e.g. unsolicited TMMBN to indicate layer pause in
multi-stream SVC).  Where there are conflicts, my assumption would be that
signaling and codec-specific messages should win.


On Fri, Mar 14, 2014 at 9:15 AM, Justin Uberti <juberti@google.com> wrote:

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