Subject: RE: [AVT] Comments on draft-ietf-avt-rtp-retransmission-06.txt

From: [email-masked]
Date: Sun, 16 Mar 2003 14:10:21 -0600

Hi Magnus,

Thanks a lot for your detailed review.
We will make the changes you recommend to the draft.

David.

> -----Original Message-----
> From: ext Magnus Westerlund [mailto:[email-masked]]
> Sent: Sunday, March 16, 2003 6:42 AM
> To: [email-masked]
> Subject: [AVT] Comments on draft-ietf-avt-rtp-retransmission-06.txt
> 
> 
> Hi,
> 
> Here is a few comments on the RTP retransmission draft I 
> think the draft 
> is in very good state and I propose that it is moved forward with due 
> swiftness. I at least has use of this format and would strongly 
> encourage authors and chairs that this draft is progressed 
> and becomes 
> an Proposed standard RFC before september. My use case would be to 
> include this in the 3GPP Packet-based streaming service (PSS) 
> Release 6.
> 
> 1. Section 4, last paragraph: "The M, CC and CSRC bit of the original 
> RTP packet MUST be copied "as is" into the RTP header of the 
> retransmission packet." I think one should change the start of the 
> sentence as the use of bit is wrong. I would propose "The marker bit 
> (M), the CSRC count (CC) field and CSRC list of the original 
> packet MUST 
> ..."
> 
> 2. Section 8.1, Third paragraph: "If multiple payload types 
> are used for 
> the original streams, then multiple "apt" parameters MUST be 
> included to 
> map each original stream payload type to a different retransmission 
> payload type." I think this is a bit unclearly formulated as 
> it can give 
> the wrong impression that multiple apt can be given for a 
> single PT. I 
> would suggest that one changes this to: "Each RTP 
> retransmission payload 
> type MUST be mapped to one and only one original payload 
> type. If there 
> is multiple original payload types, each of them needs to be 
> mapped to 
> its own retransmission payload type."
> 
> 3. Section 8.1, Fourth paragraph: "An OPTIONAL 
> payload-format-specific 
> parameter, "rtx-time," indicates the maximum time a server 
> will try to 
> retransmit a packet." I think this is wrongly formulated. To my 
> understanding the rtx-time correspond to the time that the 
> sender will 
> keep old packets in their retransmission buffer. This is also 
> formulated 
> on some other place in the draft. The above text also gives the 
> impression that a server will perform retransmission automatically. I 
> would suggest that one reformulates this to something like: 
> "An OPTIONAL 
> payload format specific parameter "rtx-time", indicates the time in 
> milliseconds a sender will keep an original packet available for 
> retransmission since its first transmission." The text needs to be 
> updated also in all MIME registrations.
> 
> 4. Section 9.1 First paragraph: I would like to add the following 
> sentence to the end of that paragraph. "The SSRC value 
> included in SETUP 
> response's Transport header SHOULD be that of the original 
> stream." This 
> makes it clear on how to use the SSRC field when doing 
> SSRC-multiplexed 
> retransmission.
> 
> 5 Section 12. With respect to the latest discussion on the aspects of 
> using SRTP and what's written in this section I would recommend that 
> some text is added to this section. I would propose to add to 
> the end of 
> the paragraph that starts "However, since ..". My proposal for text 
> would be:
> "Still as it is possible to infer a lot of the RTP fields, 
> including the 
> OSN of the retransmission payload format, it is RECOMMENDED that any 
> encryption has good properties against known plain-text attacks." I 
> would like to have some comment on this from our SRTP experts.
> 
> 6. Section 14.1 Update reference 3 to the new RTP draft. 
> Could one also 
> include [ ] around the reference numbers. I think this is clearer and 
> follows the well used IEEE way of doing reference lists.
> 
> 7. Please also look over how the page breaks falls out after editing. 
> There are definitely cases when page breaks should not be 
> allowed in the 
> middle. One such example is the author list where Rolf Hakenberg's 
> information is split over two pages. 
> 
> 
> Best Regards
> 
> Magnus Westerlund 
> 
> Multimedia Technologies, Ericsson Research ERA/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
> 
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt