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

From: Magnus Westerlund <[email-masked]>
Date: Sun, 16 Mar 2003 13:42:17 +0100

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

---

From: José Rey <[email-masked]>
Date: Sun, 16 Mar 2003 23:00:50 +0100

Hi Magnus,

thanks for your comments. I clipped off the comments on editing and wording,

> makes it clear on how to use the SSRC field when doing SSRC-multiplexed
OK.

> would like to have some comment on this from our SRTP experts.
Yeah, a comment on this is needed . Your proposed text above names a lot of
"RTP fields", I am not sure what you mean. The only field that is
potentially send both as clear tex and encrypted is the (O)SN field. I would
limit the text to that.

cheers,

José

---

From: Magnus Westerlund <[email-masked]>
Date: Sun, 16 Mar 2003 23:26:00 +0100

>potentially send both as clear tex and encrypted is the (O)SN field. I would

Actually I was a little bit to restricted in my description. First this 
does not only apply to SRTP, but also like the DES encryption of the 
complete RTP packet. Which means that all of RTP header can be known if 
you know the entry point, for example through RTSP signaling. Then some 
payload formats has rather lot of known fields. So what I mean with RTP 
fields are both RTP header fields, and RTP payload.

I hope that this clarifies and I understand that improvements of the 
language seems to be requirement.

Cheers

Magnus Westerlund