[rtcweb] Comments on draft-ietf-rtcweb-fec-03

"Timothy B. Terriberry" <tterriberry@mozilla.com> Tue, 05 April 2016 20:25 UTC

Return-Path: <tterriberry@mozilla.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 921A012D12C for <rtcweb@ietfa.amsl.com>; Tue, 5 Apr 2016 13:25:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blEfa0t5gmry for <rtcweb@ietfa.amsl.com>; Tue, 5 Apr 2016 13:25:53 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 108FD12D15D for <rtcweb@ietf.org>; Tue, 5 Apr 2016 13:25:52 -0700 (PDT)
Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 66B6AC17EF for <rtcweb@ietf.org>; Tue, 5 Apr 2016 20:25:52 +0000 (UTC)
X-Virus-Scanned: amavisd-new at mozilla.org
Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GSM2I0yVRUi for <rtcweb@ietf.org>; Tue, 5 Apr 2016 20:25:51 +0000 (UTC)
Received: from [31.133.178.193] (dhcp-b2c1.meeting.ietf.org [31.133.178.193]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 85F4CC0248 for <rtcweb@ietf.org>; Tue, 5 Apr 2016 20:25:51 +0000 (UTC)
Message-ID: <57041F4D.1090808@mozilla.com>
Date: Tue, 05 Apr 2016 13:25:49 -0700
From: "Timothy B. Terriberry" <tterriberry@mozilla.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/9PPq3HxjTB0un11dmcCE7KvtTCo>
Subject: [rtcweb] Comments on draft-ietf-rtcweb-fec-03
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 05 Apr 2016 20:25:55 -0000

Section 4.2:

Support for receiving packets with FEC in them is mandatory for Opus. 
The useinbandfec=1 parameter indicates that the receiver is actually 
prepared to *use* that data (and thus that the bandwidth overhead is not 
wasted).

The reference to the RTP draft should probably also be updated to point 
to the final RFC.

I'd propose the following text:

'For Opus, a receiver can indicate that it is prepared to use incoming 
FEC data with the "useinbandfec=1" parameter, as specified in [RFC7587], 
Section 6.1.'

Section 7:

I think it's a little unclear what MUST be supported here, particularly 
for in-band FEC. I believe both Opus and AMR require that all receivers 
can handle packets with in-band FEC. Are receivers that are WebRTC 
endpoints required to actually do something with the data they receive 
(and, e.g., to always set useinbandfec=1 for Opus)? Are senders required 
to include in-band FEC whenever the receiver asks for it (and network 
conditions/application requests support it, as indicated in Section 8)? 
I.e., is this mandatory to support (which in the case of the explicitly 
named codecs, is already mandatory), or mandatory to use? It might be 
good to clarify.

Whether or not these comments are addressed, I think this document is 
ready for WGLC.