Re: [rtcweb] #27: Section 6.2 FEC

[Colin Perkins <[e-mail]>]

On 26 Aug 2013, at 08:18, rtcweb issue tracker <[e-mail]> wrote:
> #27: Section 6.2 FEC
> 
> 
> Comment (by [e-mail])
> 
> [Magnus Westerlund]
> 
> Bernard, this is the WG consensus that we so far have arrived on. If you have a proposal regarding FEC, please make it and lets see if we can reach consensus on such a proposal.
> 
> However, I fail to see how this is generally problematic. Retransmission will cover certain parts of the deployment cases when the transport RTT and delay does not prevent it from being able to repair in a timely fashion. FEC clearly covers transport characteristics where retransmission will show its shortcomings. If one want improved transport performance in those cases clearly a common implemented FEC solution is desired.
> 
> [BA] FEC is discussed in Sections 1.1.7 and 3.3 of draft-roach-mmusic- unified-plan, with examples how it might be declared using SDP, so I found it a bit odd that draft-ietf-rtcweb-rtp-usage only had recommendations for RTX, not FEC.  For example, Section 1.1.7 says:
> 
>    For robust applications, techniques like RTX and FEC are used to
>    protect media, and simulcast/layered coding can be used to provide
>    support to heterogeneous receivers.  It needs to be possible to
>    support these techniques, allow the recipient to optionally use or
>    not use them on a source-by-source basis; and for simulcast/layered
>    scenarios, to control which simulcast streams or layers are received.

I don't see anything in this section that conflicts with rtp-usage draft.

> Here is what Section 3.3 says:
> 
> 3.3.  Handling of Simulcast, Forward Error Correction, and
>       Retransmission Streams

...

Again, that all seems reasonable, but doesn't address the issue of what type of FEC to use. Like Magnus, I don't see working group consensus to recommend a particular FEC scheme. If you believe there is consensus on using a particular FEC scheme, make a proposal, and we'll incorporate it if accepted. 

-- 
Colin Perkins
http://csperkins.org/