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

From: Magnus Westerlund <[email-masked]>
Date: Wed, 14 Sep 2005 16:42:21 +0200

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.

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.

3. Section 4: replace the reference to RFC 2048 with one to the now 
approved draft-freed-media-type-reg and RFC 3555.

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.

5. Section 4.1: ptime. Please reference the definition in RFC 2327 or 
rather SDP-new.

6. Section 4.1: Suggestion: Maybe having maxptime would be useful. In 
this case please reference SDP-new for it.

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.

8. Section 4.1: Restrictions on usage. This is an RTP payload format 
media type and this should be indicated in this field.

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.

10. Section 5. Having the sentence say "One optional parameter MUST" is 
not correct.

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.

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.

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