IETF Logo Mail Archive

Re: [rtcweb] Support for RFC7728 pause indication

Harald Alvestrand <harald@alvestrand.no> Sat, 11 November 2017 23:05 UTC

Return-Path: <harald@alvestrand.no>
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 53EFD128B8D for <rtcweb@ietfa.amsl.com>; Sat, 11 Nov 2017 15:05:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 lvi4dJVsuLv7 for <rtcweb@ietfa.amsl.com>; Sat, 11 Nov 2017 15:05:31 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A46C7128B4E for <rtcweb@ietf.org>; Sat, 11 Nov 2017 15:05:30 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 1BE817C3553; Sun, 12 Nov 2017 00:05:29 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q39ASko_zVTM; Sun, 12 Nov 2017 00:05:27 +0100 (CET)
Received: from [31.133.153.86] (dhcp-9956.meeting.ietf.org [31.133.153.86]) by mork.alvestrand.no (Postfix) with ESMTPSA id 5B2E57C0938; Sun, 12 Nov 2017 00:05:26 +0100 (CET)
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Cc: rtcweb@ietf.org
References: <91ddc524-6ef9-c3e1-7db5-eb4c4080bc91@gmail.com> <3BFD6388-4A07-4D9C-8F1A-CFBAF0EDB830@iii.ca> <CAOW+2du_sNhm4SKFAjpbOgi7HSsY-RgDK+rgCubLX_5u=N2ELA@mail.gmail.com> <266e6bdb-20b5-9d98-498e-7ddc2c2379a7@gmail.com> <CALiegfnFj5Jy1UGNvpXswfPiB6BEZqjmtTBGXL6PTw3pL86erQ@mail.gmail.com> <f3a0855b-7853-353d-a32a-ba5483cb293c@gmail.com> <CALiegfmrr0T9KtYq7QhOTdSNx0j1MzWoT=D5nqoE+B1GZZ5G2w@mail.gmail.com> <56b03aad-9d87-4465-0b96-1b9854d07c2a@gmail.com> <CALiegfnG-KTPxdSpFShskCgaamVaGBHMY4bpnCMYm7qg0=-GMw@mail.gmail.com> <CALiegfkFnpOQU+LizdCoDRJiZGtLTewEFeeYLWEvr4F0WctC0g@mail.gmail.com> <1f78b285-a9f3-6135-5e07-b9f72ac24546@gmail.com> <CALiegfm-HHWsUOeh7OPFNHq9=JFZjrOZ34__Sbu8sZ8+uvCxuw@mail.gmail.com> <f9d77638-24ad-930d-f446-f95700052c6d@gmail.com> <CALiegfkKQb92Hy+LoH7UyNePBqeX-edGWFmgL5eGcjvZbtH2bg@mail.gmail.com> <9b49201a-ac3c-0350-ff9d-abe29dee1bd5@alvestrand.no> <CA+ag07Y_vtVpLt+U=oKXZKcfioKUs_gy2hE0y5sohnN9ieWzDg@mail.gmail.com>
From: Harald Alvestrand <harald@alvestrand.no>
Message-ID: <ebe56120-3ed7-7e60-7c49-7a335fef2b71@alvestrand.no>
Date: Sun, 12 Nov 2017 00:05:08 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CA+ag07Y_vtVpLt+U=oKXZKcfioKUs_gy2hE0y5sohnN9ieWzDg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------73DE1A996A395330FA35B04C"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/96pEy7lgjSj-mF69ZEcfp6zznK8>
Subject: Re: [rtcweb] Support for RFC7728 pause indication
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 11 Nov 2017 23:05:33 -0000

On 11/11/2017 10:29 AM, Sergio Garcia Murillo wrote:
> Sure thing!
>
> But would prefer it to be in the standard, even just as a SHOULD/COULD
> than only libwebrtc implementation specific.

Sorry, I was confused - it's TMMBN that's in the spec (-rtp-usage),
PAUSED is not.

(PAUSE has two RAND IPR declarations against it, which led to some
reluctance to mention it in the past)


>
> Best regards
> Sergio
>
> El 11/11/2017 10:00, "Harald Alvestrand" <harald@alvestrand.no
> <mailto:harald@alvestrand.no>> escribió:
>
>     On 10/31/2017 12:27 PM, Iñaki Baz Castillo wrote:
>     >> Nice. However, the last RTP packet sent before PAUSED may
>     arrive after
>     >> the PAUSED itself. Not sure how to handle that in the receiver
>     side...
>     >>
>     >>    When entering the state, the RTP stream sender SHALL send a
>     PAUSED
>     >>    indication to all known RTP stream receivers, and SHALL also
>     repeat
>     >>    PAUSED in the next two regular RTCP reports, as long as it
>     is then
>     >>    still in paused state.
>     > Should be enough to mitigate the issue.
>     >
>     >
>     >> RFC 7728 allows partial implementation, with fine grained
>     control about
>     >> sending/receiving PAUSED indication:
>     >>
>     >>       "config" allows for partial implementation of this
>     specification
>     >>       according to the different roles in the use-cases section:
>     >>
>     >>       6  The implementation supports sent and received RTP
>     streams being
>     >>          paused due to local considerations and thus supports
>     sending
>     >>          and receiving PAUSED indications.
>     >>
>     >>       7  The implementation supports and desires to receive PAUSED
>     >>          indications for received RTP streams but does not
>     pause or send
>     >>          PAUSED indications for sent RTP streams.  It does not
>     support
>     >>          any other messages defined in this specification.
>     >>
>     >>       8  The implementation supports pausing sent RTP streams and
>     >>          sending PAUSED indications for them but does not support
>     >>          receiving PAUSED indications for received RTP
>     streams.  It does
>     >>          not support any other messages defined in this
>     specification.
>     > Cool. Let's see how things go. BTW, TMMBR and TMMBN (2008 spec) also
>     > seem easy to implement but, despite being mandatory, better
>     don't send
>     > a TMMBR to Chrome in 2017.
>
>     Patches welcome.
>
>     >
>
>     --
>     Surveillance is pervasive. Go Dark.
>
>     _______________________________________________
>     rtcweb mailing list
>     rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>     <https://www.ietf.org/mailman/listinfo/rtcweb>
>

-- 
Surveillance is pervasive. Go Dark.

v2.23.0 | Report a Bug | By Email