Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-15.txt

Colin Perkins <csp@csperkins.org> Tue, 15 July 2014 15:53 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF27E1B2886 for <rtcweb@ietfa.amsl.com>; Tue, 15 Jul 2014 08:53:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jsh8_qL8IDDr for <rtcweb@ietfa.amsl.com>; Tue, 15 Jul 2014 08:53:39 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4221B28BC for <rtcweb@ietf.org>; Tue, 15 Jul 2014 08:53:39 -0700 (PDT)
Received: from [130.209.247.112] (port=64835 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <csp@csperkins.org>) id 1X752v-00061b-99 for rtcweb@ietf.org; Tue, 15 Jul 2014 16:53:38 +0100
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <5385C8AB.8080606@ericsson.com>
Date: Tue, 15 Jul 2014 16:53:33 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <43EF4063-F132-4A4B-BB54-871E93DF1401@csperkins.org>
References: <20140528112153.7351.96214.idtracker@ietfa.amsl.com> <5385C8AB.8080606@ericsson.com>
To: rtcweb@ietf.org
X-Mailer: Apple Mail (2.1878.6)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VUaSARexL461PySCYVkTxH8fhOU
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-15.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Jul 2014 15:53:42 -0000

As far as I’m aware, the only open issue with the RTP usage draft is whether it should make some recommendation regarding FEC. The draft currently states:

“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.”

but some people have expressed a desire that it recommend some FEC scheme. As I understand it, the possible FEC schemes are as follows:

- RFC 2733 – parity FEC; requires FEC use same SSRC as original media, so doesn’t work with bundle; abuses RTP header fields for FEC, so can’t be used with mixers

- RFC 5109 – parity FEC with uneven level protection (ULP); unnecessary complexity due to ULP; requires FEC use same SSRC as original media, so doesn’t work with bundle

- SMPTE 2022-1 – extends RFC 2733 for 2d interleaved parity FEC; sets CC, CSRC, and timestamp to zero, so doesn’t work with mixers; requires SSRC=0 and PT=96, so can’t support >1 FEC stream per RTP session

- RFC 6015 – interleaved parity FEC; abuses RTP header fields for FEC, so can’t be used with mixers; works with bundle

- RFC 6682 – Raptor FEC; works with bundle

There are IPR declarations on most of these, most have problems with bundle due to the way they use SSRCs, and some have problems with RTP mixers due to the way they abuse the CC/CSRC header fields to convey protection information. Accordingly, I don’t see a particularly good choice for WebRTC, and since we can add FEC in a backwards compatible manner in a later revision of WebRTC, my proposal is that we leave it out. However, I’m open to other suggestions.

Also, if there are other open issues with the rtp-usage draft that I’ve missed, then please let me know.

Colin






On 28 May 2014, at 12:29, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
> WG,
> 
> This version contains some changes as result of last weeks discussion.
> Especially you who wasn't there should review this to see that you agree
> with the changes proposed.
> 
> The changes are:
> 
> - Multi-stream optimization are now a MAY support, MUST signal to use.
> 
> - The T_rr_interval = 4 is now explained in
> draft-ietf-avtcore-rtp-multi-stream, so a reference has been added here.
> 
> - Signalling of extensions has been clarified to be a MUST
> 
> - The DoS potential from RTCP configuration that Martin Thomson noticed
> is now discussed and the general consideration that an WebRTC
> implementation needs safe guards among this is present. WG needs to
> consider if it needs more or are sufficient.
> 
> Cheers
> 
> Magnus
> 
> On 2014-05-28 13:21, internet-drafts@ietf.org wrote:
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF.
>> 
>>        Title           : Web Real-Time Communication (WebRTC): Media Transport and Use of RTP
>>        Authors         : Colin Perkins
>>                          Magnus Westerlund
>>                          Joerg Ott
>> 	Filename        : draft-ietf-rtcweb-rtp-usage-15.txt
>> 	Pages           : 44
>> 	Date            : 2014-05-28
>> 
>> Abstract:
>>   The Web Real-Time Communication (WebRTC) framework provides support
>>   for direct interactive rich communication using audio, video, text,
>>   collaboration, games, etc. between two peers' web-browsers.  This
>>   memo describes the media transport aspects of the WebRTC framework.
>>   It specifies how the Real-time Transport Protocol (RTP) is used in
>>   the WebRTC context, and gives requirements for which RTP features,
>>   profiles, and extensions need to be supported.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/
>> 
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-15
>> 
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-rtp-usage-15
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
>> 
> 
> 
> -- 
> 
> 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: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb



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