Re: [rtcweb] #27: Section 6.2 FEC

Bernard Aboba <bernard_aboba@hotmail.com> Mon, 26 August 2013 18:14 UTC

Return-Path: <bernard_aboba@hotmail.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 C3ACE21F9950 for <rtcweb@ietfa.amsl.com>; Mon, 26 Aug 2013 11:14:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.568
X-Spam-Level:
X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id betRl+1xhPhZ for <rtcweb@ietfa.amsl.com>; Mon, 26 Aug 2013 11:14:08 -0700 (PDT)
Received: from blu0-omc2-s9.blu0.hotmail.com (blu0-omc2-s9.blu0.hotmail.com [65.55.111.84]) by ietfa.amsl.com (Postfix) with ESMTP id 6070A21F93F8 for <rtcweb@ietf.org>; Mon, 26 Aug 2013 11:14:01 -0700 (PDT)
Received: from BLU169-W91 ([65.55.111.71]) by blu0-omc2-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Aug 2013 11:13:57 -0700
X-TMN: [TUFPwux4n2n8siMzC7gBqdYPald0jWuI]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU169-W916B4ECB57EB451B8CC70393490@phx.gbl>
Content-Type: multipart/alternative; boundary="_84c3669a-4827-49bf-a683-07f786eefbcf_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Colin Perkins <csp@csperkins.org>
Date: Mon, 26 Aug 2013 11:13:56 -0700
Importance: Normal
In-Reply-To: <5A2C089B-BBFF-42D1-949A-AD2984EE3E90@csperkins.org>
References: <066.f62f1912f660dbc0c28343d2955a2ef5@trac.tools.ietf.org> <081.60ad42bfcba9b4972ad06bf3f62ca73e@trac.tools.ietf.org>, <5A2C089B-BBFF-42D1-949A-AD2984EE3E90@csperkins.org>
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Aug 2013 18:13:57.0176 (UTC) FILETIME=[07E0FB80:01CEA288]
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] #27: Section 6.2 FEC
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 26 Aug 2013 18:14:13 -0000

Colin said: 
"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. "

[BA] I assumed (rightly? wrongly?) that the FEC section of the Unified Plan document was put there with the intent to enable FEC to be indicated in the (SDP-based) API. Assuming that was the intent, and that the capability is developed further,  it would be useful for the supported FEC schemes to be documented somewhere, so as to enable interoperability.  I'll leave it to those who worked on the document to clarify where the RTX/FEC section is headed.