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

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 [mailto:sergio.garcia.murillo@gmail.com]
Sent: יום ב 24 אפריל 2017 11:28
To: Roni Even; Justin Uberti
Cc: rtcweb@ietf.org
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
Sergio

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