Re: [Fecframe] I-D Action:draft-ietf-fecframe-rtp-raptor-04.txt

[Thomas Stockhammer <[e-mail]>]

Colin,

thanks for your comments:

This e-mail had been missed some time ago and I will address your comments in an updated draft to be made available shortly.

Please find inline replies to your comments:

Thomas


> - Section 4.1: explain how the RTP payload type is chosen (dynamic assignment) and signalled using SDP.

[T] Yes, this has been added as follows:

  o  Payload Type (PT): The payload type codes SHALL be assigned
      dynamically through non-RTP means.  If SDP is used for signaling,
      the the rules in Section 7 SHALL apply.


> - Section 4.1: explain how the SSRC is assigned, and how the repair RTP session is associated with the source RTP session using RTCP. They should probably be sent as separate RTP sessions, using RTCP CNAME to align, but this somewhat depends on whether the FEC is systematic or not.

[T] This has been added as follows:

  o  SSRC: The SSRC values MUST be set according to [RFC3550].  The
      SSRC value of the RTP repair flow MUST be different from the SSRC
      value of the protected source flow.

In addition, in a new section 10.3 the following is added:

10.3.  Usage of RTCP

   RTCP SHALL be used according to [RFC3550].  The repair RTP session
   SHOULD be sent in a separate RTP session and the two sessions MAY be
   associated using RTCP CNAME.


> - Section 5: "Applications that use this media type" is not specified.

[T] The following has been added:

Applications that use this media type: Real-time multimedia
   applications like video streaming, audio streaming, and video
   conferencing.


> - Section 10: the SDP is incorrect: RTP/AVT on the m= line should be RTP/AVP and the fmt is not specified.

[T] The SDP example is updated as follows:

     v=0
     o=ali 1122334455 1122334466 IN IP4 fec.example.com
     s=Raptor RTP FEC Example
     t=0 0
     a=group:FEC-FR S1 R1
     m=video 30000 RTP/AVP 100
     c=IN IP4 233.252.0.1/127
     a=rtpmap:100 MP2T/90000
     a=fec-source-flow: id=0
     a=mid:S1
     m=application 30000 RTP/AVP 110
     c=IN IP4 233.252.0.2/127
     a=rtpmap:110 raptorfec/90000
     a=fmtp:110 raptor-scheme-id=1; Kmax=8192; T=128; P=A; repair-window=200000
     a=mid:R1


> - Section 10: is the grouping using FID mandatory, or an example of how it can be done?

[T] The grouping is not mandatory, but if SDP is used then the signaling according to RFC6364 is to be used. In the introduction to the example, the following is added:

   This section provides an SDP [RFC4566] example.  Assume we have one
   source video stream (mid:S1) and one FEC repair stream (mid:R1).  The
   'group' attribute and the FEC grouping semantics defined in [RFC5888]
   and [RFC5956], respectively, are used to associate source and repair
   flows.  We form one FEC group with the "a=group:FEC S1 R1" line.  The
   source and repair streams are sent to the same port on different
   multicast groups.  The repair window is set to 200 ms.  An Explicit
   Source FEC Payload ID is used for the source flow.


> - Section 9 should probably give many more details on how the RTP headers are constructed, and how the repair flow and source flows are associated. It seems somewhat light.


[T] The section is extended as follows:

10.1.  Overview

   This document only specifies the repair flow construction when the
   repair packets are delivered with RTP.  Source packet construction is
   covered in [I-D.ietf-fecframe-raptor].  This section provides an
   overview on how to generate a repair flow including the repair
   packets and on how to reconstruct missing source packets from a set
   of available source and repair packets.  Detailed algorithms for the
   generation of Raptor and RaptorQ symbols are provided in [RFC5053]
   and [RFC6330], respectively.

   As per the FEC Framework document [RFC6363] the FEC Framework
   Configuration Information includes among others the identification of
   the repair flow(s) and the source flow(s).  Methods to convey FEC
   Framework Configuration Information are provided in
   [I-D.ietf-fecframe-config-signaling].  Specifically, the reader is
   referred to the SDP elements document [RFC6364], which describes the
   usage of 'SDP' encoding format as an example encoding format for FEC
   Framework Configuration Information.

   For the generation of a repair flow

   o  repair packets SHALL be constructed according to Section 10.2, and

   o  RTCP SHALL be used according to Section 10.3.

   For the reconstruction of a source packets of a source RTP session at
   the receiver based on the availability of a source RTP session and an
   repair RTP session the procedures in Section 10.4 may be used.



> 
> Cheers,
> Colin
> 
> 
> 
> On 25 Nov 2010, at 19:45, Thomas Stockhammer wrote:
>> Experts,
>> 
>> we also have reactivated draft-ietf-fecframe-rtp-raptor-04. Highlights of the changes compared to -03
>> - Update of authors
>> - Alignment with draft-ietf-rmt-bb-fec-raptorq-04
>> - Alignment with draft-ietf-fecframe-raptor-03
>> - Alignment with draft-ietf-fecframe-11
>> - Some minor editorial updates
>> - Updates of references
>> - A significant amount of comments from Ali are integrated in the revised version. Non-implemented comments were resolved offline with Ali
>> - Some small comments from Mike Luby on terminology are integrated.
>> 
>> Thanks to Ali and Mike.
>> 
>> I think it is time to get this out of the queue. 
>> 
>> The document should also be forwarded to AVT once we have a stable version.
>> 
>> Thanks and Best regards and Happy Thanksgivings ...
>> 
>> Thomas
>> 
>> 
>> Begin forwarded message:
>> 
>>> From: [e-mail]
>>> Date: November 25, 2010 8:30:01 PM GMT+01:00
>>> To: [e-mail]
>>> Cc: [e-mail]
>>> Subject: [Fecframe] I-D Action:draft-ietf-fecframe-rtp-raptor-04.txt
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> This draft is a work item of the FEC Framework Working Group of the IETF.
>>> 
>>> 
>>> 	Title           : RTP Payload Format for Raptor FEC
>>> 	Author(s)       : M. Watson, T. Stockhammer
>>> 	Filename        : draft-ietf-fecframe-rtp-raptor-04.txt
>>> 	Pages           : 25
>>> 	Date            : 2010-11-25
>>> 
>>> This document specifies an RTP payload format for Forward Error
>>> Correction /(FEC) repair data produced by the Raptor FEC schemes.
>>> Raptor FEC schemes are specified for use with the IETF FEC Framework
>>> which supports transport of repair data over both UDP and RTP.  This
>>> document specifies the payload format which is required for the use
>>> of RTP to carry Raptor repair flows.
>>> 
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-raptor-04.txt
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> Below is the data which will enable a MIME compliant mail reader
>>> implementation to automatically retrieve the ASCII version of the
>>> Internet-Draft.
>> <Mail Attachment>
>>> _______________________________________________
>>> Fecframe mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/fecframe
>> 
>> ---
>> Dr. Thomas Stockhammer (CEO) || [e-mail] || phone [phone] || cell [phone] || http://www.nomor-research.com
>> Nomor Research GmbH  -  Sitz der Gesellschaft: München - Registergericht: München, HRB 165856 – Umsatzsteuer-ID: DE238047637 - Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering.
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Fecframe mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/fecframe
> 
> 
> 
> -- 
> Colin Perkins
> http://csperkins.org/
> 
> 
> 

---
Dr. Thomas Stockhammer (CEO) || [e-mail] || phone [phone] || cell [phone] || http://www.nomor-research.com
Nomor Research GmbH  -  Sitz der Gesellschaft: München - Registergericht: München, HRB 165856 – Umsatzsteuer-ID: DE238047637 - Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering.