Subject: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-00.txt

From: [email-masked]
Date: Sat, 14 Feb 2015 22:20:06 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF.

        Title           : RTP Payload Format for Non-Interleaved and Interleaved Parity Forward Error Correction (FEC)
        Authors         : Varun Singh
                          Ali Begen
                          Mo Zanaty
	Filename        : draft-ietf-payload-flexible-fec-scheme-00.txt
	Pages           : 40
	Date            : 2015-02-14

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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-payload-flexible-fec-scheme/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-00

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/

---

From: Varun Singh <[email-masked]>
Date: Sun, 15 Feb 2015 12:30:48 +0200

Hi,

The -00 WG version is the same as the individual version. The next
version will incorporate the feedback from the MMUSIC session.

Cheers,
Varun

On Sun, Feb 15, 2015 at 8:20 AM,  <[email-masked]> wrote:
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload

-- 
http://www.callstats.io

---

From: Fredrik Bergholtz <[email-masked]>
Date: Mon, 23 Feb 2015 12:40:35 +0000

Hi everyone. 

I am wondering if it would be a good idea to separate the SDP signalling of stream protection from the actual RTP packaging. 

We already have two, incompatible, ways to signal FEC defined in RFC 2733 and RFC 5109. It looks as if the SDP signalling in this new proposal might still be compatible with RFC 5109 even though the RTP packaging might not be. Ideally I would like to see a single RFC specifying a generic way of signalling any type of stream protection. This mechanism, which might look very much like the one in RFC 5109, will indicate what packaging scheme to use via the rtpmap attribute and the MIME type. When a device can present its capabilities in a standardised way, it will be easier to reach interoperability between devices that support several variations of FEC computation and FEC packaging.

I would appreciate feedback on this and let me know if this is something that might be possible to realise.

Best regards,
Fredrik Bergholtz
Swedish Radio

> -----Original Message-----
> From: payload [mailto:[email-masked]] On Behalf Of internet-
> [email-masked]
> Sent: den 15 februari 2015 07:20
> To: [email-masked]
> Cc: [email-masked]
> Subject: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-00.txt
> 
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 23 Feb 2015 12:46:48 +0000

You have a point, but I dont think we will ever have a single FEC 
signaling mechanism and then bunch of RTP payloads. First of all you 
should not care about 2733 as it has broken stuff in it wrt current RTP. 
As the current draft will not be much aligned with 5109, it will be better 
to contain the RTP format and signaling in a single document (you cannot 
have only one, you need both at all times).

-----Original Message-----
From: Fredrik Bergholtz
Date: Monday, February 23, 2015 at 2:40 PM
To: "[email-masked]"
Subject: Re: [payload] I-D Action: 
draft-ietf-payload-flexible-fec-scheme-00.txt

>Hi everyone. 
>
>I am wondering if it would be a good idea to separate the SDP signalling 
>of stream protection from the actual RTP packaging. 
>
>We already have two, incompatible, ways to signal FEC defined in RFC 2733 
>and RFC 5109. It looks as if the SDP signalling in this new proposal 
>might still be compatible with RFC 5109 even though the RTP packaging 
>might not be. Ideally I would like to see a single RFC specifying a 
>generic way of signalling any type of stream protection. This mechanism, 
>which might look very much like the one in RFC 5109, will indicate what 
>packaging scheme to use via the rtpmap attribute and the MIME type. When 
>a device can present its capabilities in a standardised way, it will be 
>easier to reach interoperability between devices that support several 
>variations of FEC computation and FEC packaging.
>
>> Subject: [payload] I-D Action: 
>>draft-ietf-payload-flexible-fec-scheme-00.txt
>> 
>> 
>>  This draft is a work item of the Audio/Video Transport Payloads 
>>Working Group
>> of the IETF.
>> 
>>         Title           : RTP Payload Format for Non-Interleaved and 
>>Interleaved Parity
>> Forward Error Correction (FEC)
>>         Authors         : Varun Singh
>>                           Ali Begen
>>                           Mo Zanaty

---

From: Fredrik Bergholtz <[email-masked]>
Date: Mon, 23 Feb 2015 14:40:52 +0000

The problem is that I do have to worry about RFC 2733 as well as the new approaches since we are being forced to use legacy equipment that won't be upgraded quickly enough. 

I realise that we will have to live with the issues of 2733 vs 5109 but I am worried that adding a new packaging mechanism without acknowledging that the new will have to co-exist with the old, at least for a time, will make things worse rather than better. Especially when the new involves non-backwards compatible changes. 

Without a generic signalling mechanism I foresee a lot of problems getting FEC to work well in a production environment.

Best regards,
Fredrik Bergholtz
Swedish Radio

> From: Ali C. Begen (abegen) [mailto:[email-masked]]
> Sent: den 23 februari 2015 13:47
> To: Fredrik Bergholtz; [email-masked]
> Subject: Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-00.txt
> 
> You have a point, but I dont think we will ever have a single FEC signaling
> mechanism and then bunch of RTP payloads. First of all you should not care
> about 2733 as it has broken stuff in it wrt current RTP.
> As the current draft will not be much aligned with 5109, it will be better to
> contain the RTP format and signaling in a single document (you cannot have only
> one, you need both at all times).
> 
> 
> 
> >I am wondering if it would be a good idea to separate the SDP
> >signalling of stream protection from the actual RTP packaging.
> >
> >We already have two, incompatible, ways to signal FEC defined in RFC
> >2733 and RFC 5109. It looks as if the SDP signalling in this new
> >proposal might still be compatible with RFC 5109 even though the RTP
> >packaging might not be. Ideally I would like to see a single RFC
> >specifying a generic way of signalling any type of stream protection.
> >This mechanism, which might look very much like the one in RFC 5109,
> >will indicate what packaging scheme to use via the rtpmap attribute and
> >the MIME type. When a device can present its capabilities in a
> >standardised way, it will be easier to reach interoperability between
> >devices that support several variations of FEC computation and FEC packaging.
> >
> >I would appreciate feedback on this and let me know if this is
> >something that might be possible to realise.
> >
> >Best regards,
> >Fredrik Bergholtz
> >Swedish Radio
> >
> >
> >> From: payload [mailto:[email-masked]] On Behalf Of
> >>internet-  [email-masked]
> >>Working Group  of the IETF.
> >>
> >> 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.
> >>