[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03
Thanks for the review. See inline.
> 1. In section 1 you reference RFC2733, I think it was
> obsolete by RFC 5109 ,
> do you need this downref?
Yes, this has been already discussed within fecframe and with Magnus. We give an informative reference as we are using an extension of the header RFC 2733 had.
> 2. In the registration section 5.1, the comments applies to
> all subtypes:
> 2.1 You have for security considerations and published
> specification
> "this document" it is better to write RFC xxxx and have a
> note to the
> RFC editor to replace it with the RFC number allocated, this
> will show in
> the IANA registry with the write pointer.
Will do.
> 2.2 In the restriction on usage I assume that the document
> is using RTP
> framing and is not specified for other types, if this is the case it
> should say so. E.g. " This media type depends on RTP
> framing, and hence is
> only defined for transfer via RTP [RFC3550].
> Transport within other
> framing protocols is not defined at this time"
Will do.
> 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.
> 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?
> 4. In section 5.2.1 can the answerer send a response with no
> FEC at all even
> if not offered.
If the answerer does not want FEC, yes, it can drop FEC from the offer. Let me make that clear in the text.
> 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.
> 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)
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
>
>