Re: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03

["Roni Even" <ron.even.tlv at gmail.com>]

Ali,
Inline
Roni

>   2.3 You need to add the "additional information" that is in 
> the template
> probably saying none

I believe I already have "additional information: none" for each subtype.

RE- The order was different so I missed it

> 3. In section 5.2.1 it looks like you require symmetry 
> between the send and
> received stream. Is this your requirement. 

I am not sure what "symmetry" means here. Could you explain?

RE - Symmetry means that the offerer and answerer MUST use the same mode
since this exchange results in a two streams, one from each direction.
 

 
> 5. In section 5.2.2 Can the receiver just ignore the fec 
> stream, the text
> has a MUST use the configuration that is offered which can 
> hint that it MUST
> use FEC.

The receiver may decide to receive or not receive the FEC stream. If it
decides to receive, it MUST use the configuration that is provided for the
session. I guess the text is clear about this point.

RE- I think it has to do with my assumption that you can multiplex the
streams like RFC 5109

 
> 6. In section 7 you discuss an exchange using grouping. Is it 
> also allowed
> to use FEC withoutout grouping using the video or audio media 
> types like
> section 14 in RFC 5109

Per FEC framework, we require the FEC to be in a separate flow, which
requires the source and FEC streams to be on different RTP sessions. Thus,
we require grouping (RFC 4756 or 4756bis)

RE- I will have to look at that draft, this is different from RFC 5109 and
RFC 2733

BR,
-acbegen
 
> 
> Thanks
> Roni Even
>  
> 
> 
> 
> 
> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On 
> Behalf Of Ali C.
> Begen (abegen)
> Sent: Sunday, April 19, 2009 12:04 AM
> To: fecframe at ietf.org
> Cc: avt at ietf.org
> Subject: [AVT] FW: New Version Notification for
> draft-ietf-fecframe-interleaved-fec-scheme-03
> 
> This update addresses all the comments received in the WGLC 
> period initated
> on April 1st. If there are further comments, please post them 
> soon as we
> would like to move forward with this draft.
> http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interl
eaved-fec-sche
> me-03.txt
> 
> BR,
> -acbegen 
> 
> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:idsubmission at ietf.org] 
> Sent: Saturday, April 18, 2009 1:58 PM
> To: Ali C. Begen (abegen)
> Subject: New Version Notification for
> draft-ietf-fecframe-interleaved-fec-scheme-03 
> 
> 
> A new version of I-D, 
> draft-ietf-fecframe-interleaved-fec-scheme-03.txt has
> been successfuly submitted by Ali Begen and posted to the 
> IETF repository.
> 
> Filename:	 draft-ietf-fecframe-interleaved-fec-scheme
> Revision:	 03
> Title:		 RTP Payload Format for 1-D Interleaved 
> Parity FEC
> Creation_date:	 2009-04-18
> WG ID:		 fecframe
> Number_of_pages: 31
> 
> Abstract:
> This document defines a new RTP payload format for the Forward Error
> Correction (FEC) that is generated by the 1-D interleaved parity code
> from a source media encapsulated in RTP.  The 1-D interleaved parity
> code is a systematic code, where a number of repair symbols are
> generated from a set of source symbols and sent in a repair flow
> separate from the source flow that carries the source symbols.  The
> 1-D interleaved parity code offers a good protection against bursty
> packet losses at a cost of decent complexity.  The new payload format
> defined in this document is used (with some exceptions) as a part of
> the DVB Application-layer FEC specification.
>  
> 
> 
> 
> The IETF Secretariat.
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt
> 
>