Re: [rtcweb] Working Group Last Call for draft-ietf-rtcweb-rtp-usage-13

[Colin Perkins <[e-mail]>]

Thanks for the comments. I just have a quick response now; a full response to the other points is coming later.


On 10 May 2014, at 00:47, Bernard Aboba <[e-mail]> wrote:
> Cullen said:
> 
> "This has RTX (RFC4588) and MUST. RTX has turned out to be close to useless in interactive communications systems because the RTT is just too high to make this viable. "
> 
> [BA] Where temporal scaling is used, RTX can be useful in protecting the base layer.  So it's not universally useless.  I do agree that MUST is too strict, though.

What the draft says is (Section 6.1):

   Receivers are REQUIRED to implement support for RTP retransmission
   packets [RFC4588].  Senders MAY send RTP retransmission packets in
   response to NACKs if the RTP retransmission payload format has been
   negotiated for the session, and if the sender believes it is useful
   to send a retransmission of the packet(s) referenced in the NACK.  An
   RTP sender does not need to retransmit every NACKed packet.

This is a little more nuanced than simply “MUST”.

> "It says FEC is not required. I’m OK with this but my notes have it as the WG previously agreed on this being required. "
> 
> [BA] Yeah, I wondered about that, too. 

The key passage from Section 6.2 of the draft is:

   There are several block-based FEC schemes that are designed for use
   with RTP independent of the chosen RTP payload format.  At the time
   of this writing there is no consensus on which, if any, of these FEC
   schemes is appropriate for use in the WebRTC context.  Accordingly,
   this memo makes no recommendation on the choice of block-based FEC
   for WebRTC use.

If this is wrong, and there is consensus on a particular FEC scheme that works with bundled media, then we can reference it.

Colin




-- 
Colin Perkins
http://csperkins.org/