IETF Logo Mail Archive

Re: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04

Roni Even <roni.even@huawei.com> Mon, 24 April 2017 05:43 UTC

Return-Path: <roni.even@huawei.com>
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 CB83412778E for <rtcweb@ietfa.amsl.com>; Sun, 23 Apr 2017 22:43:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 FFINB_Rba6Pi for <rtcweb@ietfa.amsl.com>; Sun, 23 Apr 2017 22:43:15 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9488D127337 for <rtcweb@ietf.org>; Sun, 23 Apr 2017 22:43:14 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLP38229; Mon, 24 Apr 2017 05:43:11 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 24 Apr 2017 06:43:10 +0100
Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by nkgeml411-hub.china.huawei.com (10.98.56.70) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 24 Apr 2017 13:43:07 +0800
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.133]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0301.000; Mon, 24 Apr 2017 13:43:05 +0800
From: Roni Even <roni.even@huawei.com>
To: Justin Uberti <juberti@google.com>
CC: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04
Thread-Index: AQHSvGI0XklmKzC3TEKAv5+LAJlrxaHT/ehw
Date: Mon, 24 Apr 2017 05:43:04 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD7B084E@DGGEMM506-MBX.china.huawei.com>
References: <1ddd77ef-da4a-1a89-e538-aa20742c11a4@gmail.com> <6E58094ECC8D8344914996DAD28F1CCD7B0714@DGGEMM506-MBX.china.huawei.com> <CAOJ7v-3yukU+SLcbAiR1TYqeu54nV+8V-h9hUgFc5JRMRzgx=w@mail.gmail.com>
In-Reply-To: <CAOJ7v-3yukU+SLcbAiR1TYqeu54nV+8V-h9hUgFc5JRMRzgx=w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.201.202]
Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD7B084EDGGEMM506MBXchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.58FD9070.0001, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.133, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 8da53849370d46293d3e029fb3a463a4
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/G0Q4svtMpLShNXXs1uuwcJbym2U>
Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04
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: Mon, 24 Apr 2017 05:43:18 -0000

Hi Justin,
I am not sure that this is something to discuss here, RTP header extensions are discussed in https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-26 , which points to RFC5285 soon to be replaced  by the rfc5285-bis draft.
The bis draft has a section about transmission considerations see https://tools.ietf.org/html/draft-ietf-avtcore-rfc5285-bis-09#section-4.1.1 discussing reliability of RTP header extension delivery by sending them in multiple RTP packets.

If you still want to say something you can probably add to section 1 “ Web Real-Time Communication (WebRTC) Media Transport and Use of RTP are discussed in https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-26”

Roni


From: Justin Uberti [mailto:juberti@google.com]
Sent: יום א 23 אפריל 2017 21:48
To: Roni Even
Cc: Sergio Garcia Murillo; rtcweb@ietf.org
Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04



On Sat, Apr 22, 2017 at 10:32 PM, Roni Even <roni.even@huawei.com<mailto:roni.even@huawei.com>> wrote:
Hi,
Inline
Roni Even

> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org<mailto:rtcweb-bounces@ietf.org>] On Behalf Of Sergio Garcia
> Murillo
> Sent: יום ו 21 אפריל 2017 12:30
> To: rtcweb@ietf.org<mailto:rtcweb@ietf.org>; Justin Uberti
> Subject: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04
>
> Hi all, Justin,
>
> I have been reviewing current FEC draft and I have a couple of comments:
>
> 1. Usage of RED and in band FEC and header extensions in Sections 3.2,
> 3.3 and 4
>
> I think it would be worth noting that neither red/audio nor in-band fec allows
> to recover RTP header extensions from previous packets. The impact of
> loosing the header extensions will be dependent of its meaning as, for
> example, this would cause minor problems to SFUs as client to mixer audio
> level info of previous packets will be lost, but could make it unusable for
> PERC (as it is currently defined) as it requires the OHB header extension.


[Roni Even] This is not a FEC problem but general RTP header extensions reliability discussed in RFC5285 and RC5285-bis draft and in the specific RTP header extension.

Roni, what would you suggest we say in this document?

>
> 2. Adaptive use of FEC for bandwidth probing (section 8)
>
> I think it would be a good addition to recommend FEC usage for bandwidth
> proving instead of other alternatives like RTX or padding only packets.
>
> Best regards
>
> Sergio
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org<mailto:rtcweb@ietf.org>
> https://www.ietf.org/mailman/listinfo/rtcweb

v2.23.0 | Report a Bug | By Email