Subject: [payload] FW: New Version Notification for draft-singh-payload-rtp-1d2d-parity-scheme-00.txt

From: Varun Singh <[email-masked]>
Date: Wed, 1 Oct 2014 10:34:16 -0500

Hi all,

As per the discussions in Toronto, I have submitted an initial draft
of a FEC draft. It is based on Ali's earlier draft in FECFRAME, but
adapted to align it with the bit mask used in RFC5109. This is an
initial version, the SDP in the draft has not been fixed and is most
likely wrong. It will be fixed in an upcoming version. However,
feedback on the header and source/reconstruction algorithm is deeply
appreciated.

Cheers,
Varun (on behalf of the co-authors)

> A new version of I-D, draft-singh-payload-rtp-1d2d-parity-scheme-00.txt
> has been successfully submitted by Varun Singh and posted to the
> IETF repository.
>
> Name: draft-singh-payload-rtp-1d2d-parity-scheme
> Revision: 00
> Title: RTP Payload Format for Non-Interleaved and Interleaved Parity Forward Error
> Correction (FEC)
> Document date: 2014-10-01
> Group: Individual Submission
> Pages: 39
> URL:            http://www.ietf.org/internet-drafts/draft-singh-payload-rtp-1d2d-parity-
> scheme-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-singh-payload-rtp-1d2d-parity-scheme/
> Htmlized:       http://tools.ietf.org/html/draft-singh-payload-rtp-1d2d-parity-scheme-00
>
> Abstract:
>  This document defines new RTP payload formats for the Forward Error
>  Correction (FEC) packets that are generated by the non-interleaved
>  and interleaved parity codes from a source media encapsulated in RTP.
>  These parity codes are systematic codes, where a number of repair
>  symbols are generated from a set of source symbols.  These repair
>  symbols are sent in a repair flow separate from the source flow that
>  carries the source symbols.  The non-interleaved and interleaved
>  parity codes offer a good protection against random and bursty packet
>  losses, respectively, at a cost of decent complexity.  The RTP
>  payload formats that are defined in this document address the
>  scalability issues experienced with the earlier specifications
>  including RFC 2733, RFC 5109 and SMPTE 2022-1, and offer several
>  improvements.  Due to these changes, the new payload formats are not
>  backward compatible with the earlier specifications, but endpoints
>  that do not implement the scheme can still work by simply ignoring
>  the FEC packets.
>
>
> 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.
>
> The IETF Secretariat

---

From: Colin Perkins <[email-masked]>
Date: Thu, 2 Oct 2014 17:24:47 +0100

Hi Varun,

This looks pretty nice from a quick read - I guess the goal is to be something we can reference from draft-ietf-rtcweb-rtp-usage?

I didn’t see any examples of the FEC packets produced by the protection and recovery procedures. Would it be possible to include some in an appendix in a later version of the draft? In particular, it’d be good to see how packets containing “advanced” features like CSRC lists and RTP header extensions are protected, as well as the simple cases. 

Cheers,
Colin

On 1 Oct 2014, at 16:34, Varun Singh <[email-masked]> wrote:
> Hi all,
> 
> As per the discussions in Toronto, I have submitted an initial draft of a FEC draft. It is based on Ali’s earlier draft in FECFRAME, but adapted to align it with the bit mask used in RFC5109. This is an initial version, the SDP in the draft has not been fixed and is most likely wrong. It will be fixed in an upcoming version. However, feedback on the header and source/reconstruction algorithm is deeply appreciated.
> 
> Cheers,
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload

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

---

From: Varun Singh <[email-masked]>
Date: Thu, 2 Oct 2014 11:42:17 -0500

Hi Colin,

comments inline.

> This looks pretty nice from a quick read - I guess the goal is to be something we can reference from draft-ietf-rtcweb-rtp-usage?

Thanks for reading the draft.

My recollection of the side meeting is, there would be a
draft-*-rtcweb-fec that will contain recommendations for FEC in audio
(incl. inband FEC in opus) and video. This document fixes the issues
identified with generic FEC and could be referenced by the
rtcweb-rtp-usage draft and/or by the rtcweb-fec draft.

Adding Justin to the cc, as he was leading the discussion on the FEC
draft and may have additional guidance.

> I didn’t see any examples of the FEC packets produced by the protection and recovery procedures. Would it be possible to include some in an appendix in a later version of the draft? In particular,…

I will add this in an upcoming version of the draft. Thanks again for the input.

Cheers,
Varun

-- 
http://www.netlab.tkk.fi/~varun/