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

From: Magnus Westerlund <[email-masked]>
Date: Thu, 5 Nov 2015 16:14:17 +0900

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.

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.

C. Section 4.2

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

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?

E. Section 5.2, first paragraph:

This section needs clearer references to SDP.

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.

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.

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?

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.

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.

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]
----------------------------------------------------------------------