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

From: "Timothy B. Terriberry" <[email-masked]>
Date: Tue, 05 Apr 2016 13:25:49 -0700

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.