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

Colin Perkins <> Sat, 10 May 2014 15:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C75431A000C for <>; Sat, 10 May 2014 08:56:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SwOVFmHB6Dds for <>; Sat, 10 May 2014 08:56:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D61781A000A for <>; Sat, 10 May 2014 08:56:41 -0700 (PDT)
Received: from [] (port=56206 helo=mangole.lan) by with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1Wj9dZ-0005Et-TJ; Sat, 10 May 2014 16:56:34 +0100
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Colin Perkins <>
In-Reply-To: <>
Date: Sat, 10 May 2014 16:56:31 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Bernard Aboba <>
X-Mailer: Apple Mail (2.1874)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Cc: "" <>
Subject: Re: [rtcweb] Working Group Last Call for draft-ietf-rtcweb-rtp-usage-13
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 10 May 2014 15:56:45 -0000

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