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

From: Colin Perkins <[email-masked]>
Date: Tue, 15 Jul 2014 16:53:33 +0100

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 <[email-masked]> 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, [email-masked] 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
>> [email-masked]
>> 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: [email-masked]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

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

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Tue, 15 Jul 2014 22:15:42 +0000

There is also RFC 6865 Reed Solomon FEC.

Since there are many encoding schemes (parity/LDPC, Raptor/Q, Reed
Solomon), many encoding-dependent variants (1d/2d interleaved, ULP,
staircase, triangle, etc.) and parameters (n,k,etc.), several RTP
packetization and multiplexing options, and several SDP expressions, it
seems premature to make any sort of FEC recommendation without some more
detailed work and discussion.

So I agree with the current draft text.

Mo

-----Original Message-----
From: Colin Perkins <[email-masked]>
Date: Tuesday, July 15, 2014 at 11:53 AM
To: "[email-masked]" <[email-masked]>
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-15.txt

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

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

---

From: Justin Uberti <[email-masked]>
Date: Wed, 16 Jul 2014 23:16:08 -0400

In DC we talked about making a baseline FEC proposal using 5109. Other
variants could be added in the future, but 5109 would be MTI.

I still need to write up said proposal though, including explaining how it
works with BUNDLE (it can do so fairly easily)

---

From: Justin Uberti <[email-masked]>
Date: Wed, 16 Jul 2014 23:20:31 -0400

One thing that has come up while discussing JSEP is the need to specify
handling of DTX in the RTP usage document. JSEP allows applications to ask
for DTX, so this needs to be supported in all implementations to give
deterministic behavior.

While Opus has the ability to support DTX internally, we also need to make
sure this works with other codecs, including G.711. As a result, I think
the RTP usage draft needs to specify RFC 3389 support as
mandatory-to-implement, so that applications can deterministically enable
DTX in all cases.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 16 Jul 2014 20:57:41 -0700

Currently RFC 3389 isn't mentioned in either the RTP Usage document or in
the Audio document.  That seems strange.

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 17 Jul 2014 13:38:02 +0000

5109 uses the old FEC semantics in SDP which were deprecated by FEC-FR. No FEC-FR encoding id has been defined yet for XOR parity with ULP. So there would be a bit more work to do.

As Colin points out though, ULP gives very little (if any) bang for lots of bucks, so reusing LDPC (XOR without ULP, which is already in FEC-FR) is perhaps a better alternative.

Some (including myself) also feel XOR is often ineffective for most real-world loss patterns. It is only useful for isolated single-packet loss, which is indeed useful for very highly multiplexed links like transcontinental / transoceanic paths. But it is mostly ineffective for low stat-mux environments like access links, especially wireless which often exhibits consecutive losses. (For this reason, we use RS which is complex but provides optimal repair.)

Mo

On Jul 16, 2014, at 11:16 PM, "Justin Uberti" <[email-masked]<mailto:[email-masked]>> wrote:

In DC we talked about making a baseline FEC proposal using 5109. Other variants could be added in the future, but 5109 would be MTI.

I still need to write up said proposal though, including explaining how it works with BUNDLE (it can do so fairly easily)

On Tue, Jul 15, 2014 at 6:15 PM, Mo Zanaty (mzanaty) <[email-masked]<mailto:[email-masked]>> wrote:
There is also RFC 6865 Reed Solomon FEC.

Mo

-----Original Message-----
From: Colin Perkins <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 15, 2014 at 11:53 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-15.txt

Colin

On 28 May 2014, at 12:29, Magnus Westerlund
<[email-masked]<mailto:[email-masked]>> wrote:
> On 2014-05-28 13:21, [email-masked]<mailto:[email-masked]> wrote:
>>
>> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>>
>> [email-masked]<mailto:[email-masked]>
> Ericsson AB                 | Phone  +46 10 7148287<tel:%2B46%2010%207148287>
> Färögatan 6                 | Mobile +46 73 0949079<tel:%2B46%2073%200949079>
> SE-164 80 Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

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

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Colin Perkins <[email-masked]>
Date: Tue, 22 Jul 2014 18:57:26 -0400

The rtp-usage draft doesn’t mandate any payload formats, and instead defers to the rtcweb-audio draft. If RFC 3389 is to be mandated, it should probably be done in rtcweb-audio.

Colin

On 16 Jul 2014, at 23:20, Justin Uberti <[email-masked]> wrote:

> One thing that has come up while discussing JSEP is the need to specify handling of DTX in the RTP usage document. JSEP allows applications to ask for DTX, so this needs to be supported in all implementations to give deterministic behavior.
> 
> While Opus has the ability to support DTX internally, we also need to make sure this works with other codecs, including G.711. As a result, I think the RTP usage draft needs to specify RFC 3389 support as mandatory-to-implement, so that applications can deterministically enable DTX in all cases.
> 
> 
> On Wed, May 28, 2014 at 7:29 AM, Magnus Westerlund <[email-masked]> wrote:
> WG,
> 

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