Subject: [AVT] RE: Comments on draft-ietf-avt-rfc3047-bis-00

From: "Even, Roni" <[email-masked]>
Date: Mon, 21 Aug 2006 17:51:58 +0300

Magnus,
I am preparing bis-02 of the draft and noticed that I have not addressed all your comments.
See inline
Roni

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Wednesday, September 14, 2005 5:42 PM
> To: Even, Roni; IETF AVT WG
> Subject: Comments on draft-ietf-avt-rfc3047-bis-00
> 
> Hi,
> 
> I have reviewed this draft and have some comments on this.
> 
> 1. Section 3 the RTP header fields. This draft is lacking a clear
> definition for the RTP header fields that are RTP payload format
> specific or used:
> - To my understanding the RTP marker bit is used as normal for audio.
> However it does require the clarification that this applies for the
> first frame in the packet.
> - The RTP Timestamp is also not defined to be timestamp of the first
> sample part of the first frame in the payload.
> - The RTP sequence number in not necessary for RTP payload handling but
> this should be indicated.
> 
> I would recommend that one creates a sub-section "RTP Header Fields" in
> section 3.
[RE:] OK

> 
> 2. Section 3.1: This section is missing a normative statement requiring
> the frames in the payload to be consecutive. Obvious but needs to be
> indicated.
[RE:] OK
> 
> 3. Section 4: replace the reference to RFC 2048 with one to the now
> approved draft-freed-media-type-reg and RFC 3555.
[RE:] OK
> 
> 4. Section 4.1: The Media type is missing the parameter "rate" that
> indicated the sampling frequency used. "rate" is the one recommend for
> this usage in AVP.
[RE:] In this codec the sample rate can be 16khz or 32 khz while the bitrate of the data can have the values defined in the bitrate parameter. I would like to keep the name of the parameter as bitrate for backward compatibility with RFC 3047.
> 
> 5. Section 4.1: ptime. Please reference the definition in RFC 2327 or
> rather SDP-new.
[RE:] OK
> 
> 6. Section 4.1: Suggestion: Maybe having maxptime would be useful. In
> this case please reference SDP-new for it.
[RE:] OK
> 
> 7. Section 4.1: Encoding consideration. As we have discussed in the
> media types discussion for 3GPP timed text the encoding consideration
> sections should indicate that this is an "framed" media type. The
> content is also binary which should be pointed out. Modifying the
> paragraph in 3GPP timed text can be considered.
[RE:] OK
> 
> 8. Section 4.1: Restrictions on usage. This is an RTP payload format
> media type and this should be indicated in this field.
[RE:] OK
> 
> 9. Section 5: The clock rate in rtpmap shall be that of rate. And if you
> have correctly defined "rate" it will provide the limitation of 16 and
> 32 kHz.
[RE:] I do not think there is a need for a rate parameter while the bitrate parameter has a different meaning then the clock rate.
> 
> 10. Section 5. Having the sentence say "One optional parameter MUST" is
> not correct.
[RE:] Thanks, will fix
> 
> 11. Section 5.1: When it comes to offer/answer I think one should point
> out that it is the combination of "rate" and "bit-rate" that defines the
> configuration used for a particular payload type and each individual
> configuration intended to be used must be declared. If you need help
> writing something useful tell me and I will try to help.
[RE:] OK will add text
> 
> 12. Security consideration section. I would propose the following down
> trimmed version:
> 
>    "RTP packets using the payload format defined in this specification
>     are subject to the security considerations discussed in the RTP
>     specification [3], and any appropriate RTP profile.  This implies
>     that confidentiality of the media streams is achieved by encryption.
> 
>     A potential denial-of-service threat exists for data encodings using
>     compression techniques that have non-uniform receiver-end
>     computational load.  The attacker can inject pathological datagrams
>     into the stream which are complex to decode and cause the receiver to
>     be overloaded.  However, this encoding does not exhibit any
>     significant non-uniformity."
> 
> Some motivation to the changes. The formulation present in the draft
> concerning the order of encryption and encoding is not watertight and
> have made the security ADs raise comments on them. As it is not vital
> and something that happens automatically when using SRTP or IPSec it can
> be removed.
> 
> Secondly, the last paragraph is common and not specific for a RTP
> payload format. Thus it is something that shall be addressed ain other
> places than a specific payload format.
[RE:] OK
> 
> 
> Cheers
> 
> Magnus Westerlund
> 
> Multimedia Technologies, Ericsson Research EAB/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