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

Roni Even <> Mon, 24 April 2017 09:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9954112EBD6 for <>; Mon, 24 Apr 2017 02:59:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yvz3BhTZBmo5 for <>; Mon, 24 Apr 2017 02:59:26 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5589212EBD5 for <>; Mon, 24 Apr 2017 02:59:25 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id DLQ41342; Mon, 24 Apr 2017 09:59:22 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 24 Apr 2017 10:59:20 +0100
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 24 Apr 2017 17:59:17 +0800
Received: from ([]) by ([]) with mapi id 14.03.0301.000; Mon, 24 Apr 2017 17:59:12 +0800
From: Roni Even <>
To: Sergio Garcia Murillo <>, Justin Uberti <>
CC: "" <>
Thread-Topic: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04
Thread-Index: AQHSvNp9xHz/lD+lLkegGJi1ZqMIFaHUP/sg
Date: Mon, 24 Apr 2017 09:59:12 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD7B090BDGGEMM506MBXchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58FDCC7B.00FE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 8da53849370d46293d3e029fb3a463a4
Archived-At: <>
Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Apr 2017 09:59:30 -0000

Hi Sergio,
I understand your distinction between FEC (ulpfec) and  RED with regards to the RTP header. Still, the RTP header extensions have their own redundancy recommendations so they less less problem for packet loss.
Maybe it will be good in section 3 to add a section that mention that FEC will protect the whole RTP packet while RED and in-band fec will only protect the RTP payload.


From: Sergio Garcia Murillo []
Sent: יום ב 24 אפריל 2017 12:09
To: Roni Even; Justin Uberti
Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04

AFAIK, FEC (at least ulpfec) protects the full packet, including header extensions. When we are addressing the usage of RED vs FEC for audio we should note the difference in behavior  and it's possible consequences.

Best regards

On 24/04/2017 11:04, Roni Even wrote:
Hi Sergio,
What I said that the redundancy of RTP header extensions in not a FEC issue. FEC addresses the payload and not the RTP header.  RTP header extensions are discussed in the RFC5285-bis draft and each new RTP header extension must address the issue of loss since RTP over UDP is unreliable.
I am not sure we need any text in rtcweb-fec about RTP header extensions.  General RTP usage in RTCweb is in the RTCweb RTP usage and this is where general redundancy of RTP is discussed, and as a general RTP usage it points at redundancy for payload and for RTP header extensions reference RFC5285 (rfc5285-bis will obsolete it and have a section about transmission consideration.

In this rtcweb-fec document audio/red is a payload; it is not an RTP packet for which you need to address the RTP header redundancy.

Roni Even

From: Sergio Garcia Murillo []
Sent: יום ב 24 אפריל 2017 11:28
To: Roni Even; Justin Uberti
Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04

Hi Roni,

Not following you. Neither RFC 5265 nor RFC 5265-bis references red/audio, also webrtc-rtp-usage references the fec draft when speaking about redundancy.

Also, please note that I am not proposing to change current RED behavior or its usage within webrtc, just proposing to add a "warning" note to make it implicit what is the current situation: When using rtp red for audio, only payload is protected, and rtp headers are not, which is almost harmless currently but could cause some issues in the future if not taken into consideration when using new rtp header extensions.

Best regards

On 24/04/2017 7:43, Roni Even wrote:
Hi Justin,
I am not sure that this is something to discuss here, RTP header extensions are discussed in , which points to RFC5285 soon to be replaced  by the rfc5285-bis draft.
The bis draft has a section about transmission considerations see 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”


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

On Sat, Apr 22, 2017 at 10:32 PM, Roni Even <<>> wrote:
Roni Even

> -----Original Message-----
> From: rtcweb [<>] On Behalf Of Sergio Garcia
> Murillo
> Sent: יום ו 21 אפריל 2017 12:30
> To:<>; 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