Re: [rtcweb] #27: Section 6.2 FEC

Colin Perkins <> Mon, 26 August 2013 15:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6738411E81C7 for <>; Mon, 26 Aug 2013 08:51:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nfGGCd+7OLEJ for <>; Mon, 26 Aug 2013 08:51:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F3B9C11E81B9 for <>; Mon, 26 Aug 2013 08:51:19 -0700 (PDT)
Received: from [] (port=54941 by with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <>) id 1VDz4M-0004gA-7m; Mon, 26 Aug 2013 16:51:08 +0100
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Colin Perkins <>
In-Reply-To: <>
Date: Mon, 26 Aug 2013 16:51:07 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: rtcweb issue tracker <>
X-Mailer: Apple Mail (2.1508)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Subject: Re: [rtcweb] #27: Section 6.2 FEC
X-Mailman-Version: 2.1.12
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, 26 Aug 2013 15:51:29 -0000

On 26 Aug 2013, at 08:18, rtcweb issue tracker <> wrote:
> #27: Section 6.2 FEC
> Comment (by
> [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