Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-fec-02

From: Justin Uberti <[email-masked]>
Date: Sat, 09 Jan 2016 00:19:59 +0000

Finally got around to updating the document. Comments inline; new version
of the doc attached.

On Wed, Nov 4, 2015 at 11:15 PM Magnus Westerlund <
[email-masked]> wrote:

> Hi,
>
> A. Section 3.2:
>
> I think the draft should note that some RTP Payload format, including
> several of the one recommended in
> draft-ietf-rtcweb-audio-codecs-for-interop-02, do support internal
> redundancy. The codecs that I know for a fact can do this within the
> payload format are: AMR and AMR-WB.
>
> I would suggest adding some sentence on that time delayed redundancy may
> be supported by codecs, and give AMR and AMR-WB as examples.
>

I added a section on AMR/AMR-WB that parallels the Opus section.

>
> B. Section 4.
>
> I think this draft should consider the recommended drafts in
> draft-ietf-rtcweb-audio-codecs-for-interop-02. Here we clearly can
> consider internal redundancy for AMR and AMR-WB.
>

Done.

>
> C. Section 4.2
>
> There are a parameter in AMR and AMR-WB that can negotiate how much
> redundancy one may include: max-red
>

I mentioned this parameter in the doc. Do you want to recommend a default
value?

>
> D. Section 5.1:
>
>     The receiver can demultiplex the incoming FEC stream by
>     SSRC and correlate it with the primary stream via the ssrc-group
>     mechanism.
>
> Given that FlexFEC has built in indication of which SSRC that are
> included in protection, why include it in SDP? For the purpose to
> indicate selectively which streams that should have FEC protection?
>
> You also need a reference for "ssrc-group" if intended to be supported
> going forward?
>

Agree. Left as a TODO for now until I can sort out the details.

>
> E. Section 5.2, first paragraph:
>
> This section needs clearer references to SDP.
>

Not sure exactly what you had in mind here.

>
> F. Section 6.
>
>     WebRTC also supports the ability to send generic application data,
>     and provides transport-level retransmission mechanisms that the
>     application can use to ensure that its data is delivered reliably.
>
>
> This should informationally reference data channel.
>

Done.

>
> G. Section 6.
>
> I think this section should say even less. Just note that SCTP has
> reliable and semi-reliable modes and the application can control it.
> Nothing more.
>

I don't see a problem with mentioning the app can do its own FEC if it
wants. I did adjust the first para to mention the reliability modes more
explicitly.

>
> H. Section 7.
>
>     To support the functionality recommended above, implementations MUST
>     support the redundant encoding mechanism described in [RFC2198]
>
> For which Codecs does on need to support this?
>

Added detail on this.

>
> I. Section 7.
>
> the FEC mechanism described in [RFC5956] and
>     [I-D.ietf-payload-flexible-fec-scheme]
>
> As RFC5956 is not a FEC mechanism, only a grouping mechanism I think
> this need to be reformulated.
>

Removed that part.

>
> J. Section 9.
>
> This section needs to be clearer that an implementation is expected to
> adapt the amount of FEC to the seen packet loss rate to ensure
> sufficient protection. And that adaptation must take into account the
> available network resources (Bandwidth) to trade-off media quality and
> what streams can be sent with use of FEC.
>

That's what this paragraph says, I think, but I rewrote it a bit to try to
make this more clear.

>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Färögatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: [email-masked]
> ----------------------------------------------------------------------
>
>

---

From: Justin Uberti <[email-masked]>
Date: Sat, 09 Jan 2016 00:21:10 +0000

[fixing wrong email address]