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

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Fri, 14 March 2014 11:26 UTC

Return-Path: <stefan.lk.hakansson@ericsson.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 21E681A011B for <rtcweb@ietfa.amsl.com>; Fri, 14 Mar 2014 04:26:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level:
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 qfs17oJBJ-S3 for <rtcweb@ietfa.amsl.com>; Fri, 14 Mar 2014 04:26:00 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0245F1A0108 for <rtcweb@ietf.org>; Fri, 14 Mar 2014 04:25:59 -0700 (PDT)
X-AuditID: c1b4fb38-b7f418e000001099-e5-5322e7405be8
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 4D.B3.04249.047E2235; Fri, 14 Mar 2014 12:25:52 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0387.000; Fri, 14 Mar 2014 12:25:52 +0100
From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= <stefan.lk.hakansson@ericsson.com>
To: Justin Uberti <juberti@google.com>, Bernard Aboba <bernard.aboba@gmail.com>
Thread-Topic: [rtcweb] Should we reference the pause/resume I-D?
Thread-Index: Ac8+HSfEqf9sT+k2TCiwilJvB9C34g==
Date: Fri, 14 Mar 2014 11:25:51 +0000
Message-ID: <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>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.146]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvja7Dc6Vgg/Z9qhYb9v1nttg6Vchi 7b92dgdmj52z7rJ7LNhU6rFkyU+mAOYoLpuU1JzMstQifbsEroym6y3sBb8VKqbvrGhgbJTs YuTkkBAwkTh9egYrhC0mceHeerYuRi4OIYEjjBLHr+5mhnCWMEqcuLiIGaSKTSBQYuu+BWwg tgiQfb11PwuIzSygLnFn8Tl2EFtYwF7iV/sddogaB4ldHU+g6vUkTt64zdjFyMHBIqAqsftJ IUiYV8BX4ld3F9Ti24wSfW8/g+1iBLro+6k1TBDzxSVuPZnPBHGpgMSSPeeZIWxRiZeP/0F9 oCTxY8MlqHv0JG5MncIGYWtLLFv4mhlimaDEyZlPWCYwis5CMnYWkpZZSFpmIWlZwMiyipGj OLU4KTfdyGATIzA6Dm75bbGD8fJfm0OM0hwsSuK8H986BwkJpCeWpGanphakFsUXleakFh9i ZOLglGpgZLv8X0rnYXjzYiGR+iUHvu/S4zjkmuRhdoG7LkehXqliDt8b3t8ZLMdVjF7/D/4b nS2tfrDgSpjP5o/CDMLhO0Uq7h+urrlxZ3tFs43LAk7dd/cnPO5KFTGrPT3nzoSa+lu7nkxV uhx9fYb3k4WdBkp/+IyjXhudnb3d4IHr1VerJvd8dl3np8RSnJFoqMVcVJwIAMmFKOhcAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/W28MobNZgRTNRrV6h6Ad-rNURYQ
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 11:26:02 -0000

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?

> 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]).

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

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.

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